Leading with Reliability: Applying SRE Principles to Build Stronger Engineering Organizations

Service Reliability Engineering (SRE) has long been the discipline responsible for keeping complex systems healthy, resilient, and predictable under pressure. But the real power of SRE lies not just in the tools, dashboards, or operational frameworks—it lies in its philosophy: focusing on what matters most, measuring the right things, and making intentional trade-offs.

As engineering leaders, we can apply these principles far beyond production environments. This talk explores how core SRE concepts can become high-leverage leadership tools for shaping team culture, guiding prioritization, and driving meaningful business outcomes.

We begin with service criticality, expanding the traditional technical lens to view the entire end-to-end customer journey. Instead of assessing components in isolation, we’ll explore how to map dependencies across teams and systems to surface the true bottlenecks and organizational weak points that impact users.

We’ll look at Service-Level Indicators (SLIs) and reinterpret them at the business level. What does “reliability” mean when framed through customer expectations rather than CPU metrics? We will see how engineering leaders define measurable signals that reflect whether the product is delivering on its intended value.

Next, we’ll dig into Service-Level Objectives (SLOs)—not as uptime percentages, but as promises to customers. We'll discuss how leaders can craft SLOs that articulate what “good enough” looks like for the business, and how these objectives guide healthier conversations around trade-offs, investment, and risk.

Finally, we’ll explore error budgets as a strategic leadership mechanism. Error budgets offer a structured way to balance innovation and stability, negotiate between delivery teams and product, and make aligned decisions about when to push forward and when to fix foundational issues.

Transcript

1. Is service reliability merely an SRE concern?
2. Leading with Reliability Applying SRE principles to build stronger engineering organizations Maxim Schepelin Architect · Booking.com
3. PART 1 Business criticality Which of your systems are truly critical to the business?
4. BUSINESS CRITICALITY Criticality is more than “it makes money” [ TODO ] Amazon price-disclaimer screenshot That tiny tooltip is a legal requirement. Miss it, and regulators come to say ”hi”. Screenshot from amazon.nl, used for illustrative purposes.
5. BUSINESS CRITICALITY How do you tailor the definition of criticality? – Revenue impact – Regulatory compliance – Contractual obligations – …
6. BUSINESS CRITICALITY Know where your hotspots are List your systems and map downtime impact
7. BUSINESS CRITICALITY Let’s use an online store example
8. BUSINESS CRITICALITY System Impact when unavailable Owners search-backend Store looks empty → immediate revenue drop Team A inventory-service No descriptions or photos → store halt Team B discount-engine No discounts shown Team C promotion-service No discounts shown Team C category-tree-api Navigation & filters broken → moderate revenue drop Team D
9. BUSINESS CRITICALITY Two services, one failure — why split them? System Impact when unavailable Owners search-backend Store looks empty → immediate revenue drop Team A inventory-service No descriptions or photos → store halt Team B discount-engine No discounts shown Team C promotion-service No discounts shown Team C category-tree-api Navigation & filters broken → moderate revenue drop Team D
10. BUSINESS CRITICALITY Coupled systems, different teams — coordination overhead. System Impact when unavailable Owners search-backend Store looks empty → immediate revenue drop Team A inventory-service No descriptions or photos → store halt Team B discount-engine No discounts shown Team C promotion-service No discounts shown Team C category-tree-api Navigation & filters broken → moderate revenue drop Team D
11. TAKEAWAY The criticality view exposes where your system and org boundaries get in the way of shipping value What you can do: – Redraw team boundaries around real dependencies – Target architecture improvements – Revise headcount allocation
12. PART 2 Service-Level Indicators What does a “good” actually look like?
13. SLIs How do we define ”good” search?
14. SLIs Metrics that miss the point – Server uptime – API success rate – The number of searches “It works” for the service. It doesn't work for the user.
15. SLIs Get as close as possible to user behavior – Click-through rate on results, by position – Number of searches per session – … Good metrics reflect both the technical health and the value your systems deliver to the business.
16. TAKEAWAY With Service-Level Indicators, you shape how your organization defines value Why you can do: – Identify metrics that describe relevant users behaviors – Use your observability stack to track business metrics – Avoid proxy metrics like number of registered users
17. PART 3 Service-Level Objectives Indicators = the metrics you care about. Objectives = when the metric becomes a problem.
18. SLOs SLO formula: X must be true Y percentage of time – 99.9% of API requests processed successfully – 99% of page loads must be under 300ms – 99.99% database availability
19. SLOs Measure your SLOs [ TODO ] SLO chart
20. SLOs SLOs cascade downstream SLO: 99.9% Dependencies must respect upstream SLOs or be made optional SLO: 99.95% Cache inside Search SLO: 95% SLO: 95%
21. SLOs Business SLO: Same idea, different language TECHNICAL 99.9% of requests processed successfully 99.99% database availability BUSINESS 99.9% of orders processed successfully Now you can measure business impact.
22. SLOs Speak the same language as the business “Last week we lost 2% of orders due to a flaky service. That’s X millions of lost revenue.” With business SLOs you can compare tech improvements and features on equal terms.
23. TAKEAWAY Define Service-Level Objectives in business terms Why you can do: – Use same language with your business stakeholders – Compare features and tech improvements in the same units – Align downstream dependencies with with customer-facing SLOs
24. PART 4 Error budgets THE SLO 99% of orders processed successfully THE BUDGET 1% may fail 10,000 orders → 100 may fail
25. ERROR BUDGETS Plan it and track the spend
26. ERROR BUDGETS Not spending your budget isn't a win You're over-paying for reliability nobody asked for Spend it to innovate: – Deploy more often – Remove unnecessary approval steps – Inject failures to learn how systems respond
27. ERROR BUDGETS What if you run out too soon?
28. ERROR BUDGETS What do you do? Why you can do: – Keep YOLO-ing changes to production? – Introduce a code freeze? – Reprioritize the backlog?
29. TAKEAWAY Use Error Budgets to balance innovation and stability – Use your budget to try improvements – Innovate when you have budget – Keep production stable when budget is low
30. Four concepts. One lens – Business criticality—where your real hotspots are – SLIs—metrics that reflect user value – SLOs—promises in the business's language – Error budgets—balancing innovation and stability Look at your org through a reliability lens Maxim Schepelin · Thank you!
31. schepelin.com/go/book