Bus factor of one: what happens to your product if one person leaves

What happens to your product if the person who knows how to deploy it, restore it, or diagnose a serious incident suddenly leaves? That is the problem measured by the bus factor. It describes how many people need to become unavailable before a project can no longer be maintained effectively. A low bus factor means too much knowledge and responsibility sits with too few people.

Last updated: 2026-09-27

Research into open-source projects has found that this is common. In one study of 133 popular GitHub projects, 65% had a bus factor of two or less. 34% had a bus factor of exactly one. That means a single developer held enough critical knowledge that losing them could put the project at serious risk.

You can estimate your own bus factor from your Git history in an afternoon. The solution is not simply to write more documentation. You need to make sure another person can actually perform the critical work. Start by giving a second person the ability to deploy, restore, and diagnose production problems.

Key facts

In this article

• What is bus factor, and why is it one on most small teams?
• How do you measure bus factor from your repository?
• What knowledge does the repository not show?
• Which three capabilities should move to a second person first?
• How do you raise it without insulting your best engineer?
• What does a 30-day plan look like?
• Where RocketDevs fits
• Conclusion
• Frequently asked questions

What is bus factor, and why is it one on most small teams?

The bus factor is the number of engineers who would need to become unavailable before a project can no longer move forward. The phrase originally uses a bus accident as an example, but the real-world situations are much more ordinary. An engineer might resign, take parental leave, go on holiday, become sick, or simply move to another project.

The term is also known as the truck factor or lottery number. JetBrains Research defines it as the minimum number of engineers who would need to become unavailable for a project to stall. For a small team, the important question is simple: how many people can actually keep the product running if one key engineer is suddenly unavailable?

Open-source projects give us the clearest evidence because their development history is publicly available. A 2016 study of 133 popular GitHub projects found that 65% had a bus factor of two or less. 34% had a bus factor of exactly one, while another 31% had a factor of two. The Linux kernel was an exception, with a much higher bus factor of 57.

That does not mean every small team has a bus factor of one. It does show how easily critical knowledge can become concentrated in one or two people, particularly when a team is small. A five-person engineering team has fewer opportunities to spread specialised knowledge than a much larger organisation.

More recent research points in the same direction. One study of more than 36,000 open-source projects found that 89% had experienced the loss of their core development team at least once. The researchers also found that many projects relied on a single core developer to maintain development activity. Only 27% of the abandoned projects in the study attracted a new core developer.

People becoming unavailable is also not a theoretical risk. In July 2026, the preliminary BLS JOLTS quits rate was 1.9% of total nonfarm employment for that month. The rate for the information industry was 1.0%. These figures cover resignations, not temporary absences such as holidays or illness. A contractor moving to their next engagement can create the same problem for a small team.

Engineers themselves recognise the risk. In a JetBrains survey of 269 engineers, 63% said that during the previous year they had worked on at least one project where they felt there was a high risk of the bus factor reaching zero. Yet only 19% had worked on a project where the bus factor had actually been communicated to them.

That creates an important gap. Teams often know that knowledge is concentrated, but they do not measure or discuss how concentrated it is. For a small team, identifying that risk is part of operating the product, not just an engineering exercise.

Knowledge silos create problems even when nobody leaves. In Stack Overflow's 2024 Developer Survey, 30% of developers said knowledge silos affected their productivity at least ten times a week. 45% agreed or strongly agreed that knowledge silos were a nuisance.

The fact that people regularly look for information about the problem also shows that it is widely recognised. The English Wikipedia article on bus factor received more than 105,000 views in the twelve months to August 2026, per Wikimedia's pageview API.

The important point for a small team is not whether your exact bus factor is one, two, or three. It is whether another person can take over the critical work when the person who normally handles it is unavailable. If nobody else can deploy the product, restore production, or diagnose a serious incident, your practical bus factor for those responsibilities is one.

How do you measure bus factor from your repository?

You can estimate your bus factor from your Git history by looking at who has contributed to the files in your repository and how much of the code depends on each person.

The basic calculation works like this: identify the main contributors to each file, remove the person who is responsible for the most files, and repeat the process. When fewer than half of the files still have a recognised author, the number of people you removed is the truck factor.

This is based on the method developed by Avelino and colleagues. Understanding the basic idea is useful because most bus-factor tools use a variation of the same approach.

