Operating through uncertainty

There is a version of building that only works when conditions cooperate. When the market is legible, when the timeline holds, when the right people show up on schedule. A lot of organisations are designed for that version. They have tidy processes, quarterly plans with confidence intervals, and a general assumption that the future will roughly resemble the recent past.

That assumption works, until it doesn't.

January 2020. Nothing catastrophic has happened yet. But there is a quality to this moment, a low-level ambient hum of things being unsettled, that makes the question of how to operate in uncertainty feel less theoretical than usual. Trade tensions. Technology moving faster than institutions can absorb. Attention splintering. Consumer behaviour shifting underneath incumbents who can't quite explain why.

These aren't crises. They are the texture of the present. And the question that feels worth sitting with is: what does a system look like when it's built for this texture, rather than for the stable conditions that used to be the baseline assumption?

Two kinds of system

The distinction that keeps coming up is between systems designed for predictable conditions and systems designed for genuinely uncertain ones.

A system designed for predictability prioritises efficiency. It eliminates slack, sequences everything tightly, and optimises each component for its expected environment. When conditions remain stable, it performs well. When conditions shift, it struggles, because the very tightness that made it efficient leaves it with no room to absorb the unexpected.

A system designed for uncertainty prioritises something different: the ability to keep functioning, adapt, and continue making progress even when the inputs are wrong or the environment changes mid-execution. This isn't the same as being slow or unambitious. It's a different shape of rigour.

The distinction matters because most advice about how to build organisations assumes stable conditions. The canonical management literature is largely about optimisation: how to remove waste, clarify accountability, sequence work efficiently. These are real skills. But they apply best to a world where you know what you're optimising for, and where the parameters stay roughly constant.

When conditions are genuinely uncertain, when you don't know which product will find traction, which market will open, which technology will mature in time to be useful, the optimisation frame can actively mislead. You optimise the wrong thing. You eliminate the slack that would have let you pivot. You build the process before you've learned what the process should be for.

What resilience actually looks like

The word resilience is used often enough that it's started to mean very little. So it's worth being specific about what a resilient operating system actually requires.

The first requirement is clarity about principles rather than rigid specification of process. A principle is something that remains valid across different conditions: move toward where the evidence points, don't scale costs ahead of revenue, prefer reversible decisions under uncertainty. A rigid process is something that was designed for specific conditions and breaks when those conditions change.

The difference sounds small but compounds over time. Organisations that run on principles can make judgements in novel situations: they have the underlying logic, not just the rule book. Organisations that run on rigid process need to write new rules every time conditions shift, which is always slightly too slow.

The second requirement is that slack is treated as a feature rather than a failure. Slack, in time, in attention, in financial headroom, is the mechanism by which adaptation happens. When a system is running at full capacity, there is nowhere to put new information. The ability to absorb an unexpected finding, redirect effort, or take a position that wasn't in the original plan depends on having somewhere for that to go. A system without slack can execute the existing plan. It cannot update the plan.

The third requirement is that feedback loops are short enough to be useful. If it takes six months to know whether a decision was correct, you have made many subsequent decisions on the basis of a hypothesis you haven't yet tested. Short loops, weekly, sometimes daily, let the system update in something closer to real time. This is not about moving fast in the startup-cliché sense. It is about not being chronically late to your own information.

The fourth requirement, and perhaps the most important, is that the people operating the system understand why they are doing what they are doing, not only what they are doing. When conditions shift, the what may need to change entirely. The why is the anchor. If everyone understands the underlying logic, they can reason about what to do in a novel situation. If they only know the steps, they are dependent on someone telling them what the new steps are, and in genuinely uncertain conditions, that person may not know either.

Building for uncertainty at MSG

This is not an abstract exercise for us. The work being done across MSG, Orbit, Orion, TUXX, Benediction Lab, CheekyGains and the broader All Purpose direction, is being done in conditions that are genuinely uncertain in the ways that matter.

We do not know which product will find its natural market first. We do not know which technology will mature quickly enough to become a genuine foundation versus remaining a research curiosity. We do not know how the commercial landscape for AI-assisted tools will settle: what the pricing will look like, how enterprise buyers will think about trust and data, whether consumers will adopt AI coaching at scale or treat it as a novelty.

These uncertainties are real. They do not go away by writing a confident plan that pretends otherwise.

What we can do is build systems, internal and external, that are shaped for this environment rather than against it. That means keeping principles clear and process light. It means treating feedback from real usage as the primary input, not the thing we'll get to eventually. It means being willing to discard conclusions we were previously confident in if the evidence points elsewhere. It means not spending the next six months building a detailed plan for a version of the future that will certainly have changed by the time the plan is complete.

For Orbit, this shapes how the product is approached. The aim is not to specify every workflow in advance and build toward a finished product. The aim is to build the operating surface that can support the workflows that actually emerge, flexible enough to serve diverse commercial contexts, clear enough to give structure, without being so prescriptive that it breaks when reality diverges from the assumption.

For TUXX, operating through uncertainty is inherent to the work. Custom systems for different clients, different industries, different operating conditions: the value is in the ability to reason across contexts rather than in having a fixed playbook that only works in one setting.

For Benediction Lab, uncertainty is the environment by definition. Research into agents, memory systems, and autonomous development is research precisely because the outcomes are not known in advance. The operating system for that work has to protect the conditions for genuine inquiry, which means preserving the space to be wrong, follow unexpected threads, and revise conclusions.

The cost of false certainty

There is a real cost to pretending conditions are more settled than they are. It produces over-specified plans that are wrong in the specific ways they needed to be right. It produces rigid processes that break when the first unexpected thing happens. It produces communication that sounds confident but is actually just avoiding the discomfort of acknowledging what is genuinely not yet known.

The alternative, acknowledging uncertainty and building for it, feels riskier on the surface. It looks less like a finished plan and more like a set of orientations and principles. It is harder to present in a deck. It doesn't have a timeline with quarterly milestones that can be checked off.

But in conditions of genuine uncertainty, the false plan is the riskier one. It commits the organisation to a particular view of the future and makes it harder to update when that view turns out to be wrong. The honest acknowledgement of uncertainty, paired with a system that is built to operate within it, is the more robust position.

A working note

There is a version of this that becomes an excuse for not deciding anything, for treating all directions as equally valid, for avoiding the hard work of making commitments and being held to them. That version is not what is being argued for here.

Operating through uncertainty still requires decision-making. It still requires commitments. It still requires that you choose what to build and what not to build, who to work with and who to decline, which signal to act on and which to treat as noise.

What changes is the posture around those decisions. Under uncertainty, decisions should be made with explicit acknowledgment of what is and isn't known. They should be reviewed against new information rather than defended past the point where the evidence has shifted. And they should be reversible wherever possible, so that being wrong about something is an opportunity to update rather than a catastrophe.

The system that survives uncertainty is not the one that predicted the future correctly. It is the one that was built to keep making progress even when the future turned out differently than expected.

That is the thing worth designing for, in January 2020, and in any month that resembles it.