In speaking with some agile teams and agile project management consultants I occasionally hear two statements that I strongly disagree with. These statements are that “the product owner is the single wringable neck on the project” or that the “product owner is the one throat to choke.” These each mean the same thing, that in an agile project, the product owner is the person ultimately responsible for the success of the project.
This is wrong, however. On an agile project—as well as in many other cases—there is no single, wringable neck. To say there is a way of releasing the rest of the team from responsibility. And this is clearly wrong.
From a manager’s perspective it can be nice to always be able to point to one person and say, “That’s who I’ll blame if things go wrong.” Howerver in agile project management the “one throat to choke” argument is false. Historically, there may be one person who takes the blame for things when they go wrong, but that doesn’t mean that person was responsible for the failure.
Take the case of a sports team. At the start of a new season, who on a sports team do we say we’ll hold responsible for winning the championship? The coach? The owner? The star player? Teams that win championships find a way to win games, no matter the circumstances. If the game plan isn’t working, the coach and players adapt. If the star player is having a bad day, someone else steps up. The whole team feels responsible for winning somehow, some way. If the team loses, it may be tempting to blame one person or another, but the team knows that each one of them is accountable for the loss. It’s never just one person’s fault. In reality, there is no single, wringable neck.
Consider a nonsports analogy. If both parents were involved in raising a child (and assuming one of them isn’t abusive or obviously negligent), which parent is the one throat to choke if a child grows up to be a convicted felon? There is a reason we call it a parental unit. Raising a child is a team effort.
The only way to ever create an environment of shared ownership and responsibility is to let go of the notion of having one throat to choke. That doesn’t mean no one is responsible. That means that on a successful team, the team members must do their part, or even go beyond a perceived role, to ensure that the team reaches its goals.
Thank you Mike for starting this blog!
I am interested in knowing how the dynamics of POs (yes, multiple POs) play out when the POs have orthogonal backlogs. One is customer focused, the other would be technology focused. The goal is to ship new features while keeping our technology current.
Disagreeing just slightly: I have found the “one throat to choke” to be very effective in my current consulting situation. This particular firm is mired deeply in a stew of hyper-over-matrix, management by consensus, right of infinite appeal, and of course, a process heavy waterfall that makes even hardened Agile consultants cry.
I have been very clear about the distinction between Pig & Chicken, which translates here into accountability of the Team to deliver upon their commitments, versus PO and the “single throat”. What that represents here is that one person owns establishing decisions as they relate to the project’s scope and priorities. In fact, we have a half dozen POs which each own various MMFs, and there is no “Uber PO” that oversees the prioritization cross MMF. So in this case, it is the collection of 6 POs who represent a Steering Committee. However, each independently and singularly owns their MMFs.
This is important because what happens in this sort of organization is someone pops up 2 months after a MMF is delivered and starts playing the “right of infinite appeal” game. Here is where empowering that single PO over that function area has tremendous benefit.
I guess I see the original concept as perhaps a legacy of what the folks were facing as they first started driving Agile change into these sorts of companies.
I might be able to help on the accountability vs responsibility front. One thing I’ve noticed in talks about Scrum is a tendency to look at the members of the team as the only part of the organization. As has been pointed out, Scrum applies responsibility to the entire team. Accountability isn’t relevant to Scrum, it’s tied to the organization’s hierarchy.
Your Product Owner is held accountable by their boss for whatever product(s) they were assigned to own. That boss is outside of the Scrum framework. If the product is failing, the Product Owner is the one who explains why to the people above them and the Product Owner is the one expected to fix the problem. A programmer is held accountable by their supervisor for showing up on time, actually performing the job they were hired for, etc. That supervisor may or may not also have a role within the Scrum team.
Just as the entire team is resposible for the project, the entire company is responsible for the success of the company. However, if something is wrong with one product, you don’t hold a company-wide meeting to discuss why. The king of the castle asks his appropriate subordinate, who asks his appropriate subordinate, etc, etc, all the way down to your Product Owner, who sits down with the team and figures out the answer (or already knows due to activities within the Scrum process) and passes it back up his chain of accountability.
In short, in Scrum, everyone is responsible and accountability is not relevant.
Sorry if that was a bit of a ramble.
You people are crazy.
What if your check didn’t go through? Or if your salary was cut? Would it be okay for the accountin gteam to talk about not assigning blame, or Results isn’t the point? It’s stuff like this that makes the rest of the world think us engineers are out of touch and naive.
Look – in order for a business to succeed, it needs to make a product. The product needs to have a certain number of features, it needs to work, it needs to be done by some particular date or another. If not, the business can’t succeed. If it doesn’t exceed, PEOPLE DON’T GET PAID. All ofthis flowery “we’re all a team” business is fine, but it falls apart when the money stops. It reflects an unrealistic perspective on sotfware development.
My perspective might come from my background – I’m an MIT engineer who has started a company. I appreciate and respect the complexity of software development, and the risks inherent in the waterfall method. However, the landlord doesn’t take story cards as payment, and neither does your mortgage company. RESULTS MATTER. EXECUTION MATTERS.
And by the way – when a sports team starts doing poorly, the coach gets fired. Period. SOMEONE HAS TO BE RESPONSIBLE, ALWAYS. Why? Because prediticability is critical. Revenue needs to e predictable so payments to YOU are predictiable (which, ironically, you demand). The predictibility of revenue is directly tied to the predictability of software development! Saying otherwise makes people think we don’t get it!
Mike,
Great stuff and you have definitely given me a good reason never to talk about “the single wringable neck” again. My interpretation of this phrase was different again, I always used it to emphasise the importance of the PO owning their backlog and listening to the people around them (clients, team, environment).
I love the idea catchy phrase to start a conversation and make things easier to remember however your article and the comments above have illustrated that any catchy phrase is open to a vast array of interpretation and abuse (unintentional or otherwise).
First let me say how much I enjoy reading this blog. It is always entertaining and educational.
I agree that thinking like “single throat to choke” thinking can often be counter productive to agile organizations because it can actually errode collaboration within a Scrum team if the PO is that person.
Funny thing is that for organizations that actually talk about it, from my experience, it is rare to see it acted upon in our overly politically correct business climate.
As soon as you want to do a retrospective type review of what happened, the politically savvy pull out the trump card seems to end any investigation that could help avoid a similar issue in the future.
That card is “Well that is in the past, we are where we are now and we need to deal with it” and then the fait accompli …”You’re not being a team player”
Finding ways to enlighten folks in environments like I describe is a real change management challenge. Any suggestions?
My 2 cents: During a ‘Contracting’ open space with Mikael Lundgren in Stockholm, we noted that we still need to lobby more with our customer’s purchasing department to get from accountability to responsibility (and I might add now, real business benefit). So in a sense the product owner is a proxy fighting the accountability issues, whereas involved people in general strive for sustainable benefits on either sides (supplier and consumer). btw – a leo.org thread puts the following example for responsible: “termites were responsible for the damage” – if you invert the sentence you may get “people will be responsible for success”. Thanks for this rich blog, Mike.
Mike,
Over the years you have brought great insight to the Agile methodology, and we all appriciate that effort. Except in this case. I agree greatly with the statement “the product owner is the single wringable neck” should the product be wrong in the customers eyes. Here is why. As the Product Owner is the liason between the team and the customer/end user it is the P.O.’s job to be correct in articulating what is desired by the customer. If the P.O. is wrong then it is not the fault of the team, this is the fault of the P.O.
Now when you bring management into the picture and they are looking as to what part of the process broke down, then you can look at the team, the SCRUM Master, the PO, etc. However these people are not to blame shouldthe customer reject the product.
Sorry Mike I just disagree with you on this one.
Bob Small
If a member of your team is not pulling their weight, it’s not really a Scrum problem. If Bob in the corner plays video games all day instead of working, handle it like any personnel issue. If he gets to stay and continue goofing off, you’re better off looking for a better company, especially if it’s a pervasive problem. If he’s let go, you can mention in a retrospective that X amount of the available effort wasn’t really present which impacted what got done. Either way, you avoid any political issues and move on in a constructive manner.
I may be making some assumptions here.
Mike, would you say that a Product Owner has a function within Scrum, but also a function outside of Scrum? Seems to me that the Product Owner’s responsibilities outside of Scrum could certainly get his neck wrung, but his functions within Scrum would not. And so when consulting on Agile/Scrum, one should either omit the concept or clarify that separation.
I think this phrase is a terrible of dysfunctional management.
Andrew Ryan says “RESULTS MATTER. EXECUTION MATTERS.” – and that’s very true. However if a team doesn’t deliver a working product in a reasonable timeframe, whose “accountability” is that? I think it’s way past the “team” level. It’s the MANAGEMENT. So if Andrew’s company doesn’t get to “done” (i.e. release) I will blame Andrew’s company.
Here’s the thing, someone else said above – “In my experience, management needs a single point of accountability.” and the thing is THAT SINGLE POINT IS THE MANAGEMENT ITSELF. That’s what being a manager is about. Leading.
It’s not fault of the the team, or the PO, or the SM, truly, if your company doesn’t get to delivery Mr Manager, it is YOUR FAULT. You allowed the crappy culture to develop, or sustain, you allowed the expectations to be unreasonable, you are the one who didn’t listen to advice, or seek it out in the first place, you are the one who didn’t get their business plan sorted out to make sure you had budget to survive for long enough to get to execution and YOU are the one who didn’t make sure the team got to execution. The Buck Stops Here and “here” is the desk of the CEO. Even if you got a team of lazy, ignorant layabout that’s STILL YOUR FAULT because you hired them, or allowed them to continue to be layabouts without doing something about it.
It’s not SUCCEED OR FAIL it’s SUCCEED OR LEARN TO SUCCEED and the Management is the one responsible to make sure that’s the way the organisation learns to function at all levels.
Anything less is still that small-minded mentality of “I would have been a business success if only YOU PEOPLE had worked harder” just scaled up to large organisations.
So yeah, great post Mike.
Hi Mike,
Great post!
As an aside, the term “parental unit” is an allusion to the old Coneheads skit from Saturday Night Live, and it referred to an individual parent, not to two parents acting as a “unit.” (The coneheads regularly referred to one another and to other individuals as “units.”)
However, in principle I agree with the idea: a functioning team works together to nurture a product just like a functioning family works together to nurture a child.
Wringing necks, besides being entirely immoral, unethical, and illegal, will not get you anywhere as a team. The right thing to do is to get regular feedback from real users and work together as a team to deliver value.
The product owner, by having a singular focus on business value and priorities, plays an important part in achieving that, but he cannot and should not do it alone. Therefore, he cannot and should not be held solely accountable.
Whoa. I wonder where this post got picked up that we had so many new comments on it today. It’s good to see such interest in this topic. I’ll try to reply to some of the issues that came up and were addressed to me but so many were just great discussion among people here, which I love to read.
Shawn: Yes, I think the PO is responsible (accountable) for making sure the team does its part. And if team members don’t, in some cases I would be mad at the PO. In other cases, though, I’d look at the situation and might think that the PO had done everything I could reasonable expect and the team was just a bunch of slugs who underperformed. It’s rarely as easy as saying there’s one person I’ll be mad at / fire / hold accountable if things go wrong.
Randy: Absolutely—sometimes saying “you’re the one throat to choke” is necessary. Some cultures have gone so far to the plausible deniability end of the spectrum that this message is needed. Hopefully after a few projects (months or years, perhaps) that culture has changed and the message can be made more inclusive.
Matt—Yes, I think your clarification helps. If I’m the boss and the project fails, I am going to want to talk (at least first) to my main interface into the project, which is probably the product owner. The product owner is the boss’s lens into the project.
Andrew—I’m sorry you feel we are (all?) crazy. To use your landlord analogy, though, does the landlord care when he comes to the door and I say “My wife has her half of the rent. I’m sorry but I don’t have my half”? No, he doesn’t. The team (me and my wife) have to pay that bill collectively. As for sports teams firing the coach: How often does that work? I saw an article recently on ESPN I think about coaches in jeopardy and how rarely changing the person in charge results in a dramatic turnaround. If the team’s players aren’t changed, it’s unlikely there will be a dramatic turnaround in that team.
Mike Lowery: I don’t suggest never using the phrase. There will be times it needs to be said but those should really only be in dysfunctional cultures that aren’t ready for a “we’re all in this together” message. Say that at the wrong time to the wrong team in the wrong culture and will come off as new-age, flowery BS. I’m with you on the last part: mostly be aware of how the message can be interpreted and know the drawbacks to any message.
Mike DePaoli—Wow, I’m with you on the issue of how rarely this is acted on. One of my angriest moments was a project that was essentially successful but the team was about 2 weeks late (on I think a 10-month deliverable with of course more than 2 weeks of scope creep). The product owner was given a 2-week trip to Hawaii on the company dime for delivering the project. The team was given a tongue-lashing by the CEO for being late. I read a little blurb in Harvard Business Review about two years that said something like only 20% of projects are ever assessed for whether they met financial goals. It seems that all projects are assessed for whether the team met the deadlines but very, very few are looked at a year later to see if they met the financial projections and such.
Thoralf—I love the “termites were responsible for the damage.” I bet the homeowner was accountable!
Bob—I’m glad you disagree with me occasionally. Life wouldn’t be fun if we always agreed. The only one I want to agree with me all the time is my wife. (And I can say that because she doesn’t read this blog; otherwise she’d kill me!) Joking aside: I agree that in the customer’s eyes, the product owner should be the single wringable neck. If I hire you to build a product for me and I never see the team (totally reasonable assumption) you are the project in my eyes. If it fails, I am furious at you. But my expectation would be that the team knows that you and they will succeed or fail together.
Matt—Yes, the product owner has responsibilities both inside and outside the team. This is part of what makes the product job the hardest one in Scrum, in my opinion.
Scot—I like your views on management accountability. To think about the “the buck stops here” attitude consider two cases. One where some manager puts a sign saying that on her own desk. Then another where her boss walks in and says “Amanda, the buck stops with you!” Those are very different. One is the person being very clear they are accepting responsibility for whatever happens. The other is the person being told “you’re accountable, no matter what.” I’d love to work on a team (software development team or management team) that said “the buck stops with us.” I wouldn’t want to work on a team where my boss told me the buck stops with me no matter what.
Adam—Do you think with a last name of Cohn (pronounced “Cone”) and going to high school in the 1970s, I was unfamiliar with the Coneheads? Oh that was a nickname I heard a lot! But, I do think you’re right—I think the etymology of “parental unit” does originate with Saturday Night Live. But I just did some Google searches now and common usage today is about the parent or parents raising a child. I saw references to “mixed-race parental unit,” “mixed-religion parental unit” and so on. But thanks for pointing this out and reminding how good that show was way back when. I still make a point of eating at the Billy Goat when in Chicago, where it is still “No Pepsi. Coke.”
Your interpretation of the “one throat to choke” concept is very different from mine. My interpretation is that the Product Owner is responsible for achieving the Return on Investment (ROI) for the project. The ROI of the project is achieved by the implementing features that either decrease costs or drive revenue enhancements.
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.
Mike, the post was featured on a VersionOne Newsletter email.
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.
Ahh, Matt. The VersionOne email explains the second round of interest in this post. I saw that I have something from them but I hadn’t opened it yet. Thanks.
I think this is too PollyAnnish. The reality is that business works when people are accountable for the results of their team. Product Managers should be the single throat to choke and this is only a problem if they cannot make decisions that effect the outcome before it occurs, i.e. if they cannot resolve team problems, rank the backlog without intervention, hold non-performers accountable to their manager, etc.
For market-driven products, we need accountable product owners.
Hmm, I never realized that the choke neck/break leg statement was actually taken so literally. It’s not about accountability or responsibility at all, whoever had that mad idea?
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”?
Serge, I think you’re blending what they were talking about with the concept of a “choke point”.
Hi Mike,
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
Hi Christopher–
It’s great to see you here. I’ve been a fan of yours since you gave the keynote at XP Agile Universe in 2004. I appreciate your insightful comments above. I’d recommend everyone interested in this topic check out your book. I’d forgotten how germane the title is to this post. For those who don’t know, the book is Teamwork Is An Individual Skill: Getting Your Work Done When Sharing Responsibility.
Thanks to for the links Elliot Jaques. I’m off to check those out now.
Mike
I agree with you. It is time to retire the phrase, but not the notion that the Product Owner (and the ensemble cast supporting the role) have domain over ‘what’ the product does to add value. Accordingly the team has domain over ‘how’ to deliver the value asked for.
Great book, even after several passes through because I realized I missed something!
Regards.
Hi Mike–
Yes, the “what/how” distinction between the product owner and team is a valid.
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!