TMMM: The Surgical Team

The section about structuing highly effective teams is no longer relevent. This essay discusses a model where one developer is supported by 9 other administrative roles, a parallel is drawn between the developer and a surgeon.

Mills proposes that each segment of a large job be tackled by a team, but that team is organiszed like a surgical team rather than a hog-butchering team. That is, instead of each member curron away on the probelm, one does the curring and the others give him every support that will enhance his effectiveness and productivity.

– Federick P. Brooks, JR

Some similarities can be drawn between this and current practices around keeping teams small (e.g. Amazon’s two pizza team size) and cross-functional teams. However, taken at face value a team of 9 supporting one developer is exessive; it makes little sense in todays environment. But, looking at this essay through the lens of 1975 where most coding was initially done on paper, then key-punched onto punch cards, then read in, then compiled, then executed, on the one machine everyone was vying for access makes for a very expensive development process. I can see how it makes a lot more sense to support the developer in that context, but is of little use to us today; current development tooling and processes are just too different.

The bit that surprised me was a direct reference to the wild productivity fluctuations bewteen different developers. Is this the gensis of the “rockstart programmer” or “10x developer” that’s in vogue with start ups over the past couple of years?

Within just this group the ratios between best and worst performers averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!

– Federick P. Brooks, JR

Overall a fun read as a historical curiosity but not of much relevence anymore; I did have some lingering questions about implementation of the model - even in 1975.

  • It’s notriously hard to pick a 10x developer, how are the “surgeons” chosen in practice? Is it just trial and error with the good ones sticking around? What if you accidently give the top job to a 0.1x developer? That mistake is amplified by the cost of the 9 support roles.
  • What if the surgeon is hit by a bus so to speak? How is the business continuity handelled? Is the co-pilot expected to step up?
Noticed an error or omission? Please look at submitting a pull request.