Your manager asks what fraction of your team's time goes to toil. How do you actually measure that, and how do you keep the number honest enough to make decisions on?

## What you are computing Toil is reported as a fraction: toil hours over total engineering hours, for a team, over a window. Both halves need care. The denominator is not headcount times 40. It is the hours actually available for engineering after holidays, leave, training and the overhead that is not toil. Using an idealised denominator systematically understates toil, which is the opposite of the mistake you want to make when you are arguing for investment. The window matters as much as the arithmetic. A week is meaningless — one bad incident swamps it. A year is too slow to steer with. A quarter is the usual compromise, aligned to whatever planning cycle the team already lives in, because the decision the number feeds is a planning decision. ## Where the numbers come from **The ticket queue is the primary meter.** The discipline that makes it work is uncomfortable but simple: every interrupt gets a ticket, including — especially — the ones an engineer fixes in three minutes without being asked. That is the work that never appears anywhere and is the reason measured toil is almost always lower than real toil. The cost is real: you are asking people to file a ticket for something they just did. You buy it back by making filing trivial and by visibly using the data. **On-call records** give you shift counts, alert volumes and incident handling time. Careful here: on-call is only one channel. A team that measures toil purely from its pager will conclude toil is low while the same engineers spend every weekday afternoon on manual access requests. **Periodic sampling** catches the rest. One week a quarter where everyone logs their day into a handful of buckets — toil, project, overhead, incident — is enough. It is self-reported and therefore biased, but you are using it to find categories the ticket queue is blind to, not to produce a precise figure. A worked example makes the shape concrete: ``` Team: 6 engineers x 4 weeks x 40 h = 960 engineer-hours interrupt tickets: 180 x 0.5 h = 90 h on-call handling (logged, 2 rotations) = 60 h manual releases + access requests = 210 h ------------------------------------------------ toil = 360 h = 37.5% ``` The useful move is then to break the numerator down by source, because it is almost never evenly spread. Two or three sources usually dominate, and that list — not the headline percentage — is what you take into planning. ## How the number gets dishonest Four failure modes, and a senior answer names them before the interviewer does. **Invisible work.** The five-minute fix nobody tickets. The engineer who quietly restarts the service every morning before standup. This is the dominant bias and it always points the same way: measured toil is a floor, not an estimate. **Classification drift.** Without an agreed boundary, one engineer books manual releases as toil and another books them as project work. The fix is a short written rule and a couple of worked examples, revisited when a genuinely ambiguous case appears. Numbers that cannot be compared across teams cannot be aggregated, and the first thing a director does is aggregate. **Gaming, in both directions.** A team that wants automation funded has an incentive to inflate; a team whose performance is judged on the number has an incentive to deflate. The moment toil percentage becomes a performance target rather than a planning input, it stops measuring anything. Keep it a team-level planning instrument. **Per-person accounting.** Measuring individuals produces defensiveness and hides the real pattern, which is usually concentration: one engineer absorbing most of the interrupts while the reported team average looks tolerable. Measure the team, but do look at the distribution — a team at 40% where one person is at 80% has a problem the average conceals. ## What the measurement is for A number nobody acts on is itself toil. The measurement exists to feed decisions: whether the team can accept another service, whether this quarter's project slate is realistic, which specific source of toil gets engineering time, whether work has to be handed back to service owners. Before you build the measurement, agree what threshold triggers what response — otherwise you will have a chart and no consequence. And keep the measurement cheap. If tracking toil costs more than a few percent of the team's time, you have added a new source of it and the practice will be abandoned within two quarters, which is precisely how most toil dashboards die.