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)

Set SLO ──▶ Monitor
               │
          Incident ──▶ Check SLO
                         │
                     Blame / Finger-pointing

SLO as conversation (effective)

Set SLO ──▶ Weekly budget review
               │
          Budget OK ──▶ Ship fast
               │
          Budget low ──▶ 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)

https://neeraja-portfolio-v1.vercel.app/insights/slos-work-when-they-create-conversations-not-when-they-create-compliance

What's the version of this that your org gets wrong? Drop it below.

#devops #sre #observability #platformengineering