Code ownership is a popular concept, but it emphasizes the wrong thing. It can bring out the worst in a person or a team: defensiveness, control-seeking, power struggles. Instead, we should be focusing on stewardship.

How code ownership manifests

Code ownership as a concept means that a particular person or team "owns" a section of the codebase. This gives them certain rights and responsibilities:

• They control what goes into the code, and can approve or deny changes
• They are responsible for fixing bugs in that part of the code
• They are responsible for maintaining and improving that part of the code

There are tools that help with these, like the CODEOWNERS file on GitHub. This file lets you define a group or list of individuals who own a section of the repository. Then you can require reviews/approvals from them before anything gets merged.

These are all coming from a good place. We want our code to be well-maintained, and we want to make sure that someone is responsible for its direction. It really helps to know who to go to with questions or requests. Without these, changes can grind to a halt, mired in confusion and tech debt.

But the concept in practice brings challenges. If you've worked on a team using code ownership before, you've probably run into:

• that engineer who guards the code against anyone else's changes, wanting all the credit for themselves
• that engineer who refuses to add anything else to their codebase, because they don't want to maintain it
• that engineer who tries to gain code ownership over more areas, to control more of the code and more of the company

I've certainly acted badly due to code ownership, without realizing what I was doing or or why I was doing it at the time. There are almost endless ways that code ownership can bring out the worst in people. And it all makes sense.

We can do better by shifting to stewardship instead of ownership.

Stewardship is about service

We are all stewards of things we own or are responsible for. I have stewardship over the house I live in with my family, for example. I also have stewardship over the espresso machine I use every day: It's a big piece of machinery, and it's my responsibility to take good care of it and to ensure that as long as it's mine, it operates well and lasts a long time. That reduces expense, reduces waste, and reduces impact on the world—but it also means that the object (an espresso machine) is serving its purpose to bring joy and connection.

Code is no different. By focusing on stewardship rather than ownership, we are focusing on the responsible, sustainable maintenance of the code. We focus on taking good care of that which we're entrusted with.

A steward doesn't jealously guard, or struggle to gain more power. A steward watches what her responsibilities are, ensuring enough to contribute but not so many as to burn out. And she nurtures and cares for the code, to make sure that it continues to serve its purpose. Instead of an adversarial relationship, stewardship promotes partnership: It promotes working with others to figure out how to make the best use of resources, instead of hoarding them for yourself.

Stewardship can solve many of the same problems that code ownership does:

• It gives you someone who's a main point of contact for some code
• It grants someone responsibility for bug fixes and maintenance of that code

And in some ways, they look alike. You're going to do a lot of the same things, controlling what goes in or out. But they are very different in the focus.

Owners are concerned with the value of what they own. Stewards are concerned with how well it can serve the group. And this makes all the difference in producing better outcomes.