Why I’ve stopped holding people accountable

EDIT: There are parts of this that I don’t really agree with anymore, I’ve probably mellowed a little overall, but I did turn it into a conference talk that I mostly still stand by.

I’m extremely sceptical about the commonplace notions of “accountability” and “responsibility”. I think there is a fundamental tension between these concepts and a desire to create psychological safety on a team. In this post I’ll talk a little bit about why they are hard to balance, and what I’m now doing instead.

What is accountability?

This is surprisingly tricky to answer. At some level, it means that you own the consequences of some decisions.

It is sometimes understood in contrast to responsibility. An engineer might be responsible for fixing a defect, because they are the ones that actually write the code; whereas a team lead might be accountable for fixing defects, because they are the one that gets to make the decisions about what the team is working on, even if they don’t directly fix the defects themselves.

Sometimes, you will see this expressed as a RACI matrix. This is a grid explaining who are the Responsible, Accountable, Consulted, and Informed individuals for any given process, deliverable, or outcome.

Received wisdom about accountability is that you must only ever have a single accountable person for any given outcome. In the words of this guide, “the buck stops there”.

The best explanation I’ve found uses Star Wars as an analogy. While Darth Vader is accountable for destroying the Jedi, it is often delegated to bounty hunters, who are responsible.

Smells

Code smells are a useful way to describe code quality. They refer to things you might observe that aren’t always a problem — but, like a bad smell, are often the sign of something bad, and so should at least be investigated.

On this metric, the RACI idea stinks. Here are some management smells:

• The single accountable person “rule” is often treated like it needs no further justification. I cannot find a justification for it that matches any context I’ve worked in: most justifications seem to come from Taylorist organisation design or the military.
• It doesn’t actually sound anything like the best teams I’ve worked on. When I think about the most productive, most outcomes focussed teams I’ve worked on, they didn’t behave like this at all. Nobody counted each others contributions. Leadership was fluid, all praise was accepted as a collective, all mistakes were dealt with as a collective. In short, we lived and breathed the Prime Directive all week long.
• It requires mental gymnastics to make it sound blameless. “The buck stops here” really means “I’m happy for you to keep playing at this agile thing, but I need to know who to fire if I don’t get exactly what I want”. It can only ever be a threat. If you don’t believe me, buy a coffee for your friend and then tell them you’ll be holding them accountable for buying the coffee next time.
• The fact that the most convincing explanation of RACI I can find has its roots in the management structure of an intergalactic genocidal military empire ruled by a religious cult raises some alarm bells.

Collective accountability

I’ve already hinted at what I think good looks like: a team of experimenters who have the knowledge and the power to constantly challenge their entire end to end process.

The process is everything and belongs to everyone, so they take both praise and criticism as a collective. Individuals do get feedback, but it is not framed as an evaluation of their performance, it is a useful stream of data thay they are trusted to deploy as they see fit.

When things go wrong, nobody piles “fault” on the person who happened to press the button, instead they reflect on the process and how it allowed a single point of failure to materialise.

Mistakes are celebrated as learning opportunities. This is so baked in to every cultural signal, that the individual who did happen to press the button will have no qualms about standing up in front of the rest of the company and proudly showing off what was learned. The idea that this might be met with some sort of punishment is simple inconceivable to them.

This is my favourite way to build psychological safety. Psychological safety is a necessary pre-requisite for experimentation, because human beings cannot be expected to be honest if doing so will materially harm then.

Moreover, it is inhumane to ask people to work without psychological safety. The emotional labour of trying to do your best while also covering your back is not a sustainable burden.

Note: This does not mean that you can run a team without individual performance management. Performance management can also conflict with psychological safety, and is hard to get right. Paradoxically, however, it is also necessary for collective responsibility — because individuals on the team can’t lean into the process unless the team can guarantee some base level of stability.

Value statements

Of course, you will still have some special roles on the team, and this is where I most often see RACI deployed in agile organisations. Product managers, delivery managers, and tech leads are fairly common special roles.

For these, I’ve started using simple value statements. These are single sentence descriptors of how people in special roles should be evaluating their actions and priorities.

Here’s one we gave to an engineering lead recently:

Value added: The team knows what it means to build something the right way, and is empowered to continuously improve its engineering practices.

These statements must be short, they must not say what an individual is expected to do, and they must describe all value through intended impact on the team.

They must be owned by the team as a whole, and the individuals in the particular roles must be open to the team deciding in a retrospective that the special role needs adjusting or removing. They must have the psychological safety to know their skills will be valued regardless of if their role on one particular team changes.

Here’s why I prefer it this way:

• They are both faster and more fun to write.
• They focus on the positive. They are aspirational and ambitious statements, not thinly veiled threats outlining bare minimum performance.
• They do not conflate individual performance management with a particular project or outcome. While these things are connected, they do not need to be managed at precisely the same time.
• They do not focus on specific tasks, meaning there is less incentive to cling on to a special role, rathern than working to make it redundant through wider team participation or automation.
• They are friendly to the growth of more junior team members, allowing other team members to try specific tasks they have not tried before, and thereby increasing resilience.
• They don’t take particular outputs as a starting point. They allow for the possibility that everything being done requires improvement or replacement.
• They are accessible to people who don’t ever intend to listen to a management seminar.

They don’t completely solve that tension between accountability and psychological safety. At their worst, they might be used as a veneer to cover up threatening behaviour. It’s probably true that all organisations under capitalism are, at some level, threat driven.

Still, I’ve seen them encourage collaboration and disincentivise territorialism — and I think that makes teams just a little bit nicer to work in.