Introduction

"Innovation comes from people who take joy in their work." - W. Edwards Deming

Fundamentally, full-service ownership is the practice that enables software teams to build increasingly reliable and efficient applications, while also deploying code even faster and more frequently. More importantly, these performance gains extend beyond the software development process to support overall business growth and profitability.

Imagine a world#

Imagine a world where you understand why you're working on something, what its dependencies are, who relies on it, and what exactly it is you're supposed to be delivering. Imagine a world where you can see the impact that your work has on your business and your customers so clearly that you know exactly what to do to continue delivering value to the people you care about.

That fundamental understanding would allow you to try new things, innovate, and solve new and unexpected problems effectively with very little guesswork. You and your teams could work together quickly and collaboratively to deliver business value by making changes without the fear of unintended consequences.

This world exists and it's called "full-service ownership." Full-service ownership means that people take responsibility for supporting the software they deliver, at every stage of the software/service lifecycle. That level of ownership brings development teams much closer to their customers, the business, and the value being delivered. In turn, that unlocks key competitive advantages that make all the difference in today's digital world.

Modern consumers expect convenience, speed, and personalized experiences when using digital applications. For any company to remain competitive, it's paramount that they are able to ship the right features, to the right people, at the right time—and that time must be fast. It's critical to remove any barriers that hinder that speed. Teaching engineers how to code, ship, and own their services in production dramatically improves your organization's ability to ship features quickly to the right people at the right time.

Prior to the adoption of methodologies like Agile and DevOps, organizations functioned in siloed environments where developers wrote big chunks of monolithic code, then handed it off to several other teams before it made its way into production. That model led to long feedback loops, communication gaps, blindspots, and several other unintended human factors that stifle a company's ability to respond to customer needs quickly.

Today, engineers must go far beyond just writing code and handing it off to someone else before it reaches customers. Owning the entire operational lifecycle of application services is the "secret sauce" that unlocks the ability to satisfy modern consumers.

Making the shift#

But many existing teams struggle with shifting into a mode where they have full ownership of their services in production. Why is that? Who exactly are these teams that may be struggling with that shift?

If you're reading this, then it's likely you may be someone on one of those teams struggling with how to make the shift. There are long-established patterns of operational silos in many of today's existing IT organizations. One team owns developing software code, another owns quality assurance, yet another owns the customer relationship, a different team runs that software in production, and so on and so forth. All of those teams may own some part of what can be defined as the overall "service," but those varied responsibilities are often shared across multiple "services" with competing demands and varying levels of involvement by each team.

It can often seem overwhelming to consider exactly how those team structures can be reworked in organizationally effective ways. But it doesn't have to be. You can start building the cross-functional structures that empower your teams to operate in that world we just imagined. It all happens one step at a time.

Regardless of company size, industry, or operating model—someone somewhere in your organization (probably a software developer) is building something that will do something. It could be you! You can call this something a microservice, a piece of functionality, a feature, a slice of a monolith, a component, a shared piece of infrastructure, or an internal tool. For the purposes of this guide, these somethings will all be labeled as a type of "service."

A "service" will be more fully defined shortly. For now, if the software you wrote provides value to other people, that's a service. If you are in charge of maintaining this service and/or delivering it to the other people for whom it provides value (e.g., customers), then you should likely be the owner of that service.

It takes more than building, maintaining, and operating a service to be its "owner," but that's a good start. Full-service ownership also includes communication, compromise, and commitment. If that sounds like a relationship, it's because it is. When you are building something that other people (your colleagues, your customers, etc.) are relying on, it means that you are in a relationship with them.

That more personal model for development may sound like a lot of time, effort, and work. But the alternative is a world of handoffs, obfuscation, confusion, distrust, and frustration. At PagerDuty, it's taken us years to understand how to do it for ourselves, and it's our hope that you can use this documentation to start productive conversations at your organization that can help you reach a more mature service ownership process in the most efficient way possible.

We've put together this "Getting Started" guide to help you navigate the different stages of full-service ownership and provide some insights about which bits we think are helpful, no matter what type of thing you're building. And if you're just starting out with a new full-service ownership initiative, this is a great way to figure out what types of process you want to start trying out for yourself!