The Art of Scale
On the core problem in scale up
Talking with a founder recently, I was reminded of something I’ve been meaning to write down.
As I’ve written before, it’s so fascinating to help out in a less hands-on role because it gives a very different perspective to what I’ve had before. When you’re heads-down working at one company, you only see what’s going on there. It’s much harder to see patterns.
And in this conversation, I was reminded of another pattern.
Lots has been written about the various tensions that companies face as they go from nothing to something bigger. In fact, I’d highly recommend Productive Tensions from Christopher Bingham and Rory McDonald, which treats what they see as the core tensions companies face from data versus instinct to efficiency versus flexibility.
But I think there’s really one core tension at the heart of a lot of early-stage decision making. Namely, figuring out how to scale enough but not too much. Very much in the spirit of thinking big but starting small. And I think this is really where the art is.
What does this mean?
If you have an idea for a new product or service — or indeed just a new part of an existing offering — you face a tricky tension. If you ramp up too early, you risk over investing. If you go too late, you may miss because you didn’t catch the wave.
On the one hand, you don’t want to scale too little. If the feature you have in mind isn’t polished enough, you may to get good data because people aren’t turned off by the core idea, they’re turned off by the subpar execution. If your idea is predicated on, say, delivering a pizza to people in under 20 minutes and you only achieve 20 minute delivery 80% of the time, I’d be dubious of the data you collect. It might have failed because you failed to meet expectations, not because people didn’t want pizza delivered quickly.
This can extend to the non-technical and non-product domains as well. If you don’t professionalize and systematize your hiring process enough, you may not be able to recruit the team you need to execute with the speed and quality required. If you don’t get serious about a finance function, you may miss because you run out of money too soon, not because your idea was per se bad.
Early Twitter comes to mind here as a concrete example. When the site unexpectedly took off in the late 2000s, they really hadn’t planned enough for the scale that they were suddenly faced with. Early users will surely remember the Fail Whale. And this at a time when large-scale data companies were relatively rare, so the tooling and technology to make that possible wasn’t as readily available. Twitter might have gotten even bigger even sooner had they planned ahead a bit more for scale.
On the other hand, you don’t want to scale too much either. If you demand the world’s most sophisticated DevOps posture when you only have two engineers, you could easily spend months building and shipping nothing, because your tiny team does nothing but configure the world’s most amazing Kubernetes deployment. If you build out an incredibly polished version of a feature that flops with customers and end users, that could be some expensive code to throw away.
If you insist on setting up the world’s most polished recruiting operation — a beautiful Greenhouse deployment, a team of top-grade recruiters to hold candidates’ hands, sources to spare engineers the indignity of pitching in — you could siphon resources away from building the core product.
I can’t help thinking of the ill-fated Quibi here. It certainly wasn’t inconceivable to me that a mobile-focused streaming service could have some appeal. Everyone loves their smartphones. But there’s no reason you have to start by burning $1 billion testing out the idea. Which, of course, did not take off and lost people a lot of money.
And figuring out how much to scale and when isn’t a science. It’s an art.
Certainly, there are patterns and benchmarks. You’d be an outlier if your early-stage team had 10 engineers, 10 recruiters, and 1 salesperson. It would be unusual to scale to 200 employees and not hire a single person in HR.
When I have conversations with founders, though, these aren’t the discussions I’m having. People who start companies are usually pretty smart, and I think it would be obvious to a non-expert that you need more people selling your product than hiring people to sell it.
Usually the tension is at the margin where the choice is nontrivial, and where I’m not sure there is an easy answer.
Dilemmas like asking whether or not it makes sense to try and raise equity financing. There are certain circumstance where that’s an easy choice, of course. If you’re bootstrapping and have off-the-carts revenue, it probably doesn’t make any sense. If you’re trying to build a commercially viable fusion energy reactor, you’re going to need lots of financial capital to get going.
But what if you have $100,000 in annual revenue and lots of interest, and want to hire three engineers — who will cost more than that — immediately?
Even with all the context in the world, I don’t think you’re ever going to get an open-and-shut answer. Until people have gotten an invoice and paid it, there’s always a risk that the demand you see won’t materialize. If you take equity financing and that happens, the fall is a lot more painful than doing that on a self-sustaining path. But if it does materialize, the bigger risk translates into a much bigger reward.
Which is where the art is.
A friend who studies startups academically explored this in her PhD dissertation, for example. She examined the impact a team’s prior startup experience has on a company’s odds of success. That is, companies that had raised a series A and made it to series B.
Like so much else, there’s a sort of Goldilocks zone. Hire too many startup people, and there’s no one who knows what it looks like to scale up. Hire too few, though, and there’s no one to point out you’re overdoing it when the person who’s only ever worked at McKinsey wants to make the world’s most perfect slides for every presentation.
And even more tellingly, this team experience impact completely disappears when the company’s founders have successfully built a company before.
If it were simply a question of getting good advice or reading the right books, I doubt this effect would be there. Because no one is ever going to have the context that you have in the weeds, whether as a company founder or an early employee working on a narrower problem. You have to build those instincts, and the only way to learn is to have done it.
From my own experience, one startup I’ve helped out a bit is building developer tools. That is, the people who use the product understand how the sausage is made. When that’s your customer base, you can get away with a lot less polish. The people using the software understand when maybe 2% of page loads fail, and can self-remediate. Very basic DevOps and container orchestration is enough. At Proton, where our audience was salespeople and the product was critical to their work, it made sense to scale up DevOps a lot sooner. The product needed to be a lot more reliable. There is no one-size-fits-all answer.
Getting scale right is hard. And I think it lies at the heart of what makes getting an idea off the ground so difficult. Go too fast, and you risk making mistakes that are unnecessarily painful to live through. Don’t go fast enough and you may miss out on what could’ve been an incredible step forward. Threading that needle is an art, though, much as we want to be able to work to a rulebook. Understanding this I think helps put problems in perspective — if it seems hard, that’s because it is. And helps prioritize. Getting to the right place on this “scale spectrum” — figuring out how much or how little to do in a given area — is a lot more important than the work itself.
Bonus: Why the Bad Reviews?
A really fascinating deep dive from an independent product reviews site about the madness that is search engine optimization. It’s always felt like a lose-lose battle, and this is more evidence to support that belief.
Enjoy this? Have an idea for something you’d like a perspective on? Drop me a line: I’d love to hear from you.