Your Best Engineer Might Be Your Biggest Risk

You probably know the engineer I mean. They know why the payment retry runs twice, which customer has a special flag in the database, and what to restart when the overnight import stalls. Every hard ticket ends up with their name on it, because they fix it in an hour and anyone else would need a week.

Then they book two weeks off. On the first Monday, a deployment fails. On Wednesday, a client asks why an invoice changed. By Thursday, someone is drafting a polite message to a person on a beach.

Nobody did anything wrong. Each time, the team did the sensible thing: give the hard problem to the person who solves it fastest. Repeat that for a year and you have built a system with one way in.

The hero is a queue

Teams reward this person, and they should. The skill is real. The trouble is what forms around them. Every hard question waits for one calendar. Other people's pull requests wait for their review, and other people stop learning the hard parts, which never reach them.

Queueing arithmetic shows why this gets worse faster than it looks. In the textbook model of one person serving randomly arriving tasks, the average wait before a task starts is the average task length multiplied by u / (1 - u), where u is the share of time the person is busy. At 50% busy, a task waits about as long as it takes. At 90%, nine times as long. At 95%, nineteen times. The person everyone depends on tends to sit at the top of that range, because their free hours are the first ones taken.

So the hero's own output looks excellent, while the team's is set by the queue in front of them. Measured one person at a time, the team looks efficient. Measured as a team, it is mostly waiting. It also distorts planning: every estimate includes an unstated wait for one person, which is one more reason an estimate is not a promise.

What the bus factor measures

The bus factor is the smallest number of people who would have to disappear, under a bus or into a better job, before work stalls. A team that routes everything through one person has a bus factor of one.

Low numbers are common. In 2016, Guilherme Avelino and colleagues estimated the same measure, which they call the truck factor, for 133 popular open-source projects on GitHub (ICPC 2016). They counted a project as in trouble once the authors who remained covered less than half of its files. By that rule, 65% of the projects had a truck factor of one or two. These are estimates from commit history, and 53% of the developers' survey answers agreed with them fully or partly, so read the figure as a pattern, not a census.

Capability is not the problem. The system around the person creates the dependency: who gets the hard tickets, who reviews what, who is paged at night, who gets thanked when the release goes out. Knowledge concentrates because work is sent to where the knowledge already is, and every assignment adds a little more.

Concentrated knowledge is a kind of debt, in the sense I used in Technical Debt Is a Loan. The team borrowed speed by letting one person learn the hard parts alone. The interest is the queue and the risk. The principal is the time it takes to teach someone else, and as with any debt, repay it first where the interest is highest.

Spread the knowledge, not the blame

None of this is the expert's fault, and the fix should not feel like a punishment. Taking hard work away from your best engineer to make a point is a reliable way to lose your best engineer. The aim is to move knowledge, not status.

• Pair on the hard problems. The next incident in the expert's area is fixed by two people, and the less experienced one types. It takes longer once. That is the repayment.
• Rotate ownership and on-call. Give each area a second owner, and put people on the rota who will need to ask questions. The questions are the point.
• Let the expert review instead of doing. Their name moves from the author field to the reviewer field. Their judgement still shapes the change, and someone else now knows how it was made.
• Write decisions down. Code shows what the system does. It rarely shows why.

Michael Nygard proposed architecture decision records for that last gap: "One of the hardest things to track during the life of a project is the motivation behind certain decisions" (Nygard, 2011). Each record is a page or two: a title, the context, the decision, its status and its consequences. Without the reasoning, he argued, a newcomer can only accept an old decision blindly or change it blindly. While the expert is away, everyone is a newcomer to the parts they never touched. In the truck factor survey, developers named documentation as the most effective remedy when a main author leaves, ahead of an active community and automated tests.

I was the formal tech lead of a five-person team from 2021 to 2023. In a team that size, one absence is a fifth of the team, and the lead is the likeliest queue, because every question already has a route to them. These habits apply to leads first.

Treat the next holiday as a test

A planned absence is the cheapest bus factor test you will get. It has a start date, an end date and weeks of notice. Netflix built the harsh version for servers: its Chaos Monkey switches off production instances at random, and the project's README gives the reason: "Exposing engineers to failures more frequently incentivizes them to build resilient services" (Netflix, 2016). A holiday is the gentle version for people. The failure is scheduled, and the person comes back.

Before the expert leaves, ask five questions:

1. Which tasks would stop if they were unreachable for two weeks?
2. For each task, who else has done it alone in the last three months?
3. Who else holds the access: production credentials, the cloud account, the domain registrar, the signing certificate? Access is the dependency people forget, because nobody needs it until the day they do.
4. Which decisions exist only in their head? Those are the first records to write.
5. After they return, how many messages did the team send them? Each one is a gap with a name on it.

Fix what the first test finds, then run it again at the next holiday. The second one should be quieter.

The goal is not a team without experts. It is a team where an expert's holiday is boring.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.