Edith Harbaugh and Jessica Craig invited me for a fireside chat at LaunchDarkly to talk about the second edition of the DevOps Handbook. The update added more enterprise case studies, a full section on DevSecOps, and integrated learnings from both the SRE movement and DORA research. The original book was heavily oriented toward startups and tech companies; the second edition acknowledges that large, regulated organizations face different constraints and need adapted patterns.
I used the barrel metaphor throughout the conversation: imagine a barrel with staves of different heights. The water level is determined by the shortest stave. In a value stream, your throughput is limited by the tightest bottleneck. The instinct is to optimize what you’re good at, but the leverage is in finding and fixing the lowest stave. Most organizations have that bottleneck somewhere unexpected – not in their CI pipeline, but in change approval boards, or in how they communicate with suppliers, or in how they handle incidents.
The SRE versus DevOps debate came up, and my position is straightforward: SRE, DevOps, and agile all point at the same thing from different angles. They’re all about reducing friction between people who build software and people who run it. The terminology differs, the practices differ slightly, but the underlying principle is identical. Arguing about which is “correct” is like arguing about which side of a coin is the real one.
We discussed the tension around autonomous teams. Full autonomy sounds great until you have fifty teams all making independent infrastructure choices, and now you have fifty different deployment pipelines, monitoring stacks, and security postures. Platform teams emerged to solve this, but they carry a real risk: becoming the new silo. If the platform team starts acting as a gatekeeper rather than a service provider, you’ve recreated the exact problem DevOps was trying to solve. The key is treating the platform as a product with internal customers, not as a mandate from above.
Psychological safety came up as the foundation everything else rests on. You can have the best tooling, the most automated pipeline, and the most comprehensive monitoring – but if people are afraid to admit mistakes, afraid to ask questions, afraid to push back on unrealistic timelines, none of it matters. My working definition of DevOps at this point is simple: it’s what you do to overcome the friction created by silos.
Watch on YouTube — available on the jedi4ever channel
This summary was generated using AI based on the auto-generated transcript.