|
The most damaging part of this risk averseness is that it's pervasive throughout the engineering side of a large company, not just the business side. I've seen a few big companies attempt to avoid the pitfalls you're describing. They set up some moonshot division consisting of "startups" and they do allow them to fail, but that's not enough. The problems are that they don't face the same financial pressures as startups, and they draw from the same talent pool as the general engineering pool of the company. This is a problem because I don't think the article's premise goes far enough, big companies don't just drive out innovators, they convert them. They create a context where adding more bloat is seen as innovation, and then suck up enormous amounts of talent into this environment. These "startups" I've seen look on paper like they have every chance to succeed. Financial institutions starting companies in the finance space for example, they have all the domain knowledge, it's right in their wheelhouse etc etc. But they don't seem to realise that they don't have the right kind of engineering talent. It's not that their devs are bad, they're just playing a completely different game. I think this is partly to blame for the whole "ageism" thing in SV as well. Somewhere along the track a big group of people realised (probably subconsciously) that there's a whole bunch of very talented senior engineers out there that are complete garbage at building something from scratch in an environment where you live and die by the quality of your software, because the majority of people work in places where their success and failure is just indistinguishable noise in quarterly profits. And for interviewers that aren't particularly good at surfacing that or don't even know what they're looking for, ageism is the easiest (and shittiest) way to filter most of that out and improve your odds All these "startup within a big company" projects seem to follow the same rules as a modern trendy enterprise project. Big fuck off kubernetes clusters on the back end, a monorepo clusterfuck for the front end with more packages than pages in the app. Everything "scales", everything is perfectly set up to handle every possible use case, there's 8 kinds of tests, and a huge CI/CD setup, and all the tooling you could ever need. And then once that's all set up, in true waterfall fashion, the dev finally starts... at the same pace all the company's other projects run at. And because all the other company's projects run at that pace, nobody notices anything is wrong. But if you do this, and you have any even remotely competent competition, you're going to get absolutely fucking poleaxed in features. Slow and steady might win the race but nobody has ever won the race after being shot in the foot with the starting pistol. |