The current “way of doing things” in startup-land seems to revolve around hiring engineers in droves the second the company has secured funding. However, just because it has become a norm doesn’t mean it makes sense. Could you be actually doing better with smaller teams around?
First, I’ll state that this is chiefly directed at companies that haven’t reached product-market fit (PMF) yet. Before PMF, by definition, companies have less product clarity, and the vision tends to shift a lot. When you throw into such a situation lots of working hands just waiting to be “fed” tasks or features, it often leads product engineering organizations to chase too many possible directions. Flailing around, throwing features on the wall to see what sticks, doesn’t frequently result in companies with a solid product foundation that can then be leveraged to grow rapidly.
The Real-Business Shift
In recent months, more and more founders that I talk to have brought up a new concern: it seems that VC firms are slowly asking companies to act more like real businesses. This is probably a trickle-down effect from the lackluster performance of many unicorns that IPO’d or went public through SPACs last year. That results in CEOs telling me they are expected to show the basis for a genuine business—and not merely tell a story—as early as when they are trying to raise their A-round.
This shift means that companies have to make that much more out of their seed-stage development and therefore requires working with a great focus on business impact and viability. Watering down this focus with the need to constantly interview, onboard, manage, and lead more and more teams is almost impossible, especially if your team, like most teams I see nowadays, doesn’t have a lot of product-leadership talent in-house already.
Things Should Be Getting Easier
Contrast this de facto standard with what I’ve seen done successfully in the past: smaller teams, not even made solely of senior engineers, that work in lockstep with product and iterate extremely fast on a couple of possible directions to execute experiments and reach conclusions. I was part of tiny teams that achieved incredible results over 15 years ago when we didn’t have access to all of the great tooling that we have today. To me, this indicates that it should be even easier to do so nowadays, with the abundance of cloud infrastructure, open-source frameworks, and advancements such as low-code/no-code offerings. Each engineer should have an incredible impact if focused correctly.
Instead, we waste this opportunity by bringing on too many people too soon. That is why it might make sense to let an engineer spend months putting up a CI/CD chain that is Twitter-level for a company that’s not expected to have more than a dozen engineers and even fewer users in its first year. Deciding to strategically hire fewer people and put in place a solid culture and product understanding first means that you can set aside scaling interviewing, onboarding, and leadership training, avoiding the habit of spreading company leaders too thin too soon.
The Caveats
Now, I will reiterate that this is mainly directed at companies that haven’t reached PMF and, therefore, cannot genuinely benefit from scaling their teams just yet. I will also add another caveat: some companies have a specific technological path that’s clear from day one, and working on that in parallel to the product work might make sense. For example, I’ve worked with companies that always knew they would need to amass a certain amount of integrations to go past a tiny MVP or that a particular tech moat was part of their strategic effort. But, even here, I will stress that you should avoid going this route if there’s a chance that this scaling effort will be covering for the ability to work smarter.
For example, instead of having teams and teams of engineers creating integrations, perhaps it is possible to create a certain tech capital tool that will enable the creation of those much faster and obviate the need to have dedicated teams (if you’re not familiar with my concept of tech capital, you can grab the sample chapter of my book that covers precisely this here). Scale only happens when it is needed. I know it might be hard not to “play the game,” but avoid the need to keep up with the Joneses and don’t go for vanity metrics like headcount.