Who’s to blame if it all goes wrong? Accountability in agile organisations

It’s amazing what you can accomplish if you don’t care who  gets the credit, (or the blame). Harry S Truman ( in brackets added by me!)

Many agile frameworks, noticibly Scrum, propose self-organising teams to increase productivity, agility and creativity. One aspect of self organising teams is accountability.

In hierarchical teams, common in traditional organisations, it’s clear who is accountable for the outcome of the work. Most teams include some type of leadership or manager role, such as team lead or project manager. If the project doesn’t go well then there is clearly somebody to hold accountable. Of course, you can’t hold someone accountable for an outcome unless you also give them the power to control the resources and coordinate the work. This leads to that person taking control of what the team is doing, which means you no longer have a self-organising team.

So if you want a truly self-organising team, with distributed rather than centralised decision making, then you must also distribute accountability. The two go hand in hand.

(Note that I avoid the term delegated authority in the above discussion. Delegated implies the power and authority are temporarily and voluntarily moved from one person to one or more others. A similar scenario usually underlies the term empowered team. But here we mean that the power and accountability belong to everyone – they are not being given them by another person who really owns them).

You may have heard the saying ‘if everyone is accountable then no one is accountable’. This usually is meant to apply to ‘joint accountability’ where not one but a number of people are accountable for an outcome. But on a self-organising team, I find a much more powerful concept is ‘mutual accountability’. Everyone on the team is individually accountable to everyone else on the team.

So I am accountable to my peers and they are accountable to me. If you are having a problem, I am accountable for recognising that and helping, while you are accountable for letting me know the issue and seeking my help. This directly encourages, or even demands, that we stay aware of our colleagues progress and actively make sure we are helping everyone succeed.

On a practical level, this might manifest itself as a renewed interest by the team in the daily Scrum or stand-up meeting. If I need to be aware of how others are getting on so I can help out if necessary, then the scrum is certainly something I don’t want to miss!

But many of you might still be thinking ‘We still need someone to be accountable for the outcome’, or, in other words: ‘Who should take the blame if things go wrong?’.

Why do we hanker after accountability? Why do organisations strive for demarcation of accountability and role definitions? Is it so that they have somebody to blame if things go wrong? Which leads to the question: are the terms ‘accountable’ and ‘blameable’ interchangable in this context? Are we really looking for someone we can blame? And an obvious follow on question is ‘Are we  designing our organisations for failure?’ So we have someone to blame if things go badly. Or you may prefer to take a more positive spin on this: we need demarcation of roles and accountability to encourage people to work to make the outcome a success. But this is the same justification from a different angle.

What if we designed our organisations for collaboration and success, rather than failure and blameability? What would such an organisation look like?


The Super Chicken Story – as told by Margaret Heffernan

An evolutionary biologist at Purdue University named William Muir studied chickens. He was interested in productivity — I think it’s something that concerns all of us — but it’s easy to measure in chickens because you just count the eggs.He wanted to know what could make his chickens more productive, so he devised a beautiful experiment.

Chickens live in groups, so first of all, he selected just an average flock, and he let it alone for six generations.

But then he created a second group of the individually most productive chickens — you could call them superchickens — and he put them together in a superflock, and each generation, he selected only the most productive for breeding. After six generations had passed, what did he find?

Well, the first group, the average group, was doing just fine. They were all plump and fully feathered and egg production had increased dramatically.

What about the second group? Well, all but three were dead. They’d pecked the rest to death.

The individually productive chickens had only achieved their success by suppressing the productivity of the rest.

To encouarage mutual accountability, where everyone on the team is charged with everyone else’s success, the differentiation of role, job and competence is key.

In most organisations, a role is synonymous with someone’s job: if you are a project manager, your role is project management. If a tester, your job is to test. However, in a self-organising team, where everyone is responsible for team success, this construct restricts our ability to help each other be successful. An alternative is to think of individuals bringing various competencies, skills and knowledge to the team, but not being confined to only practice those skills that are defined as part of their job. Instead, each individual is tasked with helping the team be successful in any way they can – whether or not that is by applying their strongest skills. In this sense, the role, or roles, a person is playing can change day by day, depending on what the team needs at the time. Roles are defined seperatly from individuals. The team has a competency in UX, and one individual usually carries out this role, but it is not only their responsibility. And if they can help another team member by applying the competency, or sharing it, or performing a completely different task, then that’s what they do. Because they are accountable to those others on the team.

Another way of looking at this is in terms of ‘span of control’ vs. ‘span of influence’. In hierarchical organisations, accountability is usually confined to a person’s span of control – that is, what they control directly – the individuals who report into them, whom they control. But in flat, team based structures, there is no direct control. Here accountability applies to your span of influence – that is, each team member is responsible for those they can influence. Depending on the organisational structure, this might extend to your self organising team, or beyond to others in the organisation. For example, some organisations use the ‘advice system’ to support distributed decision making. Here anyone can make any decision on behalf of the organisation, but only after seeking advice on the decision from a number of others. But the decision maker doesn’t have to act on the advice they get from those others – the decision is theirs, and theirs alone. The only rule is that they seek out and listen to the advice. This allows others on the team to exercise their ‘span of influence’. And mutual accountability means each person giving advice must do their best to help you make the best decision. And the decision maker is accountable for seeking out and considering that advice to the best of their ability.

So how do you cultivate a culture that values collaboration and team success over individual performance? There are a few tactics you can employ immediately:

  • Measure and reward ‘helpfulness’. The best people to measure this might be the team members themselves, so look at peer to peer measurements. For example the old 360 degrees evaluations could be developed to this purpose.
  • Define a single, compelling team goal that provides a challenge but is still achievable. Such a goal will ideally require intensive collaboration across the whole team. It will not be achievable by any individual or subset, and so require collaboration to achieve.
  • On your teams, don’t use job titles that refer to a persons job rather than competency, don’t impose a hierarchy or seniority structure, and instead allow a natural structure to emerge. From experience, this results in those that are truly respected by others in the team, for their skills, knowledge and, more than anything, helpfulness, to naturally emerge as the leaders. These are true ‘servant leaders’, elevated to leadership positions by the team because they serve the team so well. They will therefore naturally serve as role models for collaboration, respect and mutual accountability.

The above discussion raises many questions regarding career paths and planning, performance management, hiring, alignment, and so forth. These are topics that more advanced agile organisations are addressing on their journey – and AgileInnovation is helping such companies make the deeper, cultural and structural changes to go beyond mere changes to practices and agile frameworks. If these are challenges you are also facing, get in touch at services@agileinnovation.ie

Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *