# Where we depend on one person

All squads, last 90 days. People are shown as dev-1 to dev-7. Source: DevStats MCP.

**Short version:** review is healthy everywhere: no repository has a sole reviewer, and the busiest one spreads review across four people. The concentration is on the authoring side, in three places: one person resolves 70% of the product issues, one person resolves 65% of the support queue, and one person writes 66% of the site while everyone reviews it as a side job. None of them is doing anything wrong. They are the people we cannot afford to lose for two weeks.

## 1. Risk map

| Area | Person | Share authored or resolved | Share reviewed | Activity | Risk |
|---|---|---|---|---|---|
| **Development project (issues)** | dev-3 | 70% of 343 issues | n/a | 3.8 issues a day | **High** |
| **Support project (issues)** | dev-2 | 65% of 96 issues, 5 of the 12 bugs | n/a | 1.1 issues a day | **High** |
| site repository | dev-7 | 66% of 98 PRs | 5% | 1.1 PRs a day | Medium |
| devstats repository | dev-3 | 47% of 738 PRs | 21% | 8.2 PRs a day | Medium |
| devstats repository | dev-1 | 30% of 738 PRs | 23% | 8.2 PRs a day | Low |
| GTM project (issues) | dev-6 | 69% of 308 issues | n/a | 3.4 issues a day | Low |
| Hotfixes, all projects | dev-1 | 1 of 1 | n/a | 1 in 90 days | Low |

How to read it. The line for concentration is one person above 60%. On the review side nobody is close: in devstats the top reviewers hold 23%, 21%, 17% and 12%, and the Devin bot another 7%. In site the top three hold 30%, 26% and 15%. That is the good news of this memo, and it is worth protecting.

Two rows look worse than they are. GTM is a squad of 4 people, and a squad that small always looks concentrated. One hotfix in 90 days is not a pattern. It is a quiet quarter.

## 2. Top three risks

**1. dev-3 carries the product roadmap.** 239 of the 343 issues resolved in the Development project (70%), 344 of the 738 PRs merged in devstats (47%), and 252 reviews on top of that. If dev-3 is out for two weeks, roadmap delivery drops by more than half and the rest of the squad loses one of its four reviewers at the same time. The second person in the project, dev-1, resolves 22%. Together they author 77% of the repository, so this is a bus factor of two on the codebase and a bus factor of one on the roadmap.

**2. dev-2 is the support queue.** 62 of the 96 issues resolved in the Support project (65%) and 5 of the 12 bugs fixed across the company. The next person resolves 21%. If dev-2 is out for two weeks, customer-reported problems wait, and the people who pick them up will be doing it cold. dev-2 also writes the most thorough reviews in devstats (1.12 comments per review, against 0.42 for the repository), which is a second thing we would lose. It is the usual profile: the person who fixes what customers hit is both the single point of failure and the first candidate for burnout.

**3. site is written by one person and reviewed in passing.** dev-7 authors 66% of the PRs. Reviews come from people whose main work is elsewhere: dev-4 (30%), dev-6 (26%), dev-3 (15%). The signs that this review is approval and not knowledge transfer:

- Pickup time in site is 1d 2h, against 13h 21m in devstats, while review time is 31m 51s.
- Comments per review are 0.28 in site against 0.42 in devstats. The two main engineering reviewers of site left 0 comments in 52 reviews.
- In the latest 60 merged PRs, 13 PRs by dev-7 were merged in the same minute with the same single reviewer.
- 6 PRs were merged without review, 3 of them by one author, including PRs of 3,325 and 1,879 lines.

If dev-7 is out for two weeks the site stops changing, and nobody who approved those PRs could confidently pick up where they left off.

## 3. Mitigation

One step each. Small on purpose.

| Risk | First step | Owner | When |
|---|---|---|---|
| dev-3 and the roadmap | The next report-sized project is led by dev-1 or dev-2, with dev-3 as reviewer and not as author. | App squad manager | Decided at the next sprint planning |
| dev-2 and the support queue | Weekly support rotation: a second person takes first response on new Support issues every other week, with dev-2 as backup. | Support squad manager | Starts next week, reviewed after 4 weeks |
| site review | One named reviewer for site per week, who reviews within the day and is expected to leave at least a question. Batches of PRs are reviewed one by one. | GTM squad manager | Starts next week |

What I would not do: add a second required reviewer in devstats. Review there is already spread across four people and the pickup time of 13h 21m does not need another gate.

## 4. How we will know it worked

Same report, 90 days from now:

- Development issues resolved by dev-3: from 70% to below 60%, with dev-1 and dev-2 together above the 25% they hold today.
- Support issues resolved by dev-2: from 65% to below 50%.
- site: pickup time from 1d 2h to below the 13h 21m of devstats, comments per review from 0.28 to at least the 0.42 of devstats, and PRs merged without review from 6 to 0. The 66% authored by dev-7 can stay. One main author is fine when the reviewers actually know the code.

## 5. How to bring it up

To dev-3 and dev-2: "I looked at where the team depends on one person, and the answer is you, because you are the one who gets the most done. I want to make sure you can take two weeks off without the team stalling and without coming back to a pile, so I am going to move some of that load, and I would like your help choosing what."

To dev-7: "You are carrying the site almost alone, and we have been approving your work more than reviewing it. That is on us. I am putting a named reviewer on it so that someone else knows the code as well as you do."

---

*Shares are counts returned by the tools: merged PRs per repository and person, reviews completed per repository and person, and resolved issues per project and person. Reviews by person do not add up to the repository total (963 of 1,198 in devstats, 100 of 115 in site). The rest is not attributed to a listed player, so review shares are slightly understated for everyone. Bots are left out of the authoring side.*