5 ms·

I went from 20 years of several FAANG jobs to working for a small tech company with about 300 engineers. It was a bit of a rude awakening. The technology stack

I went from 20 years of several FAANG jobs to working for a small tech company with about 300 engineers. It was a bit of a rude awakening. The technology stack is a house of cards consisting of hundreds of homegrown wrappers around AWS. Everything is brittle, undocumented, and constantly changing. Every little thing is a huge pain in the ass.

greesil 4y ago
I think they meant job stability not system stability.
- deleted 4y ago
  [deleted]
- dadoge 4y ago
  Right, cuz 300 people tech companies are known for their job stability…. /s
  - statictype 4y ago
    300 is a pretty large number. I’m not sure why you added a /s in there.
    - noisy_boy 4y ago
      Maybe the /s makes sense for people in 10000 employee companies :)
      - bluefirebrand 4y ago
        I think I'd be more worried about my job in a 10000 person company than a 300 person company. If Im in a 300 person company I'm probably one of 40-60 devs, and most of my peers know me and have met me. If I'm a senior dev, there's a good chance I'm on first name basis with the executive team, and they know what I work on and the impact I have. There's a lot better chance of me being able to demonstrate my value and avoid being let go if cuts are needed. At a 10000 person company I'm basically guaranteed to just be an employee number next to a salary number in a spreadsheet, when it comes time for cuts.
- monksy 4y ago
  Job stability at that company is not guaranteed. Often times it is poorly run and their lack of formal processes and adherence to discipline is a result of the managements' incompetence.
23B1 4y ago
So what you're saying is you have a lot of work to do = job security ;)
statictype 4y ago
Welcome, Neo, to the real world. Most companies cant afford to throw large amounts of money at a team who’s entire job is managing a Jenkins pipeline. That’s a part time project for a single developer at smaller places.
- sefrost 4y ago
  Note to OP - when that developer leaves the company they will host a session called a "handover". At the handover meeting they rapidly run through how they think the pipeline works, lay out some caveats and then they're gone. That's the documentation. You own the pipeline now. It's probably a good idea to take vacation whenever the person who owns the Jenkins pipeline announces that they've handed in their notice. Otherwise you might be invited to the handover meeting.
  - jacurtis 4y ago
    Yep, been to a lot of these. We call them "KT" sessions (knowledge-transfer). I shiver all down my spine when I hear "KT". You basically take the person who's been working on something for thousands of hours most likely and has probably written a lot of work arounds and shortcuts to get their job done and they now have a 1 hour zoom session to brain dump their entire existance onto the poor souls who have to pick up the pieces when they are gone. After that hour, they basically sign off with: glhf
- genocidicbunny 4y ago
  > Most companies cant afford to throw large amounts of money at a team who’s entire job is managing a Jenkins pipeline. I don't agree with this at the 300 engineer level; Specifically that they can't afford it. At that point, one or two more engineers is 1-2% increase in spend on compensation, and if you can get someone to handle architecture and developer support (ideally two different people) and empower them to make useful changes, you can probably get the ball rolling. Now, if you're talking about a 20-50 engineer shop, the math can be a fair bit different and there I do agree with you. It seems more down to the evergreen issue of tech debt and fragile tech stacks being a hard-to-quantify cost and mostly hidden from those making the budget decisions. No budget for maintenance or architecture -- things are done in the cheapest most expedient way possible. Then it becomes harder to make future changes, so doing it the right way starts costing even more, and the cycle repeats. > Welcome, Neo, to the real world. Indeed. Gamedev was frustrating for this quite often.
