Your 10x engineer is a 0.1x risk

The 10x engineer concept has been debated for forty years. Whether the productivity gap between the best and average engineer is literally 10x is the wrong question. What is true, and what engineering leaders feel every quarter, is that on most teams there is one or two engineers who built the critical infrastructure, who understand the architecture in their head, who are called when systems break in ways nobody else can diagnose, and who do the work everyone else benchmarks against.

This is the 10x engineer. They produce real value. They are also the single point of failure for the team's continued ability to ship.

The bus factor framing has been used for this for years. It does not capture the modern version. In 2026, the engineer who built the critical system is also the engineer who has internalized the AI-tooling workflow, who knows which prompts produce the right code in your repo, who has built the convention library that the team relies on. They are not just a domain expert. They are the operational interface between the team's tools and the team's output. When they go, two systems leave with them: the code, and the workflow that used to produce more code reliably.

This is not a problem you solve with documentation alone. The risk lives in tacit knowledge, in relationships across teams, in the engineer's intuition about what to build and what not to build. The mitigation has to address all three, and it has to do so without making the engineer feel demoted.

Why the obvious responses fail#

The most common response is to ask the 10x engineer to write documentation. This fails reliably. The engineer does not have time to document everything they know, and the things they could document are the things that are easiest to write down, which are usually not the things that would unblock another engineer in their absence. The hard knowledge is intuition about which trade-offs the team made in 2023 and why. That knowledge does not write itself into a markdown file.

The second common response is to hire a second senior engineer to share the load. This works if the team can afford it and if the second engineer is willing to take a backseat for 6-12 months while learning the system. Most strong senior hires do not want this. The hires who accept it often leave when they realize the original owner is still the architectural decision maker.

The third common response is to do nothing and accept the risk. This is the default. It survives until the engineer takes parental leave, burns out, or is poached. At that point, the team's velocity is below half for at least a quarter and often longer.

The intervention that works has to do three things at once: build redundancy without demoting the original owner, redirect their effort toward leverage rather than implementation, and surface their tacit knowledge in ways that catch the parts that matter.

Four moves that actually work#

1. Pair them on a rotation, deliberately#

Pair the 10x engineer with a rotating second engineer on every major piece of work for a quarter. The pair changes every 2-3 weeks so multiple engineers absorb the context. The 10x engineer drives architecturally and the second engineer drives implementation. The second engineer asks the questions in the moment when the answers are clearest.

This is not pair programming for productivity. It is pair programming for knowledge transfer. The output measure is whether the second engineer can later answer a system-design question from someone else without consulting the original owner. After two months of rotations, two or three engineers on the team should be able to.

The intervention works because it moves knowledge transfer into the act of building, where the tacit pieces are visible, rather than after the fact in documentation, where they are invisible.

2. Make documentation a side effect of decisions, not a project#

Stop asking the engineer to write documentation. Instead, require an architectural decision record for every significant choice they make during the quarter. The ADR is short: the problem, the choice, the alternatives considered, the consequences. Two pages maximum. The engineer writes one whenever a non-trivial decision is made.

The ADR is not comprehensive documentation. It is a record of decisions, which is the part of tacit knowledge that resists transfer most consistently. When the engineer leaves, the next person can read the ADRs and reconstruct the reasoning, even if the implementation has drifted.

The Linear, Stripe, and Anthropic engineering blogs all reference ADR practices as central to long-running engineering teams. The Anthropic engineering "How we contain Claude across products" post is itself an ADR in disguise; it documents the design decisions and the alternatives considered, which is the same content shape.

3. Redirect 20% of their time to platform investment#

Take 20% of the 10x engineer's calendar and explicitly redirect it to platform work that makes the rest of the team faster. Internal tools, refactors that simplify shared abstractions, new test infrastructure, code review of work they did not write. This is the highest leverage use of their time and it has two side effects.

The first is that the platform investment compounds, which is the standard argument.

The second is that it slows the engineer's own implementation work by 20%, which gives the rest of the team room to take on the implementation work that the 10x engineer would otherwise have absorbed. This is the real redundancy intervention. It does not require demoting the engineer; it requires reallocating a portion of their time to leverage and accepting that the rest of the team will pick up the slack.

Teams that do this for two quarters report that the 10x engineer often comes to prefer the platform work. The interruption from being the on-call expert for every system question is exhausting; the platform work is structured and creative. The engineer's job satisfaction goes up and the team's redundancy goes up simultaneously.

4. Define the second-owner role explicitly#

For every critical system the 10x engineer owns, name a second owner. The second owner is the engineer who gets paged after the first owner. The second owner reviews architectural changes to the system before the first owner approves them. The second owner is named in the wiki, the on-call rotation, and the team's mental model.

Most teams have an implicit second owner who is the "person who probably knows the next-most about this system." Make it explicit. Tell the second owner. Tell the first owner. Put it in the team's documentation. The implicit version does not work because nobody acts on a role they have not been given.

The second-owner intervention is the cheapest of the four and it does the most concrete work. It creates a named relationship and a named accountability without changing anyone's title or compensation.

What this is not#

This is not a way to manage out a strong engineer. The framing matters. If the engineer suspects the moves are designed to make them replaceable so the company can let them go, they will leave on their own terms first. The framing is that the engineer is too valuable to be a single point of failure, and the moves are designed to amplify their impact across the team.

The teams that have done this consistently have a different conversation with their senior engineers: "We need you to be able to take a real vacation. Here is the plan to make that possible."

What to do this week#

Pick one critical system on your team. Name the first owner. Name the second owner. Tell both of them. Add a recurring 1:1 between them on the calendar starting next week. Track for one quarter how often the second owner is consulted before the first owner is paged. If the number climbs from zero to anything positive, the intervention is working.

Then expand to the next system. Then the next. Then revisit the 10x engineer's calendar and start the 20% platform redirect for next quarter. By the end of two quarters, the concentration risk on the team will be measurably lower and the 10x engineer will have a clearer path to higher-leverage work.

The risk does not go away. It becomes manageable. Manageable is the goal.