The original method has five main steps:

1. List the source files. List the source files in the current version of the project.
2. Identify developer aliases. One engineer may have committed code using different email addresses or account names, so those identities need to be combined.
3. Look at each file's history. This shows who created and changed it over time.
4. Assign authorship to each file. The method considers how much each developer contributed rather than simply counting commits.
5. Calculate the truck factor. Developers are removed one at a time, starting with the person responsible for the most files, until fewer than half of the files still have an identified author.

How does the algorithm decide who owns a file?

The original method uses a score called degree of authorship (DOA). The score considers whether a developer created the file, how many changes they made, and how many changes other developers made.

The formula is:

DOA(md, fp) = 3.293 + 1.098 × FA(md, fp) + 0.164 × DL(md, fp) − 0.321 × ln(1 + AC(md, fp))

You do not need to calculate this yourself. The important part is what the different factors mean.

FA measures first authorship. If someone created the file, that gives them a strong claim to authorship.

DL measures how many changes that developer made to the file. Continued work adds to their authorship score.

AC measures how many changes other developers made. As more people contribute, the original developer's relative claim to the file becomes weaker.

The scores are then normalised for each file. The developer with the strongest contribution receives a score of one. A developer is considered an author when their normalised score is above 0.75 and their absolute score is at least 3.293. These thresholds were chosen after the researchers manually reviewed a sample of 120 files.

This prevents someone who made one small change to a file from being treated as one of its main authors.

How does the final bus-factor calculation work?

The method assumes that a project is at serious risk when its remaining developers collectively cover less than half of its files.

The calculation starts with everyone still present. The person who is the main author of the largest number of files is then removed from the calculation. The process is repeated with the next most important contributor.

Once fewer than half of the project's files have a recognised author remaining, the number of people removed gives you the estimated truck factor.

The method has been tested against developers' own assessments. Ferreira, Valente and Ferreira compared three truck-factor algorithms against developers from 35 open-source systems. They found that two of the algorithms were very accurate, particularly when projects had a small truck factor.

Avelino's earlier research also compared the calculated authors with developers' own answers across 67 systems. In 84% of the valid responses, developers agreed or partly agreed that the people identified by the algorithm were the main authors.

Is there a simpler way to calculate it?

Yes. You can use a much simpler approach if you want a quick indication rather than the full research method.

CHAOSS defines a related metric called the Contributor Absence Factor. It measures the smallest number of contributors responsible for at least 50% of a project's contributions.

You can calculate it in a spreadsheet:

• List your contributors.
• Record how many commits each person has made.
• Sort them from the highest number of commits to the lowest.
• Add their contributions together from the top.
• Count how many people you need to reach more than half of all contributions.

This is not identical to the original truck-factor calculation because commit counts do not tell you which files are critical or how much knowledge a developer actually has. It is, however, a useful first check.

What does this look like in a real repository?

The core-js JavaScript library provides a useful example. Its GitHub contributors data lists 135 contributors with 7,900 commits between them. One account is responsible for 7,515 of those commits.

Using the simpler CHAOSS calculation, that gives the project a contributor absence factor of one because that single account represents more than half of the total contributions.

The scale of the project makes the example particularly useful. core-js was downloaded more than 285 million times in August 2026, per the npm downloads API. A high level of contributor concentration is therefore not limited to tiny or obscure projects.

Which tools can measure this for you?

You do not need to build the calculation yourself. Several tools can analyse your Git history.

• git-fame: produces a breakdown of repository contributors and their contributions. It can show each person's share of lines, commits, and files. Run it against the main repository to get an initial picture of where contribution is concentrated.
• Git Truck: provides a local visualisation of who has changed the most code in each file. It runs locally, which can make it useful when your repository is private and you do not want to upload its history to another service.
• JetBrains Research's Bus Factor Explorer: analyses GitHub commit history and calculates the bus-factor metric for a project.
• Truck-factor simulation tools: other research tools, such as the one from Cosentino, Izquierdo and Cabot, allow you to simulate what could happen if one or more developers became unavailable, including which files could be left without an identified author.

Measure individual parts of the product, not just the whole repository

Do not stop at the overall number.

A repository can have a healthy bus factor while one critical part of the product depends entirely on one person. For example, five engineers might contribute across the application, but only one might understand the billing system.

