20 One Throat to Choke

There is a clear mapping between each project task and a single responsible individual. Each person knows precisely which responsibilities are his own and which belong to his colleagues.

What is actually going on here is that people thrive on having responsibility and knowing exactly what that responsibility is. The business analysts know what is expected of them; the testers know what their connections are to the deliverables; the business users know precisely what is expected of them; the developers know where their tasks start and stop; the project manager knows his responsibilities for steering and allocating tasks . . . every individual on the team is confident of what he has to do and how he will know when he has done it.

In accepting the singular responsibility for any piece of work (a component, assignment, objective, or action item), the individual knows and accepts his responsibility because that work is clearly mapped to an expected outcome. The individual thinks, “It’s up to me; everyone is counting on me for this—I am responsible for my work.” Similarly, each person on the team knows the responsibilities of others and thinks, “I can count on specific colleagues for these things.”

An organization that has this pattern can also cope when unforeseen things happen and nobody is responsible for dealing with them. People are used to having responsibility and consequently are not afraid to take charge of a task that needs an owner.

Having sole responsibility does not preclude asking for help and getting critical input from colleagues and any other relevant sources. The point is that the designated individual is still responsible for the agreed component. That person knows and agrees that “for this component, it is my head on the block. . . .”

This is very different from giving someone a job title and assuming that everyone will interpret the responsibilities of that title in the same way. What happens in these cases is that nobody really knows precisely what is expected of anyone. The consequence is uncertainty, fear, erosion of confidence, waste of human effort, and a great deal of pfaffing around.

Some projects operate on the basis that everything is everybody’s responsibility. The thinking, on the surface, may seem admirable: “We are a team. We pull together, and if anything needs doing, then it is everyone’s responsibility to make sure that it gets done.” Not surprisingly, this approach rarely works. Imagine such a team running a restaurant. In between cooking soufflés, the chef would be worrying about making reservations; the waiter would add some extra salt to the soup; the maître d’ would wash the odd dish, to ensure there were enough for table 22—everyone would be worrying about (or interfering with) everything and not doing anything particularly well.

The power of having one throat to choke comes from the confidence that people get from understanding what is expected of them. And this provides a clue for how to encourage this pattern in your own projects. You need to be able to characterize a component so that there is an objective indicator of what it is and how everyone will know if it has been delivered. The component may be the delivery of a specific module of software, the responsibility of providing feedback to the developers on the quality of their design, or the development of user training for a new product. The issue is that the component can be characterized so that everyone has the same understanding of what it is. If you can do this, then you can allocate singular responsibility to an individual and have everyone reap the benefits of improved work facilitation and personal confidence.