Diffusion of Responsibility
Engineering Insights
The term “diffusion of responsibility” refers to a psychological phenomena where important tasks are left undone because each of the people involved believes that it is someone else’s job to handle it.
Unfortunately, this malaise is the bane of many engineering teams. It’s why tasks that only involve a few days worth of actual coding and testing often end up taking months of calendar time to accomplish.
Although I’m not a major enthusiast of Internet memes, I’ve created a small image which I feel adequately sums up my feelings about the kinds of pathologies observed in software development teams:
All humor aside, there are reasons why this sort of thing happens as often as it does. The main causes are overall task complexity, and the inability of task planners to comprehensively capture all of the minor sub-tasks involved in completing a task.
For example, suppose Alice, Bob and Chuck are working at an Internet startup. Alice works on the server code, Bob writes the HTML and JavaScript, and Chuck is responsible for devops and deployment. They are busy working on a new feature, and so they have divided up the work between them based on their assigned roles:
Unfortunately, as you can see, there’s a lot of gray area in the overall task which isn’t covered by the work assigned to Alice, Bob and Chuck.
And when the product manager asks, “why isn’t Task X done?”, Alice will truthfully say, “Well, my part is done”, and Bob and Chuck will say the same thing.
Part of the problem here is that there’s no one who owns the entire task. By “owns” I don’t mean the product manager; I mean someone who is in a position to take concrete action to move the task forward. In our hypothetical scenario, nobody is responsible for the gray areas, and so that work doesn’t get done.
Another problem here is that Alice, Bob and Chuck are all heavily siloed. Each individual has an assigned territory or region of comfort, and seldom strays outside of it. Alice works on server code, and doesn’t feel comfortable working on devops or client code; Bob doesn’t know anything about server programming; and Chuck knows a bit of both but is nervous about intruding on Alice and Bob’s domain.
Also, Alice, Bob and Chuck are all working on different schedules; they have many other things to work on besides this one feature. Alice may have finished her part early, but Bob is busy working on a high-priority bug and may not get to his part for another two weeks. And Chuck can’t even start until Bob’s work is done. So even though the work may only required a day or two of individual effort, the time taken to complete the project is three to four weeks.
Another problem is that the individuals involved may not even be aware that the gray area exists. In the illustration above, it’s obvious that there’s a big chunk of work that is not covered by the three engineers. But most task descriptions aren’t diagrams, they are typically bullet lists, lines in a spreadsheet, or tasks in a ticket tracking system. They tend to look more like this:
- Alice’s Task — write the server code
- Bob’s Task — write the client code
- Chuck’s Task — create the deployment scripts and run them
Presented this way, it’s not at all apparent that there are missing pieces to the task.
This is one of the reasons why “full stack engineer” has become such a highly sought-after role in recent years. When a single person works on the whole task, they not only create the individual pieces that have been identified, they are also forced by circumstances to implement all of the “glue” that binds those pieces together.
(The downside, of course, is that a single person doesn’t scale. There are only so many hours in the week.)
Absent a “super-programmer” who can do everything, the other approach is to do a better job of dividing up the task so that nothing is left out. If there is work involved integrating the client code with the server API, then that should be included in the list of tasks.
The best way to avoid these kinds of problems is to be aware that they happen, and try and compensate for them during planning. Humans are fallible, which is why we invented things like double-entry bookkeeping and the scientific method: techniques that help us compensate for our cognitive flaws and observational biases.