That means the overall repository could look healthy while the billing service has a bus factor of one.

Measure the repository by directory or service, not only as a whole. Look specifically at the parts of the product that are difficult to replace, such as billing, authentication, deployment infrastructure, data pipelines, and production configuration.

What are the limitations of these measurements?

The number is useful, but it should not be treated as a complete measure of business risk.

First, a headcount-based metric can exaggerate the potential damage.

Research by Peter Rigby, Audris Mockus and colleagues found that simple truck-factor calculations can overstate potential losses from developer turnover. Their research also found that projects can face losses more than three times larger than the expected loss.

Other research looking at Chromium and seven additional projects found similar patterns of knowledge loss. Files that were effectively abandoned could also remain in the project for long periods.

The practical lesson is that losing one developer does not automatically mean losing everything they worked on. The impact depends on which knowledge they hold and how important that knowledge is to the product.

Second, AI-generated code makes Git history less reliable as a measure of expertise.

Traditional authorship metrics assume that someone who writes or changes code understands that code. AI coding tools complicate that assumption.

If one engineer uses an AI agent to generate thousands of lines of code and then commits them, Git may make that engineer look like the expert behind the code. They may understand only part of what the agent produced.

Research into AI-generated contributions has found that these tools can affect existing measures of developer expertise. The growing discussion around "vibe coding" has also raised the concern that teams can end up with code that has an effective bus factor of zero, even when Git shows a named developer as its author.

Third, and most importantly, Git only shows you part of the picture.

Your product does not run because someone knows how to edit its source files. It runs because people know how to deploy it, restore its data, diagnose production problems, rotate credentials, manage infrastructure, and respond when something breaks.

Those capabilities may not be visible in the repository at all.

That is why a Git-based bus-factor calculation should be treated as a starting point, not the final answer. The real question is not only “Who wrote this code?” but also “Who can keep this product running if that person is unavailable?”

What knowledge does the repository not show?

Git can tell you a lot about who writes and changes your code. It cannot tell you everything someone needs to know to keep your product running.

Standard bus-factor tools mainly analyse version-control history. They cannot see who has access to your cloud console, who knows how to restore your backups, who controls your DNS registrar, or who knows why a particular production problem happens every Friday afternoon.

JetBrains Research highlighted this limitation when developing a broader bus-factor estimator. Existing tools focus on version-control data even though knowledge is also created and shared through other channels.

Those other channels can be important. In the same team's survey of 269 engineers, commits were the most commonly identified source of knowledge. Code reviews came next, followed by issues, test cases, and project documentation. Code reviews are particularly useful because they leave a record that you can analyse. Operational knowledge often does not.

A person might know exactly how to recover a failed deployment or fix a production database without that knowledge appearing anywhere in Git.

Access can become a problem too. Research into abandoned open-source projects found that people trying to take over those projects often struggled to get the repository access they needed. Even when the code was publicly available, someone still had to provide the necessary permissions.

This is why you should measure capabilities as well as code ownership. Alongside your Git-based bus-factor calculation, make an inventory of the things people need to be able to do to operate the product.

The cloud access rows deserve particular attention. AWS recommends documenting and testing emergency access procedures. It also warns against making emergency access depend on the same systems used for normal access. For a small team, that means checking whether your emergency access ultimately depends on the same identity provider as everything else.

Google Cloud similarly recommends having one or more Organization Administrators and maintaining a recovery process for the super-admin account. One administrator may technically meet the minimum requirement, but it also creates an obvious concentration of responsibility.

Go beyond the repository when you do your inventory. Check your cloud accounts, billing systems, DNS registrar, vendor accounts, backup systems, CI/CD platform, and production credentials.

A useful test is to imagine that your most knowledgeable engineer is leaving tomorrow. Ask them to hand over every system they control without relying on memory or informal explanations. Every capability you cannot confidently transfer to another person has a practical bus factor of one.

For a broader access inventory, including vendor accounts, billing cards, and DNS, you can also work through the contractor offboarding access checklist as though the person were leaving tomorrow.

Which three capabilities should move to a second person first?

Start with deploying, restoring, and diagnosing production incidents. These are the capabilities most likely to leave a small team stuck when the person who normally handles them is unavailable.

The important part is not simply teaching someone else what to do. You need to prove that they can do it themselves. A second engineer completing the task successfully is stronger evidence than a document saying they know how.

