Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

When Shared Ownership Means No Ownership

Collaboration
Ownership

30 June, 2020

Jose Pettoruti
Jose Pettoruti

Director of Engineering at Currency Cloud

Jose Pettoruti, Director of Engineering at CurrencyCloud, elaborates on his claim that shared ownership of services means no ownership at all and shares some tips on how to overcome shared ownership problems.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Identifying the “Right” Problem to Solve

2 December

Anurag Jain, a leader role at Fortinet, speaks about finding a solution when for a project the apparent needs were not the thing to be solved.

Alignment
Conflict Solving
Collaboration
Strategy
Anurag Jain

Anurag Jain

Leadership Role at Fortinet

Increasing Collaboration Within Your Team

2 December

Anurag Jain, a leader at Fortinet, discusses his strategy to promote growth within his teams, using servant leadership concepts.

Scaling Team
Personal Growth
Leadership
Internal Communication
Collaboration
Anurag Jain

Anurag Jain

Leadership Role at Fortinet

Specialization vs. Wearing Many Hats

23 November

William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.

Internal Communication
Collaboration
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Transitioning From Tech to Product Management

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, talks from his experience on how to excel in a PM role when transitioning from tech roles.

Ownership
New PM
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

Mergers and Acquisitions: Collaboration tools hold a key to bringing cultures together

23 November

Neelima Annam, Sr Director Information Technology at Outmatch, shares how something as minor as collaboration tools can be a BIG issue during mergers and acquisitions.

Acquisition / Integration
Internal Communication
Collaboration
Neelima Annam

Neelima Annam

Sr. Director Information Technology at Outmatch HCM

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.