SLOs work when they create conversations, not when they create compliance

The pattern

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 insight

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.

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)