How to hire force multipliers (not 10x engineers)

You have 1 article left to read this month before you need to register a free LeadDev.com account.

Estimated reading time: 11 minutes

Hiring a “brilliant jerk” fixes almost nothing. Instead, focus on hiring those engineers who make the whole team 10x. 

The tech industry loves the tale of the 10x engineer. A mythical beast that can carry the weight of a scrum team and close tickets faster than ChatGPT can spit out flawed code – all at 2 am on a Friday.

In reality, it’s more like Founder of Technical Accounting Christine Miao’s description of working with this fabled creature:

• “As he shipped fast, he broke things and made technical debt worse. His velocity often came at the expense of the rest of the team – who were left cleaning up his mess (and trying to figure out what he did). 
• He was constantly fighting the very issues he created. He was often the only person who could fix his non-standard, convoluted, problematic code. 
• Not only did he make a culture of constant firefighting normal, he was constantly creating more mess. The chaos didn’t even stop on weekends!”

These usually self-identifying 10x engineers – very quick to brag about their heroism – are often promoted from within, while frustrated, hardworking teammates quit. All while code quality and reliability continue to plummet. 

But the problem isn’t the engineer. It’s the industry that lauds this brilliant jerk which Nivenly Foundation fellow Hazel Weakly defined as a “walking liability that damages everything they touch,” during her LDX3 London talk, So you want to hire engineering force multipliers?

Instead, companies should be looking for what Weakly calls a force multiplier, who can support the development of a 10x team. 

Because, she continued, “brilliance is a property of a collective group of people.”

This realization, however, doesn’t make it easy to spot a force-multiplying engineer – especially within traditional tech hiring processes. That’s why Weakly shared a job profile definition and recruitment considerations at LDX3 London to aid organizations in spotting, recruiting, enabling, and retaining force multipliers pursuant to shared brilliance. 

It’s about multiplying the team force

“The smallest unit of software ownership and delivery is the engineering team.” Charity Majors, CTO of Honeycomb, argues in her work, “In Praise of ‘Normal’ Engineers.” She’s not speaking in isolation. The whole DevOps movement kicked off with a focus on team-level autonomy and effectiveness, and the recent push to measure developer productivity emphasizes the team being the deepest level metric to quantify. 

It’s a wasteful breach of trust to focus on “improving” the individual. As Majors pointed out in the same article, an engineer with all that individual ownership quickly becomes a single point of failure. Sure, someone has the potential to be 10x at a particular skillset but she writes that they are “still going to have infinitely more areas where they are normal or average (or less.)”

Software engineering is inherently a team sport, as engineering leader Kate Heddleston pointed out in her 2018 piece Becoming a 10x Developer. “When I first heard the concept of the 10x engineer, I was confused. How could someone be so talented that it overshadows the power of teamwork?”

A 10x engineer, therefore, isn’t someone who is 10 times better than those around them, but someone who makes those around them 10 times better.

Heddleston offered 10 research-backed ways to be a better teammate: 

1. Create an environment of psychological safety.
2. Encourage everyone to participate equally.
3. Assign credit accurately and generously.
4. Amplify unheard voices in meetings.
5. Give constructive, actionable feedback and avoid personal criticism.
6. Hold yourself and others accountable.
7. Cultivate excellence in an area that is valuable to the team.
8. Educate yourself about diversity, inclusivity, and equality in the workplace.
9. Maintain a growth mindset.
10. Advocate for company policies that increase workplace equality.

This 10x teammate supports the growth and development of 10x engineering teams.

“A truly great engineering org is one where you don’t HAVE to be one of the ‘best’ or most pedigreed engineers in the world to get shit done and have a lot of impact on the business,” Majors wrote. “It is a HUGE competitive advantage if you can build sociotechnical systems where less experienced engineers can convert their effort and energy into product and business momentum.”

What do force multipliers actually look like

Weakly provided the three dominant characteristics of these force-multiplying engineers: cumulative culture, intellectual humility, and ecological awe.

Firstly, these teammates exhibit an appreciation of cumulative culture. This concept explores the idea that nobody builds from scratch. Whether it’s a brownfield codebase or, as Weakly put it, how humanity has gone from banging rocks together to landing on the Moon, we work together across history in the name of cumulative progress.

“Humans are really good at copying and mimicking and doing together. And so one of the huge ways of force multipliers is people that create and facilitate these cumulative cultures,” she said during her LDX3 talk. Facilitating an environment of “Oh, that’s a great idea. I’m going to do this. I’m going to share that. Let’s put this together.” Before you know it, you’ve gone from a couple of ideas on a whiteboard to a value-driving rocket ship with the whole team on board.

These engineers tend to keep an eye out for innovation, learning, and continuous improvement. And give credit where it’s due. 

Because they value collaboration, Weakly noted, these engineers aren’t usually the ones burnt out from trying to do everything, and they aren’t wasting time bragging about all their solo accomplishments. Instead, they are humble.

Intellectual humility is the second quality to look for in a force multiplier. “Someone who is really, really good at learning, is really good at contributing to things, and then, most importantly, is never losing sight of the job that everyone can do,” she said. This person is “open-minded, and they’re able to be accepting of new actions and to contribute and be humble.”

These engineers work well with other developers and engineers at all levels of experience, Weakly continued, because they never forget that everyone can know something, leaving them more open to others’ ideas.

Sure, some people can seem like a genius in isolation. What distinguishes someone as a force multiplier is their ability to work within the organizational context. 

Weakly calls this last trait ecological awe. Like how a gardener takes a holistic view in order to optimize for growth speed and bloom timing, an engineering force multiplier respects the organizational ecosystem, understanding its interdependencies within their team and across their company. 

