# Taking over the App squad: 30-day brief

Last 90 days, with the 90 days before for direction. What I was told: "great team, just understaffed." People are shown as dev-1 to dev-6. Source: DevStats MCP.

**Short version:** the first half of what I was told is true and visible in every number. The second half is the one to test. This team is not short of hands, it doubled its output. It is short of attention for each other's work, and half of what it ships comes from one person. For the first 30 days: listen, unblock the old branches, change nothing about how they ship.

## 1. The team at a glance

**People.** 6 people and one bot (Devin) are listed in the squad. 4 of them wrote 735 of the 737 PRs merged. All of them also belong to at least one other squad, so nobody is on App full time.

**Repositories.** One: devstats.

**Cadence.** About 57 PRs merged and 40 deploys a week, one deploy every 0.2 days. Average PR size 281 lines. They run sprints (Cycle 50, 51, 52), of uneven length and with uneven results.

| | Last 90 days | 90 days before | Direction |
|---|---|---|---|
| PRs merged | 737 | 339 | Up 2.2 times |
| Deploys | 513 | 339 | Up 1.5 times |
| PR cycle time, before deploy | 21h 25m | 1d 5h | Faster |
| Issue cycle time | 3d 1h | 2d 18h | Slightly slower |
| Planning accuracy | 62.4% | 53.7% | Better, still uneven |
| Roadmap share | 99% | 98% | Flat, very high |

## 2. What this team is good at

**Shipping, continuously.** 513 deploys in 90 days puts deployment frequency in the Elite benchmark tier, and so are PRs merged per person (9.55 a week) and issues resolved per person (5.29 a week). Volume doubled and the PR cycle before deploy got shorter, not longer.

**Discipline that survived the growth.** 0 PRs merged without review in both periods, with twice as many PRs. Nothing goes in unseen.

**Building the product.** 99% of their issues are roadmap work. 64% of what they merge is features and 14% enhancements. Bugs and hotfixes are 8%. Innovation investment is in the Elite tier (60%).

**Slicing work.** The latest PRs of every person are series of small, named steps: "Release as Deploy" in 5 PRs of 16 to 310 lines, "Kiosk MCP" in 4 PRs of 41 to 319 lines, "Incidents" in 7 PRs of 104 to 554 lines. This is a habit of the whole team, not of one person.

## 3. What is probably frustrating them

**Waiting.** A PR spends 8h 4m being written and reviewed, and 1d 9h waiting: 13h 21m for a first review and 20h 27m between merge and production. Pickup has not moved since the period before (13h 11m then) even though everything else got faster.

**Reviews that got thinner.** Comments per review went from 1.26 to 0.42 and review depth from 4.15 to 0.69, while reviews per PR went from 3.3 to 1.6. The team kept the rule that everything gets reviewed and paid for the volume with depth. People who care about review usually feel that before anyone measures it.

**Too much open at once.** Open tasks went from 53 to 308. 25 branches are open and 13 of them are in coding for 9 days or more with no PR.

**Sprints that do not mean much.** Completion went 31%, 89.4%, 66.7% in three cycles. When a sprint can end at 31% and nothing happens, the team stops believing in the commitment.

**Long days.** 24% of the squad's activity happens after 6pm and 13% after 8pm. Weekends are clean (48 events out of 11,048). Worth asking about, not worth assuming.

## 4. What I inherited

Stuck today, oldest first. The tools return no links for branches, so these are by name.

| Item | Age | State |
|---|---|---|
| Branch `fix/aikido-security-update-packages-48565083-oj7w` | 98 days | No PR |
| Branch `fix/aikido-security-update-packages-51784609-opft` | 92 days | No PR |
| Branch `feature/sup2-812-fix-off-by-one-overlap-between-current-and-previous-period` | 79 days | No PR |
| Branches `feature/dev-3906-add-integration-github` and `feature/dev-3907-add-integration-gitlab` | 58 days | No PR |
| Branch `chore/delete-dead-component-tests-2` | 52 days | No PR |
| Branch `feature/dev-3998-azure-repos-pat-info-icon` | 46 days | No PR |
| Branch `fix/github-projects-syncing-lock-key` | 39 days | No PR |
| Branch `fix/copilot-org-availability-lookback-window` | 37 days | No PR |

