Engineering Teams Are Just Networks

To be a great hiring manager don’t be distracted by rockstar engineers, study up on network theory.

As a manager I like to build teams out of spare parts. I hire candidates who are rejected from other pipelines, I pick up people with middling performance in other teams, sometimes I even hire people whose skills are weak or out of date. My proudest accomplishments all involve teams constructed in such a manner completely out performing best-of-the-best rockstar teams assembled elsewhere. I’ve often struggled to explain how I tell the difference between a diamond in the rough and a mediocre software engineer. It’s an instinct.

But that’s a terrible answer because in hiring the line between instinct and bias is razor thin.

Recently, I was watching an interview with network theorist Damon Centola and he made a comment that hit me like a bolt of lightning:

“People always want to talk about the characteristics of a node that lead to success but the position in the network is much more important.”

And I thought “Holy shit, that’s it. That’s what I’m looking at.” Engineering teams are networks, you need to hire based on the shape of the network.

Baselines and Contagions

Eventually I’ll release a much longer, more in depth, piece of writing about this idea (possibly a follow up to my screed Hiring Engineers) but while I’m working on that I wanted to outline the basic concept, because at the…