What is 'bus factor' in a technical organization?

Bus factor is the minimum number of people who would need to disappear before a project or system stalls. A bus factor of one means a single departure — planned or otherwise — takes critical knowledge with it. Most organizations think of this as a risk management number. In practice, it's a measurement of how much invisible load has been allowed to concentrate on one person, and how much of that load is undocumented, un-transferable, and unacknowledged.

Why do managers think they understand the bus factor problem when they don't?

Because 'stretched thin' is visible but 'decision fatigue across a dozen concurrent domains' is not. Managers see the output, the hours, the ticket count. They don't see the cognitive tax of choosing which domain to work on when all of them are equally urgent, the focus that evaporates when interrupted mid-task, or the self-blame cycle that prevents the person carrying the load from pushing back. The gap between 'I know they're busy' and the actual experience is where the problem lives.

What is the 'acknowledgment trap' in management?

It's when a manager says something like 'I know you're doing superhuman work — we really appreciate you,' and that statement, while genuine, functionally closes the conversation the employee needed to have. The compliment becomes a seal. Raising the issue again feels like rejecting the recognition, so the employee stays silent. The manager, meanwhile, believes they've addressed it — they said the words, they showed empathy. Both sides walk away from a conversation that never actually happened.

How does impostor syndrome interact with organizational overload?

The structural problem deepens the impostor syndrome, and the impostor syndrome prevents boundary-setting that could address the structural problem. The person carrying an impossible load believes they should be able to handle it — 'I'm just a terrible employee, I'm destined for failure' — and that belief makes them afraid to push back because pushing back might reveal the fraud they think they are. It's self-reinforcing: overload creates self-blame, self-blame prevents boundaries, lack of boundaries deepens overload.

Is the bus factor problem solvable without the keystone leaving?

In principle, yes — it requires genuine redistribution, not just acknowledgment. Real backup (not in name only), documented processes, explicit scope conversations that end in someone else taking domains off the keystone's plate, and a cultural shift in who is expected to notice when the load is unsustainable. In practice, most organizations let keystones emerge because it's cheaper than hiring properly, and they don't address it until the keystone leaves. The structural change usually arrives with the resignation letter.

The Bus Factor Is Not a Number — What Managers Miss About Their Best Employee

Imagine you got hit by a bus tomorrow. What happens at work?

Not your team — they’d be fine, eventually, the way teams always are. What happens to the twelve things only you know how to do? The service that needs restarting in a specific order. The vendor relationship that lives in your inbox. The legacy codebase nobody else has touched since 2019. The deployment process that’s documented in your head and nowhere else.

If the honest answer is “several things would quietly stop working and nobody would know how to fix them for weeks,” then your organization has a bus factor of one, and you’re standing in front of the bus.

Nobody formally assigns you twelve jobs

Nobody formally assigns you a dozen jobs. The scope grows one domain at a time: “Can you also handle the CMS?” Then: “The vendor needs a technical contact.” Then: “Someone should probably look at the AWS bill.” Then: incident response, because you’re the one who understands the infrastructure. Then: triage, because you’re the one who can translate between the client and the engineering work. Each addition is individually defensible. None of them, in the moment, look like the one to refuse.

The title doesn’t change. The scope quintuples. And because it happened gradually, nobody — yourself included — has a truly accurate picture of what the role even contains anymore.

To give that some scale: one of the domains I was carrying had a monolithic codebase that desperately needed a Python 2-to-3 migration — the kind of project that obviously requires deep focus and uninterrupted time, but when it’s sitting alongside close to a dozen other domains, the tendency is to treat it like just another task on the list. Touch it when you can. Make progress where the gaps allow. During a related incident, I had the opportunity to have an outside vendor scope and quote the project. Their estimate — before full discovery was even complete — came back at a team of four engineers plus a technical project manager, approximately six months, and a bill in the tens of thousands. For one project that I’d been quietly absorbing into the margins of everything else.

What the hours column doesn’t measure

The volume of work, on its face, was often manageable. Some weeks were light. Some weeks I could have pointed at the hours column and said “see, it’s fine.”

