We’ve all heard the advice to “do things that don’t scale” at the early stages of startups. I quite agree with it. Unfortunately, as with many pithy sayings, it can be overused or abused. When we fail to understand the logic that drives it and where the same approach doesn’t apply, we are bound to make a few wrong turns.
One typical pattern I’ve been warning my B2B SaaS clients about often recently is when you decide to do things that don’t scale while committing your company to keep doing it the same way indefinitely. That’s when you needlessly set yourself up to play on hard mode.
I’ve seen my fair share of startups that used smoke, mirrors, and mechanical Turks to get off the ground. There’s nothing wrong about this in general, as long as you gain momentum. We should be fine with doing things that don’t scale so long as each manual effort moves us forward towards a future where you’ll be able to replace it with easier, cheaper, and faster mechanisms.
Contrast that with what some companies do without noticing: they feel like they are making progress by getting more leads, signing new deals, and acquiring more clients. However, if each one of those clients is going to act as a perpetual weight that’s bogging your team down, you’re not turning the flywheel—you’re making it heavier.
To make the difference concrete, let’s consider a couple of examples. The favorable scenario would be when a company signs up a new client that will require manual verification and analysts for the first months, which more intelligent algorithms and machine-learning solutions will gradually replace. With time, each client will require less effort, and we can even migrate early adopters along the way.
On the other hand, we have the SaaS that keeps agreeing to convoluted version release procedures that including several testing phases, client vetoes, customizations, and lavish grace periods. You might overlook the cost of this when you have one client or two, but this has an exponentially increasing cost. I’ve seen R&D teams that have ground to a halt having to support half a dozen different live versions with a support contract that resembles what I saw working at IBM but with a fraction of the maturity and headcount.
The latter scenario has a crucial difference: these are contractual commitments, not limitations of your current solution. You agree to support them indefinitely. You take on some on-prem enterprise clients. That one client that forces you to use a different cloud provider. The contract that names specific engineers which means that moving people between teams becomes a royal PITA.
These are all real examples I’ve seen, and with each new client that has these sorts of constraints, you’re essentially mounting another weight on your team’s shoulders. What’s worse is when these measures aren’t used extremely sparingly. If you stop after a couple of clients, you can make it. But operating in this mode of signing up clients for a year can be almost impossible to salvage.
Turning the Ship Around
You don’t have to work in hard mode. As a tech executive in charge of R&D, you have more of an influence here than you might intuitively assume. First, start by ensuring that you’ve positioned yourself upstream in the company. That’s how you will be able to spot these issues ahead of time and ensure that you will be heard in the right meetings. I’ve covered moving upstream a bit here and thoroughly in chapter 4 of The Tech Executive Operating System.
Second, do not play down contracts. Many startup CEOs tend to be very optimistic and don’t consider the contractual obligations as set in stone. However, these things eventually need to be translated into lines of code and procedures, which cannot be vague. Therefore, you have to treat all commitments with the seriousness that they deserve and weigh the consequences.
Another important aspect is not to underestimate the power you and your team have. You might be inclined to say, “that’s the way it is,” or, “we’ll never sign clients if we don’t agree to this.” The truth is that you have more sway in situations than you might initially think. Had your prospects wanted to work with a behemoth, they could’ve gone with one. Sometimes it’s not even the clients that are asking for it—your salespeople are doing things as they are used to, without understanding the different possibilities or costs associated with how they’re promoting your solutions. Ask, and you shall be given.
Get a sample chapter
Get the best newsletter for tech executives online, along with a free sample chapter of The Tech Executive Operating System 📖. Tailored for your daily work. Weekly, short, and packed with exclusive insights.