Bus Factor: What It Means, and How to Fix It When One Person Knows How Your Numbers Work

Ask who could produce the board numbers if the person who does them were on a plane next week. In most small companies there's a pause, then one name. Sometimes it's the founder, sometimes an engineer who built the reporting on the side, sometimes the one analyst. They know which spreadsheet tab feeds the deck, which script refreshes it, and what "revenue" means in it. That pause is the bus factor, and it's usually one.

The short answer: the bus factor is the smallest number of people who would have to disappear, through illness, a new job or the proverbial bus, before a project or process stops. Wikipedia defines it as "a measurement of the risk resulting from information and capabilities not being shared among team members". A bus factor of one is a single point of failure. In research on 133 popular open-source projects, 65% had a bus factor of two or less. In a company, the process with the lowest bus factor is often the reporting. You raise it by moving what's in one person's head into places others can read and run: written metric definitions, scripts that run on a visible schedule, shared credentials instead of a personal laptop, and a second person who has actually rerun it.

What the bus factor means

The term comes from software, from the question of what would happen to a project "in case they get hit by a bus". It also goes by lottery factor, truck factor and circus factor. The lottery version is kinder: what if they won the lottery and quit?

• Bus factor 1: one person leaving stops the work. "A bus factor of one is a single point of failure".
• Bus factor 2 or more: someone else can keep it going, at least for a while.

An early public example, according to Wikipedia, came in 1994, when someone asked on a mailing list what would happen to the Python language if its creator, Guido van Rossum, were hit by a bus.

What the research says

• Open-source projects. Avelino and colleagues estimated the "truck factor" of 133 popular GitHub projects, defined as "the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated." Their headline finding: "the majority of our target systems (65%) have TF <= 2."
• Small businesses. In a 2019 survey of more than 700 UK small businesses by Legal & General, 26% said they would have to close immediately if a key person died or became critically ill, and a further 26% said they would stop trading within a year. (Legal & General sells key-person insurance, so read it with that in mind.)
• Knowledge silos at work. In Stack Overflow's 2024 survey of developers, "30% of developers say knowledge silos impact their productivity ten or more times per week."

The bus factor in reporting

Code at least lives in a repository. Reporting often lives in one person's habits. The signs:

• The spreadsheet only one person edits. Everyone else gets a PDF of it.
• A script on a laptop. It runs when they run it, or from a scheduled task on a machine nobody else can log in to.
• Credentials in one place. The database password is in their password manager, or worse, in the script.
• Definitions in their head. They know that revenue excludes test accounts and refunds count in the month they happen. Nobody else does, until the numbers change when someone else tries.
• Holidays break it. The weekly numbers are late whenever they're away.

As one data-team guide puts it: "If only one person knows how to maintain ETL pipelines or Airflow jobs, even a vacation day could lead your team to being out of luck in a breakage." And: "When you’re a team of one, there’s naturally a lottery factor."

How to measure it for your reports

Make a short table. For every report or number people rely on, count three things:

The lowest count in each row is that report's bus factor. Most small companies find a column of ones.

How to raise it

1. Write the definitions down where tools read them. "Revenue is paid orders minus refunds, before tax, counted on the order date", as a SQL expression that every report uses. A definition in a document goes stale; one that the reports actually run on stays true. Our semantic layer guide explains the idea.
2. Move scripts off laptops. Run them somewhere with a visible schedule and a log, so anyone can see when it last ran and why it failed.
3. Put credentials in a shared store. Workspace secrets or a team password manager, not one person's machine or the code.
4. Name a second person, and have them do it. Not "read the docs": actually rerun the report while the first person watches. That's the step that changes the number in your table.
5. Keep it simple enough to hand over. One place for the queries, the code and the dashboards beats four tools only one person knows how to connect.
6. Recount every quarter. People change roles; the table should change with them.

Raising the bus factor with Fastero

Fastero puts the pieces of a reporting setup in one workspace a team shares, rather than on one person's laptop:

• Definitions everyone uses. Metrics are saved as SQL expressions with descriptions, alongside notes such as "exclude test accounts". Dashboards, Fastero's assistant and Claude all read them, and every change is versioned.
• Queries, notebooks and jobs in one place. Saved queries, notebooks with SQL cells and Python jobs live in the workspace, and every schedule shows in one list with when it runs.
• Credentials that belong to the team. Database connections and secrets are stored in the workspace, not in anyone's code, so a colleague can rerun a job without asking for a password.
• Answers anyone can get. A colleague can ask Claude, through Fastero's connector, "how is net revenue calculated, and what was it last month?", and get the answer from the same definition the dashboard uses, with their own permissions.
• People who only need to read, for free. Viewers are free, so the whole team can see the reports without a licence each.

A metric definition written once in the workspace, where every report and AI answer reads it. Sample data.

Every schedule in one list, visible to the team rather than hidden on one laptop.

FAQ

What is the bus factor?

The minimum number of people who would have to leave a project before it stalls because nobody else knows how it works. A bus factor of one means a single person is a point of failure.

What's the difference between bus factor, truck factor and lottery factor?

They're the same measure under different names. "Lottery factor" imagines the person winning the lottery and leaving, rather than something worse.

What is a good bus factor?

Anything above one for the things the business can't do without. In research on 133 popular open-source projects, 65% had a bus factor of two or less, so even well-known projects often rely on very few people.

What is key person risk?

The risk that a business depends on one person's knowledge or skills. In a 2019 Legal & General survey of UK small businesses, 26% said they would close immediately if a key person died or became critically ill.

How do you reduce the bus factor for reports?

Write metric definitions where reports read them, run scripts on a visible schedule instead of a laptop, keep credentials in a shared store, and have a second person actually rerun each important report.

---

Related reading:

• What is a semantic layer?
• Automated reporting
• Run a Python script online, on a schedule
• Self-service analytics
• Modern data stack for small teams

Sources: Wikipedia: bus factor, Avelino et al., A Novel Approach for Estimating Truck Factors (ICPC 2016), Legal & General State of the Nation 2019, Stack Overflow Developer Survey 2024, Locally Optimistic: reducing the lottery factor for data teams. Checked 5 November 2026.

---

Try Fastero free — put your queries, definitions, scripts and schedules in one workspace your team shares, so the numbers don't depend on one person. No credit card required.