LinkedIn Draft — Insight (2026-04-02)
End of week. Here's the thing I kept coming back to:
SLOs work when they create conversations, not when they create compliance
Most SLOs are set once, filed in a doc, and forgotten until an incident. The teams getting real value from error budgets use them as a weekly forcing function — a number that makes the reliability vs. velocity tradeoff visible to engineers and product managers in the same room.
SLO as compliance (common): SLO as conversation (effective):
Set SLO ──▶ Monitor Set SLO ──▶ Weekly budget review
│ │ │
Incident ──▶ Check SLO Budget OK Budget low
│ │ │ │
Blame Finger-pointing Ship fast Freeze features
│ │
Engineering + Product aligned
The non-obvious part:
→ An SLO that's never violated is almost always a problem. Either it's too loose (you're over-investing in reliability) or it's not being measured honestly. Both cost money in different ways. The goal is a number that occasionally creates productive tension.
My rule:
→ Review error budgets in sprint planning alongside features. If engineering and product aren't having an uncomfortable conversation once a quarter, your SLO isn't tight enough.
Worth reading:
▸ Alex Hidalgo — 'Implementing Service Level Objectives' (O'Reilly, 2020)
▸ Google SRE Workbook — Alerting on SLOs (ch. 5, free at sre.google)
What's the version of this that your org gets wrong? Drop it below.
Top comments (0)