6 ms·

as someone who has only worked on small teams, i thought this was normal. My current position is leading a small team, but we have interactions with a number of

as someone who has only worked on small teams, i thought this was normal. My current position is leading a small team, but we have interactions with a number of teams inside of FANG companies and it's amazing the limited amount of knowledge and access each position/person has. Most of my engineers can run circles around our partners. I always thought every engineer should know how to deploy a server, install deps, understand caching, etc and setup an app... turns out, that is apparently not even remotely expected at most companies. I guess the bigger the company the more narrow the skillset required.

aprdm 7y ago
Yeah, I worked in start ups and that's where I got the fast pace and I think that allowed me to rise to high ranks very fast at bigger companies as I have a solid understanding of all the stack. In bigger companies traditionally they had a person / department more specialized per part of the stack, I think is a lot about the "devops" culture.
earthboundkid 7y ago
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 ;)
ignoramous 7y ago
You're right. That's been my experience, as well. But... the crème de la crème from FANG are different beasts altogether. I must also point out that what FANG employees do get in abundance is the ability to learn from highly scalable systems that others build, cutting edge tech others work on, experiment on company's dime, pursue an eng/mgmt tract more in line with their personal interests, and job stability. It also affords them an opportunity to be part of a team that one day builds a groundbreaking tech and pushes the envelope forward not just for the company but the entire industry.
endtime 7y ago
Having been the CTO of a startup and then a SWE at a FAANG company for 8 years, I disagree. Being at a startup does indeed require a broad technical skillset, but being effective inside a large company requires a lot of skills (both technical and not) that early startup employees may not have or need. I've grown a lot from both environments.
- o-__-o 7y ago
  Are you me? I am constantly being gutchecked that a startup mentality does not fly when you have several hundred million in the bank. That said, my enterprise and upper management butt kissing experience from the 00s don’t seem to matter either. I can stay heads down in code and I’m not in fear over being downsized. The hard part is teaching these young kids how to scope.
z3t4 7y ago
It might take Alice 10 hours to do the sysadmin, 5 for the database, and 15 for the devops. Bob however can do the devops in 2 hours, sysadmin in 3 hours and database in 4 hours. Bob is of course more productive, but if you let Alice do all the DBA, then Bob will be even more productive, and the total output of your team will increase.
- mushufasa 7y ago
  Ricardo strikes again https://en.wikipedia.org/wiki/Comparative_advantage https://en.wikipedia.org/wiki/Comparative_advantage

aprdm 7y ago

Yeah, I worked in start ups and that's where I got the fast pace and I think that allowed me to rise to high ranks very fast at bigger companies as I have a solid understanding of all the stack. In bigger companies traditionally they had a person / department more specialized per part of the stack, I think is a lot about the "devops" culture.

earthboundkid 7y ago

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 ;)

ignoramous 7y ago

You're right. That's been my experience, as well. But... the crème de la crème from FANG are different beasts altogether. I must also point out that what FANG employees do get in abundance is the ability to learn from highly scalable systems that others build, cutting edge tech others work on, experiment on company's dime, pursue an eng/mgmt tract more in line with their personal interests, and job stability. It also affords them an opportunity to be part of a team that one day builds a groundbreaking tech and pushes the envelope forward not just for the company but the entire industry.

endtime 7y ago

Having been the CTO of a startup and then a SWE at a FAANG company for 8 years, I disagree. Being at a startup does indeed require a broad technical skillset, but being effective inside a large company requires a lot of skills (both technical and not) that early startup employees may not have or need. I've grown a lot from both environments.

o-__-o 7y ago
Are you me? I am constantly being gutchecked that a startup mentality does not fly when you have several hundred million in the bank. That said, my enterprise and upper management butt kissing experience from the 00s don’t seem to matter either. I can stay heads down in code and I’m not in fear over being downsized. The hard part is teaching these young kids how to scope.

z3t4 7y ago

It might take Alice 10 hours to do the sysadmin, 5 for the database, and 15 for the devops. Bob however can do the devops in 2 hours, sysadmin in 3 hours and database in 4 hours. Bob is of course more productive, but if you let Alice do all the DBA, then Bob will be even more productive, and the total output of your team will increase.

mushufasa 7y ago
Ricardo strikes again https://en.wikipedia.org/wiki/Comparative_advantage https://en.wikipedia.org/wiki/Comparative_advantage