George introduces PagerDuty’s Ops Guides: process (not product) manuals that help you figure out how to introduce leading-edge operational models to your teams.

“Ops Guides are something I think are fairly unique for our industry. They’re sorta like a whitepaper, but they’re actually useful. They’re a step-by-step process guide. They’re vendor agnostic. And they’re free open-source frameworks designed to walk you through how to accomplish newer–more modern–types of operational tasks.”

Scott proves he read the guide by describing the concept behind the name.

“It’s when those who build something are responsible for supporting it all through every single stage of its lifecycle. It brings developers and product closer to their customers and it leads you to writing better software.”

George mimics an old man yelling at a cloud: this won’t work in my org! Scott takes on software engineers who think being on the hook to support production software means that they’re responsible for fixing everything. George then references an XKCD post to pick on his favorite pet peeve: thinking that running software in production won’t make you a better developer.

“Take this Dev and shove it up your Ops!”

George discusses how a process guide works. It’s not a mechanical set of steps to follow: it’s a primer that frames the problem and the goal in a specific way so that you can then uncover your specific challenges and make a plan that’s right for you.

“How do we take this audacious marathon goal and figure out how to break it down into steps? When it comes to doing that, the idea isn’t to follow a flow chart—step A, then B, then C—it’s more that you have to think about your organization and your stack in certain ways, and in these vague orders, and that’s what helps you make a real plan for your team vs. this generic thing we’ve written,”

Scott cracks open a discussion on how the framework approach to defining this new pattern might pan out when going between organizations.

“If you use titles with so many presumptions baked into them, you don’t entirely step back to really examine where a function really lives. We shouldn’t put job titles next to that. We should tell you this is what the function should be. We’re just going to describe all the things and then you can decide how to assemble those cross-functional teams inside your own org.”

We cover how to plug into discussions about the content via Github and where to find the web version.

A discussion unfolds around why a step-by-step guide to restructuring how teams own their services in production is better for brownfield teams.

“If you have a big monolith—not just a monolithic code base, but a way of operating that’s monolithic in nature—and you want to start breaking that down into smaller components, then this guide is particularly useful.”

We debut a new show segment: our picks for stuff we’re all about right now.

George

Scott

Show wrap up