Six platform engineers support forty product teams. Each team raises roughly 1.5 requests a week and each request costs about 90 minutes of an engineer's time once the context switch is counted. Roughly how much of the team's capacity is interrupt work and what does that number rule in or out?

The assumptions stated

Forty teams at 1.5 requests a week is 60 requests. At 90 minutes each that is 90 engineer-hours a week. Six engineers do not give 240 productive hours: after meetings, on-call, reviews and incidents, 30 hours of focused time each is generous, so call it 180 hours.

The arithmetic

90 of 180 hours is half the team's capacity, spread across all six people rather than concentrated in one. That distribution is the part that matters. Half a team's hours taken as whole days would leave three engineers delivering; taken as two or three interruptions per person per day it leaves six engineers who each have no uninterrupted block, which is why the roadmap does not move at half speed — it stops.

The dominant error term is not the 90 minutes; it is requests per team per week. If it is 3 rather than 1.5, the team is over capacity and the queue grows without bound, and you would see that as lengthening response times rather than as anyone saying so.

Why the other options fail

• A tenth of the team. This is what a request count feels like when nobody multiplies it by team count. Sixty requests a week sounds like a ticket a week per team, which is how the load stays invisible in planning.
• A quarter. A defensible support load, and the figure you get by pricing a request at its handling time and ignoring the context switch. The switch is most of the cost, which is why the same work costs far less in a scheduled block.
• More than the team has. Wrong arithmetic here, and worth noticing as the state one growth step away: at 60 teams with the same rate the team is at 135 of 180 hours, and the queue starts growing.

What the number rules in or out

Ruled in: an interrupt rotation of one or two engineers so the other four keep whole days; a taxonomy of requests with a count per class, because the top three classes are nearly always most of the volume; and self-service for the largest class, measured as requests-per-week for that class trending to zero. When one class is more than 30% of volume, automate it before anything else on the roadmap.

Ruled out: hiring two more engineers as the fix. Request volume scales with the number of product teams, which grows; capacity added this way is consumed by next year's teams. Also ruled out is a strict enabling-team model where the platform only advises: at 60 requests a week somebody is doing the work, and pretending otherwise turns the queue into shadow work inside product teams.

Common weak answers

"Put everything in a ticket system and prioritise" changes who waits, not how much time is spent. "Publish documentation" reduces a class of request only when the request was a question; provisioning requests are not questions. And the honest counterweight: at five product teams this arithmetic gives about six hours a week, a shared module and a README beat a platform team, and forming one is premature.