Six SREs, Forty Teams, and a Request for Twelve More

• SRE as a ticket queue / ops team. 68% toil against a 50% ceiling means SREs are absorbing work product teams should own. Ticket volume grows with platform adoption, so headcount growth moves the ratio nowhere.
• No ownership boundary. Paging SREs for services they do not own removes the feedback loop that makes developers care about reliability. Nothing forces an SLO, because nothing bad happens to the team that skips one.
• No SLOs and no error budgets. Without them 'reliability' is an opinion and prioritization defaults to whoever escalates loudest - which is precisely why reliability projects get 12%.
• Scaling a broken model. Six to twelve doubles capacity and doubles the queue. Attrition of two out of six in a year is the signal: the model is the problem, not the headcount.
• Platform gaps presenting as tickets. Cert rotation and namespace provisioning are self-service candidates; a 3-week lead time and 22% change failure rate are platform defects being paid for in SRE hours.

Cost framing: every hour of manual provisioning is an hour not spent on the 22% change failure rate, which is the number that actually shows up in customer-facing incidents.

Q1

• Instrument the top 10 services by revenue with SLIs, SLOs and error-budget burn alerts; publish them where product can see them.
• Self-service the top three ticket types: automated certificate rotation, namespace/quota via template plus policy, generated dashboards. Gate: those three categories drop ≥70% in ticket volume.
• Cap toil at 50% and publish the weekly measurement (ticket hours / total hours). Without a published number this target silently fails.
• Publish an on-call readiness checklist and transfer paging for those top 10 services to their owning teams, with SRE as secondary for one quarter.

Q2

• Error-budget policy signed with product, including freeze rules and the exception process.
• Replace the permanent service desk with an embedded model: one SRE for four to five teams on a fixed rotation, with a written exit criterion so it cannot become permanent staffing.
• Change failure rate 22% → under 15% via progressive delivery; lead time 3 weeks → under 1 week via a service template.

Hiring gate: add SREs only against a specific capacity plan (for example, staffing a follow-the-sun rotation), never to absorb the ticket queue. If toil is still above 50% after self-service work lands, the answer is a platform fix, not a hire.

Say plainly: twelve SREs would keep the current model alive for another year, and then we would be back here asking for twenty. Offer a smaller, conditional approval - one or two hires tied to named gates such as follow-the-sun on-call coverage or the self-service build - and put the platform investment in front of them in cost language: a 22% change failure rate and a 3-week lead time cost more than two attrition replacements.

Be equally explicit about what SRE will stop doing: pager triage for unowned services and manual namespace provisioning. Leadership needs to hear that the transition requires product teams to take on-call for their own services, because that is the part that will generate internal resistance. Executive backing for that one sentence is the difference between a plan and a wish.

Also name the risk of the transition honestly: for one or two quarters, some teams will be worse off than today while they learn to own their reliability. If leadership will not absorb that dip, the honest option is to keep the ops model and staff it properly - but then stop calling it SRE.