The hours column was never where the cost lived. The cost was in deciding what to work on when a dozen domains are all equally valid and any of them could interrupt at any moment — cloud infrastructure, DevOps, legacy code, CMS administration, incident response, vendor management, and half a dozen others nobody even remembered existed. Each one a different mental model, a different set of assumptions, a different way of thinking about what “done” looks like. The tax wasn’t in the work itself but in the constant, low-grade process of choosing which domain to enter and which eleven to hold at arm’s length while hoping nothing caught fire.

I tried time-blocking. Mondays for network administration. Tuesdays for open-office IT support. Wednesdays for sysadmin work. It’s the obvious solution, and it falls apart the first time someone has an important need that doesn’t respect your calendar — a server goes offline, someone forgets their password, a certificate is expiring. The needs don’t care what your calendar says.

But the anticipation was almost worse than the interruptions themselves. The constant awareness that the bubble could pop at any moment made it nearly impossible to truly commit to deep work. You’re six pages into network topology documentation with another eight to write, and somewhere in the back of your mind you’re bracing for the ping that pulls you out. That bracing is its own form of cognitive load, and it runs all day whether the interruption comes or not.

Research on workplace interruptions consistently finds that full focus takes roughly 23 minutes to return after a single disruption — drawing on Sophie Leroy’s attention-residue work and Dr. Gloria Mark’s study at UC Irvine. In a role spanning a dozen domains where interruptions are structural rather than incidental, that 23-minute refocus window never fully closes before the next one opens.

You can’t unpop a bubble

When the interruption does come — the server goes down, the password reset request, the “just checking on this” message — focus doesn’t pause. It evaporates. Like a bubble: when it pops, you can’t put it back together. The air is already dissipating. You have to blow a new one.

The initial feeling, honestly, is helpfulness. This is your job. You enjoy solving problems for people. That part is real, and it matters.

But underneath it there’s a latent resentment. And a validation of something you’ve been trying not to think: “I knew this would happen. Why do I even try to focus?”

That’s a quick path to fatalism. Negative sentiment override — the state where your default interpretation of neutral events becomes negative — sets in faster than you’d expect when the cycle repeats daily.

So you solve the problem. Or, if it’s big enough, it bleeds into a second day, shattering your next planned focus block too. By the time you return to the original task, the exit conditions were never clean. You didn’t have a moment to organize working memory, to file away the state of where you were. Getting back into the documentation you were writing doesn’t feel like resuming — it feels like starting over.

The work you’ve done feels wasted. The other domains that need attention later in the week don’t pause because of one triage incident. And your manager is wondering why the documentation project is behind schedule.

It’s similar to the Nintendo cartridge problem: no save point, no clean shutdown, and the pile of cartridges keeps growing — though this is almost worse, because at least with a cartridge you’re swapping one game for another. This is more like driving a train with no switching stations, where someone asks you to change routes and you have to pick the whole thing up, cars and all, and put it on a new set of tracks. The train keeps getting longer because each car is another domain, and the cargo is half-loaded because nothing ever finishes cleanly before the next switch.

I thought it was a me problem

I believed it was a me problem for decades. Not abstractly — viscerally. The internal narrative was: “I’m the issue. Why can’t I do this? I should be better at this. I should be able to focus. I am just a terrible employee, and I’m destined for failure.”

The first time I left a role carrying this pattern, I thought I was leaving because I couldn’t hack it. That I wasn’t good enough. I started a company partly because I thought the problem was me and I needed to remove myself from environments where my inadequacy would be visible.

Later, even when I would tell people the problem was structural — when I could articulate the domain count, the switching cost, the impossible scope — I didn’t really believe it about myself. Externally I had the analysis. Internally the narrative hadn’t changed.

And impostor syndrome has a way of reinforcing the structural problem it feeds on. “I better not set boundaries, because then people will find out I’m a fraud. I have to do everything, to prove my value.” That logic keeps the scope growing, keeps the bus factor at one, and keeps the keystone from ever having the conversation that could change the structure — overload creating self-blame, self-blame preventing boundary-setting, absence of boundaries deepening the overload.

