Article · 10 August 2026 · 4 min read

The bus factor: when your platform rides on one engineer

Somewhere in your company there may be one person who can deploy, restore a backup, and explain why the cluster is named that. Everyone else hopes. That hope has a name: a bus factor of one.

How it happens to good teams

Nobody designs this. One engineer sets up the cloud account in the early days, keeps fixing what breaks because they are fastest at it, and three years later the infrastructure lives in their head. The better they are, the worse it gets: things break rarely enough that writing anything down never feels urgent.

What it costs before anyone leaves

• Their vacations are your freezes. Two weeks of no deploys, or two weeks of them answering Slack from a beach.
• Every platform decision queues. One calendar becomes the roadmap's hidden dependency.
• 3am belongs to one phone. Which is how good engineers burn out, which is how the bus arrives.
• Nobody can review their work. Unreviewed infrastructure grows odd corners that only make sense to their author.

The honest test

Ask three questions. Could someone else deploy to production today, alone? Could someone else restore last night's backup, and has anyone ever tried? If your infrastructure person resigned this morning, what breaks first, and when? If any answer makes you laugh nervously, you have your diagnosis.

Fixing it without a second hire

The fix is not cloning the person, it is moving the knowledge out of their head. Everything in version control, so the infrastructure is readable. A runbook per failure mode, so 3am has instructions. Pipelines built from shared components rather than personal scripts, so deploys have no favorite operator. And a second pair of accountable eyes, which does not have to be a hire: an outside practice a few days a week reviews the platform, documents as it goes, and answers when the one person is on a beach. That is how a bus factor of one becomes a platform that survives anyone's departure, including ours.