Bus Factor Signals: 10 Warning Signs of Knowledge Risk in Your Engineering Team

• Introduction
• Signal 1: The "Only One Person Can Review This" Problem
• Signal 2: Incident Response Always Pages the Same Person
• Signal 3: Sprint Velocity Drops When One Person Is on PTO
• Signal 4: New Hires Avoid Certain Parts of the Codebase
• Signal 5: One Person Is Always in the Critical Meeting
• Signal 6: Documentation Exists but Nobody Trusts It
• Signal 7: Commit History Shows a Single Dominant Author
• Signal 8: "Tribal Knowledge" Drives Decision-Making
• Signal 9: The "Hero Developer" Gets Celebrated
• Signal 10: Cross-Team Dependencies Funnel Through One Person
• Using This Checklist
• Moving from Signals to Measurement
• Conclusion

Introduction#

Most engineering teams discover their bus factor problem the hard way: a key engineer gives two weeks notice and suddenly everyone realizes how much critical knowledge lives in that one person's head. But the warning signs were there long before the resignation letter.

Bus factor risk does not appear overnight. It builds gradually through everyday decisions about who handles what, how work gets assigned, and how knowledge flows (or fails to flow) through a team. The good news is that these patterns produce observable signals. If you know what to look for, you can identify and address knowledge concentration before it becomes a crisis.

This article covers ten concrete signals that indicate your team may have a dangerous bus factor. Use it as a checklist to audit your own team's risk profile.

Signal 1: The "Only One Person Can Review This" Problem#

When pull requests for a specific service or module consistently get assigned to the same reviewer, that is a strong signal of knowledge concentration. If the team's informal rule is "Sarah needs to review anything that touches the payments service," then Sarah is likely the sole expert on that system.

What to look for:

• PR review assignments that always route to one person for a given area
• PRs that sit in review for days because the one qualified reviewer is busy
• Other reviewers approving with minimal comments because they do not feel qualified to give substantive feedback

What it indicates: The bus factor for that component is likely 1. If Sarah leaves, nobody can confidently review or approve changes to the payments service.

Signal 2: Incident Response Always Pages the Same Person#

When your on-call rotation exists on paper but one person always gets escalated to during incidents involving a particular system, you have a knowledge concentration problem. The on-call engineer may technically be responsible, but they cannot debug the issue without calling in the expert.

What to look for:

• Incident post-mortems that repeatedly name the same person as the resolver
• On-call engineers who escalate to the same colleague for a specific service
• Mean time to resolution that spikes when one person is unavailable

What it indicates: Operational knowledge for that system is concentrated in one person. This is bus factor 1 for incident response capability.

Signal 3: Sprint Velocity Drops When One Person Is on PTO#

If your team's velocity noticeably decreases when a specific engineer takes vacation, that is a measurable signal of bus factor risk. The drop happens because work that depends on their expertise either stalls or gets deferred until they return.

What to look for:

• Sprint retrospectives where "blocked waiting for X to return" appears
• Work items that get pushed to the next sprint whenever a particular person is out
• Informal policies where the team avoids certain areas of the codebase during someone's PTO

What it indicates: The team cannot operate at full capacity without this person. Their knowledge is a single point of failure.

Signal 4: New Hires Avoid Certain Parts of the Codebase#

When new engineers consistently steer away from specific systems or modules, it often means those areas are poorly documented, hard to understand without tribal knowledge, and owned by a single expert who is too busy to onboard others.

What to look for:

• New team members gravitating toward the same "approachable" parts of the codebase
• Entire services or modules with no commits from anyone hired in the last year
• Engineers who have been on the team for months but have never touched a critical system

What it indicates: Knowledge barriers are preventing natural distribution. The bus factor for those avoided systems is not improving over time.

Signal 5: One Person Is Always in the Critical Meeting#

When every architecture discussion, incident response call, or stakeholder meeting requires the same person to be present, they have become a single point of organizational knowledge. Their calendar is packed because nobody else can represent the team's understanding of how things work.

What to look for:

• Meeting invites for technical discussions that always include one specific person
• Decisions that get deferred when that person has a conflict
• Other team members who say "we should wait for X's input" before committing to an approach

What it indicates: Architectural and domain knowledge is concentrated. This is a form of bus factor risk that goes beyond code ownership.

Signal 6: Documentation Exists but Nobody Trusts It#