9 branches have been in coding for more than 30 days. The rest of the queue is healthy: 8 open PRs with the oldest at 1d 21h, and 1 issue in progress. **The quick win is here:** one hour with the team to close or revive these branches. Two of them are automated security updates that were never merged, which is worth a question of its own.

## 5. Who to ask about what

From the latest 8 merged PRs of each person. A starting map, to be corrected by the team.

| Area | Ask | Who has reviewed it |
|---|---|---|
| Release as Deploy, deploy metrics, WorkBoard | dev-3 | dev-1, dev-4, dev-2 |
| Kiosk MCP, demo data, planning accuracy, dependency security | dev-1 | dev-3, dev-2 |
| Work-timing metrics, PR size backfill, build tooling | dev-2 | dev-1, dev-3, dev-4 |
| Incidents dashboard | dev-4 | dev-1, dev-3 |

**Single owners.** In this sample every area has exactly one author. Review does cross over (everyone reviews everyone), so there is a second person who has at least read each area. The real concentration is volume: dev-3 wrote 47% of the merged PRs and dev-1 30%. Two people are 77% of the squad's output.

## 6. Told vs data

**"Great team": matches.** Elite tiers on deployment frequency, PRs merged and issues resolved per person. Output doubled with no unreviewed PR.

**"Just understaffed": does not match, at least not in the way it was meant.**

- An understaffed team usually ships less and drowns in unplanned work. This one shipped 2.2 times as much with 99% on the roadmap.
- What the data shows is uneven load and scarce attention. One person authors 47%. Reviews are thinner. Pickup is stuck at 13h. Open tasks grew almost six times.
- A hire would add PRs to a review queue that is already stretched. It would not touch the 20h 27m a merged PR waits for release.

This mismatch is the best first question I have: *"I was told you are understaffed. If I gave you one more person tomorrow, what would they take off your plate?"* The answer will tell me whether the problem is hands, reviewers, or focus.

## 7. Ten questions

For the first 1:1s:

1. What is the thing this team does well that I could break by accident? (Section 2)
2. When your PR is ready, how long does it wait, and who do you hope picks it up? (Pickup 13h 21m)
3. Reviews have fewer comments than they did 90 days ago. Do you feel the difference? (1.26 to 0.42)
4. How many things do you have open right now, and how many of those did you choose? (Open tasks 53 to 308)
5. A good part of the activity is after 6pm. Is that a choice or a consequence? (24% after 6pm)
6. For dev-3 and dev-1: you two are 77% of what ships. What happens to the roadmap when one of you takes two weeks off?
7. If I gave you one more person tomorrow, what would they take off your plate? (Section 6)

For the first retro:

8. Cycle 50 closed at 31% and Cycle 51 at 89.4%. What was different? (Sprints)
9. A merged PR waits 20h 27m for production. Who decides when we release, and what are they waiting for?
10. There are 9 branches older than 30 days with no PR. Which ones can we delete together right now? (Section 4)

## 8. Do not change yet

- **The deploy cadence.** 40 deploys a week with every PR reviewed. Do not add gates or release trains until I understand why the merge-to-production wait exists.
- **The review rule.** Everything gets reviewed. The depth problem is real, but the fix is more reviewer time, not a new process.
- **The way they slice work.** Small, named, sequential PRs. It is the reason the volume is reviewable at all.
- **The roadmap focus.** 99% planned work is rare. Before pulling this team into anything unplanned, know what it costs.
- **The sprint ritual.** It is uneven, but changing how a team plans in my first month would be read as a verdict. Ask question 8 first.

---

*Failure rate and recovery time are not attributed to squads in the data (App shows 0% and 0), so stability is missing from this brief. Ask the team how incidents are tracked. The activity heatmap is reported in a single time zone, so it cannot show where people are located. PR cycle time is compared before deploy because deploy time was not recorded in the earlier period.*