Stop Not Building Your Product
When your company first gets real funding, part of what you’re expected to do is building a real engineering team, scaling beyond yourself and your few initial employees. “Real” might mean 20, it might mean 200 - it depends on the level of funding we’re talking about. However, in general, we find that folks pursue this by following a pretty standard strategy:
Some backend developers.
Some frontend developers.
Some tech pms + product owners.
A few architects.
A QA department.
A devops/platform/SRE department.
(Sometimes) a data team.
There might be some differences around the edges, but this, in general, is what makes up the modern engineering stack.
A few weeks back, I spoke with one of our lead React developers, Stephen Kiers. Stephen has worked at companies of all sizes - all the way from bootstrapping his own or being an engineer in a company of ten total people up to some of the largest tech companies in the world. And one of the things he said that stuck with me was, roughly: if you’re doing something other than building your product, you’re probably doing it wrong.
On one level, this seems obvious. But I don’t think people really appreciate the implications here. One of the more interesting ones is that there’s a very real chance that, early on, you shouldn’t be hiring your own platform and QA departments. I don’t mean, of course, that you shouldn’t be thoughtful about platform questions and that you shouldn’t be doing QA! Instead, I mean that you shouldn’t be dedicating large portions of your budget to anything other than your core product.
We’ll take up the QA piece another time; in this post, we’ll talk about the platform piece. With astonishingly few exceptions, an organization’s infrastructure needs can be met affordably by standard packages from simple cloud hosts. A lot of applications can be hosted with only a couple clicks on something like Vercel or Heroku, maybe with a few Lamdas. And if you go up one level of complexity, there’s just about nothing you can’t run inside any of the major cloud hosts without a ton of difficulty. And if that infrastructure is built remotely well, you almost certainly do not need any FTEs to maintain it - you need coverage in case of an emergency or when you’re spinning up a new product.
Nothing I’ve said above is all that clever or subtle. So why does everyone have platform/devops in mind in their initial hire? I think this is for two reasons. The first is that it’s easy to forget just how far infrastructure providers have come in even the last ten years. There was a time not that long ago that platform scale was not just a problem but the problem for most companies. And it was a hard problem. But for those of us not lucky enough to run a Facebook or Google, these problems have gotten much, much easier. Our software does not have to respond to millions of users per minute, most of the time. Second, we naturally look to the leaders in our space when figuring out how to do things, whether that’s writing code or designing our technical organizations. And the leaders in our space are primarily very large companies who really do need full time platform staff. They’re supporting thousands of engineers and millions of DAUs. But most of us simply do not have the same needs.
We’ve seen countless companies - companies sometimes well beyond the startup stage with millions of users - apply this model successfully. And this allows them to reallocate their spend to the core parts of their business. This lets them follow Stephen’s Principle: build your product.
Want to talk more about how to build your first team? Book a call with me here.