I’m glad you enjoyed the Succeeding with Agile book. Thanks for letting me know! I also appreciate that you wrote an Amazon review for it. Thanks!

Great book, even after several passes through because I realized I missed something!

Regards.

Thanks to for the links Elliot Jaques. I’m off to check those out now.

Thanks for stirring the pot on a really important topic. I’ve spent the last 20 years trying to understand practical individual, team, and organizational issues of accountability and responsibility; I think what I’ve learned can be additive here.

First, I would guess that the “one throat” vernacular comes from the traditional management practice often called “single point accountability.” In brief, the idea is that delegating and managing accountbilities is the single most important tool, building block, and control mechanism in an organization. The assumption behind the single point notion is that if no one individual is held to account then no one will take ownership (hold on to this idea as below I will argue that “managing accountability” and “taking responsibility” are not the same at all, and, that it is more than semantics). During my career I’ve noticed the more an organization runs on fear, control, and manipulation, the more this single-point-accountability principle is cited as important.

According to a prominent researcher whose work I admire, managing accountability is the only reason for hierarchy. There is one head (CEO, Director General, etc.) who is “held to account” for 100% of the operations and results of the organization. That person frequently is rewarded for success or pays the price for failure. That person also divides his/her accountability into parts and delegates each to a subordinate and holds them to account. This activity cascades through the organization.

Accountability Does Not Equal Responsibility

As you stated above Mike, the terms Accountability and Responsibility are used interchangeably. That’s okay. The issue though is that there are two very different meanings that can be conveyed by either word. For purposes of making the distinction, I will use Accountability for one meaning, and Responsibility for the other (though individual uses vary and I’m not here to nitpick about that).

Accountability is literally “the ability to account for.” It is a story about why or how results did or did not occur. And it’s a complex relationship process of trying to connect the future and the past with prediction, negotiation, cooperation, and interpretation. The way we manage accountability is through the process of negotiating and following up on agreements (i.e., role descriptions and job duties). We call this by lots of names: job design, role description, delegation, accountability management, performance management, one throat to choke, etc.

But here is the kicker: Whether or not you are held to account is not up to you. It is up to someone on the other side of the agreement. We’ve all had the experience of being held to account for something that we did not think we deserved. And we’ve all likely had the experience of not being held to account for good work that no-one noticed. So I like to think of accountability as “external” to me (since so much of it depends on what my management–or customer, parent, spouse, teammate–perceives and does).

As important as it is, there is a dearth of research on accountability. Management researchers tend to avoid it like the plague. Most of what is published is by consultants and successful former executives. I recommend reading Elliot Jaques who spent 50 years discerning the universal laws of hierarchy (most organizations violate these without realizing the systemic problems they unleash). See:
http://en.wikipedia.org/wiki/Elliott_Jaques

Also, read some of the PDF downloads here:
http://www.osun.org/Elliott+Jaques-pdf.html

On the other hand, Responsibility is “the ability to respond.” It is a feeling of ownership. That’s right, a feeling. Responsibility is always in the present and has to do with what happens when things don’t go as planned. The question is, will you respond resourcefully or won’t you?

We may feel a sense of ownership for our job role and duties or we may not. Thus responsibility is subjective. It is completely internal and can not be managed or controlled (though it can be inspired). That is, you can’t make anyone take responsibility (feel a sense of ownership) for their situation.

More than that, Responsibility is transient — it comes and goes for all of us. We are hardwired to avoid owning it as a first response when things go wrong, and things go wrong everyday.

In my experience Responsibility (the ability to respond) always trumps Accountability (the ability to account for). The organizational problem is that you cannot manage feelings, but you can manage accountabilities, albeit poorly much of the time.

This is why we all prefer to work with others who take responsibility. It is also why we want to work on teams that share responsibility, not to diffuse and hide from accountability, but so that someone will respond to what they see needs to be done in support of the project. Needless to say, it is also why truly responsible leadership is important, as is culture, and self-organizing teams.

I’ve found well-intended leaders and professionals enjoy learning the differences I attempted to describe above. They can translate this information into higher performance and greater humanity at work.

Here are some links to more information at my site on this topic.

http://www.christopheravery.com/blog/the-difference-between-accountability-and-responsibility/

http://www.christopheravery.com/blog/team-rewards/

I’d be happy to offer a tele-seminar or webinar on this topic for agile teams, leaders, and coaches. If you would like that, let me know.

http://www.christopheravery.com/contact

The word “single” is actually the most important one here. Like with so many things, Scrum forces dialog, puts pressure on the system, makes you face reality and forces you to make the hard choices.

One of the hard choices to make is about prioritization. The team or teams have a finite capacity, and you can’t get away with not making a choice and saying “do it all!” or somehow overloading the team with what I call “death by five-minute emails”, where a team just can’t go forward because of all of the urgent-but-unimportant crap thrown their way. The whole choke thing should be interpreted as “the focal point of prioritization” or “the eye of the needle”.

An organization is not allowed to say “everything is important” and throw everything at the team, but have to explicitly address the confrontation of different needs and wishes against each other. *The PO serves as that focal point.*

I’ve always explained the statement this way to whomever I’ve coached or taught, but okay, if we need another statement, why not use “the single focal point of priorities”?

Scot, believe it or not, it’s not always (entirely?) management’s fault. I place I worked at this summer (and left due to a dislike of their culture) apparently had a fiasco after I left where a major product turned out to be unusable because of a major flaw in the system. Apparently multiple members of the team knew this and kept it secret until near the end of the project. Another person on the team discovered it and raised alarms. The others managed to get the whistleblower fired somehow, but when management found out, they axed the entire team.

Sure, you could argue that “management fostered a culture that allowed this to happen” but you’d have to micromanage the team to be sure of such things not happening. I’ve yet to meet a developer who likes to be micromanaged, not to mention that it slows everything down hugely if you don’t trust your developers (or anyone) to do their jobs.

The Product Owner maintains the product backlog and sets priority for what feature to implement and when. Of course they shouldn’t make these decisions in a vacuum, but they are the final say when it comes to what to implement when. I recently wrote a Blog posting on this topic [link removed as it no longer worked]

In my experience the Product Owner is responsible for making the case for features that will bring the highest business value (aka highest ROI for the company). If the Product Owner isn’t making wise choices about priority then the ROI for the product may not materialize. In this case, they alone are the “single throat to choke” for not achieving the financial goals of the project.

The majority of the teams that I have worked with haven’t applied this concept as a blanket statement as you describe in your posting. I do agree that the Product Owner shouldn’t be the scapegoat for all project failures. To me a healthy Scrum team (Product Owner and ScrumMaster included) should succeed or fail as one unified entity.