Lazy Leader

Jens Coldewey

Thumbnail: Sometimes the team leader puts herself on the critical path. When the going gets tough she hasn’t the resources to rescue the project. So keep the leader off the critical path.

Indication: The team has three to six members and therefore is too small to justify a full-time team coordinator. The team leader puts herself on the critical path or assigns herself the most important piece of code. When things get tough, all of the team members develop a code-like-hell strategy – nobody tries to find and fight the real causes of the problem.

Counter Indications: It is a one-person project.
Your team is not qualified to do the job.

Forces: You want to have control over the critical path...
...but tracking the progress of every team members is not as attractive as doing the technical jobs you were good in before.

When the project comes into turbulence you need most of your time to manage the crisis...
...but you don’t want to miss your own deadlines because that would even deepen the trouble.

You think your team members want their bosses to do "real work" too...
...but you need your time to enable them to do their work.

Overall project control and design of the hardest parts both may need an experienced person on their own...
...but you as the leader are typically the most experienced designer.

You want to have reliable persons work on the critical path...
...but you think you do not have enough experienced team members.

Do this: Trust your team! Assign yourself only deliverables that are not crucial for your team’s success.

If you are the only one to do a job on the critical path, try to transfer your know-how to another team member early in the project with high priority.

Spare your time to clear the way of your team if things get rough, do not try to jump onto the critical path yourself.

Resulting Context: The team's mutual trust is improved. You have the time to detect and handle risks early, saving overall effort. However, jobs you are particularly qualified for may be staffed non-optimally. The team may fail to appreciate that you don’t do "real work"

Overdose Effect: You have nothing to do.
The project may not benefit form your technical know-how at all.

Related Patterns: Balanced Staffing (not written yet) is the precondition for this pattern.

Pair Programming (not written yet) and Expert Within Earshot show ways to transfer your knowledge to other team members.

Principles: The most important job of a team leader is to enable her team to do it’s work, not to do the work on her own. Especially when times get rough she needs all her resources to put the project on the right track, not to do the hack.

Examples: An ambitious project in the financial domain started off with a team of eight highly professional analysts and developers. The team leader was very fond of his own domain knowledge and declared himself to be the domain expert. However, with all his work on the requirements, he had neither time to manage the contact with the project sponsors, nor to free the team from organizational stuff, such as ordering whiteboards. The best developer of the team decided to care for these topics too and finally did large parts of the project management job. The developer thus saved the project from experiencing the worst consequences of not using this pattern. However the team was not as effective as it could have been.

Another team worked on six new features an order managing system of a steel company. They split into sub-team two to four people for each feature, so the team leaders had to do "real" work as well. All six team-leaders - very good and ambitious young technicians - picked the hardest and most critical tasks for themselves. The project manager asked them to change the assignments in the work plan and to add personal buffers for themselves, so they had time for extra jobs like discussing supposed change requests with the client. They all chewed up their buffers, three of them had to push some of their functionality out of the schedule, the client agreed. The team delivered 5 features in time. One sub-team was late: the one whose team-leader thought it was not possible at all to let the others do the critical stuff.

A team of four coming from a third party worked on a system to schedule the production of cars. They implemented a highly sophisticated genetic algorithm depending on many parameters. The leader was the only one knowing how to deal with genetic algorithms. A second programmer implemented the GUI, a third coded the database access, and the fourth was a junior, assisting the others. When delivery came closer, the project leader had to care for a lot of things beside algorithm: Training the users, interfacing the ordering system, discussing with the client about change requests, and so on. The GUI was complete, database access worked, but not the most important part, the genetic algorithm. The project was late and the workaround was quite expensive: A new team-leader was installed as well as an extra team for training and integration. Finally the original team-leader had enough time to finish his algorithm.

Acknowledgements: Alistair Cockburn provided the structure, shepherded this pattern and provided a lot of helpful feedback. Klaus Wiemers provided two war stories and the sd&m "Project Management Pattern Team" suggested several significant improvements during a Writer’s Workshop. Thanks to you all.

Reading: Tom DeMarco: "Standing Naked in the Snow – Variation on a Theme by Yamaura" is an essay about young managers who try to lead by example putting all critical tasks onto their own. DeMarco entertainingly chats about several examples of this pattern.