OM76
Writing

Why Asking for a 10x Hire Signals a Management Issue, Not an Employee Issue

Ani Achugbue 12 min read

The statement “we need a 10x hire” is not a plan. A lot has been written on the reality of this statement, and to be honest, debating whether a 10x hire is possible is a waste of time. You could if you like read and review the mountain of research and articles that argue both sides, but regardless of where you start, you will eventually arrive at the same conclusion. As a practical approach to a real problem, the statement is not a viable plan.

Surprisingly, what does work is the sentence itself as a signal, which brings to light something very specific the moment it leaves a leader’s mouth. It names a perceived output gap and routes the fix away from the conditions that produced it. Every time a leader says “we need a 10x hire,” they are skipping the reflection their job requires of them, which is to ask why a team they are responsible for is underperforming. And underperforming so badly that a 10x hire is even conceivable.

This is the hero-vs-systems pattern that has plagued tech for decades. A label that lets a leader avoid looking at the system they are accountable for. Hearing “we need a 10x hire” out loud should be a trigger for management, specifically upper management, to have a difficult conversation about what they think is happening with their team versus the reality.

Where the Idea Came From

The “10x developer” idea has a citation history worth knowing, because the original numbers were interpreted incorrectly from the moment they left the lab.

In 1968, a study by Sackman, Erikson, and Grant, published in Communications of the Association for Computing Machinery (Communications of the ACM), compared twelve programmers on a single programming task. The famous “28-to-1” ratio that gave the trope its name was the comparison between one subject programming in ALGOL (ALGOrithmic Language, a high-level language of the era) and one subject programming in machine language. That is a tool-and-language finding, not an individual-talent finding. Every subsequent writer who cited the 28-to-1 number stripped the methodology caveat and presented it as raw individual variance.

Laurent Bossavit, in The Leprechauns of Software Engineering, documents the forty years of mis-citation that followed. By the time the number reached 2000s management literature, the original ALGOL-versus-machine-language confound had been quietly erased. What arrived in the boardroom was a clean “individual programmers vary 10-to-1.” The final catch phrase that would live on was not insight from a study but a single mis-cited footnote.

Steve McConnell, at Construx, defends the variance claim on different ground. Even after Bossavit’s clear debunking of the catch phrase, McConnell argues, replication studies across decades still show order-of-magnitude variance in individual programmer output. His defense rests on a comparison: individual variance versus methodology variance, with methodology standing in as a proxy for “everything not in the person.” His read is that individual variance dominates.

The flaw in that defense is that methodology is one variable in a system with many others, all part of the same system:

  • Uninterrupted focus time and a low meeting load
  • Continuous integration and deployment (CI/CD) pipeline and build speed
  • Reliable staging and deployment infrastructure
  • Codebase familiarity and how long someone has been in it
  • The state and structure of the codebase itself
  • How work is assigned: who gets the clean, high-impact tasks and who gets the ambiguous ones
  • Code review standards and turnaround
  • How knowledge is distributed versus hoarded
  • Which organization someone sits in at all

McConnell’s defense holds methodology constant and calls what is left over “individual variance.” But every other variable in the system is still present and has impacts. Their effects pile up in the individual column due to a lack of a stated home resulting in the individual getting credited for the work of an unrecognized system.

The honest reading is the one Lutz Prechelt offered in Making Software (O’Reilly, 2010), summarizing the academic literature. Variance is real. The headline number is bunk. The cause of the variance is environmental, and has been since DeMarco and Lister’s Peopleware (1987) showed that quiet workspaces, private offices, and uninterrupted time explained more of the variance than experience, pay, or company.

What To Do Instead

Two situations send a leader toward the 10x trope. Either you are being asked for a 10x hire (by yourself, by a board member, by your boss), or you already have someone on the team you have started calling one. The work is different in each case.

You Are Being Asked for a 10x Hire

When asked to get a 10x hire the first step needs to be an audit. Skipping this audit denies you and your company the ability to turn this request from buzzword into something useful. Consider doing this before writing any new job descriptions (JD).

Start with the team the request is implicitly about. The leader saying “we need a 10x hire” is saying the team needs something it doesn’t have. Apply these questions on the work that isn’t getting done.

