How to Lead the Mystical 10x Engineer 🦄

Many tales have been a-written of the unicorn developer that rescues failing projects with heroic code, fueled by redbulls and a disdain for the status quo.

I’ll take this opportunity to break down how to work with a 10X engineer, because lets face it, whether they are 10X or not, we all have to deal with difficult folks in the work place.

What is 10x Anyways?

An engineer that produces 10 times more code or features than any other person on the team is by “definition” a 10x engineer. Rumor has it, these rare breeds don’t like meetings, documentation or showing up to the office (or Slack) for that matter. Woe is me, what is a manager to do?

This individual is likely a high performer, and was inducted into the team because they had some merit during the interview process and seemed like a good person to work with; or maybe they just passed the tech interview gauntlet so they have skills, therefore we must hire them, right?

Let’s dissect this first. How do we identify 10x behaviors and do we even want that on our team?

Interviewing a 10x Engineer

I’m not going to make assumptions about your technical interview process. I trust that you test for the right skills. What I want to introduce however, is a behavior based technical interviewing method that may shed some light on *how* a potential candidate will *behave* once they are on the team. It’s not perfect, but it is a signal that you and the interviewers can weigh in on when evaluating candidates.

Code Review a Take Home Project

One of the most important things we do as software developers is communicating our code. Reviewing code uncovers potential bugs, requirements gaps, and transfers knowledge across the team. Code reviews can also turn into a hostile battleground if not approached lightly. Think about it, with the wrong context a review comment can come across as harsh or tone deaf. Asking an interviewee to produce working code in their own environment, and then submitting a pull request where the team is able to review code together, is a great way to determine how the candidate accepts or denies feedback.

Structuring Code Review Feedback

Have a team member candidly identify an area for improvement on the interviewees code and see how they respond. Behaviors to look out for are:

• Defensive comments indicating the code is good. This isn’t necessarily a bad behavior. It is important to set the context, and allow for healthy debate. The key behavior to extract is whether or not the interviewee can stand with conviction and get the buy in needed from the team. Code is code, but the entire team shares ownership of it, therefore it is important that everyone understands it and agrees with it.
• Stating opinions as fact. 10x engineers may have a way of doing things. Be very careful of bombastic comments. There are multiple ways implement a feature, and it is important to identify individuals that can state opposing architectures that solve the same problem.

Producing Documentation

Associated with the take home project, should be some documentation describing what has been implemented. In the real world, the person who implements a feature isn’t necessarily the person who is maintaining that feature in the future. A wiki or readme is lightweight and indicates that the interviewee is thinking about the team and the future value of the code.

If documentation isn’t supplanted, it might be a good area to probe during the interview.

• Can you describe why was there no associated documentation?
• What would you do differently if you received code that you did not understand?
• How do you feel about documenting code that is already “self documenting”?
• Can you tell me about a time you implemented something, but it wasn’t understood by future maintainers?

We are ultimately probing for the behavior that the interviewee is an effective communicator, inside and outside of the IDE.

Situational Teamwork Questions

Highly cohesive teams ship together. The final hours of important projects usually require a high degree of coordination and sometimes a little bit of overtime that can lead to emotional flares. We want to understand if the interviewee has been a part of collaborative environments where project pains are shared, but project successes are celebrated in an even grander fashion.

• Can you tell me about a time where you helped deliver a feature that was not on schedule? Who did you have to work with, and how did you accomplish this?
• Tell me about a time when you were working with someone on the team and you disagreed on an approach?

It is important to look out for real life examples about what the interviewees role in the situation was, how they behaved, and what the outcome was. Good interviewers can probe and ask deeper questions to find out why.

Assessing The Results

So 10x engineer number one passed the technical interview gauntlet and survived the behavior-culture interview. How do you know if they are the right one? A few points help me calibrate:

• Can I learn from this person? Will they make me smarter? Will they make the team smarter?
• Do I want to share late night meetings with this person in the off-case when times are tough? Will they make me calmer or more anxious?
• Do they care about the company or product as much as I do? Will they make the right decision when designing new features or architecture?

Ultimately, it is up to the team to decide whom they induct, however, sharing feedback amongst the panel and debating these points help uncover some “intangibles” that may make the decision making process a bit more data driven.

Working With a 10x Engineer

Your job as a manager is to set expectations. If a team member is misbehaving with brilliant jerk shenanigans, it is your job to remediate. Shipping features at 10x speed at the cost of team morale is much worse in the long run.

Debugging Common Brilliant Jerk Behaviors

“I don’t document my code because it is self-documenting”

This can be quickly countered by having a private 1:1 discussion explaining why documentation is good and shifting the conversation towards career improvement. A few points:

• Good documentation explains why code was written and serves as an artifact for future developers to understand the headspace you were in when writing the code. Often times, your intention in the beginning of the project is much different than the goals of someone taking over that code at the and of a project.
• Helping others learn with good documentation increases your political capital, and REALLY makes you a 10x engineer. The sum is greater than each individual part.

“I don’t go to status meetings because they are a waste of time”

• Meetings are not for you. Meetings are not for the boss, either. Meetings are for everyone else in the room who need to know a piece of information that will make them better at their jobs.
• By explaining why they were chosen to be in the meeting, because their input is highly valued is an honor, and a testament to their 10x status. Make others better by sharing feedback.
• As a manager it is also important to prune unnecessary meetings. If 10x’er is not needed, it is your job make sure you protect their time.

“Billy’s code sucks. I’m going to re-write it.”

• This is a mentorship opportunity to truly be 10x. If Billy’s code is not up to par, us constructive language to privately discuss where it can be improved. By helping Billy get better, the overall codebase gets better, and Billy will get faster, and eventually everyone moving at high speed will move faster than a lone 10x’er.
• If negative comments have already been disparaged it should be made clear, publically, that criticizing using un-constructive language is not acceptable. Public feedback is usually reserved for praise, however toxic behaviors must be made known immediately.

Mentoring a 10x Engineer

These rules apply to anyone, not just a 10x engineer, however it is important to note that I am making the assumption that your organization already pays competively. It is a tough world recruiting against MFAANG companies that offer great salaries and benefits, so securing the basic necessity for top engineers to put food on the table, and enjoy their lives is a must.

Offer Growth & Learning Opportunities

The upper echelon of most high performers are infinite learners. This is the secret to success. Having a growth mindset and improving constantly is how the 1% get to the top. As a manager, identifying training opportunities for the 10x’er will help improve the skillset on the team, and allow them to teach these new skills to the rest of the organization. The latter is a growth opportunity in the sense that everyone can improve their teaching and public speaking abilities.

Offer Growth & Learning Opportunities

Instead of going rogue and coming up for air once something has been furiously coded, providing guidance and the support structure to allow a 10x’er to lead a project will not only make their work transparent, but give them a platform to showcase their abilities and deliver results. It is highly likely that this individual can deliver, so as a manager keeping track of their projects and offering to be a sounding board and unblocking red tape can go a long way in ensuring project management success.

The Team Matters Most

Working with a 10x’er while slightly more nuanced, is no more different than the rest of the team. Continuous improvement is the goal. If the team can do this by self policing each other, everyone wins.

For more articles, tools and guidance on software leadership subscribe to my newsletter, Sheehan on Shipping.