The Pitfalls of Code Ownership
The concept of code ownership is not new. It seems that everytime I interview a Software Developer they regale me with all the systems that they “owned” at their prior employers. They are also prone to ask, “If I start here, what will I own?”
Now I love it when people “own” things. I love it when engineers own livesite issues regardless of whether they caused them or not. I love it when they own the root cause of a bug by relentlessly hunting down the issue through countless layers of abstraction. But the verb “own” seems out of place when applied to software components. If the engineer leaves the company, do they take the components they worked on with them? No, they don’t. The business keeps them because the business owns them.
Organizations seem to drill into engineers the concept of ”ownership”. They do this, presumably, to ensure that for every moving piece there is an engineer that is assigned to it. Ownership implies responsibility.
Unfortunately, the formalization of Ownership also implies the existence of lack of ownership. Meaning, it implies “You own this and I don’t”.
The introduction of this belief makes room for two dangerous mindsets:
- “I don’t own that, so i don’t need to know how it works and if it breaks it’s not my problem.”
- “I own Component X and I don’t share your priorities or what you’re proposing to do to my code, so I’m going to be a road block for you.”
#1 is not good. If all the engineers have the mentality that “it’s someone else’s problem” you’ve got a big problem. Every single task will need to be assigned to a specific person. Nothing will get done on it’s own. Inevitably, all the tasks that no one wants to do will go undone. And why should they do them… they don’t own them.
#2 doesn’t usually happen until there are multiple teams working on different objectives. See if this sounds familiar: Team A needs something done in Team B’s area of ownership. For whatever reason, Team B disagrees with Team A’s proposed changes. Egos flare and now there’s a big pissing match that requires a couple layers of management to sort it out. Now, there are frequently good reasons for disagreeing with another team’s design, but it’s easy for egos to get in the way. Ownership fans the ego-flame.
Have you heard this one? “Its a bug in X and Team Y owns X. So, it’s their problem. I sent them an email, but other than that, there’s nothing I can do about it.” Ironically, this is an engineer playing the Ownership card to get out of actually “owning” the problem. He/she is motivated to wiggle out of “owning” the problem because in Ownership-based organizations, it’s very difficult to get other owners to do anything (See problem #2 above). It’s too much of a pain, so the engineer plays the trump card: “I don’t own it. My hands are tied.”
It may be counterintuitive, but Code Ownership empowers developers to pass the buck. And the buck-passing mentality is poison to any kind of org.
Here’s the thing: Good engineers will organically take responsibility for the components they work on frequently. They will identify potential pitfalls of new changes. And they will be less likely to feel threatened when others suggest improvements if they do not consider themselves the “owners”. They will also not be blocked by artificial ownership boundaries when designing new features or fixing bugs. As a result, they will get exposure to more of the code base. That makes them capable of maintaining more components. That makes them more valuable and makes the Development Org stronger.
——
Disclaimer: I have absolutely no scientific evidence to back any of this up. But In my (limited) experience, it seems Ownership is a management tactic that, though it may sound great in theory, causes more problems than it solves.