The causal arrow can run the other way too — someone who walked in with no impostor syndrome at all can develop it after years of carrying an impossible scope, because the structure itself teaches you that you’re failing. Either way, the loop is the same once it’s running.

The three layers between your manager and the actual problem

At some point, you try to make the invisible work visible. You map the domains. You list the responsibilities. You quantify the scope. You bring receipts.

And you hit three layers of insulation, none of them malicious, all of them effective.

Layer	What it sounds like	What it does
The acknowledgment trap	”I know you’ve been doing superhuman work. You’re beyond 100% capacity and we really appreciate you.”	Closes the window for honest conversation. Pushing back now feels like rejecting the recognition.
The normalization	”No company has every role. People wear multiple hats. Expecting the ideal creates expectations no environment can support.”	Reframes a structural problem as an unrealistic expectation.
The friendly framing	”Just feedback from a friend. I hope you hear the heart behind it.”	Makes further pushback feel personal rather than professional.

The acknowledgment is the most insidious because it looks exactly like empathy. The manager says the words, names the load, expresses gratitude. And in doing so, they believe they’ve addressed the situation — they’ve shown they see it. But acknowledging the load and acting on the load are fundamentally different things, and the acknowledgment, once given, makes raising the issue again feel inappropriate. You can’t come back and say “no, you actually don’t understand” without sounding ungrateful or dramatic.

The manager walks away believing they’ve addressed it. The keystone walks away having lost their only window to actually explain what’s happening, because reopening the conversation now feels like rejecting someone’s goodwill rather than contesting a structural argument.

If the keystone does force the conversation open again — with a scope document, a domain map, a concrete accounting of what the role actually contains — the normalization layer catches it. The response comes wrapped in warm framing and genuine care: every company operates this way, no team has every role it needs, multiple hats are the reality.

Three layers of insulation between the manager and the actual problem, none of them malicious, all of them effective enough that the conversation that needed to happen keeps not happening.

The receipt

Remember that Python 2-to-3 migration from earlier — the one the vendor estimated at four engineers, a project manager, six months, and tens of thousands of dollars?

That was one slice of the total load. A professional estimate for a single project that I’d been telling myself I was a bad developer for not fitting in around my other responsibilities.

That estimate shattered something I’d been carrying for a very long time. The math was always impossible, and the exhaustion I’d spent years treating as a discipline problem turned out to be arithmetic.

If you manage someone whose scope looks anything like what I’ve described — multiple technical domains, sole ownership, no realistic backup — I’d encourage you to do the exercise of getting an outside estimate on just one of those domains. Not to build a business case, but to see the number and hold it next to what you’re asking one person to do alongside a dozen other domains of equivalent complexity.

The gap between those two numbers is your actual bus factor risk, measured in human cost rather than organizational risk.

The gap

The bus factor isn’t a number on a wiki page. It’s the distance between what you think your best employee is handling and what they’re actually experiencing.

The person carrying the load probably isn’t going to tell you. Not because they’re hiding it, but because the structure — the acknowledgment that seals the conversation, the normalization that reframes the problem, the self-blame that prevents boundary-setting — all conspire to keep the real conversation from happening.

And the exhaustion that would generate the signal is the same exhaustion that muffles it. By the time flagging is most urgent, the emotional deadening of sustained overload has made flagging hardest. The body keeps the score before the résumé does.

If you’re not sure whether this describes someone on your team, the Solo Operator Load Check works for managers too. Six questions, two minutes, nothing collected. It won’t fix the structure, but it might tell you what your bus factor actually looks like from the other side.

Sources: Jellyfish — “Context switching and developer productivity” (synthesis of Sophie Leroy’s attention-residue research and Dr. Gloria Mark’s UCI study; ~23 minutes to fully regain focus after a single interruption) · Fast Company — “Worker, Interrupted: The Cost of Task Switching” (popular write-up of Gloria Mark’s original research on interruption recovery time) · Christina Maslach — burnout research (burnout as a three-dimensional response to chronic workplace stress: emotional exhaustion, depersonalization, reduced personal accomplishment) · Maslach Burnout Inventory (the three dimensions and their measurement; emotional blunting as a specific mechanism of depersonalization)