Team & key-person risk
Which critical systems depend on one engineer?
If one engineer wrote most of a critical system, losing them can stall fixes and releases. CodeDD reads Git history to show who owns each system, whether they are still active, and where there is no backup.
pricing-engine · business-critical
41%written by one engineer
| Contributor | Status | Share | Domains |
|---|---|---|---|
| Maya Chen | Active26 days ago | PricingMLData | |
| Tom Becker | Active3 days ago | API | |
| Luis Ortega | Left5 months ago | DevOps | |
| 9 other contributors | Mixed | AppAPI |
Tom Becker, the next most active contributor, works mostly on the API layer. Luis Ortega left five months ago.
Trusted by
Beyond the org chart
Spot single points of failure in the team.
The org chart may list forty engineers, while Git shows that one of them wrote 40% of the billing system and is the only one still working on it.
Ownership
The org chart hides who built each system. CodeDD shows who wrote what, so you see which systems rely on one engineer.
Activity
A main author may have stopped working on a system. CodeDD flags owners with no commits in 90 days, so you see which systems have no active owner.
Backup by area
Some areas depend on one active expert. CodeDD counts active people per area, so you know which areas need a second person.
Concentration
What one person carries.
The top owner's share of each repository and of the entire estate. A high share in a business-critical repository carries more risk than the same share in a side project.
Maya Chen · Active · what she carries
| Repository | Files | Share of repo | Of estate |
|---|---|---|---|
| pricing-engine | 2,090 | 29% | |
| cube-pipelines | 836 | 8% |
Coverage
Two experts can still be one owner.
An area can have two active developers and still depend on one of them for almost all of the code. You need both views before calling it resilient.
| Area | Top owner | People | Experts |
|---|---|---|---|
| Data Processing | 99% | 2 | 2 active |
The highlighted row is the API 31% chip from the summary card.
Across the portfolio
Compare key-person risk across the portfolio.
The same ownership and coverage measures for every portfolio company. Company D has three business-critical systems with one active owner, and 31% of its code was written by people who have left, so its retention and hiring plan needs attention first.
Portfolio key-person risk
Last 90 days · five portfolio companies| Metric | Company A | Company B | Company C | Company D | Company E |
|---|---|---|---|---|---|
| Concentration | |||||
| Top owner sharelargest business-critical system | 14% | 41% | 26% | 38% | 9% |
| Single-owner systemsbusiness-critical, one active owner | 0 | 2 | 1 | 3 | 0 |
| Continuity | |||||
| Areas without backupfewer than two active experts | 0 | 3 | 1 | 4 | 1 |
| Code by departed authorsno commits in 90 days | 4% | 12% | 6% | 31% | 9% |
The hire plan
Where a hire reduces the risk.
CodeDD checks every material technical area for sufficient active experts and a sustainable workload per person. Each gap becomes an approximate number of hires, so the fix can go into the plan and the budget.
| Area | Active | Code | Per person | Coverage |
|---|---|---|---|---|
| Machine Learning | 1 | 62K | 62K | +1 hire |
| Data Processing | 2 | 20K | 10K | Handover |
| Application Code | 3 | 48K | 16K | Covered |
Across the investment cycle
Build a team without single points of failure.
Pre-deal tech DD
Find the systems and technical areas that depend on one engineer, and price retention or a handover plan before signing.
Hold period
Add a second active owner to each of those areas, and track ownership spreading across the team quarter by quarter.
Pre-sale preparation
Show buyers that every critical system has several active engineers who know it.
FAQ
Questions.
What does the ownership percentage mean?
The share of the audited files each person wrote, by file count, shown per repository and for the entire estate. The same person is counted once across repositories, matched by email. 35% and above is Critical, 25–34% High, 15–24% Medium, below 15% Low.
What counts as a single point of failure?
A business-critical system or technical area with only one active owner. Every change there depends on that engineer, and fixes and releases stall if they leave.
What counts as active?
A commit in the last 90 days. 91 to 365 days is dormant, and anything longer is stale. An owner with a high share and no commits in 90 days is flagged, so a system whose main author has left is easy to find.
How is coverage per area measured?
Each audited file is labelled with a technical area, such as application code, data processing, machine learning, API or DevOps. An area needs at least two active experts and a sustainable workload per developer. Both thresholds can be changed in the app.
Can I compare companies across a portfolio?
Yes. The portfolio view shows the same measures for every company: top owner share, single-owner systems, areas without backup, and code by departed authors, on the same definitions and the same 90-day window.
Are the hire numbers a recommendation?
They are an approximate headcount to close the coverage and workload gaps at your current settings, for use in the plan and the budget. Areas under 5k lines are listed but are too small to justify a hire on their own.
What about the exit scenario figures?
The app also estimates what losing the top owner would cost in hiring, handover and ramp-up time, sized from the code they own and your hourly rate. Treat it as a planning estimate and read it after share, activity and coverage.
Do bots count?
Bot accounts can appear in the ownership ranking if they authored files, so read the rows for people when you assess the team. The coverage and activity views can hide bots.
How is this different from Development activity?
This page shows who holds the knowledge of each system. Development activity shows what the team spends its time on: new work or maintenance.
What data do you store?
Authorship from Git, meaning who wrote which audited files and when they last committed, plus the per-area labels and the scores derived from them. Source code is not stored.
See who holds the knowledge in a team you are evaluating.
Run CodeDD on your own repositories, or book a walkthrough to see which systems depend on one engineer and where a hire would reduce the risk.