The Bus Factor: What Engineering Culture Gets Right About Campaign Fragility

High-stakes engineering culture has a term for institutional fragility that corporate management never came up with: the bus factor. The definition is exactly what it sounds like. How many core team members can get hit by a bus before the project enters irreversible danger? A bus factor of one means the answer is: just one person. That person disappears, and the whole thing stops working — because they were the only one who knew how it worked.

The concept has been circulating in BSD Unix and open-source culture for decades, and it is worth crediting where it comes from. In FreeBSD development circles, the bus factor is a real operational discipline, not just a thought experiment. The FreeBSD boot loader was for years maintained by exactly two engineers who understood the Forth programming language well enough to keep it running. They were the bus factor of two for an entire subsystem that every FreeBSD machine depended on. The project formally discouraged them from attending the same conferences simultaneously. Non-colocation of the people who hold critical knowledge was a named policy, not a metaphor.

The problem was eventually solved when a third engineer led the conversion of the boot loader from Forth to Lua — a more maintainable language with a larger talent pool. The bus factor for that subsystem went from two to something more survivable. That was the structural fix: not heroics, not redundant documentation, but an architectural decision that reduced dependence on rare knowledge.

Campaigns Have the Same Problem

Political campaigns are fragile knowledge networks that almost never think about this. The digital consultant who built the ad account, knows the pixel setup, and understands why the targeting is structured the way it is — that person is often a bus factor of one. If they leave mid-race, go dark for a week, or simply don't document what they built, the next person who touches the account is starting from zero. In a compressed election timeline, that is not a recoverable situation.

It's not just the digital operation. The field director who knows which precincts are soft. The treasurer who understands the FEC reporting structure they set up. The campaign manager who has the relationship with every endorser. These are all single points of failure, and down-ballot campaigns rarely think about them as such until the first crash.

Most campaigns discover their bus factor problems at the worst possible time. Not during the planning phase. Not during a calm stretch when there's time to fix things. During a crisis — when the consultant is unreachable, the account is locked, and no one else knows the password or why the campaign is structured the way it is.

Documentation Is the Structural Fix

The FreeBSD solution wasn't "hope the two guys who know Forth don't both get hit by a bus." It was architectural: replace the dependency on rare knowledge with a system that more people can understand and maintain.

For campaigns, that structural fix is documentation — written down, findable, and detailed enough for someone coming in cold to actually use. Not a list of login credentials. Not a folder of screenshots. A real operational record of how the digital infrastructure works, why each piece is configured the way it is, and what would break if someone changed something.

This is not glamorous work. It is the kind of work that campaign operations culture actively discourages, because everyone is always too busy doing the actual campaign to write down what they're doing. The bus factor problem compounds in silence until it doesn't.

At BMS, we build documentation into the engagement — not as a deliverable the client gets at the end, but as the operating standard throughout. Cron scripts have comments explaining why they fire when they do. Memory files track decisions that would otherwise live only in one person's head. The client onboarding checklist is 14 sections long because every section represents something a campaign legitimately can't reconstruct from memory alone. The goal is a bus factor that survives the people who built it.

The Non-Colocation Principle for Campaigns

FreeBSD's non-colocation rule — don't let the only two people who understand a critical subsystem travel together — translates differently for campaigns. Campaigns don't typically run parallel digital teams. But the structural question the rule asks is still valid: are the credentials, institutional knowledge, and relationships that your campaign depends on stored in one physical or digital location where a single event could destroy them?

One person's email account holds all the vendor contracts. The FEC filing history lives on one laptop. The ad account access is tied to one personal phone number for two-factor authentication. These are all versions of the same problem the non-colocation rule is trying to solve. The risk isn't getting hit by a bus. The risk is a phone upgrade, a password reset, a hacked account, or a key person who doesn't come back after the primary.

Backup credential storage. Secondary account access for critical platforms. Platform verification tied to the organization rather than an individual. These are not paranoid measures. They are the minimum for a campaign that expects to still be operational on the Tuesday that matters.

Automation as Bus-Factor Reduction

Every manual recurring task is a single point of failure. If the digital consultant has to remember to post to social media every weekday, the campaign's online presence depends on that person's memory and availability. If the FEC pull for donor data requires a specific person running a specific script on a specific machine, the campaign's compliance infrastructure has a bus factor of one.

Cron-driven automation is, among other things, a bus-factor reduction tool. An automated posting pipeline runs whether or not the person who built it is available. A scheduled data pull happens at 2 AM whether or not anyone is awake. The knowledge required to keep it running is encoded in the code and the comments, not in someone's head.

This is one of the reasons BMS builds toward automation rather than away from it. Not because automation is cheaper in the short run — it usually isn't. But because a campaign that depends on one person doing something manually every day has a bus factor problem, and automation is the architectural fix.

What "Bus Factor of One" Actually Feels Like

Here's the honest version: most consulting relationships in down-ballot politics are bus-factor-one by design. The consultant is the only one who knows the account. The campaign trusts them. The candidate is focused on knocking doors. Nobody is writing anything down because writing things down takes time that could be spent on the campaign.

That works fine until it doesn't. It works fine until the consultant moves on, or the campaign moves into the general and needs to hand off the digital operation, or the candidate wins and has to figure out how to stay elected with a new team that inherits a black box.

The campaigns that handle these transitions without disaster are the ones that made bus-factor reduction a discipline from day one — not a crisis response after the system already crashed.

The Kind of Campaign That Survives

The campaigns that win without a bus-factor crisis share a few things. The digital operation is documented well enough that a second person could take it over in a day. The credentials and account access are not tied to one person's personal phone number. The vendor relationships are in writing, not just in the consultant's Rolodex. The systems that run automatically keep running automatically whether or not the original builder is reachable.

That kind of campaign doesn't require a large staff or a large budget. It requires a discipline that most campaigns skip: building as if someone else will eventually need to understand what you built, and making sure they actually can.

The kind of campaign that survives a bus-factor-of-one event is the kind we build.