What’s the Difference Between Ownership and Accountability?
They’re the magic ingredients for great software teams — but what are they, and how do you get them?
Working in tech, you hear the words “accountability” and “ownership” a lot.
They’re always mentioned together, too, like two sides of a conversational coin. Everybody seems to agree that they’re good, and that we want more of them. We nod earnestly, with a serious and approving expression. “Yes, absolutely. We need to create a strong culture of accountability and ownership.”
Okay, but… what does that mean? And how do you actually do it?
Here’s my very simple starting point.
- Accountability is caring about what happens.
- Ownership is being able to do something about it.
Does that sound like what you expected? Or am I way off? Either way, let me tell you why these definitions capture the essence of good engineering culture for me.
Accountability
The word “accountability” makes people uncomfortable. People squirm a little bit and lower their eyes when you say it — even while they nod and reply, “yes, more of that!”
I looked at a few dictionaries. They tend to define “accountability” as taking responsibility for your actions, and being willing or able to justify them. The reason this makes people uncomfortable is that it sounds a lot like a fancy version of “blame.” It conjures images of mishaps and disagreements; of defensiveness and hostility.
That kind of accountability has no place in good software engineering, or in any healthy workplace culture.
I defined accountability instead as “caring about what happens.”
This is a much more appealing definition. Caring can be a good feeling, rather than a bad one. Engineers care about what happens when we’re proud of the work we’re doing. I’m accountable when I care about the quality of my code and the impact it will have on my fellow engineers and my customers.
If you’re more used to the “blame” version of accountability, consider this. All the things that are normally associated with accountability are things that you’ll already do if you care, and that you won’t want to bother with if you don’t care. People who care about what happens will take the time to make careful decisions. When things go wrong, they’ll feel badly, and will want to learn from it and make it right. They’ll build processes to ensure and enable responsible behaviour from themselves and from one another. These are the people you want working for you.
So where are all these mythical accountable people, and how do you hire them? This type of accountability can seem elusive, because by its nature it’s an intrinsic motivator, not an extrinsic one. You can’t force someone to care, and trying to pay them to care won’t help much either. Sure, you can drag them out of bed in the middle of the night to fix the broken system, but you can’t force them to be happy about it.
Luckily, caring about what happens is the default position.
These mysterious accountable people who care about what happens are actually all of us, including you. Every engineer wants to to a good job, and to produce something that we’re proud of. Despite what people might say, we actually do want to follow the progress of our code all the way to production. We like the feeling of knowing that it’s running safely and happily, providing value for customers.
The problem comes when this sanguine, conscientious state of pride and accountability is gradually and excruciatingly worn down and squandered by incessant, inescapable hoop-jumping helplessness. Each new obstacle wears away at our accountability a little more and a little more, until eventually, we give up. That’s when we start feeling bad, too.
Caring about something that you can’t fix is a horrible feeling. You know what I mean if you’ve ever had to just leave something broken because you couldn’t find the right person to talk to or get access to the right system. And because caring about things you can’t fix feels so bad, our self-preservation instinct eventually kicks in. We stop caring.
The quickest way to make someone not care about something is to make it impossible for them to do anything about it. Which leads us neatly on to the next topic.
Ownership
Watching a software engineer take ownership of a problem can be an inspirational thing. Some of the best engineers I’ve known are people who can assess a problem, understand the real business needs that drive it, and find the right people and tools to create a solution. That’s what taking ownership looks like.
It’s hard work, though. Working as a software engineer can sometimes feel more like bureaucracy than programming. For every code change that goes to production, there might be capacity plans, compliance checks, quality controls and release processes.
All of these roadblocks can be frustrating for an engineer who thrives on solving problems and delivering value.
But that doesn’t mean software engineers are irresponsible or lazy. In organizations where ownership culture is lacking, the problem may be that engineers are required to follow inconvenient processes without being clearly told why. That’s the opposite of ownership, and can easily leave good employees feeling disenfranchised.
Instead of prescribing processes, successful companies educate engineers about their actual business goals and associated requirements. If you think you need to provide evidence of a particular type of security scan or quality control in order to comply with contracts or regulations, don’t just give the engineers a process to follow and a form to fill in. Instead, explain to them why the process is needed, and let them come up with the details themselves. They’ll have questions, of course. Good engineers are logical thinkers and rigorous analysts. But they’re also practical solution finders. Once they understand the real problem that needs to be solved, they’ll take ownership and figure it out themselves. Ownership in engineering is always something that has to be taken, not given.
Ownership also requires trust, and trust is built on accountability. That’s why the two go together so closely. Engineers who care about what happens will want to take ownership and make sure things go well. But to give someone the tools to fix something, you also have to give them the tools to break it. The problem is that an engineer who hasn’t been given the tools to take ownership can easily get so frustrated that they stop caring. And giving the tools to break things to an engineer who looks like they’ve stopped caring isn’t something that any employer wants to do.
To give someone the tools to fix something, you also have to give them the tools to break it.
So ownership requires a leap. On the one hand, it requires the business to trust that their engineers care. But caring about what happens is a vulnerable place to be. An engineer who cares about what happens is putting their own emotional state on the line for the good of the business. So the engineer also has to trust that the business won’t put them in a position where that emotional investment only leads to frustration and powerlessness.
Only when both sides make the leap at the same time can real accountability and ownership emerge.