nine_k 4y ago
For me, 300 is a large company. I try to work for companies of several dozen people, with a dozen or fewer engineers. It makes my impact much more visible. The tech stack is usually already a hodgepodge, but it's small enough, and parts can be improved or replaced easily enough. Being to a FAANG company (I worked for the F and the G) gives one a view of colossal tech stacks, some wonderful achievements of technological thought, some well thought-out processes (and also downsides, all well-known). It's a great learning experience, but a chance to make any publicly visible dent are pretty small.
- stult 4y ago
  IME there is a code quality/sanity valley of death between about 50-1000 people, with the lower bound shifting upwards a bit depending on the maturity of the company's founding/early stage technical contributors. You get more bang for your buck with five of the right people than 50 of the wrong ones in the early stages, and sometimes that determines five years later whether you are drowning in tech debt (bad) or 1000 years ahead of the competition (inefficient, probably) or maybe just barely staying one step ahead of the reaper (optimal, probably). But a lot of companies limp into the valley, get enough revenue to stay alive for a while, and then slowly fade into obscurity the second a nimbler competitor shows up on the scene and eats their lunch. That's why small companies are fun. All that visible impact and you know you won't be mired in the bureaucratic death spiral of a medium-sized company lurching into obscurity!
- jacurtis 4y ago
  I've worked at the G and hated it. It was too big and agree 100% with your analysis. Money and benefits are great, especially considering how little work is actually expected of you (compared to smaller orgs). I enjoyed always being able to find someone who knew more than me, which opened up really good learning opportunities. But as you said, good luck getting any of your accomplishments noticed. Your direct manager would notice and you hope they write the right kinds of letters and accolades to other people to notify them, but that's about all you can ask for. I've also been at small startups. I worked somewhere early in my career where I was employee #5 and stayed there until we were about 70 employees. It was exciting and I can say humbly that I touched essentially every feature and decision that happened during those ~3 years, which can be rewarding. I'm not saying I personally built the whole company, i had other good engineers around me, but you were involved in everything, so you touched everything and played at least a partial role in everything that was built. That's a great learning experience in its own right. But I found it very stressful to have so much expected of you. At these small companies you will always have more on your plate than even the most efficient engineer can accomplish. The backlog is endless, and solving even basic problems often required new systems or decisions because everything is new and no precedent exists for anything. I've found my happy place at what i call a "mid-size" company. By my defintiion that is ~250 employees (+/- 100). I admit that the industry definition of mid-size is generally 500-1000 though. I really like this 200-300 range size. It is big enough that at least basic systems exist for everything already. There are teams for each product meaning that you aren't building everything and can focus on a certain area. But you also aren't pigeonholed in a narrow job description either. While you might have a sector of the app you manage, it can still be moderately broad giving you good variety. The team isn't so small that you are doing everything, but its also still small enough that if you accomplish impressive achievements that it still gets noticed. It is small enough that you know most people in the company by name but the team is still large enough you can always find someone with expertise in a weird thing you might want help with. By the time the company is this size, they aren't going to dissapear overnight like a 20 person startup might (although in tech anything is still possible). I'm happy where I am now, so no plans on leaving. But when I search again, I am going to be targeting companies of 100-400 employees again. I really think its the perfect size.
taneq 4y ago
Try an actually small company with like 3 engineers. Then if there’s an issue you talk to Bob if it’s hardware related or Fred if it’s software related, and hopefully both of them keep their part of the stack a little more streamlined purely out of self defence.
EdwardDiego 4y ago
Yeah, I left a large company for a smaller company, and yeah, you do miss having people entirely dedicated to build systems etc.
- jacurtis 4y ago
  I worked on a team that managed the build systems at a FAANG. It was seriously the worst. Teams would come to you and say > "we made this service, we need a pipeline that does this, exactly this way, and we need it.... by Friday, let me know if I need to escalate it." Whenever people threatened to escalate stuff, I would always laugh and say "go for it", to be honest I can't remember the last time I worked on something that wasn't "escalated". Basically the escalated pipeline was e size and our bandwidth was 0.9e - so we never would catch up and if it wasn't escalated it basically didn't exist.
