Service Stewardship: How to Get What You Really Wanted Out of Service Ownership

Many have championed Service Ownership in Agile and DevOps environments to overcome the inherent challenges in the more traditional approach that separates development and operations. While this approach mended some fences, it hasn’t been enough.

In my own experience with implementing service ownership, I would say it was a good first step. In the traditional siloed approach, teams are distinctly incentivized to care about different, often competing aspects of a service (ie. innovation vs stability). This naturally creates tensions when each team is merely fighting to optimize their side of the equation, they fail to take a more holistic approach to value delivery in which both concerns must be balanced. 

Service ownership sets out to have one group of people responsible for a service throughout its lifecycle such that both development and operational needs are taken into consideration from the beginning. This naturally leads to higher quality, more sustainable and maintainable services. 

When I look back, it certainly improved some of the conflicts between development and ops, since teams now had the autonomy to deploy their own code and the responsibility to maintain it. Quality appeared to improve. 

So, with all the obvious benefits, what’s the issue with service ownership? 

For me, it boils down to the word “ownership.” 

While ownership empowered teams to be responsible for their services, it also encouraged them to lean into a false sense of autonomy and become defensive of their territory. While we’d addressed the silo between development and ops, we increasingly saw teams were siloed from each other. Sure, collaboration within a team was improved, but collaboration between teams started to be an issue. 

Teams wanted to manage their services based on their own internal standards and determine their own rules of engagement. Without clear centralized authority over standards, this led to a lack of consistency between teams and made it harder for people to work on services outside their team. 

What’s more, people increasingly focused on the part of the system they “owned” without understanding the context of interrelated components in a large and complex system. And as systems thinking teaches us, focusing on optimizing individual components of a system without taking into account the whole can result in unpredictable and often undesirable outcomes. 

So, while service ownership left individual services in a better state, the system as a whole was not.

What was the solution? After all, having teams be more responsible and autonomous was still desirable. We just needed to broaden the perspective and make it clear that the services fit into a larger picture and that broader collaboration across teams was key. We did that by replacing the word ownership with stewardship. 

Meet Service Stewardship: Can one word make a difference?

While we only changed one word, it dramatically shifted the mindset of teams in how they think about their responsibility. Where ownership has to do with possessing something and having rights over it, stewardship has to do with caring for something that has been entrusted to you. The focus shifts from having control to being responsible, from being possessive to being protective, from working for self-interest to working for others’ benefit. 

[When you go from Service Ownership to Service Stewardship] the focus shifts from having control to being responsible, from being possessive to being protective, from working for self-interest to working for others’ benefit.

In the Service Stewardship model, we made it clear that the business is the real owner of all the services that comprise the broader system which collectively delivers value. While the business entrusts the engineering teams with stewardship of the services, they have entrusted other responsibilities to other parties. Product is entrusted to make decisions about those services, and architecture, security, and finance have been given the authority to make rules and standards by which those services are managed. 

All of this helps keep the bigger picture in mind so that we can focus on improved quality and collaboration across the entire org. The ultimate goal is to have the system as a whole run smoothly, not just individual services. 

What are the roles and responsibilities in Service Stewardship?

The service stewardship model involves multiple different roles that must be fulfilled (either by an individual, a team, or a team of teams). When it comes to roles, certainly not every organization looks the same, but there are flavors of these roles throughout the software industry. We’ll look at a few areas of the pipeline and some of the responsibilities and benefits of each when it comes to Service Stewardship:

• Security and Compliance
• The Business
• Engineering
• Product
• SRE
• Architecture

It is only when each of the roles successfully upholds their set of responsibilities that they can achieve the benefits of service stewardship for the system as a whole, and for each individual function.

Security / Compliance as Service Stewards

Stewardship turns the department of “Thou Shalt Not!” into the department of “Here’s how!”

