34% Toil and Two Contractors
A 6-person platform team supports 400 engineers. A three-week time audit shows 34% of hours spent on a request queue (access grants, quota increases, TLS certificate renewals for 120 internal services on 90-day certs), 22% on project work, 18% on-call and incident response, 26% meetings and reviews. Ticket volume grew 40% last year and is projected to grow another 50% as two teams onboard. The director's proposal is to hire two contractors for twelve months to absorb the queue. One engineer says the queue is "just how platform works." There is no self-service portal; the cert renewal runbook has 14 manual steps, including a copy-paste CA password from a shared vault.
1. Is the queue toil? Apply the standard criteria and put a number on it.
Read the worked answer
Apply the six criteria to each ticket class rather than to "the queue" as a whole.
| Class | Manual | Repetitive | Automatable | Tactical | Enduring value | Scales with growth |
|---|---|---|---|---|---|---|
| Cert renewals | yes | yes | yes | yes | no | yes |
| Quota increases | yes | yes | yes | yes | no | yes |
| Access grants | partly | yes | the provisioning, not the approval | yes | no | yes |
The access-grant case is the interesting one. The approval step encodes a real security decision and must stay human. The provisioning after approval is pure toil and should never be a person's job.
Quantify it: 34% x 6 FTE = ~2.0 FTE, or roughly two full-time engineers doing work with no enduring value to the platform. Growth projection is 40% last year and ~50% next year, so on the current trajectory this becomes ~3 FTE within a year.
That number is the argument. It is also why the contractor proposal feels correct - but it is linear: it buys two FTE now and needs three or four later. It is a loan against future growth, not a structure change.
2. Sequence the automation. What do you automate first, and what do you deliberately leave manual?
Read the worked answer
Rank by (volume x time per ticket) x risk, not by loudest complaint.
- TLS certificate renewal - first. 120 services on 90-day certs = ~1.3 renewals/day, forever, with a hard deadline attached to each one. The failure mode is a full outage, and the current process requires a human to copy a shared CA password, which means the credential is spread across the team and cannot be rotated. Automating this is the highest risk-reduction per engineering hour of anything on the list. Use automated issuance with short-lived certs, a renewal monitor that alerts at 30/14/7 days, and removal of the shared password entirely.
- Quota increases - second. High volume, low judgement once a ceiling policy exists. Replace with policy-as-code: the requester gets an instant grant inside published limits, and anything above the limit routes to a human. This turns most tickets into zero tickets.
- Access grants - third, and only partially. Build self-service for the post-approval provisioning with a policy engine and an audited approval step. Do not automate away the approval.
Deliberately left manual: the approval decisions themselves, incident response, and any one-off change touching production state. Automating a judgement call is how you get a fast, confident, wrong outcome.
Target and publish a toil budget: get the queue from 34% to under 20% in two quarters, with a standing cap of 50% as the line above which the team is not allowed to operate.
3. How do you answer the engineer who says "the queue is just how platform works," and how should the contractors be used?
Read the worked answer
Answer the engineer with the growth curve, not with principle.
The claim that "this is just how platform works" is only testable against volume. At constant volume, a 2-FTE queue is a cost. At +90% volume over two years, it is a scaling failure: the queue consumes a growing share of a fixed team while delivering zero enduring value. The team is on a path to being a ticket-processing department that occasionally does platform work, and the 22% project allocation is what will disappear first.
Two supporting points the engineer will actually feel:
- Toil is the strongest predictor of SRE burnout and attrition. Losing one of six people costs more than any of this automation.
- The on-call load (18%) is already squeezed. If incidents get worse, it is because nobody built the thing that was supposed to prevent them.
How to use the contractors: hire them explicitly to run the queue for twelve months while the permanent team builds the automation. Write that into the contract scope. If you hire them to run the queue permanently, you have converted toil into a recurring line item and the audit will show the same 34% next year - with the added problem that the knowledge of how the queue works now lives with people who leave in twelve months.
Set a hard checkpoint: at month 9, re-run the audit. If toil is not under 20%, do not renew.