Great article Alex, and I'm really looking forward to the next ones in the series.
I'm a big fan of SLOs as they really help de-politicise decisions around technical investments by setting clear expectations up front.
One mistake that I've seen sometimes with SLO is that we take a too narrow definition of what they should cover, focusing mostly on infrastructural requirements and expectations.
I've seen SLOs used very effectively to measure expectations higher up in the stack, such as commitments on data freshness / latency, data quality, etc.
One small final comment: OKRs were not invented at Google but at Intel. Google though is the company that contributed the most to make them popular across the tech industry.
Yes, it's a bit tricky to get it right especially when it's new to the org. The education part shapes the first impression. Google has laid out the framework for a workshop here: https://sre.google/resources/practices-and-processes/art-of-slos/ I'm doing something similar at our company but instead of using a fake service, we use the actual service that the team is responsible for. There's also a 13h course by Google introduced on that page that might be helpful. I'll share more about our experience running these workshops when there's enough insight worth sharing.
Re: OKRs, you're absolutely right. I updated the wording there. "Measure What Matters" (book) played a role in popularizing OKR as a concept, but unlike SLOs I haven't seen a good implementation of them across a large org at 3 companies. What's your experience with OKRs?
Great article Alex, and I'm really looking forward to the next ones in the series.
I'm a big fan of SLOs as they really help de-politicise decisions around technical investments by setting clear expectations up front.
One mistake that I've seen sometimes with SLO is that we take a too narrow definition of what they should cover, focusing mostly on infrastructural requirements and expectations.
I've seen SLOs used very effectively to measure expectations higher up in the stack, such as commitments on data freshness / latency, data quality, etc.
One small final comment: OKRs were not invented at Google but at Intel. Google though is the company that contributed the most to make them popular across the tech industry.
Thank you Sergio :)
Yes, it's a bit tricky to get it right especially when it's new to the org. The education part shapes the first impression. Google has laid out the framework for a workshop here: https://sre.google/resources/practices-and-processes/art-of-slos/ I'm doing something similar at our company but instead of using a fake service, we use the actual service that the team is responsible for. There's also a 13h course by Google introduced on that page that might be helpful. I'll share more about our experience running these workshops when there's enough insight worth sharing.
Re: OKRs, you're absolutely right. I updated the wording there. "Measure What Matters" (book) played a role in popularizing OKR as a concept, but unlike SLOs I haven't seen a good implementation of them across a large org at 3 companies. What's your experience with OKRs?