These are the folks often most directly tasked with keeping the company safe and out of the news. They feel pressure that many of us just can’t understand. In their world, they’re responding to insane global events, hacking attempts, compliance issues, and more. We’re all just one step away from a breach. They get non-stop pressure from regulators, customers, auditors, and the board to prevent the dreaded CNN moment we’ve all become familiar with of late.

But here’s the thing, they really don’t want to make your life harder, quite the contrary in fact. Smart security folks know that there is no company or job without products, and those products have to be secure. Security must be tightly interwoven through the product requirements. The very fiber of everything in the modern product lifecycle needs to be natively secure.

So what impact can security have on service stewardship? And why does it matter?

In most mature organizations, there’s a long list of risks, vulnerabilities, and findings that security and compliance teams are generating through audits, scans, threat-models, etc. There are wonderful tools available on the market for scanning/finding/cataloging risks and vulnerabilities in an environment. 

What there is not a lot of are great tools for fixing those problems. Finding the right person and tracking down all the relevant context about these findings can be wildly labor intensive and time consuming. This leads to finding rates that exceed closure rates. Enter the never ending burndown graph that leads to enormous security backlogs and the outcome of a reputation as the department that always says no.

A well mapped and cataloged stewardship model surfaces all the relevant context. These type of questions get answered:

• “We found this vulnerability, who do I talk to about getting it fixed?”
• “We think this may be a serious risk to the business, who can I talk to about the architecture?”
• “Does this scenario exist in other parts of the product?”
• “What would actually happen if this vulnerability were exploited in real life?”
• “How bad is this compared to other vulnerabilities that we have?”

Service Stewardship transforms security into a team of enablement.

Responsibilities

• Define and communicate security and compliance requirements and best practices that services must adhere. Examples of the kind of requirements that security might define include creating schedules for regular patching, setting timelines for vulnerability remediation, and defining security gates for deployment. 
• Be aware of changes in the overall security/ compliance landscape and alerting teams to new and emerging threats 
• Provide the tools and training necessary for the service stewards to be able to proactively identify and address security issues in their services

Benefits:

• Clear line of accountability for the security of each service
• Easier and faster to remediate critical vulnerabilities because each service has a known steward
• Because services are built by the same people who are responsible for their security, services are naturally designed with security in mind and are more proactively maintained to remain secure and compliant 

The Business’s Part in Stewarding Service

A lot of hand waving goes into defining “The Business”. How many engineers in the product pipeline know what “The Business” does? Who is “The Business”? These are the folks that often lead product requirements, work with customers, sell products, manage administration, etc. They could be an Executive, Head of Sales, Customer Success, etc.

They don’t directly build the product, they’re not committing code or spinning up cloud resources, but their role is extremely important in ensuring that we’re building the right products that our customers want to buy. They’re heavily involved in managing the high level strategy that guides the stewards of a service.

So how does Service Stewardship impact the Business?

Responsibilities 

• Make clear decisions about top-level priorities and risk tolerance
• Clearly communicate business decisions and priorities
• Be consistent about how business value is determined
• Appropriately fund teams to be able to execute on the priorities 

Benefits

• A set of services that meet the business’ needs holistically, including functionality, quality, stability, and security. 
• A clear line of accountability for various aspects of the system. 

Product’s many roles are all inherently service stewardship

Similar to “The Business” in that the Product organization leads the charge on the “are we building the right thing?” bandwagon, they’re much closer to the execution side of the product pipeline. Oftentimes “Product Owners” are embedded directly into the product development teams.

Like many terms in different organizations, we see different “Product” roles and they’re all too often confused. There’s Product Management, Product Owners, Project Managers, and I’d venture to say that many companies use these very different roles interchangeably. We’re not going to go into all that nuance.

So what impact does Service Stewardship have on Product?

Responsibilities 

• Clearly understand and represent the priorities of the business 
• Clearly understand and represent the needs of the customer
• Understand both the cost and value of maintaining the services in production
• Adequately balance new feature work with existing maintenance 

