The "Everything Else" Team
In many organizations, the "SRE Team" becomes the catch-all drawer for anything that isn't writing feature code. This is the most common failure mode, and it has a recognizable fingerprint.
What it looks like in practice:
- Scope creep: "If it's not writing feature code, give it to the SREs." DNS changes, SSL certificate renewals, manual database migrations, on-call for services the SREs didn't build and can't modify.
- Toil accumulation: The team drowns in Toil — Google's term for repetitive, manual, automatable work that scales linearly with traffic and provides no lasting value. Restarting a crashed pod manually every Tuesday morning is toil. Writing a self-healing controller that restarts it automatically is engineering.
- Zero engineering time: Because the team is perpetually firefighting, they never have the capacity to write the automation that would eliminate the fires.
Why it fails structurally, not just culturally:
The Kitchen Sink model preserves the wall between Dev and Ops under a new name. Developers have no incentive to build stable, operable code because "the SREs will handle it." The SREs have no leverage to push back because they have no formal mechanism — no Error Budgets, no SLO enforcement, no seat at the product planning table. The result is a team that burns out and quits, taking institutional knowledge with them.
The Google SRE Book recommends that SREs spend no more than 50% of their time on toil. If your team is above that threshold consistently, you are running the Kitchen Sink anti-pattern regardless of what the org chart says.
Interviewers at companies adopting SRE often ask: "How would you know if an SRE team is healthy?" A strong answer references the 50% toil cap: "I'd measure the ratio of toil to engineering work. If SREs spend more than half their time on repetitive manual tasks, the organizational model is broken — the team has become an ops team with a different title. The fix is structural: enforce Error Budgets, give SREs the authority to push back on unreliable services, and carve out protected time for automation work."