Diffusion of Responsibility: Why Things Don’t Get Done on Software Projects and What to Do About It

If you’ve ever seen a committee in action, you may know that they tend to not get things done very quickly if at all. The United States Congress is a great example of a committee that is very successful at failing to get things done on a regular basis where even the simplest of things can be drawn out over an extended period of time. The challenge that committees have is that everyone shares part of the responsibility to achieve an outcome. This shared responsibility changes the mindset of people on the committee for the tasks assigned since no one can point at any single person if failure occurs. Project teams are a committee in effect and as such will tend to behave like any other committee. When team members can hide under the cloak of shared responsibility there is less urgency for anyone to take action because no one sees themselves as being directly responsible. Diffusion of responsibility as defined by Wikipedia is a sociopsychological phenomenon whereby a person is less likely to take responsibility for action or inaction when others are present.

Part of my motivation for this particular post came from an experience I had at a coffee shop I visited recently. On this occasion I ordered something that needed to be cooked in the oven. At the time, I didn’t think to ask how long it would take making the poor assumption it would be ready relatively soon. After about 20 minutes I started feeling frustrated that there didn’t appear to be any progress on my order. To my surprise as I saw someone else who had clearly ordered after me sit down and start eating the very thing I ordered.

I approached the barista and asked what was happening with my food. Knowing nothing else he quickly replied saying it would probably be about 15 minutes to cook the food. I informed him that not only had I already been waiting 20 minutes, but I just saw someone else sit down to eat what I had ordered. My expectation (as poor as it was) from him was that he would at least check to see what was happening or he would follow up with the order taker. I was unfortunately not that lucky. He instead gave me his rationale on why my order wasn’t his problem. The first excuse was that he didn’t take my order therefore he didn’t know anything about my specific order. The second excuse was that maybe the people who were eating had simply come in before me which would explain why they had theirs first. Then after feeling like he gave me his logical explanation to do nothing he proceeded to go back to what he was doing.

What he had just explained to me was that he did not see it as his personal responsibility to assist me with my order. He deferred that responsibility to the team. The problem for me was that no one else on the team saw it as their responsibility either. The order taker was busy taking orders, the barista was busy making drinks and the cook was busy cooking. Yet as a team no one saw it as their responsibility to make sure my order was fulfilled successfully. This was a classic case of diffusion of responsibility and is the same thing that happens on development teams during project delivery.

When you assign tasks to a group of people the notion of shared responsibility removes the natural urgency the group members might feel if they were assigned the task as an individual. When “no one” or an individual is responsible for a given task, no one feels it’s their responsible to make it happen. It’s one thing to assign a task to a group of people. It’s another thing to make one person responsible for the outcome regardless if multiple team members work on the task. When a single person bears the sole responsibility of the task being completed the urgency of it being done is greatly enhanced because no one wants to be put on the spot for why something isn’t done. In the industry, we like to call this “The single throat to choke”. This is even true of outside vendors and teams when something needs to happen. It’s very easy for groups of people to diffuse their responsibility of taking action. If you don’t find that one person that can be held responsible, then you very well may have a long road ahead if things begin to fall through the cracks.

The key to making sure tasks don’t get left by the wayside is to make sure that only one person is ever responsible for any given task being completed whether that is on your delivery team or outside parties. This isn’t to say that individual is the one doing all the work. What matters is that someone is responsible for it being done. If it doesn’t happen then you have your single throat to choke when necessary.

Categories: Blog, Project Delivery


%d bloggers like this: