When Shared Ownership No Longer Works

Problem

I had a number of product teams that were working on the same technical and data foundation. They were building on the same data layer and were in the awkward position of needing a lot to be the same, but also a lot to be different. I also had an infrastructure team that was responsible for a broad array of things but was very much a DevOps team--the folks who would help upgrade a package or switch from Python 2 to Python 3, but not get into the nitty-gritty of data pipelines. A pain point that grew as the product teams was that all the common systems would only get attention when they broke, and whatever team needed them most would be the one to fix them. It escalated as more teams were added; it wasn’t great when there were two teams, it was even less great with three teams, but with four teams it was a complete mess.

Actions taken

My first approach was to try to take an existing team, whose product was the closest to a “base” product that we had, and encourage them to take ownership of some of these shared systems. They didn’t say no, but they didn’t do a great job either. They had their own needs and product goals, so even though they tried to help out other teams, they didn’t have the bandwidth or attention to be successful.

I realized that if I wanted to make progress on the tech debt in those shared systems, I needed a team that could be focused on it, without the distraction of external customers. A group with more understanding of the product and data ecosystem than our infrastructure team, who could serve multiple products. It felt like a lot of platform investment for the number of teams that we had, but I nevertheless convinced my business stakeholders to try it.

I had a few individuals passionate about these goals who helped launch the team with a well-developed one-year roadmap. Within six months of the team’s launch it had made a massive difference to everyone’s health and happiness. They owned the systems that before didn’t get much attention and were able to think about problems that were common across all the teams, and invest in areas I never thought of investing in. I was always in favor of better testing, but I never realized the dramatic reduction of build breakage we would experience almost the instant a solid data testing platform was rolled out. Testing data changes went from impossible to trivial. By focusing a group of people on platform investments, I got huge returns in short order.

Lessons learned

• Listen to your people who are telling you about their pain points. When a team is not executing well and has many things on their plate that usually means that they are unable to focus and then you need to pull things off their plate and give them focus. I had several teams with split focus and by introducing a team that would take some responsibilities off their plate, I was able to improve their focus.
• A shared code without an owner is a disaster waiting to happen. As soon as you delegate the responsibility to someone and provide them with space to be responsible, you will get better results.
• Shared ownership of tech debt doesn’t work.