Years ago, when I read The Mythical Man-Month, I found lots of stuff which I already knew from other sources. However, there were also new things in there, despite the book being from 1975. One of them was:

The Surgical Team

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

This is a very interesting pattern for organizing a software development team, but I never found it described in any other Software Engineering book, not even mentioned anywhere.

Why is that?

  • Was the "Surgical Team" even unusual back then?
  • Or, has it been tried and failed?
    • If so, how did it fail?
    • If not, why don't we see that pattern implemented in today's software projects?
  • 12
    I would say this can only bring opinion-based answers. My knee-jerk opinion is that no "software engineer" wants to be seen as "support" role. They want to be seen as equal to everyone else on the team. This may be related to the fact, that majority of software developers are extremely young. Most teams don't have anyone who could claim seniority and be considered the "surgeon" of the team.
    – Euphoric
    Commented Aug 6, 2017 at 17:21
  • 44
    A potential problem that I see when you intentionally try to organize a team that way is to correctly identify who the surgeon should be. Commented Aug 6, 2017 at 17:21
  • 9
    @Euphoric Don't forget some of the managers that delude themselves into thinking that they already have their super-uber-guru-star-surgeon programmer, so why employ all of those support peasants in the first place? I've seen my share of mgrs that didn't show evidence of understanding software development and its inherent challenges while "managing" software teams, or much else beyond their colorful excel spreadsheets, unfortunately (usually, though not always, people close to retirement).
    – code_dredd
    Commented Aug 6, 2017 at 19:35
  • 7
    It may have something to do with the fact that "surgery" is one of the most backward-looking branches of medicine - indeed, it's a well known joke in the UK that surgeons spend 7 years studying so they can be called "doctor", and then a further 7 years so they can be called "Mr" or "Mrs" again! In fact reorganizing surgery to improve its performance by following the "best practice" of other industries with much lower error rates, etc (in particular, civil aviation) is an ongoing effort within the medical profession. ...
    – alephzero
    Commented Aug 7, 2017 at 2:55
  • 6
    @alephzero: Those are a couple of funny claims. Where exactly did you practice surgery? Here, the amount of crap that you call "best practice" takes up a major part of a surgeon's time, and it yields zero benefit. Super smart people [ironic] try ever so hard to improve something they don't understand by adding more bureaucratic crap to it almost every week. The causes of the failure rate that you mention are however not addressed, on the contrary. Almost all failures are due to sleep deprivation, under-education, and over-estimation. Often all three of them together.
    – Damon
    Commented Aug 7, 2017 at 13:36

11 Answers 11


"The Mythical Man-Month" came out the year I started college and was, to use the current vernacular, UUUGE! :-) What you need to understand is the difference in how software was developed THEN vs. NOW. Back In The Day (tm) pretty much all coding was done on paper first, was then keypunched onto (you guessed it) punched cards, then was read in, compiled, linked, executed, results were obtained, and the process repeated. CPU time was an expensive and limited resource and you didn't want to waste it. Ditto and likewise disk space, tape drive time, etc, blah. Wasting perfectly good CPU time on a compile which resulted in (shock and horror!) errors was...well, a waste of perfectly good CPU time. And this was in 1975. At the time that Fred Brooks was developing his ideas, which was the mid-to-late 1960's CPU time was even more expensive, memory/disk/whatever was even MORE limited, etc, etc. The idea behind The Surgical Team was to ensure that the One Super Great Rockstar Developer did not have to waste HIS time on mundane tasks like desk-checking code, keypunching, submitting jobs, waiting around (sometimes for hours) for results. Rockstar Dude Developer Man was to be WRITING CODE. His legion of groupies/clerks/junior developers was supposed to do the mundane stuff.

