Hello again friends,
tl;dr: By definition, startups need to work in uncertain environments. The startup–uncertainty connection runs deeper even: Startups need uncertainty as a source of the new opportunities they are trying to find and exploit. But, at the foundational level of everyday work processes — a company’s machine-level code — conventional management “best practices” developed from research on traditional companies create drag and impede startups from flourishing in uncertainty. To build low-drag startups, leaders need to understand uncertainty clearly and use that clarity to rewire and upgrade their companies.
Last month in Singapore, the VC I was having coffee with asked if startups could use uncertainty to create competitive or operational advantage.
Uncertainty is a startup feature — not a bug
All startups definitionally operate in territory that is uncharted in some way. Some startups are developing new products, others are introducing established products to new markets, or building entirely new business models. Without some uncertainty about what will work, there is no reason for a startup to exist. And without uncertainty, the success a startup achieves is not defensible. The essence of the startup is uncertainty as a generative force for opportunity — startup work is uncertainty work.
Traditional best practices aren’t right for startups
Traditional management thinking largely comes out of research on companies that are not startups. These companies are established, with well-understood markets, products, and business models. Let’s call these “optimising companies.” Unlike startups, optimising companies don’t succeed by navigating and using uncertainty strategically. Instead, optimising companies succeed by hunting out and killing uncertainty so they can be more efficient at exploiting their competitive space. Optimising companies treat uncertainty as a bug, not a feature.
Startups are not, and should not be, optimising companies. Management best practices taken from optimising companies aren’t right for startups.
The machine-level code of startups
Startup investors, founders, and workers seem to overlook how “best practices” taken from the world of optimising companies often get imported into the processes that make up the daily operations of a startup.
This is the startup’s machine-level code: Trivial-seeming stuff like the actual details of the process used for hiring new employees, or for setting goals for/motivating individuals and teams.
“Best practices” from optimising companies get implemented in startups because they are ubiquitous. They are rarely critically examined for appropriateness. This is a category error, and it hampers the startup’s ability to play with and take advantage of uncertainty.
The wrong machine-level code causes drag
Hiring is a good example of how an uncritically chosen “best practice” borrowed from optimising companies messes with a startup’s ability to work well in uncertainty.
HR best practice for hiring is usually based on selection. First, the hiring manager builds a job scope which describes the roles, tasks, and competencies of the successful hire. Then, recruiters go out to find as many candidates as possible who are good fits for that job scope. Current employees at the startup use interviews, tests, and maybe case-studies to select and hire the candidate who best fits the scope. Nearly all companies use a hiring process like this. The problem: This hiring process is inappropriate for startups.
Why? Because this process sets the candidate’s expectations about what the job will be and, crucially, that the scope of the job will not change much. Selecting for best fit with a stable job scope is highly desirable for an optimising company where the nature of the job is well-understood and pretty stable over time.
Selection-based hiring is terrible for a startup which wants to be able to pivot to respond to changing technology and new competition. When startups pivot, they need employees who expect their jobs to change and who are actively scanning the environment for change. The selection-based “best practice” for hiring fails to do this. Worse, it creates employee expectations that run counter to this.
Machine-level mismatch generates friction that slows the startup down — it creates unnecessary drag.
Selection-based hiring is just one example of how a “best practice” imported from optimising companies creates unnecessary drag for startups. Other key areas are how startups choose and talk about the goals they pursue, and how they motivate their employees and teams.
Reducing drag
Having the wrong machine-level code hampers a startup’s ability to work well in uncertainty. So redesigning machine-level code to be well-adapted to uncertainty work is vital. But how?
Counterintuitively, the way to reduce drag is by getting to clarity about uncertainty. The root of the problem is confusion about the difference between risk and true uncertainty.
Risk and uncertainty are not the same
Risk is when we don’t know exactly what will happen, but we know the range of possibilities with both precision and accuracy.
The archetypical example of true risk is betting on flipping a fair coin — there is only one possible action (flipping the coin) and two possible outcomes (heads or tails) with clear causation (an equal probability of either outcome). When we believe the world is risky, we believe it is unknown in a knowable, ultimately controllable way. The knowable unknowns of risk are the domain of optimising companies. Their best practices are designed around managing risk (eliminating it, hedging against it, etc) because they are predicated on the knowability of what’s unknown.
There are all kinds of unknowns that aren’t risky. These unknowns aren’t well-understood — they can’t be quantified precisely or at all. What’s the exact probability that AI systems continue to be built using large language models (LLMs, 2023’s dominant approach)? Or the probability that mixed-reality headsets will become the default mode of interacting with the internet? These and many others are the true uncertainties — not risks — that provide opportunities for startups to emerge and flourish.
Risk mindset is all-pervasive
Unfortunately, we often mischaracterise all unknowns as risky, even when they aren’t the well-understood unknowns of true risk.
Back to the example of hiring best practice. Though no one talks about it, selection-based hiring implicitly embodies a belief in knowability, the unquestioned assumption that the company can know in advance what it will need a new employee to do. And, by extension, the assumption that the company can know in advance what it must do to succeed. Without making this assumption, it would be nonsensical to spend the time and effort of working to a job scope to recruit candidates and select the eventual hire from them.
This assumption is a manifestation of what I call risk mindset. As I wrote here, “a risk mindset assumes that all unknowns are risky. [It] makes risk-like aspects of a situation more noticeable … [and] favors interpreting partial knowledge situations as simply risky situations.”
Even innovators often fall into the risk mindset by default, simply by not explicitly distinguishing between risk and true uncertainty. This makes it easy to forget that the reason startups exist is to do uncertainty work. And this oversight leads to unintentionally building drag-inducing practices into startups.
Change begins with an uncertainty mindset
Explicitly recognising the difference between risk and uncertainty is the foundation of an uncertainty mindset.
An uncertainty mindset makes three things possible:
Better startup strategy. It gives leaders language for identifying and selectively promoting uncertainty that creates innovation opportunities (and for identifying and managing true risks that reduce operational efficiency).
Better startup operations. It gives leaders a framework for mindfully evaluating and choosing operational practices based on whether the unknown to be addressed is knowable (i.e., risky) or unknowable (i.e., truly uncertain), instead of uncritically adopting inappropriate “best practices” across the board.
Better startup capacity building. It gives leaders a way to identify and selectively build capacity appropriate for doing great uncertainty work. For instance, by systematically exposing individuals to situations designed to reduce their fear of failure, or training teams to design faster, cheaper, and more informative experiments.
These three changes reduce drag by rewriting the machine-level code of the startup and upgrading its people at the same time.
Building the low-drag startup
True uncertainty is not the same thing as risk. For startups, uncertainty isn’t a flaw to be eliminated. On the contrary, they need to recognise and embrace uncertainty to survive and succeed. Startups that confuse risk with uncertainty end up adopting optimising “best practices” that create unnecessary drag for themselves. To avoid this, startup leaders need to have an uncertainty mindset that explicitly differentiates between risk and uncertainty. For startup leaders, an uncertainty mindset reduces drag by enabling more startup-appropriate strategy, operations, and capacity building.
I’ve written much more how the uncertainty mindset changes concrete processes businesses use for hiring, setting goals, and motivation; that’s in a book titled The Uncertainty Mindset that came out in 2020. My current research on not-knowing explores different types of uncertainty to develop type-appropriate strategy. If you find that stuff interesting, you should join me and a pretty diverse group for a concluding conversation about not-knowing and strategy on Thursday, 15 February 2024.
See you next time,
VT