When Shared Ownership Means No Ownership

Problem

Some organizations have many services (any size -- micro to large) that are usually owned and supported by different teams. Some of those services -- especially large ones -- have multiple owners or their various parts have different owners. In reality that frequently means that no one owns them; when there tend to be too many people involved, no one cares enough to be genuinely involved.

I found that disturbing because when we wanted to improve, or just maintain, those services no team committed to getting their hands dirty and everyone kept shifting the responsibility to other teams.

In the long run, this prevented us from maintaining high quality and keeping these services up to date, as they were not taken care of in the same, accountable manner, as when a single team was solely responsible for a service.

Actions taken

First off, you should define and put down in writing what it means to own a service. This will give you and your teams clarity on responsibilities and accountabilities. Do not forget to share this within your organization.

The next step would be to create a visual map of what belongs to whom by drawing a box for each service, mapping your whole architecture, and then dividing this map with dotted lines, defining what areas belong to each team.

Tip: You can also create a supporting document to give more clarity on the domain for each team outlining why one service belongs to a specific team and not to the other and also explaining what every service does. When mapping the domain knowledge and establishing who is the most knowledgeable about a specific problem or an aspect of a service, it is also useful to include who has maintained it in the past. Eventually, you will end up creating high-level documentation for all services -- what every service does, what it interacts with, in which language is written, etc. and that will help you grasp the whole picture and allow you to re-think your original sketch and reshuffle pieces if needed.

In addition, you can apply a similar process inside larger services. This can be harder within highly coupled monoliths, but it’s still a useful exercise to define ownership to parts of it - by parts of the code, by function, etc.

With a visual map in-hand and supporting documents in place, you can easily assess how services are distributed across teams and check for how balanced this distribution is.

The goal is to have one clear owner for each service or part of it. If you see that one service still has many maintaining teams, try to consolidate into one team or at least, if that is not possible, clearly define parts of it and assign them to one team or the other. Assign a fair share of your architecture by ensuring that there is no team that gets too much and one that gets a small share, transfer services between teams if needed.

In the end, you can start working on your roadmap alongside the service map, anticipating the future relationship that a particular service will develop with other services and how that will affect the team in the future. If there are big features that will depend upon changes to a particular service owned by another team, you may want to transfer services between teams in order to avoid creating cross-team dependencies, making it easier for a team to build new features single-handedly.

Lessons learned

• While it almost comes as a self-evident truth, it’s often overlooked that shared ownership in fact means no ownership.
• Clarity and purpose are essential to teams’ progress -- for driving new features and maintenance of existing services -- a well-defined ownership model is a key ingredient to that.
• As a leader, you should think about what ownership means to you and the organization -- this sometimes differs across companies. As your company grows, your architecture and teams keep growing. Sharing your insights with the organization, being extra clear and transparent will help teams understand what they are responsible and accountable for.
• Clear ownership still works well as part of internal open-source models. There needs to be a designated owner/maintainer, even if everyone else is pushing changes to the services.