Bus Factor for a Small Firm: Find the Recurring Jobs Only One Person Can Run
For a small firm, the bus factor of a job is the number of people who could run it alone today, and every recurring job where that number is one is a key person risk. Find those jobs by checking who actually ran each one over the last 90 days. The only hard number on how concentrated knowledge gets comes from software, where a study of 133 popular GitHub projects found that 65 percent depended on two people or fewer, so expect to find one-person jobs in your firm too.
The failure is quiet. Nobody decides that the monthly invoice run belongs to one person. They did it once, they got fast, and everyone started asking them. The firm learns the dependency when that person is on a two week holiday and the invoices, the payroll inputs or the client report do not happen. Below are a job-level scorecard, a rule for ranking the one-person jobs by what a gap would cost, and a monthly Slack check that keeps the list current, so you find the dependency before a calendar does.
What does bus factor mean for a business, not a codebase?
Engineers coined the term for code: it is the minimum number of developers who would have to be hit by a truck, or quit, before a project is incapacitated, which is how the arXiv study defines the truck factor. Business writers use the same idea under the name key person risk or key person dependency, and the head term still mostly returns engineering pages.
For a firm of 5 to 100 people, drop the repository and count jobs. The unit is a recurring job with a deadline: invoicing, payroll prep, the monthly client report, supplier orders, a production deploy. For each job, the bus factor is the count of people who could run it start to finish without asking the usual person. The VeryCreatives guide reads the scale this way: 1 is a key-person dependency, 2 to 3 is manageable if the job is documented, and 4 or more makes the knowledge an asset. VeryCreatives wrote that table for software teams and their investors, and it carries over to jobs unchanged.
Having an owner is a different thing. A job can have one clearly accountable name and still have exactly one person who can run it, which is why a RACI chart answers a different question. A risk register entry is different too: one row for "key person away" says the risk exists, and does not say which ten jobs it touches.
Why do one-person jobs build up without anyone deciding it?
They build up because speed rewards concentration. Sally describes the pattern as one person taking over an area, getting good at it and becoming the fastest point of contact, so knowledge flows toward them and the dependency grows with every problem they solve. Because everything works day to day, nobody notices. Vacation, illness or a resignation turns the latent risk into an acute one overnight.
Small firms add a constraint that larger guides skip. In a 2023 Hacker News thread about letting go of an employee with a bus factor of 1, one commenter says that many, mostly small, companies cannot justify an IT department to cover this risk, and that it shows up in non-IT jobs too: sales, contract law and accounting. That is one commenter's report, not a measured rate, but it matches what a 12-person firm can afford. Instead of duplicating the bookkeeper, make sure a second person has run the bookkeeper's month once.
The same people who built the dependency are also the worst judges of it. In a 2016 Ask HN thread, one commenter warned that people will be biased into thinking their bus factor is lower than it really is, because in practice businesses adapt and someone steps in once they must. Another commenter in the same thread could point to several places where one person is pivotal to core business functions and causes problems whenever they go on vacation. Both are author reports, and they pull in opposite directions. So an answer from memory is not a measurement.
How do you find the jobs only one person can run?
Check who actually ran each job over the last 90 days from the threads, not who people think could cover it, because an audit from memory is biased and the written trail is the only version a second person can check.
Most guides tell the owner to ask, once, who else could operate each job if its owner took a month off. Tallyfy suggests asking, for every function, whether someone else could do the job within a week. Sally starts from the areas where a two week absence would cause serious disruption. Those are good questions. The weakness is the source of the answer: one person's recollection, given once, with no way to tell the difference between "Dana could cover it" and "Dana covered it in March".
Evidence beats opinion because it separates three cases that sound the same in a meeting:
- Someone else ran it in the last 90 days. The job has a working second person, whatever the org chart says.
- Someone else could, in theory. This is the case memory reports as coverage. Treat it as unproven until they have done it once.
- Nobody else has touched it. This is a one-person job, and it is the list you need.
The scorecard
Build one row per recurring job. Here is a made-up example for a 14-person services firm, with illustrative names and costs.
| Job | Runs | Owner | Others who ran it in 90 days | Backup named | Write-up exists | Cost of a two week gap |
|---|---|---|---|---|---|---|
| Client invoice run | Monthly, 1st to 3rd | Priya | None | No | Partly | Cash arrives 2 weeks late |
| Payroll inputs | Twice a month | Priya | None | No | No | Staff paid late, legal exposure |
| Monthly client report | Monthly, by the 5th | Marcus | Lena (once) | Lena | Yes | Clients notice, no money lost |
| Supplier orders | Weekly | Tom | None | No | No | Stock out within 10 days |
| Production deploy | Ad hoc | Anika | Marcus | Marcus | Yes | Fixes wait, no hard deadline |
| Domain and software renewals | Quarterly | Tom | None | No | No | A lapsed domain takes email down |
Read the "Others who ran it" column first, before the "Backup named" column. In the example, the firm believes it has a backup for two jobs. The thread trail says it has a working second person for one of them, and for the other the backup has run the job once. Four jobs have no second person at all.
Try Kipwise Agent free in Slack: mention it once in a thread and it does the repetitive work, with your permissions.
How do you rank one-person jobs by what a gap would cost?
Rank one-person jobs by what a two week absence would cost, not by how likely the person is to leave, because vacation and illness make an absence certain and only the cost decides which write-up comes first.
The tempting way to prioritise is to worry about the person who seems restless. That ranks by a guess about someone's career. A two week absence is not a guess: everyone takes holidays, and anyone can be ill without notice. The question that sorts the list is what stops, and how soon, when that job does not run for two weeks. This is a recommendation, not a sourced rule, though it borrows the two week framing from Sally's self-check.
Use three tiers:
- Money or a legal deadline falls inside the gap. Payroll inputs, invoice runs, tax and filing dates, renewals that take a system down. Fix these this month.
- A client sees the gap. Reports, deliverables, onboarding steps. Fix these next, because the cost is trust, not cash.
- Only the team feels it, and it can wait two weeks. Internal housekeeping. List them, name a backup, revisit them quarterly.
Within a tier, put jobs with no write-up ahead of jobs with a partial one. In the example table, payroll inputs and the invoice run both sit in tier 1 with no second person, and the payroll job has no write-up at all, so it goes first.
What does the monthly Slack check look like?
It is one scheduled thread in your operations channel that does the evidence step for you and leaves the decisions with people.
Kipwise Agent can run a request on a schedule, in plain language, and post the result in the channel with the same tools and permissions as a live request from the person who set it up, per the Kipwise Agent page. A scheduled task needs one approval when it is created, and later runs do not ask again. Here is the shape of the monthly run, using the scorecard above:
- Post the list. On the first Monday of the month, the task posts the recurring jobs from your operations manual or the page you point it at, and asks each job's owner to reply in the thread.
- Check the trail. For each job, you ask the agent to find past discussions of that job and report which people appear in them. With memory on, which is the default, it recalls short facts with a link to the source message. With memory off, it searches Slack live with the asking person's own connection. A person opens the linked threads before trusting the list. Tell it to report only what it found, to link each source, and to say so when it finds nothing.
- Sort the result. A job where one name alone appears, or where the owner names nobody, goes onto a short list. You order that list by the three tiers above.
- Decide the backup. A person picks the backup for each listed job and confirms in the thread. The agent does not choose.
- Draft the missing write-up. The agent offers to write the job up as a Kipwise page from the owner's walkthrough in the thread. The page is written under the requester's name, so ask the owner to read it before the backup relies on it.
What stays with people is the part that changes the bus factor: picking the backup, the cross-training session, and the handover of logins. The agent finds and drafts, and people decide and teach.
Tallyfy's advice on capture applies here. It says not to ask people to write manuals but to have the expert walk through the process while someone records the steps, the decisions and the "oh and you also need to do this" moments. In Slack, a walkthrough in a thread is that recording, and turning a thread into a page is a chore the agent can take on. A page written this way is a handover document in the practical sense: the backup can run the job from it. For the structure of the page itself, the guide to writing an SOP covers it.
Why repeat it every month?
Repeat the check every month, because a backup named once goes stale the first time that person changes role, and a stale backup looks exactly like coverage.
A one-off audit has the same half-life as any chart. Someone moves from operations to sales, a contractor ends, the backup for payroll goes on leave, and the scorecard still names them. Nothing flags it. The monthly run is cheap insurance because it asks the same question against fresh evidence: who ran this job in the last 90 days? A name that has not appeared in any thread for a quarter is a backup in name only. This is also a recommendation, not a measured result. It follows from the fact that the scorecard is a snapshot and roles change.
What can go wrong with a thread-based check?
The check fails in four predictable ways, and each has a rule.
A job with no Slack trace looks like a bus factor of 1. If the owner runs the job by phone, in person, or inside QuickBooks or a bank portal without ever posting about it, the search finds nothing. Do not treat "no trace" as proof. Treat it as a prompt: ask the owner who else has done it, and ask that person to confirm in the thread. If the answer is "nobody", you have found the real one-person job.
The agent can only see what the asker can see. It searches with the asking person's own access, so a private channel the asker is not in is invisible. Run the check from someone who is in the channels where the work is discussed, or accept that the list under-counts coverage in private threads.
A backup who has never done the job is a name, not a backup. Naming Marcus does nothing until Marcus has run one cycle with the owner watching. For a monthly job, that means one month. Schedule the shadow run the same day you name the backup, and move the job off the one-person list only after it happens.
Credentials do not transfer through a write-up. A page can say how to run payroll inputs, but the backup still needs access to the payroll tool. Handing over logins and permissions is a person's decision, made through the tool's own sharing, and it is the step most often forgotten. Put "access confirmed" in the scorecard as its own column if the job sits behind a login.
A last trade-off: a monthly check adds a small recurring task for every owner. Keep the first run to the six to ten jobs that carry money or a client deadline. A list of forty jobs gets ignored, and an ignored check is worse than none because it creates the feeling of coverage.
How do you know it is working?
You know it is working when the one-person list gets shorter without the job list getting shorter. Track three numbers each month: how many jobs have exactly one person in the 90 day trail, how many of those have a backup who has run the job once, and how many tier 1 jobs have a write-up. The first should fall, the other two should rise.
Run a pilot before you commit to the whole firm. Pick three tier 1 jobs, run the thread once by hand or with the agent, and see whether the owners' replies match what the trail shows. If an owner says three people could cover a job and the trail shows none, that gap is the finding, and it is worth more than the scorecard. If the trail shows more coverage than the owners expected, that is a good result too: some of your one-person jobs are not, and you can stop worrying about them. The Ask HN commenter's point that businesses adapt cuts both ways.
Finally, test one backup under real conditions. Take a tier 1 job and have the backup run it from the write-up while the owner is on a day off. If they get stuck, the write-up has a hole, so fix the page.
What to do next
Pick the three recurring jobs that would hurt most if they did not run for two weeks, and for each one write down who actually ran it in the last 90 days, using the threads as your evidence. Any job with a single name or none goes onto the list, and the owner names a backup who will shadow the next run. If you want the thread to do the searching and drafting each month, Kipwise Agent costs $10 per user per month with a minimum of 3 users, as set out on the pricing page, and the first scheduled run takes one approval.
