Tools when conditions change

What March clarified

The office closed. Then another one. Then entire cities. Within two weeks of March 2020, an enormous number of organisations found themselves operating in conditions they had never designed for, and the things that broke first were not the expensive things. They were the ordinary things: the processes, the handoffs, the coordination rituals that had never needed to be formal because proximity made them automatic.

This is a familiar pattern in systems thinking but rarely this visible in real time. Conditions had changed. Tools had not. The gap between them became impossible to ignore.

What gets stress-tested in a moment like this is not resilience in the abstract: it is the quality of a system's underlying structure. Organisations that had already built coherent digital operating layers found that their tools transferred. Organisations that had accumulated shadow processes, informal agreements, and uncodified knowledge found that the move was not just physical. The context that made those processes work had not transferred with them.

Fragile by default

Most operational systems are built for normal conditions. That is not a criticism: it is how most things get built. You design for the most common case, add incremental features as needs arise, and accumulate a set of tools that works reasonably well until the environment changes sharply enough to expose the gaps.

The fragility is rarely visible until pressure arrives. A team that has always worked in the same room does not know how much coordination happens informally, through proximity and overheard conversation, until those signals disappear. A process that has always involved someone walking to someone else's desk does not know how much of its reliability depended on the physical act of walking.

Software does not fix this automatically. Moving to a digital tool does not by itself solve the problem of uncodified process. A video call is not a meeting with better posture. A shared document is not an operating model. The underlying structure still has to be there.

What the lockdown revealed, fairly quickly, was a distinction that is easy to miss in normal conditions: the difference between tools that are channels and tools that are systems. Channels let you communicate. Systems let you operate. When conditions change, channels keep working but systems that were never really systems stop working almost immediately.

The operating layer question

The question that became meaningful in March 2020 was not which software a team used. It was whether their work had an operating layer at all: a coherent, explicit structure that captured what was happening, why, and what was supposed to happen next.

Organisations with genuine operating layers found that the pandemic was logistically disruptive but operationally continuous. The work had a shape that did not depend on being in the same room. Decisions had records. Projects had states. Accountability was structural rather than social.

Organisations without that layer found themselves in a difficult position, not because they lacked tools, but because they lacked the model the tools were meant to serve. You can give a team every available collaboration product and they will still struggle if the underlying operational logic has never been articulated.

This distinction matters because it changes what the problem actually is. The problem is not access to software. The problem is what the software is asked to do, and whether the underlying operating model is explicit enough to transfer to any medium.

What this means for building products

Orbit exists because this gap is real and persistent. The problem is not that people lack software: the market has never been short of it. The problem is that the category of tool most commonly reached for is communication software, when what commercial teams actually need is execution software.

Communication software lets you send messages about work. Execution software gives work a shape: stages, states, accountability, memory. It captures not just what is being said but what is actually happening: where a deal is, what a client needs, what has been promised, what is blocking completion.

The distinction between these two categories is not obvious in normal conditions. Proximity, informal coordination and social accountability can paper over a missing operating model for a long time. When conditions change suddenly and those informal mechanisms disappear, the gap becomes structural.

The commercial workflow, from initial contact through to a launched product, is a process with genuine complexity: multiple stakeholders, variable timelines, handoffs across functions, commitments that have to be tracked and honoured. When that process lives in email threads, informal conversations and individual memory, it is stable only as long as the environment is stable. When the environment moves, the process does not reliably move with it.

Orbit is an attempt to give that process a proper operating surface. Not a place to discuss work, but a place to do it: where the lead-to-launched workflow has structure, where the state of commercial execution is visible, where accountability does not depend on everyone being in the same building.

Pattern Up and the TUXX layer

Within TUXX, the services division, the same principle shows up in how work gets done for clients. Services work is inherently variable. Conditions change from one engagement to the next: different organisations, different workflows, different levels of operational maturity. What makes services work scalable is the same thing that makes an organisation resilient: the extent to which the work is operating-model-led rather than context-dependent.

Pattern Up sits within TUXX as an attempt to codify the repeatable parts: the patterns of how good work gets structured, how operating models get built, how a services engagement transfers learnable approaches rather than just delivering outputs. The goal is not to make every engagement identical. It is to ensure that the structural intelligence from each engagement is not lost.

This is the same thesis applied to a different level. An organisation that captures pattern across its engagements becomes more capable over time in a compounding way. One that treats each engagement as isolated starts from a similar baseline every time.

What the research layer sees

There is a narrower question that sits beneath all of this, and March 2020 has surfaced it in a way that is hard to ignore. The question is not just whether an operating model can transfer across physical contexts. It is whether a system can carry enough context, enough memory of what has happened and why, to function coherently when the people who hold that memory are suddenly unavailable or working under pressure.

This is partly a human systems problem. But it is also an interesting research problem. The systems that held up best were not just the ones with more explicit structure: they were also the ones with better institutional memory. Records of decisions. Clear ownership of what was in progress. States that could be read by anyone without needing to interrupt someone else to understand them.

At Benediction Lab, this period is a useful frame. The research work on agents, memory systems and autonomous operation is not purely abstract. It maps directly onto the question that March 2020 has put in sharp relief: how does a system maintain coherence when the informal scaffolding disappears? Human teams that survive condition changes are the ones that have already encoded enough of their intelligence into durable, transferable structure. That same principle extends to software systems: the ones that hold context reliably, that do not require constant human narration to stay coherent, that carry their memory forward through disruption rather than losing it.

The gap between a tool that helps people communicate and a system that actively holds the operating context of work in progress is not cosmetic. It is architectural. And closing it, both in products and in research, is a significant part of what is being worked on.

Resilience as a structural property

What March 2020 made unusually clear is that resilience is not a value or a disposition. It is a structural property. You either have it built in or you do not. You cannot choose to be resilient after conditions have already changed.

The organisations that came through the early months of the pandemic in operational shape were not necessarily the ones with the most sophisticated technology. They were often the ones with the most explicit operating models: the ones where the structure of work had been articulated clearly enough that it could run on any available medium.

This is a lesson that applies well beyond pandemics. Conditions change in businesses for many reasons: personnel changes, market shifts, regulatory changes, sudden growth. The question in all those cases is the same: is the operating model explicit and structural, or is it distributed across the informal knowledge of the team?

An operating model that lives in people's heads is not really an operating model. It is a collection of habits that happen to produce acceptable results when nothing disrupts them. The test of an operating model is whether it transfers: to a new context, a new team member, a new working arrangement, a new set of conditions.

The useful product question

The useful product question in March 2020 is not "what can we build?" It is "where does the operating model break when you remove the informal scaffolding?"

Repeated friction is a signal. It tells you where teams lose momentum, where people abandon standards, where a better structure would change the outcome. The friction that became visible in March 2020 was the friction of operating without an operating model: the cost of coordination without structure, execution without memory, accountability without explicit record.

That friction was always there. The conditions had just changed enough to make it undeniable.

Building for that friction means building products that are genuinely systemic: not channels or dashboards or productivity tools, but operating surfaces that give work a coherent shape. Products that transfer when conditions change, because the logic of how the work operates is built in rather than assumed.

That is the thesis being tested here. Not just whether the tools work when nothing is disrupted. Whether they hold when everything is.