Blog

A Guide to Structuring Full-Service Ownership Teams

by George Miranda February 26, 2020 | 6 min read

IT industry research has repeatedly shown that DevOps-oriented teams that can ship software quickly and effectively routinely outperform their slower counterparts in terms of company profitability, market share, and just about every competitive business metric that matters. That sort of success comes from restructuring teams in ways that empower them to move faster and get closer to their customers. But one of the biggest challenges for existing teams is understanding exactly how to transition from where they are today into those more competitive structures.

The mid-February episode of the Page It to the Limit podcast is here to help.

Full-Service Ownership

At PagerDuty, we call that type of operational model “Full-Service Ownership.” That’s a fancy way of saying that service ownership requires a soup-to-nuts (aka “full-service”) approach. In order to be nimble, software delivery and operation teams must have complete ownership over every aspect of the services they support: from design and development, to production operation, and the eventual sunsetting of their software.

Moving fast typically means being small. Or, rather, it means that the level of depth it takes to fully own software and delivery operations goes so deep that the necessary tradeoff is to reduce the surface area of that team’s responsibility (see: the popularity of microservices).

The problem for most organizations more than a few years old is that this simply isn’t the way many of them operate. In the late 2000s and early 2010s, the economics of scale lured many companies into centralizing IT operations into bigger and more consolidated monoliths. The larger size may have saved costs, but it slowed performance significantly, which paved the way for smaller, more nimble companies to disrupt established industry incumbents.

Now, many of those incumbents struggle to figure out how to redesign their monolithic organizations into smaller, more agile components. We may be getting better at redesigning monolithic web applications into microservices, but how do we redesign centralized IT teams with long-established silos and separations of duties into cross-functional full-service owners?

PagerDuty Ops Guides

The PagerDuty Community team writes a number of Ops Guides: handbooks designed to break complex and large-scale procedural tasks into bite-sized concepts, with concrete methods you can use to practice how it’s done. These guides are product-agnostic frameworks that focus on providing both fundamental theory and pragmatic practice. Typically, they do that by showing you how both PagerDuty and our customers have tackled common operational challenges.

Our new version of the Full-Service Ownership Ops Guide provides an in-depth look at the concepts behind building cross-functional teams that own the entire software lifecycle of a service. It also gives you concrete actionable steps you can take to redefine team structures and prepare those new teams to avoid common pitfalls.

Redesigning team structures is typically a part of most digital transformation initiatives. It’s during these types of undertakings that teams start considering how exactly to approach full-service ownership. The new Ops Guide starts by demonstrating how to make a measurable business case in support of full-service ownership teams.

The next step is to define the specific boundaries of any given “service.” A service is a discrete piece of functionality that provides value and that is wholly owned by a team. There’s quite a bit to digest in that statement (see the guide for more in-depth exploration), but the takeaway is that a key first step is to come to a shared understanding of the boundaries of a given service and to figure out who its key stakeholders are. The guide provides a few critical considerations for determining these boundaries in your organization.

We then describe all of the individual functional roles necessary to support a full-service ownership model. Rather than labelling those roles by job title (e.g., software developers own this piece, product managers own this one, etc.), the guide lists functions that must be accounted for in the overall shape of the team. Some organizations choose to dedicate individuals with these skills to each team, while others create embedded roles where individuals in cross-functional teams split time among several teams to contribute these skills. However your organization decides to do this, the important part is that the functions described in this guide are clearly addressed and owned within every full-service ownership team.

The lifecycle of a service section describes different considerations to account for at each phase of the software delivery and operational process: design, runtime, and sunsetting. The section on escalation policies describes a common area of concern for software development teams that have never before operated their software in production: how to design a process for how to respond when things go wrong. The on-call shifts section then prepares teams to go on call for the first time.

Like all of our Ops Guides, this isn’t a prescriptive flowchart of exact steps to take. Instead, it’s a primer of practical considerations, lists of questions to answer to help you prepare a fleshed-out plan to build your own process, and examples of how companies like PagerDuty have built those same types of processes. Ops Guides are frameworks designed to help jumpstart your organization by sharing the lessons we’ve learned when embarking on those same journeys.

Page It to the Limit

We launched a new podcast, Page It to the Limit, back in December (thanks for all the listens and support!). The goal of that podcast is to talk about common challenges we all face when running software in production, in bite-sized accessible ways. Typically, we do that by interviewing guests from across many different facets of the IT industry in short 30-minute segments.

Last week, we published a different sort of episode. Scott McAllister and I sat down to chat about full-service ownership, what it means, how to use this guide, and what we’ve learned in the process of its development. This episode is a quick intro to a more in-depth guide. Check it out here:

For a more in-depth look at how to create more empowered, high-performing, agile software delivery and operations teams that help deliver competitive business outcomes, check out the Full-Service Ownership Ops Guide.

Let us know what you think of the Ops Guide or the podcast by reaching us on Twitter @PageIt2theLimit.