Does the team know what it is supposed to be doing? If the work in question never had a written responsibility behind it, no one was going to deliver against an absent target whether they were 10x or 1x. Hiring a unicorn into an awareness vacuum still leaves you with the vacuum. The worse outcome is when the unicorn is allowed to fill the vacuum themselves, deciding on their own authority what the team should or should not be working on. Now the team, in some cases the company, is being pulled in the direction the unicorn thinks is right.

Does the team have the skills the work requires? If not, the gap is specific. Train the people you have, hire someone for the named skill gap, or buy the capability as a service. None of these is a 10x problem. They are normal hiring or development problems with specific solutions.

Does the team have the conditions it needs to do the work it is aware of and skilled to do? This is where most “we need a 10x” requests actually live, and tech debt is the dominant version of the problem. An undocumented codebase. A test suite that doesn’t pass cleanly. A deployment pipeline that takes a half-day per release. Dependencies the team cannot upgrade because the upgrade path has been deferred for three years. A planning process that ships every other priority before this one. A 10x hire dropped into these conditions produces 1x output, the same as everyone else. The conditions are the multiplier, and the conditions belong to the leader.

Are the people on the team choosing to do the work? If not, the question shifts. Has the role drifted from what they were hired for? Has the team around them changed? Is someone burned out and not saying so? Hiring a 10x candidate into a team that has lost its will to do the work is a way of asking the new hire to inherit a problem the leader has not yet named.

Now run the same questions on the hypothetical candidate. Will the candidate be aware of what the role actually requires? Only if the role is written down accurately, which the audit above suggests is unlikely. Capable in the specific skills the team is missing? Only if the specific skill gap has been named, and “10x” is not a skill gap. Able to do the work under the team’s current conditions? Almost certainly not, because those conditions are what blocked the team you already have. The candidate’s individual brilliance does not override an environment that has been blocking everyone else. Willing to do the role you can actually offer, in the conditions you can actually provide? The candidate has options. The conditions you are hiding from them in the interview are the same conditions they will find out about in their first week.

“10x” does not show up in any of these answers. It cannot. The questions do not have a 10x scale. Each is yes or no. A candidate is more capable than another in a specific skill, or more aware of a specific responsibility, or more able under a specific set of conditions. The label “10x” across all four collapses every dimension into a single mystified word. It exists to skip the diagnosis.

You Already Have One (or Believe You Do)

In this situation you haven’t been asked for a 10x hire because you already believe you have one on the team. Or you hired one a year ago and the math hasn’t worked out the way you expected. The label is comforting, which is why it sticks. What follows underneath it is almost always one of two things: a hire who is about to fall short of your expectations, or a team member whose apparent brilliance is a system pathology you have not yet named.

Let’s focus on the new hire first. Boris Groysberg, in Chasing Stars (Harvard Business School, 2010), tracked star Wall Street analysts who moved between firms. He found their results were firm-specific. The analyst who had been an “A player” at Goldman did not port to Merrill. What ported was their name. Their performance dropped because the conditions changed.

The 10x candidate you hired produced their output under specific conditions at their previous employer. A particular team. A particular technology stack. A particular set of internal advocates. A particular product-market context that made their work matter. They will arrive at the new role with the same skills and the same work ethic and land in a system that has none of the same conditions. Their output will drop, not because they got worse, but because the environment that was multiplying them is gone.

The leader who hired them does one of two things at this point. The honest move is to recognize that the candidate is producing what the system allows, and that the system is the leader’s responsibility. The much more common move is to conclude that the candidate was overpromised in the interview. This is the manufactured-disappointment ending. The candidate, who has done nothing wrong, becomes the person who did not live up to the hype, even though the hype was the leader’s own. Within eighteen months the candidate leaves. They go somewhere with conditions closer to what they had before, and their output recovers. The leader who hired them learns nothing, because the next time the team struggles the conclusion is “we need a 10x hire.”

Now take the team member you already have, the mislabeled team member you have started calling a 10x. Gergely Orosz, at The Pragmatic Engineer in March 2024, listed what a “10x developer” usually turns out to be on closer inspection. His list is worth reading carefully, because every entry is a system pathology hiding behind a person attribute.

  • The fast shipper who writes code nobody else can maintain. The system has no code review standard that catches downstream maintenance cost. Other engineers are slower because they are trying to ship work that lasts. The 10x is faster because they are allowed to externalize cost onto everyone else’s future calendars.
  • The expert who knows the legacy system better than anyone. The system has no knowledge distribution norm, so the one person who learned it is structurally irreplaceable. The 10x is the absence of documentation in human form.
  • The senior engineer who outpaces every junior. The system has an onboarding gap newer hires never closed. The 10x is a tenure advantage the team failed to amortize.
  • The lead who always lands the high-visibility project. The system has no transparent project assignment process, so political routing decides who gets the work that gets noticed. The 10x is the person with the best internal network, not the best output.
  • The one whose name lands on every successful project. The system has no honest attribution norm. The 10x is the person who let the team’s work be summarized in their own performance review.

