
What Happened to the “Surgical Team” Pattern from “The Mythical Man-Month”? - vog
https://softwareengineering.stackexchange.com/q/355203/69228
======
phd514
For better or worse, I think the idea of the surgical team runs counter to the
prevailing egalitarian spirit in software development. Personally, I think
there are some projects that are better suited to it than others. For example,
I've been involved with technically-demanding projects that suffered from the
"too many cooks in the kitchen" syndrome that the surgical team approach
addresses. On the other hand, there's plenty of more mundane feature
development work that probably doesn't benefit nearly as much from that
approach.

One criticism that I would expect some to make against the surgical team
approach is that it doesn't help to develop more junior team members. From
personal experience, I think it's actually a good way to develop junior team
members. I learned the most when I was around more technically experienced
team members even if they were dictating the breakdown of the work rather than
when I went off on my own to develop less technically challenging features.
Some mix of the two is probably ideal, but I think there's some lack of
appreciation for the benefits of a surgical team environment.

------
dvfjsdhgfv
Many open source project are functioning in this way. In companies, it's more
common in the initial phases, but when you just maintain code, it wouldn't
make much sense.

------
lj3
Isn't this how most companies are set up? If the architect/technical lead is
the surgeon, then the junior/mid level developers are the support team.

~~~
dagw
Some companies certainly, but far from all. Some place I've been the
architect/technical lead doesn't actually do much day to day coding. They're
more responsible for defining tasks, and making sure they get delegated and
completed to a high enough standard. Sure they'll keep an eye on the code and
come with suggestions, but they only very rarely get their hands bloody (to
extend the metaphor).

------
mpweiher
Simple: it is great at solving problems, but not so great for middle
management.

