Which squad needs help?

I run several squads and my attention is limited. I want to know which squad is struggling, what kind of trouble it is in, and what kind of help would actually work. ## Context - Squads: [all squads] (call List Squads, then List Players per squad to count the people, leaving bots out) - Period: [last 90 days], compared with the 90 days before it - What I can offer: [nothing yet, I just want to know | my time | one headcount | a platform or tooling investment] - 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 (each squad, both periods, same filters) 1. PR Cycle Time with stage breakdown, and Throughput 2. DORA Metrics — deploy frequency, change failure rate, MTTR 3. Daily WIP, Aging Issues and Open PRs — what is in flight and what is stuck 4. Allocation — roadmap vs unplanned vs maintenance 5. Planning Accuracy — only for squads that run sprints 6. Benchmarks ## How to analyze - This is triage, not a ranking. Never produce a league table of squads. - A squad needs help when it is getting worse against itself on two or more dimensions at once, or has been stuck in a bad place for both periods. One bad metric is noise. - Name the kind of trouble, because each one needs different help: - Overload: WIP and aging up, throughput flat, unplanned share high. Needs protection and less scope. - Flow friction: long pickup and review, open PRs piling up. Needs ownership and review habits. - Instability: failure rate or MTTR up, hotfixes growing. Needs quality investment. - Planning: low accuracy, scope changing mid-sprint. Needs a conversation with product. - Starvation: throughput and WIP both down with healthy cycle time. There is not enough ready work. That is a backlog problem, not an engineering one. - Headcount is the slowest and most expensive fix. Only overload that lasted both periods and squeezed the roadmap share justifies it. Adding people to a squad with flow friction makes it worse: more PRs into the same review queue. - Compare volume per person, never raw totals. Squads of three or fewer have noisy numbers; say so. - Great numbers with most of the time in maintenance can mean an under-challenged squad. Flag it. - Say which squads are fine. My attention is also an interruption. - A stage that comes back blank in one period (deploy time is the usual one) was not tracked; it did not take zero time. The totals of the two periods are then not comparable: compare the stages both periods have, and say so. - A change failure rate of 0% or an MTTR of zero almost always means incidents are not being recorded, not that nothing failed. Say so instead of celebrating. - Two squads with identical PR, deploy or DORA numbers share a repository, and DevStats cannot split them. Show those numbers once for the pair, and tell the squads apart with the issue-based reports (Allocation, Issue Cycle Time). ## Deliver A memo of two pages at most. If it runs longer, cut rows and sentences, not sections: 1. **Triage table** — squad, state (needs help / watch / healthy), kind of trouble, and the two numbers behind it 2. **Squads that need help** — for each: what is going on in three sentences, the help that fits, the help that would backfire, and the first step 3. **Where my offer goes** — which squad gets it, why, and what should change within 60 days if it works 4. **Ask first** — the questions to put to each engineering manager before acting 5. **Leave alone** — squads that are healthy, in one line each