deleted 4y ago
[deleted]
zug_zug 4y ago
I went from 10 years in startup to fang and felt fang was awful. Everything was built in-house, and none of it held a candle to industry-standard tools. Every single thing: observability, containerization, CI/CD, code-review, source-control, etc was mostly written in PHP with seemingly no UI input and no documentation. The economy of scale largely favors the startup, because they simply rent best-in-world tools hosted by another company that has hundreds of people dedicated to source control or IDE (or whatever) versus 20 engineers a FANG company would put on it.
- taeric 4y ago
  I've yet to see these mythical industry tools that do these tasks well. :(
  - chihuahua 4y ago
    You can say whatever you want about Facebook, but their tool/system for committing code changes is sheer perfection. Starting with managing source code changes on your own dev server, getting it code reviewed, merging it into the main branch, and getting it deployed to production. All of it is easy to figure out, and it works without complications. It can handle pull requests of 20000 files without any trouble.
- ryanwaggoner 4y ago
  Widespread PHP at a FAANG has to be Facebook, right?
- Karrot_Kream 4y ago
  Those tools are affordable until the company making the tool needs to start actually making a profit and they raise their prices or they decrease their LOS. Then the tools become an expensive risk and the price increases end up percolating into your own startup. If you raise prices to compensate, you'll affect your growth. That's how startups go under. In a ZIRP world using the tools of other startups makes sense but the stability of the FAANGs and their in-house tooling means they can weather much choppier economic conditions than the equivalent startup.
triyambakam 4y ago
That's interesting. 300 engineers isn't what I would consider small in my startup experience. That's 3x larger than the current engineering organization I would in.
alsetmusic 4y ago
I’m surprised people are responding talking about being more visible in a small company. The best thing about moving to a small company (for me) is knowing everyone, even if I don’t necessarily like everyone. I’m on a first-name basis with the entire org and we can all celebrate an achievement together by going out to a restaurant plus drinks. We have board game nights at the office (we’re barely over 20 people). These types of connections aren’t anything like when I was in a huge multinational and was close with a handful of people. (Not everyone wants to participate in the group activities and that’s fine too.) (Also, again, I have this luxury because I don’t have dependents. I know this calculus doesn’t work for everyone.)
meowtimemania 4y ago
How old is this tech company? I find most smaller companies use well known open source frameworks + AWS services. It’s the big companies that do everything in house
- chihuahua 4y ago
  The company is over 10 years old
bradlys 4y ago
> small tech company with about 300 engineers. This is not a small tech company. This is medium to large. If the company itself has over 1,000 employees - it's a large company. It's just not a giant company like any of the FAANG types.

greesil 4y ago

I think they meant job stability not system stability.

deleted 4y ago
[deleted]
dadoge 4y ago
Right, cuz 300 people tech companies are known for their job stability…. /s
- statictype 4y ago
  300 is a pretty large number. I’m not sure why you added a /s in there.
  - noisy_boy 4y ago
    Maybe the /s makes sense for people in 10000 employee companies :)
    - bluefirebrand 4y ago
      I think I'd be more worried about my job in a 10000 person company than a 300 person company. If Im in a 300 person company I'm probably one of 40-60 devs, and most of my peers know me and have met me. If I'm a senior dev, there's a good chance I'm on first name basis with the executive team, and they know what I work on and the impact I have. There's a lot better chance of me being able to demonstrate my value and avoid being let go if cuts are needed. At a 10000 person company I'm basically guaranteed to just be an employee number next to a salary number in a spreadsheet, when it comes time for cuts.
monksy 4y ago
Job stability at that company is not guaranteed. Often times it is poorly run and their lack of formal processes and adherence to discipline is a result of the managements' incompetence.

23B1 4y ago

So what you're saying is you have a lot of work to do = job security ;)

statictype 4y ago

Welcome, Neo, to the real world. Most companies cant afford to throw large amounts of money at a team who’s entire job is managing a Jenkins pipeline. That’s a part time project for a single developer at smaller places.

