Partners in Crime

/ San Francisco, California

In videogame design there’s the concept of ‘the loop’ – a pattern that a game has been designed around. You shoot, you drive, you jump. There’s a finite number of things you can do in a world, and the real videogame design magic is the order in which you let a player experiment with those mechanics. A game isn’t a good one if it has jumping, shooting, or driving, but instead it’s good if the order of those actions makes sense and is constantly surprising.

Or so the theory goes.

But when it comes to software development there’s a different kind of loop and it (mostly) works like this: an engineer will sit in a team of a dozen or so people, and after they’ve typed with their headphones on silently for a couple of hours alone, they’ll send someone a tiny bit of code to review once they’ve finished. They’ll wait for automated tests to pass, they’ll maybe have another round of reviews and then once everything checks out, their code will be published.

And after working on an engineering team for the last 3 years I’ve come to the conclusion that we got this all wrong. Well, the structure and organization of software development anyway. Here’s why:

It’s clear to me that software shouldn’t be built or designed like this. A lone genius isn’t the right way to think about an engineer and it appears to me that working alone is the worst possible way to build complex applications.

So how do we structure a team instead? How should we think about the relationship between engineers?

Well, I think we should take inspiration from, of all places, detectives. Each engineer should be seen as one half of an investigative unit; on the first day on the job they should should be assigned a partner in crime that they sit next to everyday and work on the same problems together. And my experience here is perhaps a bit limited but every moment of intense productivity I’ve experienced is when I’m paired with someone and our skills overlap slightly but we’re at opposing ends of a spectrum.

That’s when things really fly.

And the more I think about this way of seeing an engineer – not as an individual, but as one of a pair – the more I believe this should be how eng teams are organized. There’s so many reasons why this works better! And lately this happened to me – I’ve paired with an engineer everyday for the last three months and I’ve noticed so many improvements over the lone wolf model:

So today we’ve built our engineering teams around missions or features or pods – giant clumps of engineers that sit next to each other everyday but work almost entirely in isolation – and I think that makes things easy for management and org structures but it makes things so much harder for capable engineers to get good work done.

I think we’ve built these teams in service of managers and not what the work requires of us.