1. Deploy

Deploying comes first because it affects everything else. If only one person can release changes, the rest of the team may not be able to fix a problem while that person is away.

Think of it like learning to drive. Reading a manual about driving doesn't prove you can drive a car. You need to actually get behind the wheel. Engineering knowledge works the same way.

Pair on three real deployments. The second engineer should perform the deployment while the first engineer watches. The first person should only step in if something is about to go wrong. This shows whether the second engineer can actually complete the process without relying on the original owner's memory.

Once the process works, add a CODEOWNERS file so the right people are automatically asked to review changes to important parts of the repository. Name at least two owners for the deployment configuration so that responsibility does not remain with one person.

2. Restore

Restoring comes next because backups are easy to assume are working.

Having a backup does not prove that you can recover your product from it, as AWS's guidance on recovery testing warns. The backup could be incomplete, corrupted, incorrectly configured, or impossible to restore in the way you expect.

Have the second engineer restore the previous night's backup to a separate database. They should then run queries against the restored data and confirm that it is actually usable.

If the restore fails, you have found the problem during a controlled test rather than during a real outage. That makes the test valuable even when the result is bad.

3. Diagnose a production incident

On-call diagnosis takes longer to transfer because it involves judgement as well as instructions. Someone who has spent years with a system often recognises a problem from a few signals that another engineer would not immediately understand.

A written playbook can help. Google's Site Reliability Engineering guidance reports that using a playbook produced roughly a threefold improvement in mean time to repair compared with simply improvising. That is Google's own experience rather than an independent measurement, but the principle is useful for a small team: the person responding at 3am needs enough context to investigate and resolve the problem without calling the original owner.

The best way to transfer this knowledge is through practice. Have the second engineer work through real incidents, review previous incidents together, and follow the playbook without being given the answer. Update the playbook when they get stuck.

Do the handover before you need it

Do not wait for a resignation, emergency, or extended absence to test whether someone else can take over. Handover is harder under pressure, and bringing someone in after the original owner has already left can create additional risk, per Audris Mockus's study of a large commercial project.

If your team works across time zones, allow extra time for the handover. The second engineer needs enough overlap with the original owner to ask questions, perform the work, and repeat it without assistance.

The practical goal is simple: pick one backup owner for each critical capability this week and have them prove they can perform it independently. If they cannot, you have found a bus-factor problem while you still have time to fix it.

How do you raise it without insulting your best engineer?

Frame bus-factor risk as a risk to the business and a cost to the engineer, never as a judgement of their performance. The engineer who holds the most knowledge is often the person who has gone the longest without taking a real holiday. They usually know this better than you do.

The conversation can go wrong if the engineer feels that their value is being treated as a problem. A Workplace Stack Exchange question titled "Terminating an employee with a bus factor of 1" has been viewed more than 33,000 times. That is an example of what can happen when knowledge concentration becomes a standoff. The goal is the opposite: the person with the knowledge becomes the person who helps spread it, and is recognised for doing so.

There is an honest cost here for the business too. A single contractor from any platform can become your bus factor. The engineer who built the deployment pipeline in month two may still be the only person who understands it in month eight, regardless of who employs them. The same conversation works for employees and contractors.

The conversation

Adapt the words to your team, but keep the structure.

Start with the business risk, not the person. "I have been looking at what would happen if any one of us could not be reached for two weeks, me included. For deploys, database restores and being on call, the honest answer is that it all runs through you. That is a compliment to how much you have built. It is also a risk I have been carrying without saying so."

Name the cost to them. "It also means you have not had a holiday where your laptop stayed shut. I would like to fix that, and I need your help to do it, because nobody else knows this system as well as you do."

Make them the owner of the fix. "Over the next month, I want you to teach Sam how to ship a deploy, restore last night's backup to a scratch database, and work through the next real incident with you watching. You decide the order and what gets written down. I will protect the time."

Define what success looks like. "By the end of the month, Sam ships a deploy alone and restores a backup alone. Then you take a week off with your phone on silent. That is the goal."

Then stop and listen. The most useful answer may be a list of things you did not know about: the certificate that renews by hand, the cron job on a machine nobody else can reach, or the vendor account attached to a personal card. Add each discovery to the capability table.

What to avoid

Do not ask for "documentation" in the abstract. Without a clear purpose, it can sound like an exit interview.

