Published: October 14, 2025
18
20
566

This is so typical of eng leadership coming from Big Tech: "The whole senior engineering leadership came from Amazon, where they were used to each team owning a distinct service. They tried to apply that model directly." Copying *exactly* what they are used to. Though (cont'd)

Though in the defense of Amazon, out of all of Big Tech, eng leaders coming from Amazon and copying practives *usually* works out pretty well! Because of all of Big Tech, Amazon is 1. The most scrappy 2. Don't use custom in-house infra (but AWS) 3. Are HUGE on reliablity!!

So Amazon eng leaders coming over to any company usually sort out reliablity issues plaguing the company very quickly (they just put in a weekly Ops review, prioritize reliablity work and 2 months later things magically get much better - not even kidding, first-hand experience)

It's also a reason that if you can hire into a startup from Google, Meta, Apple and Amazon: the Amazon eng leader hire is by far the most likely to "hit the ground running" and help the startup. Those coming from the other 3 will be disoriented for a while in a smaller place

(As usual, this is generalizing: amazing people work at all places and many can and do hit the ground running, so always focus on the individual if you're hiring, and just check that they are someone who is low on ego, high on learning and they will be fine if so)

@GergelyOrosz AWS internally uses a litany of internal tools no? Or has this changed dramatically over the last few years — thinking Brazil, Pipelines, Apollo… even Chime lol. Do other major enterprises use significantly more?

@oskarmcdermott Yes they use a bunch but the cloud infra is… AWS All other Big Tech uses custom cloud infra, not public one Save for Microsoft, but startups don’t use Azure, Azure is the boomer cloud

@GergelyOrosz "we're converting our entire app to graphql" when you have 3 engineers, no customers, running on pre-seed money

@GergelyOrosz The OP resulted in me writing this yesterday https://robbyonrails.com/artic...

@GergelyOrosz The post suggests poor implementation was the key reason for failure but it’s also possible that the idea was flawed as well. Likely non technical managers trying to cargo cult a solution they didn’t understand and inexperienced engineers not knowing how to implement the vision

@GergelyOrosz This is also true of engineers in smaller firms getting enamored by blog posts from BigTech, thinking they need Google scale tech for their half-dozen enterprise customers. (Been there)

@GergelyOrosz The temptation to cargo-cult best practices from big tech is very high - since they have a degree of validity and proof at scale. It becomes challenging when they are implemented as-is with a high degree of fidelity (identical processes, frameworks, rituals) - as opposed to

@GergelyOrosz Everyone should re-read chapter 3 of Mythical Man-Month and then the industry can embrace the Surgical Team https://www.bryanking.net/2025...

@GergelyOrosz This happens more often than people will admit. Making engineering leadership own outcomes and working closer to sales/customers works out well for small teams.

@GergelyOrosz Same for copying the performance process from big tech. Calibrations at the big companies are about dividing a pie that's going to be there with or without you. Performance at a startup is about a whole team going 0 to 1 or failing collectively. It's a different ballgame.

@GergelyOrosz At my last company they did exactly that. The "principal meta engineer" only spoke to other new meta leadership, but somehow knew already what the solution was before we even got to explain the problem. Not sad about jumping that ship, not a moment.

@GergelyOrosz I work on crap like this. The architecture is always, ALWAYS an awful, bloated, continuously crashing mess. There's no reason for it to be like that except to justify the jobs of the seniors. Absolute corruption all to run something that could be done on 1/36th the compute.

@GergelyOrosz Big tech is a cesspool of executives copy and pasting the same thing they did at the last company, typical poorly.

@GergelyOrosz I have a hard time believing that Amazon principal engineers reach for a Go stack

@GergelyOrosz Good engineers know how important is to pick the best tools/methods/good practices and tailor them to solve the problem. Bad engineers try to tailor the problem to use their tools/methods of choice. Context is king.

@GergelyOrosz FAANG costs

@GergelyOrosz They are actually bad engineers if they just copy what they did somewhere else with zero consideration to where they are or if it’s even generally a good idea or not

Share this thread

Read on Twitter

View original thread

Navigate thread

1/22