Who is a single point of failure?

I want to know where my team depends on a single person before that person goes on vacation, gets sick or resigns. ## Context - Scope: [all squads | squad name] - Period: [last 90 days]. Shorter windows make everything look concentrated. - Concentration is not a fault. It usually points at my best people. The goal is to protect them and the team. - If I left anything in [brackets], keep what reads as a default (a period, a number of days, the first of several options) and ask me for the rest in one go, before pulling any data. - Write everything, the deliverable included, in the language of this prompt. ## Pull this data from DevStats 1. List Players for the scope 2. PR List, merged, limit 500, fields repository, player_login, reviewers, merged_by, size_total, merged_at. Page through if there are more. 3. Issue List, resolved, limit 500, fields project, player_logins, issue_type, resolved_at 4. Code Review and Player Metrics — review activity per person 5. PR Cycle Time per repository for the areas that come out concentrated — to check pickup time ## How to analyze - For every repository compute two shares: who authors the merged PRs and who reviews them. One person above ~60% on either side is concentration. Use player_login and leave bots out. - Review concentration is the more dangerous one. A sole reviewer is a queue and a knowledge silo at the same time. Long pickup time in that repository confirms it. - Two people who only author and review each other are a bus factor of two. Better than one, still fragile. - Weigh by activity. A concentrated repository with three PRs in 90 days is dormant and low risk. A concentrated repository that ships every day is the real exposure. - Do the same on the issue side per project, and look separately at hotfixes. The person who always fixes production is both a single point of failure and the first candidate for burnout. - Squads of three or fewer will always look concentrated. Say so instead of raising an alarm. - For each high risk, answer one question: what stops if this person is out for two weeks? ## Deliver A memo of two pages at most. If it runs longer, cut rows and sentences, not sections: 1. **Risk map** — table with area (repository or project), person, share authored, share reviewed, activity level, risk (high / medium / low). Highest risk first. 2. **Top three risks** — for each: what breaks if the person is out for two weeks, and the evidence. 3. **Mitigation** — for each: the smallest first step. A second required reviewer, a pairing rotation, a recorded walkthrough, rotating hotfix duty. One step, one owner, one date. 4. **How we will know it worked** — the share that should drop, and to what, over the next 90 days. 5. **How to bring it up** — two sentences for talking to the people named, framed as recognition and protection, not as a problem with them.