Earning the privilege to work on unoriginal problems

The startup world is almost by definition a place where you “live in the future”. Working in an early-stage startup, your whole belief system is based on being able to successfully create something new. Something that will become a great and cherished product, used all around the world. It needs to be this way, or else you won’t be able to cope with the stress and insecurity of working in a startup.

What’s particularly dangerous though, is that from this coping mechanism of blind belief springs a deceptive rationality of investing in systems and tools that will support this grand future. This is why so many startup dev teams are hellbent on frontloading an investment in building the perfect dev-tooling, and ensuring the infrastructure setup is highly flexible and scalable. After all, since your product is going to take over the world, you must get ready for scale. Right? Wrong.

You need to earn the privilege of working on unoriginal problems

Let’s face it, in this day and age, scaling software is not an original problem. It’s been done, thousands of times over. What hasn’t been done yet is figuring out what shape and form your specific product needs to have, in order to resonate with its potential users. Unless you have users paying for your product and telling others about it, you haven’t got Product/Market Fit (PMF). And if you're pre-PMF, you haven’t got any business spending time on things other than what will get you there.

For engineers, this means taking shortcuts, making do with ready-made solutions, and focusing on speed of iteration over quality of iteration. You don’t get to spend time perfecting CI/CD pipelines or setting up the latest and greatest infrastructure-as-code versioning tool. You haven’t earned that privilege yet.

So why do so many teams fail to focus on the real problem and waste time on the unoriginal problems instead? Let’s look at the common traps.

Trap 1: The illusion of progress

Why do intelligent people, including experienced CTOs, fall into this trap? Because building tooling feels like progress. It's tangible. It's technical. And it comes with the rewarding sensation of “shipping”. However, what you're actually shipping has not necessarily got anything to do with delivering an original new product that your still-undetermined market wants or needs. In the best case, it’s a short-term distraction that may pay off in the long term. In the likely case, it’s time wasted that will need to be rebuilt before you ever get to the level of scale where you needed it in the first place.

Trap 2: If we build it, they will come

This old chestnut. Need I say more? Really? Ok, well the gist of it is that builders will generally do what they do best; simply build and build endlessly, finally releasing what they believe is the perfect product that everyone will want to start using. Only, most often nobody ever does. Creating new products is an iterative game, where customer interaction should happen early and often in order to validate that what you intend to build is desirable in the first place.

Trap 3: Best practices

It’s rational to look at what successful companies do and take inspiration from them. They sure make a point of talking about it a lot. The problem is that you’re not Google or Facebook. Realistically, any impressive company you’ve heard of is by definition already playing in a different league, meaning they have different priorities and practices.

A Future CTO's Nightmare: Selling Phantoms

So what happens if you fall into these traps and end up making a big investment in platform tooling up front? It’s not the end of the world, you’re still going to make it right? Maybe. A lot of companies will still find PMF and begin to scale. Good for them, it’s not easy getting there!

But the problems don’t stop there. Making an upfront investment in platform tooling, when it wasn’t needed, can come with long-term consequences.

Imagine a future scenario where your product is finally scaling and user numbers are through the roof. It’s very exciting! You’re able to hire a bunch more developers, and now suddenly you genuinely need more sophisticated platform capabilities. Turns out, the tooling you built a year ago when you were a 5 person team doesn’t cut it now when you are 15 developers and have pivoted the product more than once since. 

Now you, as the CTO, need to approach leadership to get buy-in to shift focus from delivering on the feature requests that are pouring in from new users, in order to spend weeks or months on rebuilding your platform. Only this time, you're not just selling the new platform, you're also fighting the ghosts of past choices. The memory of a 'wasted' platform investment that provided little value makes your job exponentially harder, turning every proposal into a hard sell.

Token Economics: A Startup CTO’s Currency

By now you will be familiar with the term “innovation tokens”. It’s often mistaken to mean something like: “You can only use 3 shiny new technologies in your startup, the rest needs to be boring or you’ll end up with a big ball of mud”.

What I think it actually boils down to though is that you need to recognize that your team has a limited capacity for doing creative, innovative, and difficult work. So in a pre-PMF startup, why would you ever want them to spend that limited capacity on anything other than iterating on the actual product?

So for all the CTOs out there, let's introduce a new term — your startup's “platform tokens”. These are the finite resources you have, in terms of creative capacity, time, and internal credibility, to invest in platform tooling. Spend them too soon, and you risk bankruptcy of more than just finances; you risk bankruptcy of trust within your organization.

The point isn't to never invest in building tooling. Rather, it's about choosing the right moment when those tokens can be invested in something that will provide real value for the organization. When you're still in search of PMF, your tokens are better spent on customer discovery, prototyping, and other ways in which you can find market validation.

An alternative path: The virtue of being lazy

So what should you do? As little as possible! Ask your team to be lazy. Find ready-made tools that give you the most of what you think you will need, for the least amount of effort. 

In a pre-PMF startup, you should expect that you’re going to be wrong – a lot! That’s to be expected when you’re building something new and when solving original problems. This is the time when it really pays to be lazy when it comes to platform work.

These days there are many great tools out there, so I won’t even try to make any sort of comprehensive guide in this post. However if you made it all the way through this article, and you are working on something that is likely to make heavy use of cloud services, I’d be happy to talk to you about what we’re building at Encore.