Do you think that this work that had to be done was business critical? My experience while working at FAANGs is that everyone was working a lot but a sizable number of projects were vanity/promotion/keep-em-distracted projects. People imagine overstaffed companies as full of idle engineers but I've seen instances of very busy overstaffed companies working on the wrong projects (migrating to Go because, using Protobuffs for a simple eCommerce API that does not need it, creating a component library for a small internal tool that will not grow much, building your own chat system, etc).
Good point. The end result is the same: inefficient allocation of resources that could pass for productivity. Weird incentives at the management level.
Firing productive engineers isn't going to fix managers whose vision is not aligned with business needs.
In my corporate life, I saw total of two exceptions to that rule ( now and my previous boss ).
My guess is "undercompeted", though I'd hope there is a better word.
If an organization has a large and secure revenue stream whether is works on improving output or not, it will focus inward, on making life better for the insiders, not the customers.
It's not always obviously true that there is such a project. Neither companies nor teams are fungible enough to make this necessarily true, at least not to the extent that ROI is expected to be higher than a smaller more focused team.
I do think the platform org’s choices can cause a lot of low quality churn for the rest of engineering, and everybody resents having to switch out a perfectly fine dependency for somebody’s half baked promo project, but even the platform group when it does these things is trying to save itself the headcount involved in maintaining legacy. As things get leaner, support for older stuff gets worse, and we have to do even more migration work of dubious value to tread water.
If I were starting a Big Tech tomorrow I would put a lot of value on choosing a stable, long term supported tech stack and laying it out so that platform teams can iterate without distributed migration efforts. But no one ever starts a Big Tech. All that is awkward in Big Tech is due to path dependence flowing from the understandably odd choices made by tiny startups.
At the benign end of the scale, you might need to use a more heavyweight tool than you'd like, because the company also has more intense problems and prefers to standardize on one tool. At the other end there's cruelty and farce. Elaborate workarounds for things that ought to be easy. Mind-bending debug sessions for what never should have been possible.
No one wants this to happen! The career incentive is to ship. We're tearing our hair out over it - honestly a big reason people have side projects is the catharsis of just doing everything the sane way. Overcomplication is a dysfunction that plagues engineering organizations. But the solutions are more subtle than "just say no" - it's about the quality of the company's platforms, degrees of NIH syndrome in the platform group, tradeoffs made between freedom and consistency in system design culture, wisdom and foresight in anticipating how different things will interact, etc.
Also underrated: at the time the company needed an X, Y was not around yet, so we adopted X. Yes everyone now agrees Y is better. We are migrating to it, but that takes time. No you can't have your own instance ahead of schedule. so you need to make do with X, even though it is worse and more complicated.
I would imagine improving throughput a fractional percentage point could have multiple millions of dollars in return for any company close to FAANG size. I fail to see how these are good examples of 'wasted' engineering effort.
Building your own chat system is a good one though, definitely seems like a vanity project.
I think a lot of companies suffer from premature optimization. I myself even fell victim to it in one of the projects I worked on for that company by rewriting a large portion of the code instead of hacking the new feature in.
It is a hard problem to solve for. How much tech debt do I take on now to deliver customer value. I guess that is something that just comes with experience though. I have noticed that has I gain more experience I am not enamored by the new shiny framework as much anymore and focus more of my effort on delivering whatever feature is needed with the smallest change possible. Yeah this creates tech debt, but at least it keeps the lights on especially when every service seems to get rebuilt in 5-10 years anyways.
It's entirely an economic problem, not a "too many" or "not enough" people problem.
Sorry you got laid off. If anything, I felt like the Stripe layoffs we're a bit of a special case, because I've seen Stripe churn out tons of useful new features and functionality over the past couple years, in contrast to some of the other tech layoffs where the companies seem like they've been treading water for years.