The Surgical Team

When it comes to estimating the size of a team needed for a specific project, there have traditionally been two schools of thought. One approach is to hire an army of programmers; the other is to maintain a small team of higher level individuals.

There are some broad assumptions with both approaches. For example, it can be assumed that with large teams, they are populated with mediocre programmers. In addition, where they can tackle large volumes of work, they are not nimble enough to adjust or change direction when needed, almost like a runaway locomotive. By contrast, the smaller teams are typically comprised of highly talented and top level workers. They are usually tops in their field and can handle any problem that comes along the way, except handling the work load associated with larger projects.

As you can see, both approaches have their advantages and drawbacks. While it has been beneficially to have smaller teams of effective personnel manage these large teams, it can be argued that, except for the largest projects, just giving the work to the smaller team may prove to be just as efficient, if not more so. Again, the problem is that the smaller team would take years to accomplish what larger teams could accomplish due to volume, albeit the quality would most likely be better.

Harlan Mills eventually developed a compromise to these two approaches. His proposal suggested that the large project be carved up and handled by teams, and that these teams should be organized like a surgical teams, not mass assembly line teams. The logic was that instead of each team member cutting away at the big picture, smaller teams would be assembled with one team member doing the cutting and the other teams members would be there in a support role. This would enhance the overall effectiveness and productivity of the team as a whole. Broken up by role, the team would look like this:

  • Surgeon. This would be the chief programmer. The ideal profile of this individual would be that of an individual who is extremely talented, at least ten years of experience, and unmatched knowledge of the systems and applications. This person would be responsible for designing the program, inclusive of coding, testing, and documentation.
  • Copilot. The copilot is usually referred to as the alter ego of the surgeon. While the capabilities of the copilot and surgeon are most likely on equal footing, the copilot will have much less experience. The role of this team member is to help lead, provide backup leadership, fill gaps in production, and provide advice.
  • Administrator. The administrator will handle the everyday operations associated with handling money and resources. While the surgeon will have final say on these matters, the team would run inefficiently if the surgeon were bogged down with such details.
  • Editor. Much like the administrator, the editor is there to relieve some of the tasks from the surgeon. In this case, the duty of documentation ultimately falls to the surgeon, however, the editor will be tasked with overseeing the mechanics of its production.
  • Two secretaries. These roles will handle project correspondence for both the administrator and the editor.
  • Program clerk. The team needs someone dedicated to maintaining technical records and that role will fall to the program clerk.
  • The toolsmith. This person is responsible for ensuring the constructing, maintaining, and upgrading special tools needed by the team. This will almost exclusively be the computer systems and applications.
  • The tester. Debugging is a critical step when it comes to software development. Therefore a dedicated resource for testing will keep the team moving efficiently.
  • The language lawyer. This resource is typically leveraged by a number of teams. A language lawyer can usually service up to three surgeons. They are very useful in the intricacies of programming language.

These types of specialized teams can work much more effectively and promote communication that is unmatched. The surgical team can provide quality far better than the large teams, while being able to handle volumes out of the reach of the smaller teams.