# Which squad needs help

App, Support and GTM. Last 90 days, compared with the 90 days before. What I can offer: my time. Source: DevStats MCP.

**Short version:** one squad needs help and it is GTM. Its problem is not speed or people. Its work is done in about an hour and then waits more than a day for someone to look at it. Support is worth watching for three stuck items. App is fine and should be left alone.

## 1. Triage

| Squad | State | Kind of trouble | The two numbers behind it |
|---|---|---|---|
| **GTM** (4 people) | **Needs help** | Flow friction | PR pickup 1d 2h, up from 21h 27m. 6 of its 8 open PRs have waited 15h or more. |
| Support (10 people) | Watch | Stuck items, not overload | 3 issues in progress for more than a week, the oldest for 4mos 1w. Unplanned work 77%, down from 100%. |
| App (8 people) | Healthy | None | Roadmap share 99%. Planning accuracy 62.4%, up from 53.7%. |

This is not a ranking. The squads do different work and only the comparison of each squad with itself counts. GTM is a squad of 4, so its numbers are noisy. The pickup problem shows in both periods and in today's queue, which is why I trust it.

## 2. The squad that needs help: GTM

**What is going on.** GTM doubled its output (98 PRs merged against 49) and planned more of its work (roadmap share 43%, up from 22%). But a GTM PR takes 43m 31s to write and 31m 51s to review, and waits 1d 2h in between. Pickup is 95% of the time a PR spends before merge, up from 82%, and it was already slow 90 days ago.

Today's queue shows the mechanism. 8 PRs are open. 6 are documentation PRs from the same author, waiting between 15h 13m and 22h 7m. GTM has no reviewer of its own: its PRs are picked up by engineers from other squads when they have a moment. Work in flight grew with it, from 67 open tasks to 233.

**The help that fits: ownership of review.** Someone has to own the GTM review queue, by name, with an expectation of a first look within the working day. This is a habit and an agreement, not an investment. It is exactly what my time can buy.

**The help that would backfire: a hire.** Another author in GTM means more PRs into a queue nobody owns. Pickup would get worse, not better. For the same reason, do not ask GTM to "move faster". The work is already done in 1h 15m.

**First step.** This week, sit down with the GTM and App managers and agree on one named reviewer per week for the site repository. Clear the 6 waiting PRs in one sitting the same day.

## 3. Where my offer goes

**My time goes to GTM, for two sprints.** Not to do the reviews. To set up who does them and to check that it holds.

Why GTM and not Support: Support's trouble is three specific items that one conversation can unstick. GTM's trouble is structural and has lasted both periods. It will not fix itself, because nobody inside GTM can fix it: the reviewers belong to other squads.

What should change within 60 days if it works:

- PR pickup in GTM from 1d 2h to below App's 13h 21m.
- No GTM PR open for more than a working day. Today 6 are.
- Review size down from 535 lines per PR, the largest of the three squads. Smaller PRs are easier to pick up.

If pickup has not moved in 60 days, the agreement did not hold and the next step is a required reviewer rule on the repository.

## 4. Ask first

**GTM manager**

- When a PR is ready, who do you expect to review it? Does that person know?
- The 6 documentation PRs open now: are they waiting for review, or for the features they document to ship?
- 57% of the work is still unplanned, down from 78%. What arrives without warning, and from whom?

**Support manager**

- "Update PHP" has been in progress for 4mos 1w. Is anyone working on it, or is it parked with the wrong status?
- Two customer issues have been open for 1w 3d and 1w 2d. Are they blocked on us or on the customer?
- Roadmap share went from 0% to 23%. Was that a decision, and do you want it to keep growing?

**App manager**

- Open tasks went from 53 to 308 while the squad shipped 2.2 times as much. Is that the size of the current project, or is work being started faster than it is finished?
- Your engineers are also GTM's reviewers. What would a weekly rotation cost you?

## 5. Leave alone

- **App** is healthy. 737 PRs merged against 339, 99% of the work on the roadmap, planning accuracy improving, 1 aging issue, and the oldest open PR is 1d 21h old. Its pickup time has been flat (13h 21m, from 13h 11m) while volume doubled. My attention would be an interruption.
- **Support** does not need me yet. Unplanned work fell from 100% to 77%, open tasks fell from 142 to 107, and 3 of its aging issues were opened today. Ask the three questions above and look again in a month.

---

*App and Support work in the same repository with the same engineers, so their pull request numbers are identical and are reported once, under App. Failure rate and recovery time are not attributed to squads in the data (every squad shows 0%), so instability could not be assessed per squad. Company-wide, the change failure rate is 3.1%, down from 4.4%.*