It has long been understood that differences in personnel account for the greatest swings in productivity. The original COCOMO model, for example, suggests that the combined effects of personnel skill and experience can have an impact on productivity of as much as a factor of four. This is the difference between an unskilled team of amateurs and a veteran team of experts. In practice, it is risky to assess a given team as being off-scale in either direction. For a large team of, say, 50 people or more, you almost always end up with nominal people and experience. It is impossible to staff a nontrivial project with personnel who all have optimal experience, are fully trained in the tools and technologies, and possess IQs greater than 130. If you did pull this off, the team would likely be dysfunctional. So the old "Just hire good people" approach needs to be applied carefully. A better way to state this is "Just formulate a good team."
Balance and coverage are two of the most important aspects of excellent teams. Whenever a team is out of balance, it is vulnerable. To use a sports analogy, a football team has a need for diverse skills, very much like a software development team. There has rarely been a great football team that didn't have great coverage: offense, defense, and special teams, coaching and personnel, first stringers and reserve players, passing and running. Great teams need coverage across key positions with strong individual players. But a team loaded with superstars, all striving to set individual records and competing to be the team leader, can be embarrassed by a balanced team of solid players with a few leaders focused on the team result of winning the game.
Teamwork is much more important than the sum of the individuals. With software teams, a project manager needs to configure a balance of solid talent with highly skilled people in the leverage positions. Some maxims of team management include the following:
• A well-managed project can succeed with a nominal engineering team.
• A mismanaged project will almost never succeed, even with an expert team of engineers.
• A well-architected system can be built by a nominal team of software builders.
• A poorly architected system will flounder even with an expert team of builders.
In examining how to staff a software project, Boehm offered the following five staffing principles [Boehm, 1981]. (Quotations are presented in italics.)
1. The principle of top talent: Use better and fewer people.
▲ This tenet is fundamental, but it can be applied only so far. There is a "natural" team size for most jobs, and being grossly over or under this size is bad for team dynamics because it results in too little or too much pressure on individuals to perform.
2. The principle of job matching: Fit the tasks to the skills and motivation of the people available.
a This principle seems obvious. On a football team you use a good leader as your coach, a good passer as the quarterback, a superfast runner as a wide receiver, and a 300-pound bruiser as a lineman. With software engineers, it is more difficult to discriminate the mostly intangible personnel skills and optimal task allocations. Personal agendas also complicate assignments. In football, the 300-pound lineman would never think about being promoted to quarterback; the skill sets are too obviously different. On software teams, however, it is common for talented programmers to seek promotions to architects and managers. I think the skill sets are equally different, because most superstar programmers are innately unqualified to be architects and managers, and vice versa. Yet individuals and even their organizations often view such promotions as desirable.There are countless cases of great software engineers being promoted prematurely into positions for which they were unskilled and unqualified. This makes a B player out of an A player, taking an A player out of a moderate- to high-leverage position and putting a B player in a higher leverage position. It's a double whammy.
3. The principle of career progression: An organization does best in the long run by helping its people to self-actualize.
▲ Good performers usually self-actualize in any environment. Organizations can help and hinder employee self-actualization, but organizational energy will benefit average and below-average performers the most. Organizational training programs are typically strategic undertakings with educational value. Project training programs are purely tactical, intended to be useful and applied the day after training ends.
4. The principle of team balance: Select people who will complement and harmonize with one another.
a Although this principle sounds a little drippy, its spirit is the paramount factor in good teamwork. Software team balance has many dimensions, and when a team is unbalanced in any one of them, a project becomes seriously at risk. These dimensions include:
Raw skills: intelligence, objectivity, creativity, organization, analytical thinking
Psychological makeup: leaders and followers, risk takers and conservatives, visionaries and nitpickers, cynics and optimists
Objectives: financial, feature set, quality, timeliness
5. The principle of phaseout: Keeping a misfit on the team doesn't benefit anyone.
a This is really a subprinciple of the other four. A misfit gives you a reason to find a better person or to live with fewer people. A misfit demotivates other team members, will not self-actualize, and disrupts the team balance in some dimension. Misfits are obvious, and it is almost never right to procrastinate weeding them out.
Software development is a team sport. Managers must nurture a culture of teamwork and results rather than individual accomplishment. Of the five principles, team balance and job matching should be the primary objectives. The top talent and phase-out principles are secondary objectives because they must be applied within the context of team balance. Finally, although career progression needs to be addressed as an employment practice, individuals or organizations that stress it over the success of the team will not last long in the marketplace.
Software project managers need many leadership qualities in order to enhance team effectiveness. Although these qualities are intangible and outside the scope of this book, I would be remiss if I didn't mention them. The following are some crucial attributes of successful software project managers that deserve much more attention:
1. Hiring skills. Few decisions are as important as hiring decisions. Placing the right person in the right job seems obvious but is surprisingly hard to achieve.
2. Customer-interface skill. Avoiding adversarial relationships among stakeholders is a prerequisite for success.
3. Decision-making skill. The jillion books written about management have failed to provide a clear definition of this attribute. We all know a good leader when we run into one, and decision-making skill seems obvious despite its intangible definition.
4. Team-building skill. Teamwork requires that a manager establish trust, motivate progress, exploit eccentric prima donnas, transition average people into top performers, eliminate misfits, and consolidate diverse opinions into a team direction.
5. Selling skill. Successful project managers must sell all stakeholders (including themselves) on decisions and priorities, sell candidates on job positions, sell changes to the status quo in the face of resistance, and sell achievements against objectives. In practice, selling requires continuous negotiation, compromise, and empathy.
Was this article helpful?