What Is Service Ownership?
Chances are your organization is working on a number of digital transformation initiatives. It’s no surprise because today’s customers want high-quality, always-on customer experiences, which are leading to increasingly complex digital environments.
System failures are common occurrences. But downtime, outages or slowdowns can negatively affect a customer’s impression of your company, so how you deal with incidents matters. But the more complex your systems are, the harder it is to get them fixed quickly and efficiently.
Service ownership enables your organization to do this better by providing clear ownership, including code in production, and accountability for all the digital services you run.
Q: How is digital transformation changing the way businesses run?
We’re all aware just how much customer expectations have changed over the last few years. If a digital service won’t work, then customers are more than willing to switch to a rival. Some may never come back at all.
This challenge is falling to technical teams to solve. But the huge amount of digital transformation and adoption of hybrid and multicloud environments is resulting in increasingly complex digital operations infrastructures. This is further compounded by the effects of decentralizing teams into lines of business, each with their own tools and workflows. There’s less visibility across teams, and it’s restricting collaboration.
Services will fail; that’s a fact. What matters is how your company responds when it happens, and you can’t do this efficiently or effectively without a centralized view. Siloed systems and teams hurt customer experience and put your business at risk.
Q: What is service ownership?
At its simplest, service ownership is about “you code it, you own it.” It’s an operating model where the people creating and delivering software take responsibility at every stage of the software’s life cycle. In practice, service ownership means that the people involved in designing and coding a product (or software or service) continue to support it once delivered.
Service ownership reallocates workloads to the most appropriate person to manage them. It reduces the burden on traditional support teams by making engineers own their services in production. It can dramatically speed up time-to-fix, a key performance indicator for teams, but can also improve the speed at which organizations ship new features.
It’s incredibly logical when you think about it. If you’re the person who understands the code, knows what its dependencies are and what relies on it, then you’re ideally placed to solve new and unexpected problems effectively and with very little guesswork. You can also work quickly to make changes without worrying about unintended consequences.
Q: What are the benefits of service ownership?
Moving to a service ownership model gives people clear responsibilities across your services. It encourages ownership and accountability for performance as well as for fixing things when they go wrong. There are three key benefits:
- A far better experience for your customers. Service ownership puts developers much closer to the people they’re ultimately working for, the customer. This means they can better see the impact of their work, not only on customers but also the business. It’s more motivating for them, but it also speeds up fixes or updates, because developers see the issues themselves, rather than relying on a second-hand briefing or a support ticket.
- You can focus on what you deliver, not the organizational structure behind it. When you own their code end-to-end, you’re creating an automatic quality control loop: No one wants to be disturbed out of hours because they didn’t check something properly. But an added advantage is that you’re creating a personal connection that can outlive organizational changes. It will always be clear who is responsible for what, even if the company hierarchy changes.
- A significant reduction in mean-time-to-resolution (MTTR). When a service’s developer is first-line support for their own code, fixes happen quicker. Fewer staff need to be involved, and there’s no need for handovers from first-line responders, which can introduce added risks. It quite simply minimizes the impact on your customers and your teams, and vastly speeds up MTTR.
Q: How can organizations navigate this cultural shift?
Shifting to service ownership is not just a case of simply saying to engineers, “You’re responsible for your code in production now.” You’ll need organizational buy-in, supported by senior managers, and a robust change management program.”
For service ownership, as for any significant organizational change, it’s a good idea to start from a position of shared responsibility and compassion. Developers may feel that being called to fix something means they’re being blamed for causing the issue in the first place. It can take time to achieve “blamelessness.”
You might also find that resistance comes from fear of the impact, and with service ownership, that’s often the case in a central operations team. We know that being able to clearly articulate the benefits can help here. So, we would usually find ways to discuss things like the increase that teams will see in visibility and pipeline control as they move to the cloud, or the reduction in manual work — and increase in productivity — that comes from automation, and even about how security and governance are easier to manage.
Q: What steps should organizations take to activate service ownership?
We have seen that it can be difficult for organizations to get started with service ownership, especially as it does involve such a cultural shift. There’s also a real fear of failure in some organizations that can be hard to overcome.
However, it’s worth remembering that many organizations have already taken this journey, so there are a lot of best practices out there that are ready to adopt. These are some of the best practices PagerDuty has gathered in helping customers get started on the journey:
- Stay agile. Agile-type workflows can help teams to identify things that are going well and potential blockers. These can be essential when implementing a new culture and keep teams on track to longer-term goals.
- Start small. It’s well worth choosing a noncritical production system to demonstrate the value you can see from service ownership and measure a baseline to help show improvement, particularly to get the executive support you’ll need to successfully implement change. Measure a baseline of performance for your current production system.
- Don’t play the blame game. Mistakes are inevitable, but people have to be empowered to make decisions and experiment, and they can’t do that if they’re afraid of retribution for making the wrong choices.
- Define services clearly. Services should be set up in a granular way to help identify the sources of problems, and dependencies should be documented to help define roles and responsibilities so incidents and actions don’t fall through the cracks.
These are just a few, but there’s a lot moreout there, from getting the right size teams, to which projects you should prioritize for service ownership and how to document what you’re doing.
Reaping the Benefits of Service Ownership
Service ownership is about shared responsibility across your organization. Yes, you’re asking a developer to be the person who ultimately fixes the code in a failed service, but they can’t do that without an organization-wide adoption of the service ownership approach. You also need the right tools to make it happen.
There may be reluctance from business teams to adopt service ownership. The benefits may not be clear to them, they might be worried about blame, or perhaps they simply don’t understand how it would work. PagerDuty Operations Guides provide best practice solutions and has frameworks available to support organizations on this journey so that they can quickly make that cultural shift and start to see the benefits, for their business and their customers.