Do not tie the exercise to a performance review either. Research by Jabrayilzade and colleagues recorded practitioners reducing bus-factor risk by rotating people between project areas, writing documentation, organising talks with key developers, and conducting code reviews. Some also described retaining key engineers through higher salaries and strong relationships. Retention can reduce the chance of someone leaving, but it does not remove the underlying dependency on one person.

If the engineer resists the transfer after you have explained the business risk and protected time for it, treat that as information rather than an insult. You may need to examine whether the role, engagement, access model, or team structure is creating a dependency that cannot be resolved through knowledge sharing alone.

The recommendation is simple: make knowledge transfer part of the engineer's job, give them protected time to do it, and measure success by what another person can perform without help. Your best engineer should leave the process with less pressure, not less importance.

What does a 30-day plan look like?

A practical 30-day plan should follow a clear sequence:

• measure first;
• transfer one capability at a time;
• then test the result.

1. Days 1–5: measure the repository and inventory critical capabilities.
2. Days 6–12: transfer deployment.
3. Days 13–19: prove a database restore.
4. Days 20–26: transfer on-call diagnosis.
5. Days 27–30: measure again, close any remaining gaps, and test whether the original owner can step away.

The schedule is a practical framework, not a research-backed rule for how long each capability takes to transfer. Some tasks will take less than a week. Others may need longer. What matters is that each capability is transferred through real work and tested before the original owner becomes unavailable.

By day 30, you should be able to name two people who can independently perform every critical capability in your table. More importantly, you should have watched them do it successfully.

Days 1 to 5: measure and inventory

Start with the repository. The Git analysis should take an afternoon using the tools described earlier. Run the measurement at repository level and by directory so you can see where knowledge is concentrated.

Then inventory the operational capabilities. Spend an hour with the engineer who currently holds most of the knowledge and work through the capability table together. Ask who can actually perform each task, rather than who has access to it or has watched someone else do it.

Expect the capability inventory to reveal more than the Git analysis. Git can show you who changes the code. It cannot tell you who knows how to renew a certificate, restore a backup, access a vendor account, or diagnose a production problem.

Days 6 to 12: transfer deployment

Keep the scope narrow. The second engineer should drive three real deployments on production systems while the original owner watches.

A deployment the second engineer performs is evidence that the capability has transferred. A deployment they merely watch is not.

Use the process to identify missing access, unclear steps, and undocumented decisions. Once the second engineer can complete the process independently, add CODEOWNERS with two owners for the relevant configuration.

Days 13 to 19: prove the restore

Repeat the same approach with backups. Have the second engineer restore the previous night's backup to a scratch database and query the restored data.

The important result is not that the restore job says it completed. The proof is that the second engineer can recover usable data without the original owner taking over.

Write down every step that caused confusion or required intervention. Those discoveries become part of the restore procedure.

Days 20 to 26: transfer on-call diagnosis

On-call diagnosis takes more care because real incidents happen on their own schedule.

The second engineer should take the pager while the original owner remains available as backup. When an incident occurs, let the second engineer investigate and resolve it wherever possible. Every question they need to ask is useful information about what still lives only in the first person's head.

If nothing breaks during this period, run a game day. Choose a previous incident and have the second engineer diagnose it from the available logs and dashboards while the original owner stays silent. Turn every missing piece of information into a playbook entry.

Days 27 to 30: measure again and close the gaps

Now repeat the Git measurement and recount the capability table. Compare the results with the baseline from days 1–5.

If a critical directory still has only one recognised contributor, or a capability still has only one person who can perform it, use these final days to close the gap. That might mean another paired deployment, another restore test, or another on-call exercise.

The target is two capable people for every critical capability, particularly the directories and systems connected to revenue.

The final test should be practical rather than theoretical: let the original owner take a genuine week off without being the emergency contact. If the team immediately needs them, the dependency still exists.

The plan cannot guarantee that every capability will transfer in exactly one week. No published study establishes a standard transfer time for a small engineering team, so the schedule is a practical rule of thumb rather than a research finding.

What the evidence does support is the approach: identify where knowledge is concentrated, transfer the capabilities that can stop the business first, prove the transfer through real work, and do it while the original owner is still available.

Treat day 30 as a test, not a deadline. If the original owner cannot step away without the team depending on them, keep transferring knowledge until the product can operate without its single point of failure.

