This is one in a series of deeper-dives into various Learnings from 5 years of tech startup code audits. In that article, I list several observations I had during the course of doing code audits fro 20-30 tech startups at or around the Series A / B mark.
We did several code audits for companies that rapidly scaled their engineering orgs relatively early on (we’re talking 50-100 engineers, maybe 10-35M annual revenue, series A/B). None of them are doing well right now, and some are out of business.
What made this observation interesting is how different it is from stories of the well-known counterexamples (Uber, FB, etc, etc, etc), where it seems like the ability to double headcount every 6 months is assumed to be a key component of their ability to scale rapidly with hypergrowth.
But I think we are taking the wrong lesson from these success stories. Here’s the real lesson:
You don’t grow engineering headcount like crazy in order to achieve hyprgrowth: these companies underwent hypergrowth first, and then are forced to grow headcount rapidly.
Typically the architectures we saw from these large engineering groups were not bad: they just were not really necessary. We often looked at the code and the infrastructure and kind of scratched our heads: why were they doing all this? It just didn’t seem to make sense. But then we talked to the very smart engineers they had, and it seemed like there were good explanations for most things. Looking back, I think a lot of the complexity was frankly busy work: you bring in a lot of engineers without enough truly business-essential work to do, and they will come up with things to do. This is not a crack on them, it’s just human nature.
