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 core of it is an assertion that many will find difficult to get used to:

After a baseline level of competency is satisfied, who you hire does not matter.

Of course competency includes both technical characteristics and EQ characteristics, but … yeah … once you’ve filtered on technical qualifications and removed toxic personalities, you can choose a candidate at random and have a successful hire.

The trick is figuring out what that baseline of competency should be. It is determined by the shape and structure of the network and is not static, but it’s not arbitrary either. The features that will lead to a successful hire are the features that can form advantages out of the structural incentives surrounding the position, those structural incentives are determined by the network the team forms internally and how it connects to other teams as part of a larger organization.

Let’s say for example I have a world class SRE in my pipeline, but this world class SRE’s deepest, most valuable expertise is in a technology my organization does not use. If we chose to hire this once in a lifetime talent, what are their pathways to success?

• They can encourage adoption of their preferred technology, thereby fully playing to their strengths
• They can take the opportunity to learn and deepen their expertise in a different set of technology already in use

The latter scenario is an EQ assessment that a well structured interview loop should give the hiring manager some feedback on — Is this candidate even willing to learn new things? And how easy/hard might that be for them?

The former scenario is a straight up complex contagion problem from network theory. If we hire this rockstar SRE and they successfully encourage adoption of their preferred technology, then their expertise can be fully maximized. If they can’t get adoption then we could have hired an SRE with less expertise and gotten the same value. If they can’t get adoption and also resist building new skills by learning the existing technology then they might even prove to be dead weight on the team and we would have been better off not hiring anyone at all. The question of how likely it is that the preferred technology can get traction determines the baseline competency I’m hiring for with my open SRE headcount. If adoption is unlikely then my baseline is low: our expert SRE’s expertise does not make them more valuable than an average SRE. If adoption is likely and my desired outcome then my baseline is high: the stronger that expertise the more valuable the candidate is.

Complex Contagions and Network Structure

Network theory predicts the ease or difficulty of something spreading among a group by looking at how people are connected to each other. These are called “contagions” for obvious reasons. A simple contagion is something that requires only one exposure to spread. In social theory simple contagions are typically just information. If I hear a conspiracy theory I might believe it or not believe it but I only need to hear it once to know about it.

With complex contagions transmission requires the right conditions. It could take multiple exposures, but the number of exposure could be influenced by assessment of risk. Or it could be a matter of the ratio of positive to negative exposures (ie: reading three positive movie reviews won’t help if you also read six negative ones). Anything connected to belief and behavior is usually a complex contagion. Knowledge of a conspiracy theory is a simple contagion, belief in it is complex.

Adopting a new technology is definitely a complex contagion. While simple contagions spread best across networks where there are lots of weak ties connecting different groups, complex contagions spread best across networks with what are called wide bridges. Rather than a single contact between groups, a person from group B is connected independently to two or more people from group A.

Let’s say for example we have two engineering teams with three engineers and one manager each. The manager from the blue team used to work with engineer 2 on the pink team and they maintain a relationship. The two managers are direct colleagues and therefore they also maintain a relationship.

If we want to spread information between these two teams the best person to activate with the information are the managers, their relationships link the two groups and they are also connected to everyone on their team. But if we want to encourage the adoption of new technology, we need to activate both a manager and engineer 2. If two exposures is enough for the complex contagion to spread, then the relationships between the managers and the pre-existing relationship between the manager and an old teammate create a bridge.

Network Structure as Incentives

We can talk about contagion complexity in the language of incentives too. Without knowing anything about the team they are being hired into, how can we figure out how easy it will be for our rockstar SRE to spread adoption of their preferred technology?

If I asked you to estimate the probability of adoption you’d probably start with looking at who knows the technology already, or at least who is interested in it. Does the rank of these people make a difference on your probability estimate? Are senior managers more valuable than rank and file engineers?

Or you might consider whether adopting a new technology involves migrating away from an existing solution. Then you might think about who will be required to do that work and use how much of a burden the migration will be on them as an estimate of the barriers to adoption and therefore probability of success.

We’re talking about incentives here, but it’s not difficult to spot the network dynamics. Support from senior managers is valuable, but a project with a mix of senior management support and engineering support is most likely to be successful because it creates wide bridges across engineering teams. We can think of willingness to do the work of migration as itself a complex contagion and reason about the challenge as a dependency tree of contagions.

Without understanding network theory, we still understand that if our expert SRE is coming in having worked with people on our team before, their odds of successfully promoting adoption of the new technology are much greater than if they are a stranger. If I asked you how likely a shift to kubernetes was to succeed if all the advocates for doing it were on the same team, you do not need to know network theory to understand that real traction needs supporters outside a single group.

Network theory is just talking about incentives in the passive voice.

We have a sense of these dynamic as we build teams, we are just not used to expressing our feelings about staffing decision in this language. When we lack the language to talk about complex concepts, we frequently default to simpler abstractions.

So what’s a simpler abstraction than looking at the open position within the context of a network of people? Treating every position as equal in context. If every position has an identical context then skill is the only difference between nodes. That’s how we end up with the assumption that extremely high standards is the pathway to building successful teams.

And that strategy fails because it is rarely the case that two nodes have exactly the same context in a network and it is never the case that all nodes have the same context.

Missed Opportunities

If you want to hire well, have modest baseline of minimum qualifications and think of your engineering organization as a network.

Most hiring managers incorrectly assess the risks of hiring decisions. They are overly concerned with missing high caliber talent because they spent their open headcount on an okay talent and ignore the consequences of running a team over capacity and short staffed well they wait for their perfect hire. It’s true that hiring the wrong person is painful, but you don’t minimize the odds of that by making the hiring standards harder (especially not the technical standards). In my experience when people do not work out it’s often because they are not actually set up for success. Their strengths do not align with the incentives the network creates or network structures play into their weaknesses.

If you have a rockstar engineer in your pipeline, by all means hire them. But many teams fail because they spend months rejecting good hires in favor of a flashy candidate who cannot succeed.