Bus Factor: The Hero Engineer Risk an Engineering Manager Can Measure

An overloaded hero engineer leaves a trace that a manager can measure: the team’s bus factor. Atila Ekimci argues in a recent article that this kind of risk is hard to see, and this piece extends one question from that article into a number an engineering manager can check every quarter.

Ekimci argues that the hardest management work happens before problems reach a dashboard

Ekimci describes three situations where early attention matters: quiet tension between two engineers, a dependable engineer taking on more than they can sustain, and stretch projects that slow a team down in the short term. The example given for the second is a newly promoted mid-level developer who volunteered constantly, stayed late, and less than two months later asked for two weeks away, unable to face a screen any longer. Ekimci had already raised working sustainably with the developer.

Ekimci warns that people will not always say when they have too much on, and lists warning signs to look for. One of them is whether half the team would lose track of how something works if one person were away for a week. The article also criticizes engineering culture’s attachment to heroes, and says the question Ekimci now asks about a strong performer is “can they keep delivering like this?”

The bus factor turns one of Ekimci’s questions into a measurement

Ekimci’s question about a week of absence has a name in software engineering research. The truck factor, also called the bus factor, is the smallest number of developers who would have to leave before a project stalls. In 2016 Guilherme Avelino, Leonardo Passos, Andre Hora, and Marco Tulio Valente published an automated method for estimating it from version control history and ran it against 133 popular GitHub projects. They found that 65% of those projects had a truck factor of two or less.

Those were mature, widely used open source projects, and most of them depended on one or two people. A product team of eight that has grown around a single dependable engineer has no reason to look better. The difference is that Ekimci’s social signals take judgment to read, while a truck factor estimate can be produced from the repository the team already has.

A Git-only bus factor misses the knowledge held in reviews and meetings

The measurement has a known gap. In 2022 Elgun Jabrayilzade, Mikhail Evtikhiev, Eray Tüzün, and Vladimir Kovalenko published Bus Factor In Practice, based on a survey of 269 engineers. Respondents saw the bus factor as an important problem, and the authors pointed out that existing tools read only version control data while knowledge also moves through code reviews and meetings. They built an estimate that adds both sources and tested it on 13 JetBrains projects against what the engineers on those projects reported. It did slightly better than the Avelino tool at predicting the bus factor and at naming the key developers.

This gap matters for the engineer Ekimci describes. The person everyone relies on is often the person who reviews every risky change and answers every question in the incident channel. Much of that load never appears as authored code. A manager who wants the number to reflect the hero should count reviews and on-call answers alongside commits.

The bus factor shows where knowledge sits and says nothing about strain

The boundary on this tool is important. A truck factor estimate measures concentration of knowledge. It does not measure hours, fatigue, or whether a person is close to the point Ekimci’s developer reached. Avelino’s own validation was mixed: developers from 67 projects responded, and 53% of the valid answers were positive or partially positive about the estimated truck factors. The number is a prompt for a conversation, and a manager still has to have the conversation.

There is also a counter-case. If a team is told to raise its bus factor, people can spread trivial commits across files without spreading understanding. Worse, the engineer who carries the load can start to look like the problem. The number belongs in the manager’s notes, where it points to the areas that need attention, and it should stay out of performance targets.

Route stretch work into the areas where the bus factor is one

The measurement connects two of Ekimci’s situations. Ekimci argues that managers should give stretch projects to engineers who have not led one, even when a senior engineer would deliver faster. The bus factor tells a manager where that stretch work would do the most good. A first project lead, a review rotation, or a paired on-call shift placed in an area with a truck factor of one grows a less experienced engineer and takes weight off the hero at the same time.

A practical cadence follows. Once a quarter, estimate the bus factor per service or component, including review data where the tooling allows it. For each area with a value of one, name the person who holds it, ask them directly how sustainable their load is, and choose one piece of stretch work that would bring a second person in. Recheck the next quarter. The names produced by this exercise are the people Ekimci says may never tell you they have too much on.

Why This Matters for Engineering Leadership

Key person risk is a governance question as much as a people question. When one engineer holds the only working knowledge of a critical system, the organization’s ability to change, patch, or explain that system depends on that person’s health and goodwill. Ekimci’s point is that managers should catch this before it shows up as burnout or a resignation. The research shows that the concentration is common and that it can be estimated from data the team already produces. Leaders who ask for the estimate each quarter, read it alongside conversations, and keep it out of performance targets get an early signal for one of the problems Ekimci says rarely reaches a dashboard in time.

FAQ