Where engineering time goes

All squads. Last 90 days, compared with the 90 days before. Counted by issues. Source: DevStats MCP.

1. The answer

Of every ten engineering days, six and a half go to the roadmap and three and a half go to work nobody planned. Ninety days ago it was the other way around: three and a half planned, six and a half not.

The same work cut by purpose says the same thing. 65% of it builds or improves the product (36% new things, 29% improvements), 25% keeps the lights on and 10% goes to the team's own productivity. In the previous period, keeping the lights on took 47%.

2. The chart

3. What feeds the unplanned work

The 35% that is not roadmap is 33% unplanned work and 2% unplanned maintenance. Where it comes from, largest first:

1. GTM, about 69% of it. 57% of GTM's 306 issues were not planned, roughly 174 issues. GTM is 41% of all issues in the company, so it moves the company number more than any other squad.
2. The support queue, about 29%. 67% of Support's 95 issues were unplanned and another 10% were unplanned maintenance. That is what a support queue is. It is by design.
3. Bugs: small. 12 bug issues in 90 days. Only 3 took longer than 2 days, and the slowest took 3d 22h (SUP2-923, a redirect after the GitHub Copilot setup).
4. Hotfixes: one. A security fix, resolved in 13h 52m.
5. App: almost nothing. 1% of App's 343 issues were unplanned. The product squad works on what it planned.

On the code side the picture agrees. Bugs and hotfixes are 8% of merged PRs, down from 11%. Quality problems are not what takes time from the roadmap.

4. The gap

Leadership expects 70% roadmap and 30% everything else. The real split is 65 / 35, a gap of 5 points. Ninety days ago the gap was 37 points, so 32 of them have been closed.

Read one level down and the gap changes shape. App and Support together, the two squads that build and run the product, are at about 83% roadmap, above what leadership expects. The company number sits below 70% because of GTM.

5. Two levers

1. Plan GTM's week before it starts. If GTM went from 57% not planned to 33%, that alone is about 73 issues, the ten points we are looking for (ten points is 74 issues). What it costs: a short weekly planning pass where GTM work goes into a cycle or a project before anyone starts it. It costs no engineering time. It may also show that much of this work is planned in someone's head and simply never labeled.

2. Decide what the support queue is allowed to cost, then stop counting it as a surprise. Support cannot plan which customer problem arrives. It can plan how much room it keeps for them. Set that budget explicitly (today it is 77% of Support's issues) and label recurring maintenance as planned. Planned maintenance is 0% in both periods, which means nobody uses the label, not that nobody does maintenance. What it costs: triage discipline, and an honest conversation about whether 23% is all the roadmap we want from that squad.

What I would not do: squeeze App. It is at 99%.

6. Confidence

Medium for the planned and unplanned split. Low for anything by type of work.

• 78% of resolved issues have no type (582 of 744 are "Other"). In GTM it is 304 of 306, and outside GTM it is still 63%. Anything that says "features against bugs" from issues is blind for most of the work, so I did not draw conclusions from it. The type split above comes from merged PRs, where 17% are untyped.
• Story points are not used. The story point run returned zero in every category, so this is counted by issues only. That overweights small items, and GTM has many small items.
• Rework is rising, worth a second look. Rework went from 13.7% to 17.7% of merged code, up 4 points, while new code fell from 47.6% to 32.3% and refactoring rose from 38.7% to 50.1%. Part of this is deliberate cleanup. If rework is still climbing at the next read, we are starting to pay twice for the same feature.
• Fix before the next read: require an issue type when an issue is created, use the planned maintenance label, and decide whether GTM tasks belong in the engineering number at all.

---

The shares by squad in section 3 and the 83% in section 4 are estimates: each squad's issue count multiplied by its allocation percentages, which the tool already rounds. They add up to 34% not planned, against the 35% the tool reports for the company.