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.
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.
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.
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:
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.
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.
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:
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.
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.
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.
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."
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.
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.