Let’s Talk: Full-Service Ownership
We recently surveyed 700 DevOps and IT practitioners around the world and found that more than 80% of organizations have experienced a significant increase in pressure on digital services since the start of the pandemic.
Compared to 6 months ago, respondents reported a 47% increase in the number of daily incidents, and 62% of DevOps and IT responders work at least an extra 10 hours per week resolving incidents.
And most importantly, it’s not going anywhere: 79% of DevOps and IT responders believe digital acceleration has to be their company’s number one priority in 2021.
The truth is, traditional operating models are no longer keeping up with modern application stacks and systems. As systems and teams get more complex, there is no way to efficiently manage everything in a purely centralized fashion. This can be especially painful when it comes to incident response because when incidents happen, siloed systems and teams operating in traditional models can create a domino effect that can negatively impact the customer experience and put your business at risk.
Enter full-service ownership. The software world has changed a lot in the last few years: developers, who once may have been removed from their code in production, are increasingly starting to own their code for the entirety of the product development lifecycle. Tying developers directly to the impact of their work and its performance in production has led to greater accountability and streamlined processes for routing incidents, which has in turn driven down resolution time and helped minimize customer impact and downtime.
To successfully adopt full-service ownership for your organization, it’s not enough for engineers to simply take responsibility for their code—a cultural shift is also required. I sat down with Julie Gunderson from the PagerDuty Community Team to get her candid take on what’s required to think through and navigate this transition.
Q: First things first, what exactly is a service?
Julie: At PagerDuty, we define a service as a discrete piece of functionality that provides value and is wholly owned by a team. It is specific because it refers to an infrastructure composed of distinct services that are written as separate pieces of code, but it also applies to parts of our monolithic codebase and even to external tools. With that universality in mind, we find this definition to be particularly helpful—regardless of your current architectural model—and we encourage its use.
PagerDuty includes concepts of both “technical services” and “business services.”
- Technical services map to underlying pieces of architecture that deliver specific technical functionality.
- Business services are an overlay of the technical services that map back to the product that your business provides to your end users. Business services should A) map back to your business and B) roll up to the technical services that support a given business entity.
Defining the interrelations between the technology side and business side of the product removes ambiguity and gives greater visibility to all stakeholders, customers, engineering, support, product owners, and executives.
If it provides value to other people, it’s a service.
Q: So what’s the big deal about full-service ownership? Why should IT and engineering leaders care? Paint me a picture.
Julie: 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.
“Full-service ownership” effectively turns this fantasy into a reality. It’s an operating model where 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, it unlocks key competitive advantages that make all the difference in today’s digital world.
Q: What is one of the biggest drivers for moving to a model of full-service ownership?
Julie: Services will fail; it’s a fact of operating. How your company responds when that happens is what makes all the difference between consumers staying with you or abandoning your services in favor of a competitor. Full-service ownership helps streamline the incident response lifecycle by empowering engineers to own their services in production, which reduces the number of handoffs and can significantly reduce MTTR when incidents occur. Placing subject matter experts with direct knowledge of the systems they support in the role of first responders, which helps decrease the inevitable chaos and panic that arise from uncertainty.
The role of the developer has drastically changed over the last few years to be more focused on and closer to the customer experience. This is an exciting time to take accountability over the code that is written. Accountability ensures you are doing higher-value work as you have a direct line of sight into how your product/service is actually performing and impacting your customer’s day-to-day.
Q: Where does one even start?
Julie: For your organization, 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. If there are multiple teams contributing, maintaining, and supporting the given service, understanding the boundaries and stakeholders becomes even more important.
At the end of the day, full-service ownership is a shared responsibility across cross-functional parts of your organization. Engineers who wrote code aren’t the only people accountable for ownership of a service—it truly takes a village.
_______________________
Want to learn more about this topic? You can hear more from Julie in this webinar titled “Deep Dive: Driving Cultural Transformation Towards Service Ownership in Cloud & Hybrid Environments” that she held with Kieran Galvin, PagerDuty’s Director of Solutions Consulting. In this webinar, they go over tips for establishing this new operating model at your organization and offer loads of tactical advice on how to define services and how PagerDuty can help govern full-service ownership throughout your incident response process.
For even more information around full-service ownership and how to implement it at your organization, check out our Full-Service Ownership Ops Guide.
To see how you can empower your developers to own their code, visit www.pagerduty.com or start a 14-day free trial today.