Where RocketDevs fits

A client who discovers their bus factor during a resignation has already had a bad month. If the engineer who resigned was from RocketDevs, part of that risk sits with us too. Providing a strong engineer is not enough if the account eventually depends on that person for every critical operation.

The solution is the same one described throughout this article: spread critical knowledge before it becomes urgent.

If one RocketDevs engineer has become the only person who can deploy, restore the database, or diagnose a production incident, we would recommend adding a second engineer to the account and using the same transfer process. The two engineers pair on real deployments. The second engineer performs a backup restoration. They work through on-call incidents together. The goal is to reach two people who can independently perform every critical capability in the table.

That changes the role of the second engineer. They are not simply extra development capacity. They become a second holder of the knowledge that keeps the product running.

This is also where the vetting process matters. Every RocketDevs engineer on the bench has completed 6-8 hours of structured assessment per developer, and RocketDevs accepts only the top 2% of applicants. That means the second engineer starts with an established technical baseline rather than having to prove their fundamental engineering ability from scratch. The account still needs to provide product-specific context, architecture knowledge, access, and operational history. Those are learned through the handover and pairing process.

The transfer should also happen while the original engineer is still available. A new engineer who receives a list of instructions after someone has resigned is in a very different position from one who has spent several weeks working alongside the person who built the system. The first can ask questions while the answers are available. The second may have to reconstruct those answers during an incident.

Adding a second engineer

If you want to add a second RocketDevs engineer to an existing account, the engagement runs under the same 14-day risk-free trial as a first placement. The trial is money-back and is 100% honoured.

That gives the client an opportunity to test the additional engineer in the actual environment where the knowledge needs to transfer. The important test is not simply whether the engineer can complete development tasks. It is whether they can become useful enough in the account to share responsibility for critical capabilities.

The honest version is simpler still: whoever employs your engineers, run the 30-day plan.

A bus-factor problem does not disappear because the engineer is a contractor, employee, freelancer, or supplied through a talent platform. If one person is the only person who can deploy your product, restore its data, or diagnose a serious production problem, the dependency exists regardless of the employment arrangement.

RocketDevs would rather work with teams that do not depend on a single engineer. Two people who understand the critical parts of an account give the client more resilience, give engineers more opportunity to take genuine time off, and make future changes in the team easier to manage.

The practical recommendation is to use your next new engineer to reduce an existing dependency, not create another one. Start with the capabilities that would cause the most disruption if their current owner disappeared, pair on the work while that person is still there, and keep testing until someone else can perform it without help.

For more on the surrounding processes, see the contractor offboarding access checklist, the cost of handover across time zones, and what to do when a new engineer is not working out.

Conclusion

A bus factor of one is not a developer problem. It is a business dependency that happens to live inside one person's head. Your best engineer should be important because they're valuable, not because the entire company stops working without them.

Your most experienced engineer may be the reason your product runs as smoothly as it does. They may know the architecture better than anyone, solve incidents before anyone else understands there is a problem, and carry years of decisions that never made it into a ticket or a document. None of that is a reason to make them indispensable. It is a reason to make sure their knowledge does not leave with them.

The answer is not to make that engineer less valuable. It is to make the team more capable around them.

Start by measuring where knowledge is concentrated. Look beyond Git history and identify the operational capabilities that the repository cannot show you. Then transfer the work that would hurt most if its current owner disappeared. Have another engineer deploy. Have them restore the data. Let them diagnose a real incident. Watch what they can do without help, and document what they cannot.

Then test it.

The real measure of success is not a lower number in a Git report or a larger documentation folder. It is being able to say, with confidence, "If this person is unavailable tomorrow, someone else can keep the product running."

That is what a healthy bus factor looks like. It gives the business resilience. It gives engineers the ability to take holidays without carrying a laptop everywhere. It makes onboarding less fragile. It makes departures manageable instead of catastrophic.

And it changes how you think about hiring. The next engineer you add should not simply increase the amount of code your team can produce. They should also reduce the number of things that only one person knows how to do.

Measure the dependency. Transfer the knowledge. Prove the capability. Then let the person who used to be indispensable take a week off.

If nothing breaks, you have not just solved a bus-factor problem. You have built a stronger engineering team.

Frequently asked questions

What is a good bus factor for a startup?

