Across the country, in every accelerator, exec team meeting, advisor session, and board meeting, startups are asked the same question:
“But how will it scale?”
My answer: “Who cares?”
Whether you founded your company yesterday or you’ve been growing for years, the problem remains the same: the moment that you create a solution, whether it’s a piece of software or a business process, you start to feel pressure to optimize it. The questions come hard and fast:
“But what happens when we grow 10X? We’d have to hire 20 people to do that work!”
“What if we land five more clients like this one? The system will be too slow for them.”
“If we’re still doing this in five years the company will be out of business.”
“What if Elon Musk tweets about us? The site will crash in an instant!”
This urge to prematurely scale is almost entirely fear-based, a fear that’s ironically fed by a startup’s intense desire to succeed. When we pitch our companies to investors and customers we dream big, touting exponential growth rates and massive returns on investment. We dream of disrupting industries, not niches, so naturally we start to worry on the same scale. We crave success while fearing its side effects:
The Hug of Death: “I don’t want to be the guy whose site collapsed when it went viral.”
The Architect’s Nightmare: “I don’t want to get in trouble because we have to rebuild this in a year.”
The Accountant’s Dilemma: “If I don’t get this system upgrade now, I’ll never get the chance again.”
This urge to prematurely scale is almost entirely fear-based… We crave success while fearing its side effects.
Our natural response to fear is to seek control, so we try to anticipate everything that might happen and build for it now. The architect focuses on hyper-efficient code, modularity, and infinite horizontal scalability while the operations lead pushes for standardization, automation, and a host of new SaaS tools that their team won’t need for another year. In our quest to reduce risk, we add the two things our growing company doesn’t need: weight and inertia.
The Hardest Problem Fallacy
Besides fear, the other significant driver of premature scaling is what I call The Hardest Problem Fallacy. This is the idea that by solving the most complex version of a problem you’ve automatically solved all of the simpler versions. Engineers fall prey to this fallacy all the time because it has a certain intellectual appeal. Logically, doesn’t it seem like the most complex version of a problem should contain all of the simpler variants? If my elegant solution can handle 10,000 calculations per second then it should make short work of 10, 100, or 1,000, so I only need one solution for everything. The same goes for the business lead who only wants to train their team once. If we come up with Standard Operating Procedures that cover every eventuality, then we can just skip unnecessary steps in specific instances. Problem solved, let’s move on!
The Hardest Problem Fallacy: the idea that by solving the most complex version of a problem you’ve automatically solved all of the simpler versions
For the mind that values efficiency, the Hardest Problem is terribly alluring. In fact, it’s a huge waste of energy. By trying to anticipate and solve for all eventualities, you waste time, money, and effort at all phases of creating a solution:
Analysis: you spend time thinking about all of the things that might happen, but lack the data to know the likelihood that they actually will happen, so all needs carry equal weight. In reality, a few needs will cover the majority of the actual activity in your business, with the remainder making up low-probability edge cases.
Design: due to the size of the problem space, any solution you create must be complex and robust, even when a far simpler solution might work in the near term. In the absence of real data, you’re forced to guess at the best way to tackle imaginary problems and automate processes.
Implementation: building a complex solution, whether software or a business process, takes much longer than building a simple one. In the meantime, you lose valuable opportunities to gather feedback and real-life data, even as your commitment to the solution hardens.
Execution: once your solution is built, you’re stuck with it, both because it took so long to build (another fallacy: Sunk Cost) and because complex systems are hard to change. As you learn which of your guesses were correct and which weren’t, you find out which investments were valuable and which were simply bad bets.
If you’re reading this and thinking, “Gee, that sounds an awful lot like a waterfall process. We’re Agile, so this could never happen to us,” don’t worry. You can make big mistakes in a series of small hops just as easily as in one large leap. This is a problem of mindset, not process.
While this holds true regardless of company size, the cost of the Hardest Problem Fallacy is especially painful for startups. While a large company can afford some inefficiency or wasted investments, every moment is precious to a startup. The time and money that you spend overbuilding could be invested in growing your customer base and refining your products, and a few missed opportunities are frequently the difference between success and bankruptcy.
Premature Optimization
There’s a saying in software development: “premature optimization is the root of all evil.” The software architect who’s obsessed with serving millions of users when they only have a few hundred will spend days chasing all of the inefficiencies out of a system that may never see that stress. The CFO who insists on “doing more with less” when the company doesn’t even know what it’s doing yet soon finds every department falling behind while the company stagnates. The young company that constantly asks, “but will it scale?” rarely gets the chance to find out.
The young company that constantly asks, “but will it scale?” rarely gets the chance to find out.
Building for tomorrow’s problems sacrifices today’s success. Instead of worrying how you’ll serve millions of users next year, you could be learning what features will delight the hundreds or thousands of customers you have today. Instead of squeezing 10% more efficiency out of business processes that will soon change anyway, you could be building personal relationships with clients and learning what they really need from you. By building for the bigger company that you hope to have someday, you sacrifice flexibility, responsiveness, and growth in the company that you have today.
Learning: The Antidote to Fear and Guessing
So what’s the alternative? Rather than committing to scaling, commit to learning. A learning organization doesn’t worry about scale because it knows that it will get there when it needs to. It replaces fear of the unknown with a commitment to gaining knowledge through experimentation. It avoids the Hardest Problem Fallacy by building for known needs and planning to rebuild when new information becomes available. Above all, it recognizes that agility and adaptability defeat complexity every time.
A learning organization doesn’t worry about scale because it knows that it will get there when it needs to… it recognizes that agility and adaptability defeat complexity every time.
Rather than seeking the false efficiencies of premature optimization and “one solution to rule them all,” a learning organization sees the value of inefficiency, leveraging the power and adaptability of the human brain to find the best solution before encoding it in a system.
The Power of Inefficiency
Every time we try something new we’re naturally inefficient, and everything a startup does is new. The pain of trying something new, though, is good: it stimulates change. Like an oyster building a pearl around a grain of sand, people will unconsciously optimize processes for a long time in response to discomfort. If you encourage teams to be uncomfortable and adapt to the discomfort, you’re on your way to creating a learning organization.
If you learn through these adjustments, that optimization eventually becomes your “official” process, which eventually becomes your automated process, which people will immediately work around when it stops meeting their needs. Encourage this rather than fearing it, because people can adjust almost instantaneously, which is much faster than code or documented SOPs can change, so a learning organization is constantly improving.
Standardization and locked-down processes — “This is how we do it here” — are the enemies of learning and optimization, so hold them at bay forever if possible. Make learning and experimentation your standard process instead.
Planning to Change
No business can accurately predict what the market will expect of it a year from now. A young, growing company can’t even predict whether it will be the same business a year from now, so while scaling requires commitment and certainty, startup planning is an exercise in creative doubt and a willingness to be wrong.
While scaling requires commitment and certainty, startup planning is an exercise in creative doubt and a willingness to be wrong.
How does a learning organization plan?
Instead of valuing certainty and commitment, it accepts the limitations of what it knows and creates a series of experiments to uncover what it doesn’t know
It understands that uncertainty shortens its time horizons, so instead of blindly committing to long-term decisions it plans based on the information it has today and commits to adjust as it learns, accepting the inevitable rework as an investment in better solutions
Rather than asking “how will this scale?” it asks “how long will this work before we have to change it?” and “Is that good enough for now?”
Rather than “running lean” and optimizing efficiency when it doesn’t know if it’s solving the right problems, it sees the value of manual processes and makes room to learn by investing in people early
Above all, a learning organization curbs the fear of being wrong by both accepting it as part of the process and committing to continuous improvement, so its people always have another chance to be right.
The Rhythm of Innovation
I’ve been down this innovation road many times, so if you’re making your first journey here’s your map. Every significant change to a process, product, or industry goes through these steps:
Total chaos: figuring out how your new idea works (or if it even does) while your environment fights to reject the change
Figuring it out: finding the things that work and making them repeatable while pruning the things that don’t
Optimization: Optimizing both the repeatable processes/systems and their exceptions, training new people to do it and watching them optimize further
Automation: Automating the optimized processes
Disruption: Coming up with a new idea and returning to step 1
Every company that tries to skip to step 3 or 4 is always thrown backwards after a lot of frustration and wasted effort. When you automate bad processes, all you do is make bad things happen faster. On the other hand, organizations that let things be messy for a little while are always amazed by how quickly the natural human instinct for efficiency pushes them along this curve.
When you automate bad processes, all you do is make bad things happen faster.
Rather than optimizing think about how you get better at innovating.
We’ve all heard the saying, “Nobody on their deathbed has ever said ‘I wish I had spent more time at the office.’” My question is: while shutting down their companies, how many founders have said, “I wish I’d spend less time worrying about scaling?”