Having documentation does not reduce bus factor if the team does not trust or use it. When engineers skip the wiki and go directly to the expert with questions, the documentation is not serving its purpose.

What to look for:

• Wiki pages or README files with "last updated" dates from years ago
• Engineers who say "the docs are outdated" and ask the expert directly
• Documentation that describes what the code does but not why decisions were made

What it indicates: The gap between documentation and the expert's actual knowledge is too wide. The documentation creates a false sense of security about knowledge distribution.

Signal 7: Commit History Shows a Single Dominant Author#

When you look at the commit history for a repository or service and one person accounts for the vast majority of meaningful changes, that is a quantitative signal of bus factor risk. This goes beyond raw commit counts. What matters is who made the substantive architectural and feature commits.

What to look for:

• One contributor responsible for 70% or more of the files in a repository
• A Degree of Authorship analysis showing a single person above the 0.75 threshold for most files
• Long stretches of history where only one person made commits to a service

What it indicates: This is the most direct signal of bus factor. ContributorIQ calculates this automatically across all your repositories using DOA analysis, giving you a precise bus factor score for each one.

Signal 8: "Tribal Knowledge" Drives Decision-Making#

When important technical decisions are justified with phrases like "we tried that before and it didn't work" or "that's just how it's always been done," and only one person remembers why, the team is operating on tribal knowledge. These unwritten rationales are some of the hardest knowledge to transfer.

What to look for:

• Architecture Decision Records (ADRs) that do not exist or are incomplete
• Decisions explained by referencing past experiences that only one person witnessed
• New approaches being vetoed based on institutional memory held by a single person

What it indicates: Not just the code, but the reasoning behind the code is concentrated in one person. This makes the system harder to evolve even if others can technically read the source.

Signal 9: The "Hero Developer" Gets Celebrated#

When the team or organization regularly celebrates one person for saving the day, fixing critical bugs, or single-handedly delivering features, it may feel positive in the moment. But it is a signal that the team's success depends on individual heroics rather than distributed capability.

What to look for:

• The same person repeatedly recognized for "going above and beyond"
• Narratives about one engineer being "10x" or indispensable
• A culture where firefighting is celebrated more than prevention

What it indicates: The team may be trapped in a hero culture that rewards and reinforces knowledge concentration. The hero developer pattern is both a cause and a symptom of low bus factor.

Signal 10: Cross-Team Dependencies Funnel Through One Person#

When other teams consistently reach out to the same person on your team for integration questions, API support, or coordination, that person has become a bottleneck for cross-team communication.

What to look for:

• Slack messages from other teams always directed at one person
• Integration meetings where one engineer represents all the tribal knowledge
• Other teams blocking on your team because "we're waiting to hear back from X"

What it indicates: The bus factor risk extends beyond your team. Other teams' ability to deliver also depends on this one person's availability.

Using This Checklist#

Count how many of these signals you recognize in your team:

• 0-2 signals: Your knowledge distribution is likely in reasonable shape. Monitor and maintain.
• 3-5 signals: You have moderate bus factor risk. Prioritize identifying which specific systems are affected and start knowledge sharing efforts.
• 6-8 signals: You have significant knowledge concentration. Treat this as an urgent priority before a departure forces the issue.
• 9-10 signals: Your team is heavily dependent on one or two individuals. Immediate intervention is needed.

Moving from Signals to Measurement#

Recognizing these signals tells you that a problem likely exists. The next step is quantifying it. Bus factor analysis using Degree of Authorship gives you precise, repository-level scores that tell you exactly where risk concentrates and how severe it is.

ContributorIQ automates this measurement across your entire GitHub organization. Instead of relying on gut feelings or anecdotal signals, you get data-driven bus factor scores for every repository, color-coded risk levels, and trend tracking over time. This turns bus factor from a vague concern into a measurable, improvable metric.

Once you have the numbers, you can prioritize. Focus your knowledge sharing efforts on the systems with the lowest bus factor scores and the highest business criticality. Track improvement quarterly and celebrate the team's progress toward resilience.

Conclusion#

Bus factor risk is almost always visible before it becomes a crisis. The signals described here are patterns that develop over months or years, giving engineering leaders time to intervene. The challenge is not spotting the signals. It is taking them seriously enough to act before a departure forces the issue.

Start by auditing your team against this checklist. Then measure with data. Then improve deliberately. The teams that treat knowledge distribution as an ongoing practice rather than a crisis response are the ones that absorb departures without disruption.