Reducing fragility through systems

Fragility is a design problem

By July 2020, the shape of the damage was becoming clear. Some teams had adapted quickly. Some products had proved unexpectedly durable. Some businesses had exposed, under pressure, exactly the cracks that had always been there: just never stress-tested at this scale or speed.

The common thread was not industry. It was not size. It was not whether the company had a digital strategy written down somewhere. The common thread was whether the underlying systems were fragile.

Fragility is not the same as weakness. A fragile system can look strong for years. It can hit revenue targets, attract good people, produce reliable output. Fragility only announces itself when conditions change: when the assumption underneath the design gets violated. And in 2020, a great many assumptions got violated at once.

What became visible in those months was that fragility is, at root, a design problem. It is not the result of bad luck or unusual circumstances. It is the result of building operations, products and teams around conditions that could change. It was not building for the possibility that they would.

---

What was actually being tested

A useful way to think about this period: it was not a crisis that attacked organisations from outside. It was a stress test that revealed what had always been true about them from inside.

The organisations that adapted well had not done anything exotic. They had, over years, made a series of sensible design decisions that, in aggregate, produced resilience:

**Operations that did not depend on a specific location.** When working from a particular building became impossible, these teams barely slowed. The location had never been load-bearing. The work was the work regardless of where it was happening.

**Communication that did not depend on proximity.** Some teams discovered that the informal hallway conversations that held everything together were not as informal as they thought: they were doing real structural work. When those conversations disappeared, nothing else was in place to replace them. The teams that adapted had, deliberately or not, externalised their communication into something more legible: written norms, documented decisions, shared context that lived somewhere persistent rather than in someone's head.

**Processes that did not depend on a specific person being present.** Key-person dependency is a form of fragility. When one individual holds an entire workflow in their head and that individual is unavailable, whether through illness, circumstance or the ordinary fact of being human, the workflow stops. Durable processes are ones that can survive the temporary absence of any single contributor.

**Products that did not require in-person delivery or assumption of physical access.** The products that proved most durable in this period were, almost entirely, digital-first in their delivery model. Not because digital was inherently superior, but because the assumptions underneath digital delivery held in 2020 when many other assumptions did not.

None of this is novel insight. These are the basics of good operational design. But basic principles, consistently applied over time, are precisely what produce durable systems.

---

The compounding effect of accumulated assumptions

Every system is built on assumptions. This is unavoidable. The question is whether those assumptions are legible: whether the people building and running the system know which assumptions they are making and what happens if those assumptions fail.

Most fragility is not the result of bad decisions. It is the result of decisions made under conditions that were assumed to be permanent. The office-first team did not decide to be location-dependent. They decided, thousands of times over years, to solve problems in ways that happened to require physical proximity. They never had a reason to question that pattern until March 2020.

This is why fragility compounds invisibly. Each individual decision is reasonable within the current conditions. The accumulation of those decisions produces a system whose assumptions are invisible because they were never examined as a set. The system works. Until it does not.

The clearest signal of a fragile system is when a team, asked to explain why they do something a particular way, responds that they do it that way because they have always done it that way. That answer is not always wrong. But it is worth asking what would break if the conditions that made that choice sensible were to change.

---

What designing for durability actually looks like

Reducing fragility is not about building redundancy into everything. It is not about planning for every possible failure mode. It is not about moving slowly or avoiding commitment.

It is about making assumptions legible and making critical ones load-bearing only when necessary.

In practice, this means asking a specific question at each design decision: what has to be true for this to work? And then: what happens if that thing is no longer true?

For a business operation: what has to be true about how people are located, what tools they have access to, who is available on a given day? For a product: what has to be true about the user's environment, connectivity, familiarity with a particular interface? For a team structure: what has to be true about who holds which knowledge, who is available when, who makes which decisions?

Most of the time, these assumptions are fine. The point is not to eliminate them but to be aware of which ones are structural. The ones that are structural deserve investment: in documentation, in redundancy, in alternatives that activate if the assumption fails.

---

How this shapes the work at MSG

The lessons from this period have been directly instructive for how we think about building across the portfolio.

The work at Benediction Lab on agent systems and memory is, at one level, research into capability. But it is also, at another level, research into how to build systems that hold state across interruptions: systems that do not lose context when conditions change, when a session ends, when a person is unavailable. The fragility of context is one of the fundamental problems in building intelligent systems, and it maps directly onto the fragility of human operational systems.

The design of Orbit as a product is shaped by a similar principle. A commercial operating surface should not be fragile around individual people. It should not make the business's knowledge dependent on one person's memory or one person's availability. The goal is to externalise the intelligence of commercial execution: to make it legible, accessible and durable regardless of who is present on a given day.

TUXX, working directly with clients in live environments, has seen firsthand what operational fragility looks like at the team level. The patterns that appear under pressure are not random. They are entirely predictable from the design decisions made months or years earlier. This informs how we approach custom systems work: not just solving the immediate problem, but identifying the assumptions underneath it and making them explicit.

---

Durability is not conservatism

There is a version of this argument that slides into caution for its own sake: the idea that reducing fragility means slowing down, hedging everything, avoiding commitment to particular directions.

That is not what we mean.

Durable systems are not slow systems. Durable systems are systems that can absorb change without losing coherence: they can move fast without the gains of speed being erased by the costs of the failures that speed produces. The most fragile way to build is to move quickly in ways that accumulate invisible debt, in assumptions, in process, in team knowledge that lives nowhere but someone's head. Until conditions change and the debt comes due all at once.

The goal is to move with the confidence that comes from knowing what your system depends on and having made deliberate decisions about those dependencies. Not to avoid dependency but to be honest about it.

This is, in a sense, the core institutional thesis for Mustard Seed Group. The work is not about building things quickly and selling them. It is about building things that hold: things that compound in value over time because the systems underneath them are honest about what they assume and durable against the changes those assumptions might not survive.

July 2020 was a period of unusual clarity about which systems had been built that way and which had not. The lessons are worth holding onto, because the conditions that revealed them will not be the last conditions to change.