This is part three of a three part series on decisions. Here are part one and part two.

---

Main Ideas

• The role of “code owners” in tech companies is to know and understand the decisions that went into the code that they own. When interacting with unfamiliar code, you should be in contact with its owner regarding questions and changes.
• If you’re trying to grow your career, consider finding code you can own by looking for neglected code or bugs and assuming ownership.
• If another team is more interested than you are in some code that you own, consider giving them ownership of that code.

---

As described in part two, the “theory” of a program is stored in the brains of its maintaining engineers. In this essay, I’ll try to lay out how I’ve seen this work in practice, and how it can form the foundation for teamwork in software in general. Looking back, I think I could’ve avoided a lot of embarrassment and frustration in my early career if I’d gotten the right conceptual model for software teamwork early.

Code Owners, The Knowers of Things

When one engineer wants to know how some unfamiliar piece of their company’s codebase works, there is typically another engineer at the company, often called the “code owner”¹, whose job is to know that. The code owner may direct inquisitors to documentation, but that is, from a teamwork perspective, only an efficiency that saves the owner time—the owner still has unique personal familiarity with the code and its history. In particular, they will have knowledge that is unobtainable from the code itself and is inconsistently documented: what else has been tried, or considered, and why the code is written this way. The code owner is often, but not always, the code’s original author, and when a new owner takes over existing code, they often make heavy modifications (not as a rule, but, as described below, code often comes under new ownership as part of larger changes).

This organizational dynamic is the scaffolding on which teamwork in tech is built. Because code owners are responsible for knowing the theory of their code, they must also review and approve any new changes (because, as the owner, they might be called on to explain them). Non-code decisions are typically distributed in a similar way, though typically not among engineers (product decisions are owned by PMs, sales and marketing decisions are distributed among sales and marketing, etc). In my capacity as a manager, I’ve written documentation specific to my team about ownership, built on this framework.

This foundation leads to two pieces of advice for my former self:

• If you need to understand how some code that you don’t own works, find the owner and ask them
• Before changing code, talk to the owner. They’re responsible for it.

How Do I Get to Own Stuff?

Very often, the most knowledgeable engineers on a team (the tech leads and staff engineers) write the least code. This is a somewhat unstable arrangement: as soon as you work on some code, you’ll be the expert in how that code works and its de facto owner. When you start someplace new, your manager will hopefully ask you to work on code that is unowned, or code whose owner is overwhelmed. You’ll naturally be the new owner.

That said, at my first software engineering job, the company culture was that managers remained aloof and engineers directed their own work. This often left new engineers, and especially new engineers who didn’t understand ownership yet (like me), feeling lost. Thus a third piece of advice: if you want to build your career, and your manager isn’t giving you stuff to own, or you’re generally not sure what to do, try to find something to own yourself. Look for code in your team’s codebase or a feature in your team’s bug queue that the rest of the team has neglected, and make yourself the owner of it (with the assent of its current owners, if any). Mainly, establish yourself as the expert on some part of the codebase instead of bouncing around haphazardly.

Isn’t This Claiming Turf?

It can feel that way, but the best engineers assiduously avoid doing this. The counterweight to the above advice, “find code to own,” is this: eventually you may find yourself the owner of some code that another team cares about more than you do. When that happens, your best option is to give them ownership.

Early in my career, I accidentally became the owner (the prior owners left for other teams) of an authorization library. The library no longer made sense with our company’s new storage systems, so we were replacing it with a new service on which I also worked. The library was still widely-used when I inherited it, but over the next year or so, its user base dwindled to, effectively, two or three other products. My relationship with one user in particular deteriorated rapidly: my TL didn’t want me spending a lot of time on a dying library, but that user still made heavy use of it and, with their own ambitious product goals in mind, wanted to make some sweeping changes. They would send me massive code reviews that I would try to get through at night and in spare moments so I could finish the new service’s projects during the day, which was not the level of responsiveness they wanted. True to part two of this essay, the hardest part was remembering all the details of the old library while learning all the details of the new service, so my work on the new service suffered too.

Things really came to a head when my TL cornered me in a conference room and asked me why my projects were going so slowly. I actually lost it: I told him that nobody seemed to care about the old library but that it still had users and was still running in production and still mattered to the company. And it was taking up a ton of time and I was exhausted. In a moment that I’ve taken with me for the rest of my career, he actually cheered right up. He really just wanted to understand the problem, and now he did.

My TL solved the problem by giving the other team ownership of the authorization library. In retrospect, this was a natural and obvious change, but at the time, I didn’t realize it was an option. Immediately, everything improved. The old library’s ambitious user could make the changes they wanted, I could focus on the projects my new team needed, and I was working a more sustainable schedule while I did it. As far as everyone’s careers went: I still owned code and still had natural places to contribute, but it was all in the new service; I was growing by working on promising new software, and the other team was growing by getting new features to market quickly.

Your Old Company Sounds Weird

I would be remiss not to clarify that not all software teams work this way. It is true, though, that only the engineers involved in the design and implementation of a piece of software can explain, fully, why it is the way it is. Some organizations make this division of knowledge more explicit than others. In my case, though, I wish I’d known about code ownership out of the gate. The organizational dynamics are real and unavoidable, and whether or not they’re recognized, they’re central to the success of software projects and teams.