The problem was that within 2 years of Brooks' book being published the basic ideas behind The Surgical Team were breaking down:

  1. CRT terminals and disk files began to replace keypunches and card decks. Computer time became less expensive, multiple computers became available, and job turnaround time dropped dramatically. When I got to college (Miami University, Oxford, Ohio, class of '79, thanks for asking) good job turnaround was about an hour. During finals week - four hours, maybe, sometimes six. (We competed for CPU time with a bunch of commercial companies and universities - and the commercial users got first priority). During my senior year, by which point Miami had gotten out of their "shared computer" arrangement, had their own IBM 370/145 installed on campus, and had a nice HP mini I worked on that acted as an RJE station we could turn mainframe jobs around in five minutes or less. It was now worthwhile to bang your code in on the HP, send it from the HP to the mainframe, twiddle your thumbs/smoke a cigarette, and get your output back long before you could finish desk-checking your code.

  2. The Surgical Team has as its basic premise the idea that you (or "management", god help us all) can identify The Rockstar Surgical Developer Dude. In fact, I doubt that's possible. There are rockstar developers, everyone knows it - studies have shown differences in productivity between the best and worst developers of as much as 2000% - but identifying that person without having them write code over a long period of time is most likely impossible. The only way to know if someone is a rockstar developer is to have them actually develop code - but if they're NOT the Rockstar Surgical Developer Dude they'll be doing exciting things like desk-checking his code, keypunching it onto cards, and schlepping boxes of punched cards down to the Job Entry department, then standing around waiting for results so they can schlep them back to Mr. Rockstar Surgical Developer Dude instead of learning to code the only way that really works - by writing code, debugging code, and etc. Back In The Day (tm) there were no programming contests, there was no Stack Overflow, you didn't have a PC you could go write code on whenever you felt like it, there were no Algorithms For Idiots books - the only way to learn programming was to go to school and major in something where you got to do a bit of programming. But programming per se was not taken seriously, and it was assumed to be something people didn't want to do. In my first college course (SAN151 - Introduction To Systems Analysis, Dr. Tom Schaber - thanks, Tom :-) we were told by the instructor that "...we just had to face the fact that we'd have to spend a couple of years as programmers before we could become systems analysts". "Two years?", I thought. "I ONLY GET TO DO THIS FOR TWO YEARS?!?". I was seriously bummed. Thankfully he was wrong and I've been coding pretty much ever since. :-)

  3. The Surgical Team assumes that programmers are a relatively rare resource. It actually took a few more years, but with the advent of PC's in the early 80's programming became something that any geek could get involved in. The price of computers began to fall, the price of development tools began to fall, and it was all hail Turbo Pascal - by today's standards it wasn't much but at the time it was a complete Pascal IDE for about 40 bucks, which was absolutely nuts! Now ANYBODY could get into programming - if you could afford a computer, and when IBM decided to put the PCjr (yep, my first PC was one of IBM's biggest mistakes :-) on sale for about $500 to get rid of those turkeys, cash-strapped geeks everywhere skipped their rent payments for a month ("Yeah, uh, I know, but I, uh...broke my uuvula and had to have surgery and...uh...yeah, next week, no problem, thanks, man...) and sucked 'em up at fire-sale prices. Then spent more than we paid for the computer on add-ons to make it usable. ("Yeah, man, next week, for sure, probably..." :-).

What makes me really sad is that even today, if you ask people if they've ever read "The Mythical Man-Month" or understand its principal lesson ("Adding resources to a late project makes it later") they give you a blank stare - and then proceed to make the exact same errors as were made All Those Years Ago during the development of OS/360. Everything old is new again... :-}

  • 22
    If anyone reading this has the 20th Anniversary edition of the book, it is worth reading the new preface and the new chapter 19. While even the 20th anniversary edition is over 20 years old as of 2017, the author points out several of the assertions in this answer which are often overlooked in the rush to summarize the whole book as "adding engineers to an already-late project makes it even more late."
    – user22815
    Commented Aug 7, 2017 at 13:44
  • 3
    What in the world does "UUGE" mean? Great answer, by the way. Commented Aug 8, 2017 at 15:47
  • 6
    @WayneConrad vernacular for huge.
    – zzzzBov
    Commented Aug 8, 2017 at 16:05
  • 2
    Having been an IBM systems programmer during that period, it was common to have very tightly defined roles in the team,with a specialty in a particular part of the OS. The person in each of those roles would be expected to know or learn everything there was to know about it, and act as support staff to any of the other experts. We essentially ended up with a surgical team per member of the staff, each with their own specialty. Commented Aug 10, 2017 at 0:27
  • 1
    In response to your comment about making the same errors over and over, the Wikipedia article for the book has a quote from the author you might like: The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, and a few people go by it".
    – Ryan
    Commented Jul 22, 2019 at 21:43

There are some aspects of that concept that are sometimes implemented today, there are other aspects that are avoided.

Keeping teams small is one of the basic features of Agile Methods, but is also practiced outside of Agile.

Cross-functional teams are also a staple of Agile, but common outside of Agile as well.

The role of the Program Clerk is largely subsumed by computerized systems such as Version Control Systems, Software Configuration Management Systems, Change Management Systems, Document Management Systems, Wikis, Continuous Build Systems with Artifact Repositories, and so on. I mean, can you really imagine paying a full-time employee to print out source code, and manually index and file it?

Similarly, the role of a System Administrator (not part of Mills's Surgical Team, but part of a typical cross-functional team of the last years) is being obsoleted by concepts like DevOps (absorbing the role of Sysadmin into the role of Software Engineer), Platform-as-a-Service, Infrastructure-as-a-Service, and Utility Computing (making the role of Sysadmin "someone else's problem"), or Infrastructure-as-Code (turning System Administration into Software Engineering).

One of the aspects that we try to avoid today, is that at most two people understand the system. Only the surgeon is guaranteed to understand the system fully, the co-pilot may or may not. This gives a bus factor of between 1 and 2. If the surgeon gets sick, the project is dead. Period. The Agile answer to that is Collective Code Ownership, which is the exact opposite of that model: nobody is singularly responsible for any part of the system. Instead, everybody is responsible for everything as a group.

Lastly, there are some assumptions baked into that concept, which are outdated. For example, even though it is not stated explicitly, the team is set up in a way in which only one person in the team (the surgeon) actually has a computer. That is, of course, because at the time the article was written, even the idea that an entire team would have one computer for themselves, let alone one person on the team, was a stretch. (Even in 1980, when Smalltalk was released, one of the things that contributed to its failure was the fact that the system was set up such that every developer and every user had their own computer – completely unthinkable at the time.)

So, in short: I don't think the concept has been implemented exactly as described, but some aspects of it definitely are implemented, some aspects are seen as undesirable and actively avoided, some are obsolete, and some are Probably Good Ideas™, but nobody does it.

  • 1
    Regarding the second to last paragraph, I think the surgeon was expected to work with pen and paper and the clerk would have been the one team member with access to the computer. Commented Aug 6, 2017 at 18:18
  • 16
    'can you really imagine paying a full-time employee to print out source code, and manually index and file it?' No, but I can definitely imagine paying a full-time employee to manage version control and continuous build systems, and in fact in any medium-sized or bigger company this is the norm. In fact, managing wikis, document management systems and such is an entirely separate, even bigger role that there's usually an entire time of technical writers paid to do full time.
    – mrr
    Commented Aug 6, 2017 at 22:53
  • 9
    "entire team would have one computer for themselves... was a stretch" - in the early 1980s orgs would have minicomputer + terminal-based systems, so while it was the same computer, users still would have had access to it on an equal basis and the ability to run their own programs (assuming decent user isolation and security existed).
    – Dai
    Commented Aug 7, 2017 at 4:33
  • 2
    While computers were expensive in 1975, keypunches were fairly cheap. When I first programmed mainframes (not in 75, but 77) we'd write out the code on paper, punch it onto cards, deliver it to a wicket and then check back periodically to see if the printout had been delivered back. (Turn around time could be 2 hours for us and at some sites more than a day.) A clerk would have been very handy for all but the first of these tasks. I didn't see terminals until 1979 or so. Commented Aug 8, 2017 at 16:15
  • 1
    Re: Smalltalk - not only was every dev and every user supposed to have their own computer, those computers were also supposed to be powerful computers with lots of memory and a GUI. Think "workstation" rather than "PC". The original IBM PC's didn't have the horsepower to run Smalltalk. A dang shame, in my opinion... Commented Aug 9, 2017 at 16:20

It used to be, a college education was something unique, and engineers were among the chosen few. Computers were expensive, and teams worked on projects with defined business RoI. These were not very common.

What happened was micro computers, ubiquitous undergraduate education, and computer systems that don't even need University degrees to make progress with. Also, what happened was shifting economics and rising cost of labor.

The economics of a 8:2 support:engineer ratio don't make sense anymore. Engineers must be their own support. A modern human being with sufficient education and skills to be effective attached to a development team is too expensive to not be doing their own development of some sort.

(A related economics term is "the cost disease of the service sector.")

  • 5
    I downvoted due to the absurd claim regarding rising cost of labour. Labour, even specialized engineering knowledge, is cheaper today than it was in 1969. Indeed the cost of labour being more expensive today underpins this entire answer and it is a false claim. Commented Aug 6, 2017 at 19:42
  • 2
    @RibaldEddie with respect to what? If you benchmark labor against the cost of living, it has been decreasing; an hour of work can get you more food/housing than it could in 1969
    – k_g
    Commented Aug 6, 2017 at 19:58
  • 3
    @k_g well it does depend on location. In terms of inflation, in most places in the US, you can hire a developer for less in inflation-adjusted dollars today than in 1969. For reference, in the book Brooks suggests 20k for what today we would consider to be a senior dev architect and 10k for a run of the mill programmer that does the bulk of the work. In today's dollars, that 10k is about 65k. Today having most of the devs on your team earning 65k is a very good price. Commented Aug 6, 2017 at 20:23
  • 3
    This, essentially, software salaries are unchanged from 1969. Given inflation overall and the higher cost of living, developers are significantly cheaper today. Commented Aug 6, 2017 at 21:11
  • 11
    Indeed all of the benefits of the modern economic environment in terms of productivity and cheaper labour has all gone to the executive and shareholder class in business. As I said, even adjusted for inflation, software developer salaries have stayed the same while executive compensation has increased many hundreds of times higher than inflation. Additionally, many places, particularly along the west coast of North America, costs of living have increased significantly faster than inflation (see real estate) and yet professional developer salaries have barely kept pace with inflation. Commented Aug 6, 2017 at 21:33

This patterns sounds a lot to me like Mob programming:

The whole group (QA, developers and even Product Owner if needed) is working at the same time in the same problem. No stand up, high communication, directly deployed into live.

From http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is: one team – one (active) keyboard – one screen (projector of course). It’s just like doing full-team pair programming.

See it in action here: https://www.youtube.com/watch?v=dVqUcNKVbYg

  • That quote is basically what I was thinking: It sounds like pair programming, where the "surgeon" is what we've called the "driver", except on a different scale.
    – Izkata
    Commented Aug 7, 2017 at 3:49
  • 7
    It seems to me this would require that extroverted people-oriented competent software developers. Best of luck with that. Commented Aug 7, 2017 at 11:41
  • Came here to say this; or various forms of team self organisation.
    – Marcin
    Commented Aug 7, 2017 at 20:26
  • 3
    @BobJarvis I disagree. I've had great success working in teams of introverts (and I think some that included extroverts too). The key is creating a space where people feel safe and open to contribute, and are willing to stretch their natural inclinations for a time for the benefit of the group. Susan Cain's Quiet was a huge help in understanding how to work well with different temperaments: ted.com/talks/susan_cain_the_power_of_introverts Commented Aug 9, 2017 at 13:15

This team model is mentioned again in Rapid Development - Taming Wild Software Schedules by Steve McConnell on page 305. There it is called the Chief-Programmer Team.

This model arose because there was a genius on the team and computing resources were limited. It's fallen out of favor because genius is rare, and with ubiquitous computers and distributed version control we have room for many hands at the operating table.

Other references:

Baker, F. Terry. "Chief Programmer Team Management of Production Programming," IBM Systems Journal, vol. 11, no. 1, 1972, pp. 56-73.

Baker, F. Terry and Harlan D. Mills. "Chief Programmer Teams." Datamation, Volume 19, Number 12 (December 1973), pp. 58-61.


My guess is that most small self-organizing teams will tend to settle into a de-facto surgical team model anyway.

The last two teams I've been on have tended to consist of three or four people, usually one senior (surgeon), an intermediate (co-pilot) and a couple of juniors / specialists. Some of the roles in the surgical team as mentioned by Brooks nowadays are filled out by Scrum masters and sysadmins or cloud providers. Remember that source control barely existed at the time, let alone something as powerful as git.

Think of Bezos' two-pizza rule. That's your self-organizing surgical team right there.

  • 1
    so basically, nothing happened to it. +
    – gordy
    Commented Aug 6, 2017 at 22:02
  • 1
    @gordy yes and no. You'll notice that in the Brook's example, in all likelihood it would be up to the managers to determine who was in each role on the team, but in a modern agile concept, the team is self-organising. So the roles of surgeon or co-pilot fall out naturally from the way the team works. I think that's a key difference: self-organising vs. company-dictated. Commented Aug 6, 2017 at 23:26
  • I'd change "most" to "some". It really depends on the team dynamics. And it definitely has to grow organically if a surgeon is dictated from above the outcome will be suboptimal so +1 for self organized.
    – Peter
    Commented Aug 7, 2017 at 14:03
  • 2
    Sayings from The Tao of Software: #IV - The Tao of Teamwork: Good software is written by small teams working fast. Bad software is written by large teams working slowly. Corollaries: - The optimal size of a team is 1; - The maximum practical value for team size is 3; - For team sizes > 3, (mis)communication becomes a serious issue; - For team size > 6, project completion becomes seriously compromised. Project completion on deadline is likely out the window. In cases such as this the smarter developers will use the door... Thus it is written... (BWOOoooonnnggggg!!!) Commented Aug 8, 2017 at 17:52

There was a paper out of HP that suggested something similar:

  • Each software engineer would require multiple managers and multiple support people.
  • There should be a technical writer, tester, build manager, and tool-maker for each engineer.

The paper was in pre-web days, and was brought up from time to time as funny. Each year it was brought up, the commentary moved a bit more from "so ridiculous its funny" to "maybe we should do that".

Actual tests are notoriously hard to design, so it probably remains opinion. There might exist some surveys of projects and their completion rates.

  • 9
    The part that makes me smile (?) is the "...multiple managers..." thing. One manager is more than sufficient to reduce productivity. Multiple managers might drive developers to thoughts of either suicide (introverts) or murder (extroverts). Commented Aug 7, 2017 at 11:41
  • 4
    @BobJarvis -- I have had, depending on the project, as many as five simultaneous "managers" with varying titles. The effect is pretty much as you'd imagine. Commented Aug 7, 2017 at 14:03
  • 1
    Obviously you're an extrovert. So...insanity defense? Mexico? Or...justfiable homicide..? :-) Commented Aug 8, 2017 at 17:56
  • So that's why I had five bosses at one company. While I was there, any problem, whether it was mine or someone else's, I would hear it from 5 different perspectives. I usually had it analyzed by the time number 2 came along and it was just annoying to hear about it there more times. Commented Aug 9, 2017 at 11:29
  • The original idea was not "have five different managers trying to interfere" but provide, for example, "an HR benefits person" and "an HR career development person" etc. I think multiple managers would work if you billed each manager's department based on how often they contacted the engineer. Would make a fun video game! Commented Aug 25, 2017 at 21:46

I wonder how much of the need for a surgical team has become redundant because of the rise of the Internet, integrated development environments and software development kits, which can take on a lot of the functionality Fred Brooks attributed to the surgical team, including:

  • Surgeon: a programmer
  • Co-pilot: pair programmers, co-workers, online communities such as StackExchange or IRC
  • Administrator: role generally taken by a software project manager
  • Editor: IDEs integrating documentation-generators like Javadoc or Doxygen; documentation from software development kits
  • Secretary: e-mail client, project management tools such as issue trackers and pull requests, company chatrooms and mailing lists
  • Program clerk: IDE storing information on the project design, with the added ability to refactor code; documentation and examples from software development kits
  • Toolsmith: the entire open source community
  • Tester: on an immediate basis, test suites and testing libraries. But of course a separate QA process is necessary for production code.
  • Language lawyer: online documentation, StackExchange

I think you need to look at the premise of The Mythical Man Month. Hiring more programmers only makes a problematic/overdue software project get worse. The problem is in communication and getting newly added programmers up to speed on the project (takes time from existing development), technology and sometimes the domain itself.

One well supported programmer eliminates many of the communication time and coordination. Let's say you hire a consultant for Technology X. Instead of bringing this consultant up to speed on the project enough to where this individual could do all the coding in that area, he just coaches the existing developer to the point where he can get something built with some supervision.

One reason you don't see much of this is because most software gets written by one person anyway. Teams divide up the work and everyone goes and does their thing. Pair programming, reviews and anything that smells of micromanagement is frowned upon. Many do not see programming as a team sport. One person solves a given problem with some consideration for the over-all constraints.


I would argue that the more we separate design, implementation, testing, documentation, build, deployment, operations, etc into unique roles done by specialists, the more we are following the "surgical team" philosophy (though maybe not in exactly the way described).

In my experience, the devOps philosophy that every person should be capable of every task is a return to the hog-butchering model (not to say that it's bad, just different).

  • 2
    That's definitely not the DevOps model. Commented Aug 6, 2017 at 18:27
  • 5
    In fact DevOps is more like the surgical team model because Developer Operations implies that operations exists in service to development. DevOps is about two core concepts: that operations should be seen as a development practice and therefore that the tools and techniques used in development, like source control and agile methods of management, should be used by operations and that operations is there to support development. Commented Aug 6, 2017 at 18:30
  • 1
    @RibaldEddie Interesting. My experience with the DevOps group at my company is that they only hire developers and they are responsible for everything from product development, testing, documentation, deployment, etc. The word "cross-functional" comes to mind. Oh well, with 2 downvotes and a delete vote inside 15 minutes, I guess I'll be staying away from this site. Commented Aug 6, 2017 at 18:35
  • 1
    Ah, then we have different definition of "cross-functional". I'm using it to mean that every member of the team is capable of doing every task - Jiras routinely get thrown around between people because they have done away with specialization. Someone who is developing this feature will test or document the next feature. That is the "DevOps" that I have experienced. Commented Aug 6, 2017 at 18:48
  • 1
    @MikeOunsworth: that's a team of cross-functionals :-D Commented Aug 8, 2017 at 20:16

As a programmer that often filled the roles of DevOps and Build Master I felt that I often ended up in that position of being the surgical team.. err... guy in the team. As a build master I had overview on the whole code and was the first line when it failed. Oftentimes I would just fix it myself.
I was often the one writing these metrics systems and measure the hotpoints in the code, parts that would fail more often, that attracted the most bug reports etc. I did not just published the results to the team I would analyse them too, find the kink that caused issue and proposed solutions and architectural changes to address this.

As a DevOps I would automate huge swathes of process and overhead. I'd research technologies and tools that would make life easier on the team, the whole team, from developers, QA testers IT ops all the way up to management. My role was to understand the process, yes; but by keeping my eyes fixed on the team (the actual humans) using (suffering through) that process I was able to distil it to a point of making it completely transparent while still getting a swath of useful data to get an objective view of that ever elusive "big picture".

It's an ungrateful position to have and likely why it is shunned so much. I know I did my job well when nobody noticed that process, when nobody gave a thought about the build pipeline. So yes, a well oiled machine is quickly taken for granted. But I knew, in fact I measured, the multiplicative impact this work can have on a team's productivity and it is well worth the investment.

So yes, I think that role is still very much alive today, though admittedly it did evolve from what it was back then.

Not the answer you're looking for? Browse other questions tagged or ask your own question.