Code ownership in flux
A mental model for code ownership
“Who owns this codebase?” — you might’ve heard this question before. I was asked this question recently, and it stumped me because I didn’t have a clear answer.
“We do!” I thought , followed by “Right 🤔?”.
Could I just sidestep the question entirely by saying “we don’t”?
It got me thinking about how code ownership transitions between 3 different states, so I jotted down some simple definitions and made the following diagram to represent the mental model:
- Unowned — no accountable party; finding the next-best owner is crucial.
- Owned (not staffed) — has an accountable party, but work isn’t prioritized.
- Owned (staffed) — has an accountable party; development and maintenance are prioritized.
I’ve found these states helpful in creating clarity and focus, both for the team, and its stakeholders.
Ownership state transitions
These transitions tend to occur unexpectedly, and as side-effects. And since most teams don’t have transition checklists readily available, codebases end up…
- becoming unowned — when products are abandoned or teams dissolved, reorged, etc.
- becoming owned, but unstaffed — when products are inherited by new teams or de-prioritized.
“Owned, but not staffed” — a short story
Recently, a team I lead was reorged into a different group. As part of this change, I was asked to own an existing product. I didn’t know what ‘owning’ this product meant or how it would fit into my team’s north star.
The product had previously been moved from team to team, and attempts to sunset it had failed. However, there was just enough reason to keep the lights on since it was generating revenue. Thus, someone had to own it, and I become the next best owner.
As expected, support tickets piled up as our unfamiliarity with the product tripled bug-fixing times.
This started to slow down the team. Sometimes, 2–3 developers were needed for “urgent” fixes demanded by strategic customers.
I recall a conversation with one of the developers on the team.
“We probably shouldn’t own this” he said.
I agreed, responding, “I get it, but leadership needs us to own it for now”.
After discussing the backstory, we moved forward.
A breakthrough moment
After a few sprints of disruptions and rising frustration, something had to change.
My product partner and I discussed the situation — we would only fix the highest priority bugs and make no feature improvements for now. We decided to draft up a small memo describing our stance on this product:
Team X has a variety of competing problems to solve, including high priority initiatives related to company goal Y — the highest priority for the business. Inheriting product Z without extra staff, we’ve decided to label it ‘unstaffed’ to concentrate our engineering on more impactful projects.
This was a breakthrough moment! We had made a decision.
I was able to tell my team to focus solely on the highest priority (P0) bugs, relieving them from additional overhead. I also pinned this memo to our team channel, which provided clarity to our stakeholders about how we’d triage requests.
Being explicit about the state of this product (owned, but unstaffed) unblocked us mentally and allowed us to focus on higher priority work — ultimately towards successful outcomes!
If you’ve run into a similar challenge I’d love to hear from you and learn about how you tackled it.
The learning continues in…
- All chapters — The Engineering Manager’s Pocket Guide
- Chapter 13 — Continuous Team Advocacy
- Chapter 14 — Cadences — engineering manager time horizons
- Chapter 15 — Beyond the Feature Factory
- Chapter 16 — Empowering independent thinking
- Chapter 17 — Managing managers — what changes?
- Chapter 18 — Manager of managers — Leverage is a double-edged sword
- Chapter 19 — Manager of managers — Outcomes over output
- Chapter 20 — Code ownership in flux
If you have any thoughts or experiences to add, let me know! Respond to this post or let me know on LinkedIn. I’m happy to talk about anything software engineering related.