sefrost 4y ago
Note to OP - when that developer leaves the company they will host a session called a "handover". At the handover meeting they rapidly run through how they think the pipeline works, lay out some caveats and then they're gone. That's the documentation. You own the pipeline now. It's probably a good idea to take vacation whenever the person who owns the Jenkins pipeline announces that they've handed in their notice. Otherwise you might be invited to the handover meeting.
- jacurtis 4y ago
  Yep, been to a lot of these. We call them "KT" sessions (knowledge-transfer). I shiver all down my spine when I hear "KT". You basically take the person who's been working on something for thousands of hours most likely and has probably written a lot of work arounds and shortcuts to get their job done and they now have a 1 hour zoom session to brain dump their entire existance onto the poor souls who have to pick up the pieces when they are gone. After that hour, they basically sign off with: glhf
genocidicbunny 4y ago
> Most companies cant afford to throw large amounts of money at a team who’s entire job is managing a Jenkins pipeline. I don't agree with this at the 300 engineer level; Specifically that they can't afford it. At that point, one or two more engineers is 1-2% increase in spend on compensation, and if you can get someone to handle architecture and developer support (ideally two different people) and empower them to make useful changes, you can probably get the ball rolling. Now, if you're talking about a 20-50 engineer shop, the math can be a fair bit different and there I do agree with you. It seems more down to the evergreen issue of tech debt and fragile tech stacks being a hard-to-quantify cost and mostly hidden from those making the budget decisions. No budget for maintenance or architecture -- things are done in the cheapest most expedient way possible. Then it becomes harder to make future changes, so doing it the right way starts costing even more, and the cycle repeats. > Welcome, Neo, to the real world. Indeed. Gamedev was frustrating for this quite often.

nine_k 4y ago

For me, 300 is a large company. I try to work for companies of several dozen people, with a dozen or fewer engineers. It makes my impact much more visible. The tech stack is usually already a hodgepodge, but it's small enough, and parts can be improved or replaced easily enough. Being to a FAANG company (I worked for the F and the G) gives one a view of colossal tech stacks, some wonderful achievements of technological thought, some well thought-out processes (and also downsides, all well-known). It's a great learning experience, but a chance to make any publicly visible dent are pretty small.

stult 4y ago
IME there is a code quality/sanity valley of death between about 50-1000 people, with the lower bound shifting upwards a bit depending on the maturity of the company's founding/early stage technical contributors. You get more bang for your buck with five of the right people than 50 of the wrong ones in the early stages, and sometimes that determines five years later whether you are drowning in tech debt (bad) or 1000 years ahead of the competition (inefficient, probably) or maybe just barely staying one step ahead of the reaper (optimal, probably). But a lot of companies limp into the valley, get enough revenue to stay alive for a while, and then slowly fade into obscurity the second a nimbler competitor shows up on the scene and eats their lunch. That's why small companies are fun. All that visible impact and you know you won't be mired in the bureaucratic death spiral of a medium-sized company lurching into obscurity!
jacurtis 4y ago
I've worked at the G and hated it. It was too big and agree 100% with your analysis. Money and benefits are great, especially considering how little work is actually expected of you (compared to smaller orgs). I enjoyed always being able to find someone who knew more than me, which opened up really good learning opportunities. But as you said, good luck getting any of your accomplishments noticed. Your direct manager would notice and you hope they write the right kinds of letters and accolades to other people to notify them, but that's about all you can ask for. I've also been at small startups. I worked somewhere early in my career where I was employee #5 and stayed there until we were about 70 employees. It was exciting and I can say humbly that I touched essentially every feature and decision that happened during those ~3 years, which can be rewarding. I'm not saying I personally built the whole company, i had other good engineers around me, but you were involved in everything, so you touched everything and played at least a partial role in everything that was built. That's a great learning experience in its own right. But I found it very stressful to have so much expected of you. At these small companies you will always have more on your plate than even the most efficient engineer can accomplish. The backlog is endless, and solving even basic problems often required new systems or decisions because everything is new and no precedent exists for anything. I've found my happy place at what i call a "mid-size" company. By my defintiion that is ~250 employees (+/- 100). I admit that the industry definition of mid-size is generally 500-1000 though. I really like this 200-300 range size. It is big enough that at least basic systems exist for everything already. There are teams for each product meaning that you aren't building everything and can focus on a certain area. But you also aren't pigeonholed in a narrow job description either. While you might have a sector of the app you manage, it can still be moderately broad giving you good variety. The team isn't so small that you are doing everything, but its also still small enough that if you accomplish impressive achievements that it still gets noticed. It is small enough that you know most people in the company by name but the team is still large enough you can always find someone with expertise in a weird thing you might want help with. By the time the company is this size, they aren't going to dissapear overnight like a 20 person startup might (although in tech anything is still possible). I'm happy where I am now, so no plans on leaving. But when I search again, I am going to be targeting companies of 100-400 employees again. I really think its the perfect size.