Of course, now that you know what force-multiplying signals you’re looking for, it’s not easy to attract that profile if your current engineering recruitment isn’t set up to find them.

Creating an intentional engineering interview process

The industry must focus, as Majors wrote, on shifting focus away from “hiring the BEST PEOPLE and realigning around the more reasonable and accurate RIGHT PEOPLE.”

This journey of meaningful hiring starts with the tech job interview(s).

Weakly tasked the LDX3 audience with writing down their favorite system design interview questions, offering the perennial favorite: How would you approach splitting up a monolith?

Then break it down into two questions:

• What is a cultural approach to this?
• What is the technical approach to this?

For each, she recommends writing down one positive indicator that shows the candidate knows the answer, and one indicator showing that they can spot when things go awry. Then ask for their reasoning behind each.

Take the cultural shift needed to break up a monolith. A strong answer from a candidate might highlight the need to fix communication gaps between teams. When they’re explaining their reasoning behind the suggestion, look for answers that touch on how communication imbalance means losing the context of a single codebase, which is often the driver of failure in a move to microservices. On the flip side, a red flag might be rolling out process changes without explaining the context. If teams don’t get the “why” they’ll bypass the process, and that hampers productivity. 

Compensate for biases within interviews

Once you design a sociotechnical interview, examine it for biases. 

Especially when interviewing for the social demands of this role, Weakly says this varies by socioeconomic background. 

“If you are from a marginalized environment, you will probably favor demonstrating social cognition via a cultural process,” she said in her talk, while “if you’re from a privileged background, you would probably tend to favor a technical process.”

“If we design the interview to only look for people that solve the problem by…throwing code or throwing anything else at it, it doesn’t matter how well your interview is designed. It is selecting for people that grew up in a privileged background,” which means, Weakly said, you aren’t hiring for force multipliers because “impact requires technical and cultural problem solving skills.”

This isn’t just anecdotal, but rather, there is large-scale potential for class biases across hiring practices at large tech companies. And it’s been long realized that sexism is a feature, not a bug, throughout tech hiring.

As Weakly pointed out, some hiring managers and team leads look for the use of “we” to signal collaboration, but then when they use “we” a lot, women aren’t considered assertive enough or more distant from the work their teams accomplished, while “I” from a woman can be perceived as selfish and unwelcoming. 

Your interview process should compensate for bias, including gender disparity and non-native English speakers. This includes not using potentially confusing terms, like positive and negative indicators. Instead, approach the interview as a conversation that puts everyone more at ease.

Before, it was: How would you approach splitting a monolith? After, it becomes: “Let’s work together and examine the process of splitting a monolith. How would you approach this culturally and technically? Let’s focus on the human elements first.”

Weakly explains how it’s all about “giving all these cues and indicators,” and clarifying the form and expectation of what you hope to get out of a successful interview.

We can’t forget that we want to make tech interviews suck less because we want to make sure candidates feel like they can do their best. 

Continuous improvement to debug your tech interviews

Hiring force multipliers, paradoxically, doesn’t just stop after interviews. It extends throughout the entire employee lifecycle.

“You really got to double check your work particularly when you’re hiring force multipliers because these are people that do not go cleanly into your career hierarchy,” Weakly said. “They’re usually the people that do not clearly map to requirements for being promoted,” either.

• Do men only pass the technical interview?
• Does the system interview weed out non-native English speakers?
• Do you primarily hand out offers to one demographic?
• Do the hires you regret making follow a predictable pattern?
• Are you hiring people from groups that make it only to a certain point?
• When you hire from certain groups, do you find that they don’t last more than a year?

Remember that writing a better tech interview isn’t a one-off endeavor. You’ve got to experiment a lot, Weakly said, and especially dogfood it on your own team. Famously, some technical interviews can’t be passed by those already in the role.

Your team should be able to pass the interview without any problem and bring insights into the indicators from the perspectives of their roles.

Just don’t get too fixated on AI. 

The vast majority of engineers are now going to use generative AI in their workflow. So why ban it from technical interviews?

The main argument here is that by using generative AI, just like they used Stack Overflow before, candidates are just going to get really good at parroting back answers that pretend to be knowledge. 

To avoid this, Weakly recommends not banning AI, but instead asking questions that don’t have answers. “If people sound like they know everything, change the question.” She continued, “Look for factors that are impossible to game.”

In a follow-up interview, Weakly clarified that questions really become conversations. Of course, anyone could type “how would you split a monolith” into a chatbot and read its response, but, she said, “The signal actually happens when the interviewer digs deep and asks follow-up questions about why they answered the way they did,” not whether the answer was right or wrong.

The generative AI interface may have suggested “use microservices and test-driven development,” but the interviewer doesn’t need to waste the conversation on asking about the benefits of microservices. Weakly instead recommends asking something like, “How would you go about determining whether or not a migration to microservices would be successful at a company?” or, “How would you help teams work effectively with microservices?”

You don’t want to waste an interview on information regurgitation when you can learn how a candidate could help an organization operate better.

If you love working with them, it won’t matter if they use AI or not. And a force multiplier – unlike most self-proclaimed 10x engineers – is someone people actually love to work with.

“Remember: 10x engineers don’t exist but engineers have helped build 10x engineers,” Weakly emphasized to close out her talk. “When I’m thinking of force multipliers, I am not multiplying myself. They are multiplying the team. Which means they have to be really, really good at this distributed cognition, and this ability to take the collective ways of working of the entire team and make it better, happier, and healthier for everyone.”