Code ownership is a culture problem, not a technical one

When a group of teams with roughly twenty engineers writes and supports a codebase, but only two engineers can approve changes to its core parts, it can look like a sensible technical constraint.
Someone needs to protect quality. Someone needs to make sure new features do not break production. Someone needs to preserve the history and context of the system. All of that is true.
But over time, having only a few engineers act as code owners can reduce quality instead of protecting it. Not because those engineers are doing a bad job, but because the ownership model changes how everyone else behaves.

The cathedral model and the bazaar model

At a high level, there are two ways a group of software engineers can organise ownership of a codebase.

The cathedral model

A cathedral building project follows a rigorous plan, and it’s owned by only a few people to make sure that it follows the instructions. Imagine if everyone could do whatever they wanted and asked the group to review the work, that would be very impractical and time consuming. We can treat software in the same way, instead of allowing all software engineers to review each other’s code, only a subset of the engineers will have the final say in approving production-bound code, thus maintaining the quality of the code.

The bazaar model

Now, let’s imagine a completely different scenario. On a bazaar, everyone contributes to make the bazaar work. Imagine if only two or three people tried to control everything that happens at a bazaar, the whole thing would stall, nothing would happen. So, in this case having the participants owning their part helps the bazaar to function properly. The same can be true for software, instead of relying on a few owners that are the gatekeepers of the code, all software engineers have a say. The quality doesn’t come from a few engineers deciding about it, the quality comes from different perspectives, experience, knowledge of specific parts of the code. Having a lot of eyes on software changes can also help to maintain the quality of the code.

Shared ownership does not remove standards. It distributes responsibility for maintaining them.

Starting from the cathedral builder

I joined an engineering team with six engineers, part of a group of four teams, totalling around twenty engineers in total. All teams worked on the same code base, my team owned the system, and was mainly responsible for keeping the system healthy. The system was added to an on-call rotation and all the engineers in the group were added to the rotation, so it was expected that any of the engineers could be called in the middle of the night if needed.

The team was following the Cathedral builder method, having only two software engineers as code owners. They were responsible for approving any pull request that touched the core part of the system. This seemed like a good way to ensure quality and proper review of the code changes.

But, on the other hand I noticed a few problems:

• Lack of motivation to contribute improvements to the system
• Bus factor, having only two people as owners is risky since they might be unavailable at the same time
• Slower review times, especially because the owners were in the same team

Moving in the bazaar explorer direction

Seeing these problems and how they were affecting the system and the software engineers, I decided to move towards the bazaar explorer and share the ownership with the remainder of the software engineers.

At this time, the group of teams had seven senior software engineers, including the existing code owners. This was a good place to start, giving all senior engineers the code ownership. This addressed two problems from the start: seven people eliminate the bus factor, and the senior engineers were spread across all four teams, so the review times went down.

This was a major change in the ways of working of the whole group. So, my first step was to create a plan, explaining the reason for the change and how to monitor it. If this change caused more failures, production incidents, or deteriorating quality, it would be reversed immediately.

Then, I aligned this with all stakeholders, namely: my manager, peer engineering managers, software engineers, and product managers. Once everyone agreed, I started implementing the idea.

First all the senior engineers were made code owners, for a trial period. After monitoring it for a while, the rest of the engineers were also added to the list. And every software engineer from the group was a code owner.

Permission changed behaviour

In the first phase, after adding the senior software engineers, a encouraging pattern started to emerge: the newly added code owners started to propose improvements.

Some examples:

• Some engineers started improving parts of the CI/CD pipeline that had been slowing them down for months
• Others proposed cleanup work in areas they touched frequently but had never felt ownership over
• Some engineers added reusable methods and classes that reduced the effort required to add new features
• One of the new owners proposed to merge two repositories that were separate only for historic reasons

This raised a very interesting pattern: by not having the code owners permission, the senior software engineers felt that they did not have permission to propose those changes before. It was actually harming the collaboration in the group of teams.

Every new software engineer that was added, brought their own experience working with the system, they knew what was slowing them down, brought more eyes to the code. This also meant that code quality didn’t deteriorate, the number of rollbacks did not increase, so the change was made permanent.

After I saw that the first phase was successful, I started planning the second phase: making all software engineers in the group code owners. I aligned with the same stakeholders again before implementing it. And, something that caught my attention was that the software engineers wanted to be part of the code owners group, they felt that this would help them do their work in a better way.

I changed the permissions one more time, including all software engineers in the code owners group. The same pattern appeared again, they started proposing improvements, and the quality remained high.

Ownership has to be practiced, not declared

Most companies that I worked for have a value around ownership, the company where I made this change is one of them. This situation showed a contrast between having ownership as a value while restricting the ownership with processes. This was sending mixed signals to the software engineers.

One of my personal values is to trust by default, if we hired someone, we need to trust them to do good work. If that’s not the case, it is my job as a manager to help them and make sure that they can perform at their best, continuous feedback is a very important tool here. This change was centred around it, by making every engineer a code owner, the message was clear: “We trust you.”. And this gave them the permission to own the software.

Having only two engineers owning the system doesn’t increase quality, it ends up decreasing it because no matter how good these engineers are, they cannot anticipate all the possible scenarios by themselves, the view becomes narrower.

By including more people and broadening the view, the team can surface more potential problems. That’s the biggest value in working in a diverse team.

Shared ownership is not lower standards

Shared ownership does not mean lowering standards. It means making more people responsible for maintaining them.

Having only two engineers own a system does not automatically increase quality. No matter how good those engineers are, they cannot anticipate every problem by themselves. Their view will always be narrower than the combined experience of the group.

By including more people, we broadened the view. More engineers could surface risks, propose improvements, and bring context from the parts of the system they worked with every day. The real measure of code ownership is not who appears in the CODEOWNERS file. It is whether engineers feel responsible for improving the system.

In this case, once ownership was shared, engineers stopped waiting for permission and started acting like owners.