6 ms·

And the thing is, generalists do better work. They do less work overall because there are fewer of them, but compare a typical enterprise 50 person team to the

And the thing is, generalists do better work. They do less work overall because there are fewer of them, but compare a typical enterprise 50 person team to the output of a team of 5 generalists, hands down the generalists will make a better product every time because there's no buck passing or shoulder shrugging about problems.

jedberg 7y ago
I think specialists make more robust systems, but generalists get more done. When I work at large companies, it makes me sad how long it takes to get anything done. But once the work is complete, it is really solid. It scales well, it handles edge cases gracefully, it deploys cleanly, all because a large team of specialists made each part of the puzzle work really well. The slow progress was dictated by the extra communication to coordinate the specialists, but at the end of the day it ends up being worth it. (All of this of course assumes you work in an org with lots of really good specialists).
- mtnGoat 7y ago
  i agree on this point. having highly specialized SMEs certainly helps with scale, for sure. iteration is slower at bigger companies but some of those teams are inventing wheels as they go. which requires slower movement than general web/mobile dev.
encoderer 7y ago
“Every time” until they are asked to build a product that requires a deep specialized skill set. I am a generalist full stack developer who has built a SaaS business very similar to the way OP has. No team of me’s could’ve produced, say, TensorFlow. Great teams and companies have generalists and specialists.
caspar 7y ago
IMO, the reduced output of a team of specialists vs a team of generalists has less to do with generalists doing better work, and more to do with it being impractical to hire specialists at lower levels of scale - and higher levels of scale are less efficient. A 3 person engineering team doesn't want to hire a specialist DB admin who knows Postgres back to front but can't code. A company of 1000+ engineers might, because they might have problems that require that expertise. But any engineer working in a company of 1000+ engineers is also subject to friction resulting from resource allocation inefficiencies, communication overhead, regulatory compliance, etc: the reduced output from those factors has little to do with the specialist engineers doing worse work, and more to do with them working at the size of company that can afford to hire specialists. (You could make the case that buck passing is an example of resource allocation inefficiencies, as it is often accidentally or purposely enabled by company management, but nonetheless, that's not a generalist vs specialist tradeoff.)
- BigJono 7y ago
  Completely agree. IMO the optimal efficiency is easily a team of either 2 or 3, with one FE and one BE, and optionally someone doing dev-ops-y stuff for both of them. After that point your 'output per man hours' can only really go down.
  - vonseel 7y ago
    In economic terms, sounds like the marginal utility of adding an engineer goes down significantly as companies get larger and past the start-up phase ;)

jedberg 7y ago

I think specialists make more robust systems, but generalists get more done. When I work at large companies, it makes me sad how long it takes to get anything done. But once the work is complete, it is really solid. It scales well, it handles edge cases gracefully, it deploys cleanly, all because a large team of specialists made each part of the puzzle work really well. The slow progress was dictated by the extra communication to coordinate the specialists, but at the end of the day it ends up being worth it. (All of this of course assumes you work in an org with lots of really good specialists).

mtnGoat 7y ago
i agree on this point. having highly specialized SMEs certainly helps with scale, for sure. iteration is slower at bigger companies but some of those teams are inventing wheels as they go. which requires slower movement than general web/mobile dev.

encoderer 7y ago

“Every time” until they are asked to build a product that requires a deep specialized skill set. I am a generalist full stack developer who has built a SaaS business very similar to the way OP has. No team of me’s could’ve produced, say, TensorFlow. Great teams and companies have generalists and specialists.

caspar 7y ago

IMO, the reduced output of a team of specialists vs a team of generalists has less to do with generalists doing better work, and more to do with it being impractical to hire specialists at lower levels of scale - and higher levels of scale are less efficient. A 3 person engineering team doesn't want to hire a specialist DB admin who knows Postgres back to front but can't code. A company of 1000+ engineers might, because they might have problems that require that expertise. But any engineer working in a company of 1000+ engineers is also subject to friction resulting from resource allocation inefficiencies, communication overhead, regulatory compliance, etc: the reduced output from those factors has little to do with the specialist engineers doing worse work, and more to do with them working at the size of company that can afford to hire specialists. (You could make the case that buck passing is an example of resource allocation inefficiencies, as it is often accidentally or purposely enabled by company management, but nonetheless, that's not a generalist vs specialist tradeoff.)

BigJono 7y ago
Completely agree. IMO the optimal efficiency is easily a team of either 2 or 3, with one FE and one BE, and optionally someone doing dev-ops-y stuff for both of them. After that point your 'output per man hours' can only really go down.
- vonseel 7y ago
  In economic terms, sounds like the marginal utility of adding an engineer goes down significantly as companies get larger and past the start-up phase ;)