20. One Throat to Choke
,
Copyright © Tim Pannell/Corbis
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.
In a well-run restaurant, the responsibilities for work are clearly divided among the team members. The saucier makes sauces; the pâtissier is responsible for the pastries; the maître d’ tends to greeting and seating; the sommelier focuses on the wine; and the scullery maid washes the dishes. If you observe the work patterns, you see how each person focuses on the tasks for which he is responsible. The waiter pins an order onto the orders clipboard and takes a basket of bread to the table. The head chef scans the order and shouts the dishes’ names to each specialist. The fish chef cooks the halibut; the saucier makes the sauce; the vegetable chef prepares the watercress garnish; and the presentation chef puts the dish together. When the dishes are ready, the waiter is summoned and carries them to the table. Each individual knows what he has to do, when he has to do it, and just as importantly, what to expect of his colleagues. The atmosphere is alive, busy, and purposeful. When you find this pattern in a project, you can feel the same buzz of excitement and achievement in the air.
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.