> That doesn't sound anything like a surgical team to me. It just sounds like you're mixing experience levels to train new people.
I think I'm more saying that we have moved toward a specialization of labor that supports the software engineer in a different way, even though it hasn't ended up looking like a surgical team. We have product managers who understand the user's needs and organize feedback sessions, we have product designers who are experts of UX design, we have junior engineers that implement components with the oversight of the more senior engineer, etc. It has ended up being more collaborative, and it's not clear to me that it would be better if instead we tried to organize it around a single person who was the overall "surgeon" who did the key aspects of all this work with the others in a supporting position.
In some companies there is a "directly responsible individual" who is in charge, but in others there isn't. Are they acting as a surgeon in that case, or are they doing project management? It depends on the organization. How much ownership that person has and what is the impact on that person of success and failure? It's hard to analyze a different organizational framework as it relates to Brooks.
> Why? Has human nature changed in 40 years? This isn't like reading Plato, where he simply made up things he didn't understand. On the contrary, I would be much more surprised if the nature of team productivity had changed in only 40 years.
Brooks' writing wasn't grounded in fundamental human truths, it was grounded in his observations of software projects that existed in 1975 and related observations of how work was performed in other industries.
My intuition is that if there are Way A through Way Z ways of doing things that are optimized for A through Z different types of organizational problems, Brooks was saying "Way D is the best for software projects." But because we now work on different types of problems (much shorter feedback loops, higher levels of abstraction, users with higher levels of sophistication, greater importance of software ecosystem) maybe Way E (Silicon Valley style agile, lean product management, etc.) is more appropriate. Since Way E has been successful in the market, it at least seems adaptive. Otherwise companies would have a strong incentive to change to Brooks' Way D.
I think I'm more saying that we have moved toward a specialization of labor that supports the software engineer in a different way, even though it hasn't ended up looking like a surgical team. We have product managers who understand the user's needs and organize feedback sessions, we have product designers who are experts of UX design, we have junior engineers that implement components with the oversight of the more senior engineer, etc. It has ended up being more collaborative, and it's not clear to me that it would be better if instead we tried to organize it around a single person who was the overall "surgeon" who did the key aspects of all this work with the others in a supporting position.
In some companies there is a "directly responsible individual" who is in charge, but in others there isn't. Are they acting as a surgeon in that case, or are they doing project management? It depends on the organization. How much ownership that person has and what is the impact on that person of success and failure? It's hard to analyze a different organizational framework as it relates to Brooks.
> Why? Has human nature changed in 40 years? This isn't like reading Plato, where he simply made up things he didn't understand. On the contrary, I would be much more surprised if the nature of team productivity had changed in only 40 years.
Brooks' writing wasn't grounded in fundamental human truths, it was grounded in his observations of software projects that existed in 1975 and related observations of how work was performed in other industries.
My intuition is that if there are Way A through Way Z ways of doing things that are optimized for A through Z different types of organizational problems, Brooks was saying "Way D is the best for software projects." But because we now work on different types of problems (much shorter feedback loops, higher levels of abstraction, users with higher levels of sophistication, greater importance of software ecosystem) maybe Way E (Silicon Valley style agile, lean product management, etc.) is more appropriate. Since Way E has been successful in the market, it at least seems adaptive. Otherwise companies would have a strong incentive to change to Brooks' Way D.