taneq 4y ago

Try an actually small company with like 3 engineers. Then if there’s an issue you talk to Bob if it’s hardware related or Fred if it’s software related, and hopefully both of them keep their part of the stack a little more streamlined purely out of self defence.

EdwardDiego 4y ago

Yeah, I left a large company for a smaller company, and yeah, you do miss having people entirely dedicated to build systems etc.

jacurtis 4y ago
I worked on a team that managed the build systems at a FAANG. It was seriously the worst. Teams would come to you and say > "we made this service, we need a pipeline that does this, exactly this way, and we need it.... by Friday, let me know if I need to escalate it." Whenever people threatened to escalate stuff, I would always laugh and say "go for it", to be honest I can't remember the last time I worked on something that wasn't "escalated". Basically the escalated pipeline was e size and our bandwidth was 0.9e - so we never would catch up and if it wasn't escalated it basically didn't exist.

deleted 4y ago

[deleted]

zug_zug 4y ago

I went from 10 years in startup to fang and felt fang was awful. Everything was built in-house, and none of it held a candle to industry-standard tools. Every single thing: observability, containerization, CI/CD, code-review, source-control, etc was mostly written in PHP with seemingly no UI input and no documentation. The economy of scale largely favors the startup, because they simply rent best-in-world tools hosted by another company that has hundreds of people dedicated to source control or IDE (or whatever) versus 20 engineers a FANG company would put on it.

taeric 4y ago
I've yet to see these mythical industry tools that do these tasks well. :(
- chihuahua 4y ago
  You can say whatever you want about Facebook, but their tool/system for committing code changes is sheer perfection. Starting with managing source code changes on your own dev server, getting it code reviewed, merging it into the main branch, and getting it deployed to production. All of it is easy to figure out, and it works without complications. It can handle pull requests of 20000 files without any trouble.
ryanwaggoner 4y ago
Widespread PHP at a FAANG has to be Facebook, right?
Karrot_Kream 4y ago
Those tools are affordable until the company making the tool needs to start actually making a profit and they raise their prices or they decrease their LOS. Then the tools become an expensive risk and the price increases end up percolating into your own startup. If you raise prices to compensate, you'll affect your growth. That's how startups go under. In a ZIRP world using the tools of other startups makes sense but the stability of the FAANGs and their in-house tooling means they can weather much choppier economic conditions than the equivalent startup.

triyambakam 4y ago

That's interesting. 300 engineers isn't what I would consider small in my startup experience. That's 3x larger than the current engineering organization I would in.

alsetmusic 4y ago

I’m surprised people are responding talking about being more visible in a small company. The best thing about moving to a small company (for me) is knowing everyone, even if I don’t necessarily like everyone. I’m on a first-name basis with the entire org and we can all celebrate an achievement together by going out to a restaurant plus drinks. We have board game nights at the office (we’re barely over 20 people). These types of connections aren’t anything like when I was in a huge multinational and was close with a handful of people. (Not everyone wants to participate in the group activities and that’s fine too.) (Also, again, I have this luxury because I don’t have dependents. I know this calculus doesn’t work for everyone.)

meowtimemania 4y ago

How old is this tech company? I find most smaller companies use well known open source frameworks + AWS services. It’s the big companies that do everything in house

chihuahua 4y ago
The company is over 10 years old

bradlys 4y ago

> small tech company with about 300 engineers. This is not a small tech company. This is medium to large. If the company itself has over 1,000 employees - it's a large company. It's just not a giant company like any of the FAANG types.