Two for every capability that can stop revenue, measured by who can actually perform it, is a practical floor for a team of two to ten. CHAOSS's viability guidance notes that smaller projects and organisations may be more comfortable with a contributor absence factor of two. No published study sets a specific benchmark for small commercial teams, so treat two as a minimum rather than a universal target.

How do you calculate bus factor?

Decide who authors each file from Git history, then remove the top author repeatedly until fewer than half the files still have a recognised author. The number of people removed is the truck factor. This is based on the Avelino algorithm, and tools such as git-fame, Git Truck, and the JetBrains explorer provide ways to estimate it.

A simpler CHAOSS approach counts how many contributors are responsible for at least half of the project's contributions. Either approach gives you a useful starting point, but remember that Git cannot measure operational knowledge that lives outside the repository.

Is bus factor the same as truck factor?

Yes. The two names describe the same basic measure, which research literature also calls the lottery number. The idea is to estimate the minimum number of developers who would need to become unavailable before a project is significantly impaired. Use whichever term your team already understands.

How do you reduce key-person risk in software?

Name a successor for each critical capability and have them perform the work while the original owner watches. Then reverse the roles so the original owner becomes the learner.

In Rigby's study of turnover, having successors reduced expected knowledge loss by as much as 15%. Documentation helps, but it should support a transfer that has actually happened rather than replace one.

How often should you measure bus factor?

Measure it whenever your team, architecture, or responsibilities change significantly, and consider a regular review for critical systems. A new hire can reduce one dependency while creating another if knowledge gradually concentrates around them. A resignation, major system change, new service, or change in on-call responsibility can also alter the practical bus factor.

The important point is to measure capability ownership, not just Git contribution. A repository can show two active contributors while only one person knows how to deploy, restore, or recover the production system. Repeating the measurement helps you catch that dependency before it becomes an emergency.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• Avelino, Passos, Hora and Valente, A novel approach for estimating truck factors, ICPC 2016
• Avelino, Passos, Hora and Valente, A novel approach for estimating truck factors, arXiv full text
• Avelino, Constantinou, Valente and Serebrenik, On the abandonment and survival of open source projects, ESEM 2019
• Nourry, Kondo, Saito, Iimura, Ubayashi and Kamei, Myth: the loss of core developers is a critical issue for OSS communities, arXiv 2412.00313
• Jabrayilzade, Evtikhiev, Tüzün and Kovalenko, Bus factor in practice, ICSE-SEIP 2022, arXiv 2202.01523
• Jabrayilzade et al., Bus factor in practice, full text
• Ferreira, Valente and Ferreira, A comparison of three algorithms for computing truck factors, ICPC 2017
• Rigby, Zhu, Donadelli and Mockus, Quantifying and mitigating turnover-induced knowledge loss, ICSE 2016
• Nassif and Robillard, Revisiting turnover-induced knowledge loss in software projects, ICSME 2017
• Foucault, Palyart, Blanc, Murphy and Falleri, Impact of developer turnover on quality in open-source software, ESEC/FSE 2015
• Mockus, Organizational volatility and its effects on software defects, FSE 2010
• Cosentino, Izquierdo and Cabot, Assessing the bus factor of Git repositories, SANER 2015
• Cury and Avelino, The impact of generative AI on code expertise models, SBES 2025
• CHAOSS, Contributor Absence Factor metric definition
• CHAOSS, viability starter metrics model
• GitHub REST API, core-js contributors
• npm downloads API, core-js, August 2026
• git-fame
• Git Truck
• JetBrains Research, Bus Factor Explorer
• GitHub Docs, About code owners
• AWS Well-Architected Framework, SEC03-BP03 Establish emergency access process
• AWS Well-Architected Framework, REL09-BP04 Perform periodic recovery of the data
• Google Cloud, Super administrator account best practices
• US Bureau of Labor Statistics, JOLTS quits rate, total nonfarm
• US Bureau of Labor Statistics, JOLTS quits rate, information
• Google Cloud, Announcing the 2023 State of DevOps Report
• Google, Site Reliability Engineering, Introduction
• Wikipedia, Bus factor
• Wikimedia pageviews, Bus factor
• Stack Overflow, 2024 Developer Survey, professional developers
• Hacker News via Algolia, item 44966856
• Stack Exchange API, Workplace question 194162