Benefits

• Quality products with fewer customer issues
• Fewer unplanned disruptions due to technical debt and security escalations
• More predictable delivery cadence 

Engineering in a Service Stewardship Environment

Quite simply, the Engineering teams develop the code and products in one way or another. There are several roles here, along with many opportunities for technical specialists. This could be data analytics, software development, devops, build pipeline engineering, etc. So many opportunities for different roles, yet also probably the most understood when it comes to impacts of service stewardship.

So how does Service Stewardship affect engineers?

Responsibilities 

• Maintain their set of services to meet the requirements and standards set forth by security, service reliability, architecture, and product.
• Monitor the performance of their services in production
• Provide on-call support for their services

Benefits

• The autonomy to deploy their own code
• The ability to take pride in delivering a quality product 
• The support needed to proactively maintain services and address issues
• Fewer unplanned disruptions due to technical debt and security escalations

Stewarding Service Reliability

There are so many different definitions for SRE these days. Like the term DevOps, or DevSecOps, this is a term that is understood differently in many companies. Liz Fong-Jones sums it up the most succinctly.

"The goal of a Service Reliability Engineer is to try and make systems easier to operate for the people who are working on them, whether it’s the SRE themselves or on-call or the software engineering team that is building, operating, and running the system."

- Liz Fong-Jones (Tech Lead Journal, Episode #88: - Observability Engineering)

‍

So what impact does Service Stewardship have on SRE?

Responsibilities 

• Monitor system-wide performance and respond to system-level issues
• Define and communicate requirements and standards related to service stability and reliability
• Provide the tools and training necessary for the service stewards to be able to successfully deploy and monitor their services in production
• Work with teams to understand service level agreements and define service level objectives

Benefits

• Troubleshooting production incidents is easier because service stewards are required and incentivized to provide adequate documentation 
• Having a clear line of accountability for each service makes issue escalation faster and easier
• Because services are built by the same people who are responsible for deploying them and maintaining them in production, services are naturally designed with reliability in mind, resulting in fewer production incidents

The role of Architecture in Stewarding Services

While giving autonomous teams the freedom to innovate and release products without interference sounds incredible, it can have the byproduct of significant technology sprawl and unsustainable and unsupportable software if not done properly. We’ve covered already that the primary goal of stewardship is not one of isolated control but one of the betterment of the organization. This cannot be done without Architecture and leadership around standards and technology strategy.

The role of Architects as influencers has never been more important. It’s often the case that an organization will have far more engineering teams than there are architects to support them so there are often parallels between the role of security and the role of architecture when it comes to being viewed as the “Department of No!”. This is the image we seek to break down.

Architecture is a role of influence as much as it is a role of control. If Architecture only ever says no, without providing a solution, vision,  or direction, then teams will seek to avoid and bypass this incredibly important function.

So how does Service Stewardship affect Architects?

Responsibilities 

• Be systems-thinkers when it comes to how services interact with each other to deliver the broader vision
• Document clear technology standards and direction for the components needed to deliver on the product vision 
• Be available as an escalation point for technical challenges
• Build the guardrails for the teams to operate within

Benefits

• When an area of the system is needing change, it becomes clear where that change needs to be effected
• Architectural standards will be well understood across the engineering teams and achievable.
• Broader, systems-oriented architecture will interface better and deliver on product vision

Service stewardship unites perspective across the organization.

When implemented effectively, Service Stewardship brings an organization together around the shared mission, vision, and values. It’s built upon an extremely clear understanding of where requirements come from, where responsibility lies for critically important roles, and why those roles matter. These are just some examples of how we’ve structured teams/roles/responsibilities in past encounters.

Every company is different and your mileage may vary. What is principally most important is that you clearly and deliberately design roles/responsibilities to fit what will work best for your organization.

To learn more about shared context and how service stewardship can help unite your organization, we’d love to hear from you.

The first step to context is making contact: