The most common team structure is probably the peer group headed by a technical lead. Aside from the technical lead, the team members all have equal status, and they are differentiated by area of expertise: database, graphics, user interface, and various programming languages. The technical lead is an active technical contributor and is thought of as the first among equals. The lead is usually chosen on the basis of technical expertise rather than management proficiency.

Most commonly, the lead is responsible for making final decisions on tough technical issues. Sometimes the lead is a regular team member who merely has the extra duty of being the team's link to management. In other cases, the lead occupies a first-level management position. The specific amount of management responsibility the technical lead has varies from one organization to another, and I'll discuss that topic more later in the chapter.

From the outside, the business-team structure looks like a typical hierarchical structure. It streamlines communication with management by identifying one person as principally responsible for technical work on the project. It allows each team member to work in his or her area of expertise, and it allows the team itself to sort out who should work on what. It works well with small groups and with long-standing groups that can sort out their relationships over time.

It is adaptable enough that it can work on all kinds of projects—problem resolution, creativity, and tactical execution. But its generality is also its weakness, and in many cases a different structure can work better.

The idea of the chief-programmer team was originally developed at IBM during the late 1960s and early 1970s (Baker 1972, Baker and Mills 1973). It was popularized by Fred Brooks in the Mythical Man-Month (Brooks 1975, 1995), in which Brooks referred to it as a surgical team. The two terms are interchangeable.

The chief-programmer team takes advantage of the phenomenon that some developers are 10 times as productive as others. Ordinary team structures put mediocre programmers and superstars on equal footing. You take advantage of the high productivity of the superstars, but you're also penalized by the lower productivity of other team members. In the surgical-team concept, a programming superstar is identified as the surgeon, or chief programmer. That person then drafts the entire specification, completes all of the design, writes the vast majority of the production code, and is ultimately responsible for virtually all of the decisions on a project.

With the surgeon handling the bulk of the design and code, other team members are free to specialize. They are arrayed about the surgeon in support roles, and the chief-programmer team takes advantage of the fact that specialists tend to outperform generalists (Jones 1991).

A "backup programmer" serves as the chief programmer's alter ego. The backup programmer supports the surgeon as critic, research assistant, technical contact for outside groups, and backup surgeon.

The "administrator" handles administrative matters such as money, people, space, and machines. Although the surgeon has ultimate say about these matters, the administrator frees the surgeon from having to deal with them on a daily basis.

The "toolsmith" is responsible for creating custom tools requested by the surgeon. In today's terminology, the toolsmith would be in charge of creating command scripts and make files, of crafting macros for use in the programming editor, and of running the daily build.

The team is rounded out by a "language lawyer" who supports the surgeon by answering esoteric questions about the programming language the surgeon is using.

Several of the support roles suggested in the original chief-programmer proposal are now regularly performed by nonprogrammers—by documentation specialists, test specialists, and program managers. Other tasks such as word processing and version control have been simplified so much by modern software tools that they no longer need to be performed by support personnel.

When it was first used more than 20 years ago, the chief-programmer team achieved a level of productivity unheard of in its time (Baker and Mills 1973). In the years since, many organizations have attempted to implement chief-programmer teams, and most have not been able to repeat the initial stunning success. It turns out that true superstars capable of serving as chief programmers are rare. When individuals with such exceptional capabilities are found, they want to work on state-of-the-art projects, which is not what most organizations have to offer.

In spite of 20 years worth of changes and the rarity of superstar programmers, I think this structure can still be appropriate when used opportunistically. You can't start out by saying, "I need to get this project done fast, and I want to use a chief-programmer team structure." But what if you do happen to have a superstar who's willing to work exceptionally hard, who has few other interests, and who is willing to put in 16 hours a day? In that case, I think the chief-programmer team can be the answer.

The chief-programmer team is appropriate for creative projects, in which having one mind at the top will help to protect the system's conceptual integrity. It's also well suited to tactical-execution projects, in which the chief programmer can serve as near dictator in plotting out the most expeditious means of reaching project completion.

In the feature-team approach, development, quality assurance, documentation, program management, and marketing personnel are arranged in traditional hierarchical reporting structures. Marketing people report to marketing managers, developers report to development managers, and so on.

Layered on top of this traditional organization are teams that draw one or more members from each of these groups and that are given responsibility for a chunk of the product's functionality (McCarthy 1995a). You might have a feature team assigned to printing, or reporting, or graphing. The feature team then becomes ultimately responsible for decisions about that part of the product.

Feature teams have the advantages of empowerment, accountability, and balance. The team can sensibly be empowered because it contains representatives from development, quality assurance, documentation, program management, and marketing—in short, from each of the concerned parties. The team will consider all necessary viewpoints in its decisions, and thus there will hardly ever be a basis for overriding its decisions.

For the same reason, the team becomes accountable. They have access to all the people they need to make good decisions. If they don't make good decisions, they have no one to blame but themselves. The team is balanced. You wouldn't want development, marketing, or quality assurance alone to have ultimate say over a product's specification, but you can get balanced decisions from a group that includes representatives from each of those categories.

Feature teams are appropriate for problem-resolution projects because they have the empowerment and accountability needed to resolve issues expediently. They are also good for creativity projects because the interdisciplinary team composition can stimulate ideas. The additional overhead incurred with feature teams will be wasted on tactical-execution projects—if all the tasks are clearly defined, feature teams have little to contribute.

In the search-and-rescue team model, the software team acts like a group of emergency medical technicians who go looking for missing mountain climbers. The search-and-rescue team focuses on solving a specific problem. It combines specialized emergency medical training with mountaineering or other wilderness survival skills. It needs intimate knowledge of the terrain it will search, it needs to be ready to go at a moment's notice, and it needs excellent knowledge of first-aid practices so that it can stabilize and possibly improve the victims' conditions until they can be transported to appropriate medical facilities.

The software equivalent is to combine specialized knowledge of specific hardware and software tools with equally specialized knowledge of a particular business environment. For example, you might have software that tracks an overnight delivery service's packages. If that software breaks down, it will need to be fixed immediately, not by noon tomorrow. The team charged with maintaining that software could be conceived as a search-and-rescue team. Such a team needs intimate knowledge of the terrain it will be searching (the package-tracking software), an ability to respond to problems immediately, and an excellent knowledge of how to stabilize the system in the short-term—addressing the immediate problem of lost packages.

The search-and-rescue team model is most appropriate for teams that need to focus on problem resolution. It is too bottom-line oriented to support much creativity and too short-term oriented to support tactical execution.

The SWAT team model is based on military or police SWAT teams, in which "SWAT" stands for "special weapons and tactics." On that kind of team, each member is highly trained in some specialty such as sharpshooting, explosives, or high-speed driving. The team trains extensively so that when the crisis hits, they can work together as one seamless unit.

In software, "SWAT" stands for "skilled with advanced tools." It originated as part of James Martin's RAD methodology (Martin 1991). The idea behind a SWAT team is to take a group of people who are highly skilled with a particular tool or practice and turn them loose on a problem that is well suited to being solved by that tool or practice. A SWAT team might specialize in any of the following areas:

SWAT teams are usually permanent teams. They might not perform SWAT duties full-time, but they are accustomed to working together and have well-defined roles. If they are trained in Access, for example, they understand each other's strengths and weaknesses and know how to work together to create an Access application in record time.

SWAT teams are especially appropriate on tactical-execution projects. Their job is not to be creative but to implement a solution within the limits of a tool or a practice that they know well. SWAT teams can also work well on problem-resolution projects. Team members trust each other, and their focus on a particular project phase allows them to treat completion of that phase as a single problem that they can quickly overcome.

The professional-athletic-team model emphasizes several characteristics that are common to shrink-wrap software production and probably to other kinds of software development, too. For simplicity's sake, I'll use a baseball team in the examples, but almost any kind of professional athletic team could serve as a model.

Some software project teams are similar to professional baseball teams in that the players—software developers—are selected at least as carefully as the management is and are probably more critical to the project's success. The athletes are the stars of the baseball team, and the developers are the stars of the software team.

An athletic team manager handles the back-office decisions, which are strategically important, but the manager is not the one who swings the bat, scores the runs, or throws out the runners. The fans don't come to watch the manager; they come to watch the players.

Similarly, the software manager is important, but not because of any development capabilities. The manager's role is to clear roadblocks and enable developers to work efficiently. Developers might be able to develop a product without the manager, but the manager couldn't develop a product without the developers.

Athletic teams also have highly specialized roles. The pitcher doesn't say, "I'm sick of pitching. I want to play third base today." Likewise with software teams. The project manager can hire a database specialist, a user-interface specialist, and a software-metrics specialist, but no one should expect the database specialist to do graphics any more than they should expect the pitcher to play third base. Of course, in baseball there are only 9 positions, while in software more than 100 specialties have been identified (Jones 1994). Specialties in software can include system architecture, reusability, package evaluation, specific hardware, specific software environments (such as Macintosh, X-Window, and Microsoft Windows), specific programming languages, performance, LAN, CASE, customer support, maintenance test, customer liaison, and many more.

In professional baseball, as in software, the manager is often a former star player. There is no sense in which the manager is better than or hierarchically above the superstar players. He might have the authority to hire and fire some of the weaker players, but if he has a personality conflict with the team's biggest star, he is as likely to get the ax as the player is.

This specific model applies best to tactical-execution projects, which emphasize the highly specialized roles that individual players play. You can apply the model's general idea that management plays a supporting role to development to all kinds of projects.

The theater team is characterized by strong direction and a lot of negotiation about project roles. The central role on the project is occupied by the director, who maintains the vision of the product and assigns people responsibility for individual areas. Individual contributors can shape their roles, their parts of the project, as their own artistic instincts move them. But they can't take their ideas so far that they clash with the director's vision. If their ideas conflict with the director's, the director's vision has to prevail for the sake of the project.

In the theater model, you are not just assigned to a project. You audition, and then you accept a role. A lot of negotiation goes on before you accept the role:

In the theater model, you don't sign up to play the lead role and then get moved to villain (or database).

The software manager occupies the role of producer. The producer is responsible for obtaining funding, coordinating schedules, and being sure that everyone is in the right place at the right time. The producer generally does not play an active role in the artistic aspects of the project.

The theater model's strength is that it provides a way to integrate strong individual contributions within a strong central vision on creativity projects. As Fred Brooks argues, conceptual integrity is the most important consideration in system design, and if a system is to have it, one person must control the concepts (Brooks 1975). It also helps to explain why even with a strong cast and strong direction, some projects still turn out mediocre or fail. Some software projects might be out of control, but anyone who's seen a terrible movie that cost $50 million can see that sometimes projects just don't work out.

The theater model is particularly appropriate for software teams that are dominated by strong personalities. Everyone knows that actors and actresses are temperamental, and some software developers have reputations as prima donnas too. If a project role is important enough, and if a particular developer is the only one who can play it, the director might decide that he or she is willing to put up with the prima donna for the sake of the project. But if the rest of the cast is strong, the director might pass up a prima donna in order to have a smoother project.

The theater model is an appropriate model for modern multimedia projects. Whereas software projects used to have to integrate the contributions of multiple software developers, now they have to integrate the contributions of graphic designers, writers, video producers, audio producers, editors, illustrators, content coordinators—and multiple software developers.

Large teams pose special problems of communication and coordination. If you're the only person on a project, you can work any way you want to because you don't have to communicate or coordinate with anyone. As the number of people on a project increases, however, the number of communication paths and the amount of coordination needed increases, too. It doesn't increase additively, as the number of people increases. It increases multiplicatively, proportional to the square of the number of people. Figure 13-2 on the next page shows how.

Figure 13-2. Communication paths on projects of various sizes.

A two-person project has only one path of communication. A five-person project has 10 paths. A ten-person project has 45 paths, assuming that every person talks to every other person. The two percent of projects that have 50 or more programmers have at least 1200 potential paths. The more communication paths you have, the more time you spend communicating and the more opportunities there are for communication mistakes.

A project with 1200 communication paths has far too many paths to operate effectively, and, in practice, 50-person projects aren't organized so that every person communicates with every other person. Large projects call for organizational practices that formalize and streamline communication. Formalizing communication is an important element of success on large projects, but it's out of scope in a chapter on team structure. Streamlining communication, on the other hand, can be greatly affected by team structure.

All the ways to streamline communication rely on creating some kind of hierarchy, that is, creating small groups, which function as teams, and then appointing representatives from those groups to interact with each other and with management. You can create these small groups in several ways:

Regardless of how the small teams are organized, I think it is critical that there be a single person who is ultimately responsible for the product's conceptual integrity. That person can be cast as the architect, surgeon, director, or even sometimes the program manager, but there must be a person whose job it is to be sure that all the teams' good local solutions add up to a good global solution.