Here is a common problem: A manager has a 10-person team that sits close together and achieves high communication rates with little energy.
The manager needs to increase the team's output. He has two choices: add people or keep the team the same size and do something different within the team.
If he increases the team size from 10 to 15, the communications load, communications distances, training, meeting, and documentation needs go up. Most of the money spent on this new group will get spent on communications overhead, without producing more output.
This group is likely to grow again, to 20 people (which will add a heavier communications burden but will at least show improvement in output).
The second strategy, which seems less obvious, is to lock the team size at 10 people (the maximum that can be coordinated through casual coordination) and improve the people on the team.
To improve the individuals on the team, the manager can do any or all of the following:
* Send them to courses to improve their skills.
* Seat them closer together to reduce communications cost.
* Improve their amicability and teamwork.
* Replace some of the people on the team with more talented (and more highly paid) people.
Repeating the strategy over time, the manager will keep finding better and better people who work better and better together.
Notice that in the second scenario, the communications load stays the same, while the team becomes more productive. The organization can afford to pay the people more for their increased contribution. It can, in fact, afford to double their salaries, considering that these 10 are replacing 20! This makes sense. If the pay is good, bureaucratic burden is low, and team members are proud of their output, they will enjoy the place and stay, which is exactly what the organization wants them to do.
As a programmer and not the manager how can I help our team improve? Hopefully reading this book is a start, but I am going to keep looking for ways to do more.
No comments:
Post a Comment