Read this way, the “10x developer” is a roster of management failures wearing a person’s name. Each pattern is a thing the leader could have set conditions for and did not. Each is also a thing that, once the 10x label is applied, gets harder to fix, because the label rewards the leader for not looking.

Both versions (the disappointing hire and the mislabeled team member) produce the same downstream effect on the team around them. Marianne Bellotti’s 2019 piece “Heroes and Juniors” described the pattern. Hire or anoint the strongest senior engineer you can find, and the team’s velocity goes up for the first month. After that it goes down. The hero takes on the load nobody else could handle and becomes the bottleneck for everything that depends on their attention. The rest of the team learns to wait for them rather than do the work themselves. Mentorship moves in one direction only, from the hero outward and never inward. Eighteen months in, you have one tired hero and a team that has structurally degraded around them.

The 10x label accelerates this, because by labeling someone a different category of person than the rest of the team, you create the gap before any actual work has been done.

The Trope in 2026

The same move is happening right now, under a new label. Andrew Filev, writing at Unite.AI in April 2026, made a representative version of the new claim: “The new 10x engineer doesn’t write 10x the code. They build the system that writes it.” The phrase “build the system” is doing all the work in that sentence. Having named the system as the source of the multiplier, Filev then proposes a new individual hero to embody it. He calls them the AI (artificial intelligence) Orchestration Engineer. The role this new hero is supposed to play is exactly what an existing organization’s tech leads, senior engineers, architects, and dev managers already (or should) do. The system does not need a new hero. It needs the roles it already has to be supported in doing their jobs, which include figuring out how AI fits into the team’s work.

The AI-augmented 10x is the trope finding a new costume. The current generation of leaders gets to keep its preference for hiring heroes over system solutions, with the additional comfort that the hire now has the word “AI” in their job title.

Closing

A leader who keeps asking for 10x hires has, somewhere upstream, decided not to build the conditions a team needs to do its best work. The trope is what that decision sounds like out loud.

If you are a leader being told you need a 10x hire, ask questions about the team you already have. If you are a leader being asked for a 10x hire by someone above you, ask the same questions back to whoever is asking. If you are an engineer being told you are the 10x on a team, look at the work you are absorbing and ask which of those things should not be sitting on you alone.

The first response to “we need a 10x hire” is not “let me write the job description.” It should be a real conversation covering:

  1. What is the actual issue or opportunity we have, or need to address.
  2. Are we sure the team is fully clear on the issue or opportunity.
  3. Does the team have the skills to address the issue or opportunity.
  4. Are the conditions in place for them (or the organization) to deal with the issue or opportunity.
  5. Is it possible we have a motivational problem around the issue or opportunity.

Doing this basic audit will shed light on what needs to be addressed. Some of what surfaces will be cheap to fix. Some will be expensive. A small number will require an actual hire, and when they do you will have a much better chance of real impact from the hire.

Sources

Organized by section. URLs verified at time of publication.

Where the idea came from

What to do instead

The trope in 2026

Glossary

  • ACAW: Aware, Capable, Able, Willing. The four-question evaluation framework introduced in Article 1.
  • ACM: Association for Computing Machinery. Publisher of the 1968 Sackman, Erikson, and Grant paper that is the original source of the 10x claim.
  • AI: Artificial Intelligence.
  • ALGOL: ALGOrithmic Language. The high-level programming language used in the 1968 Sackman study; one subject’s use of ALGOL versus another subject’s use of machine language produced the famous 28-to-1 figure later mis-cited as individual-talent variance.
  • CI/CD: Continuous Integration and Continuous Deployment. The automated build, test, and release pipeline; its speed is one of the environmental factors that drives apparent output differences.
  • HBS: Harvard Business School. Publisher of Boris Groysberg’s Chasing Stars.
  • JD: Job Description.