I expect that to many people, “accountability” seems like a euphemism for “blame”. That’s hardly surprising, given how it’s used in the media and news.
From a recent Vox article on the opioid epidemic:
An overwhelming majority of Americans want pharmaceutical companies to be held accountable for the opioid epidemic, according to a new NPR and Ipsos poll.
From an op-ed by Chris Hughes, a co-founder of Facebook:
The government must hold Mark accountable….Any day now, the Federal Trade Commission is expected to impose a $5 billion fine on the company, but that is not enough.
“When you look at the [criminal case for reckless endangerment of EMTs], he needs to be accountable for those actions because he knew the risks that were involved.”
These uses of “accountability” feel very tied up in desires for justice and punishment: firings, fines, convictions. Consequences.
In the workplace, though, I see many uses of the word “accountability” for a different, less negative idea, one that I think is closer to “ownership”. This use is about who’s owning the final decision-making to ensure a project is successful. The accountable person is the one that knows what’s going on, what has already happened, and what needs to happen next.
That meaning of “accountability” is really useful, because I want to give my team accountability for their work; that empowers them to do what they think is best and gives them the recognition for it. Accountability is also important to divide up clearly, because otherwise, people pay a huge coordination tax, accidentally stepping on each others’ toes, getting frustrated trying to reach consensus. It’s not surprising that I see “accountability” often being used among managers.
My use of “accountability” isn’t meant to be about who gets punished when something goes wrong, since focusing on apportioning punishment or blame is often harmful to effective teamwork.1 But I can’t control how language evolves; when I’ve tried to use “accountability” in the way I describe above, I too often see my team look uneasy—maybe on guard for the threat of punishment. Every time, I feel I need to reassure folks and explain the difference I see between “accountability” and “blame”, and when I do, it seems like I’m rowing upstream against the current. I don’t want my team looking over their shoulder or trying to cover their ass.
That’s why instead of “you’re accountable for this”, I’m going to start saying “you’re the driver for this”. The driver is the one at the controls, keeping things on track, taking detours, and course correcting to get things done. It conveys the same meaning, but without the implied threats. At the end of the day, what matters to me is that my team can work effectively together to build great products, and the word “accountability” is doing more harm than good for that. I doubt I’m alone in feeling this way, and I think it’s time for that use of “accountability” to end.
Software engineers might have seen this idea that throwing blame is counterproductive in the form of blameless postmortems. Instead of focusing on who should be punished or shamed, these postmortems focus on learning and self-improvement, creating a safe space for really understanding what happened and preventing similar issues in the future. The book Difficult Conversations calls this moving from a “blaming mindset” to a “problem-solving” one.↩
One of my favorite things about High Output Management was the way Andy Grove treated managing organizations as a special case of managing systems. He starts off his book with a model of a company as a breakfast factory.
Similarly, Acolyer in this blog post applies ideas from optimizing distributed systems to the scaling of organizations:
I was thinking about the advice I should give to the CTO of a fast-growing company struggling to maintain velocity amongst all the competing demands on his time. And it occurred to me that the Universal Scalability Law has a lot to say about this situation.
This also reminds me of Will Larson’s posts lately on systems modeling of organizations, such as this one on modeling reliability of an organization:
We’re doing an annual strategy refresh on how we’ll approach security, reliability and such, and incorporating modeling into developing these strategies has been a surprisingly effective brainstorming tool.
I’ve found posts like these to be very useful, so hopefully you will, too.
When I was in high school, I took a class that attempted to integrate many subjects through the study of one time period in history. What I remember most fondly from that class was our study of Bauhaus, the art school in Weimar Germany that started 100 years ago. This amazing website celebrates that history with details of the people, the art, the settings, and the classes. Well worth an evening to peruse!