Breaking Down a Complex System So Anyone Can Understand It

I’ve spoken about documentation and the growing divide between the systems we design and the end users consuming such systems, but there’s something almost ephemeral that bridges the two: learning how to break down a story.

I’ve always had a passion for learning different things – outside those that are part of my career – and that’s helped me build up a generous thesaurus of analogies. I’ve been able to explain nearly everything to nearly anyone: from firewalls doing deep packet inspection as turnstiles on the subway to query execution plans and binders being organized on a desk. I think it’s my superpower, but it’s also something anyone can learn to be an effective storyteller in the information landscape.

Every complex system hides a simple truth: it’s built from smaller, understandable parts. The challenge isn’t the complexity itself. It’s the translation of those parts. When we fail to break systems down, we don’t just lose clarity; we lose connection. People stop engaging because they can’t see how the system relates to their goals. And when people can’t see themselves inside a system, they stop caring about how it works.

Ultimately, this is the gap we’re all trying to close.

The Altitude Problem

Most explanations start at the wrong altitude.

Neither approach helps someone build a mental model. Without that model, the system remains abstract. Abstract systems are something to be used, not understood – it’s like having a wrench in your hands, but not understanding the reason you are torquing down a nut. And when a system is only “used,” it becomes fragile. People follow steps without knowing why those steps matter. They troubleshoot symptoms instead of causes. They treat the system like a vending machine: push button, get output. Hopefully that’s not enough for you because it’s never been for me as a consumer of any technology service.

The right altitude is the one that connects the system’s machinations to human intent. It’s where the “how” and the “why” meet.

Complexity Isn’t New — Obfuscation Is the Oldest Tradition in Tech

One of the biggest misconceptions in modern software is the idea that complexity is a recent invention. It isn’t. Obfuscation has been baked into technology since the earliest days of chip design.

We’ve always layered systems:

• Microcode hiding transistor behavior
• Drivers hiding hardware behavior
• Virtualization hiding OS behavior
• Containerization hiding process behavior
• Orchestration hiding container behavior
• Serverless hiding infrastructure behavior

Every generation adds another layer. Every layer hides something. And every hidden layer creates a potential for a new kind of confusion.

Engineers love these layers because they’re elegant. They solve real problems. They let us build faster, safer, more resilient systems. We’re taught this in computer science long before we begin to talk about complex data structures. Build functions (and procedures) that you can use over and over again. If you build a function called AddTwoNumbers and all it does is add two numbers, you’ll always know what it does.

But for the operators, analysts, support teams, and customers using the system, the layers don’t matter. They don’t need to know how the sausage is made. They need to know what the system does, how to reason about it, and how to make good decisions inside it.

Getting lost in the minutia of the layers isn’t important for most people. It’s interesting. It’s neat. It’s intellectually satisfying. Personally, it’s one of my favorite parts, but in the end, it’s not useful.

And that’s why breaking down complexity matters: it helps people navigate the system without forcing them to understand every layer of abstraction that got us here.

Why Breaking Down Complexity Matters

Breaking down a system isn’t about dumbing it down. It’s about making it navigable.

A navigable system is one where:

• People understand the flow of information.
• They can predict how the system will behave.
• They can reason about problems instead of memorizing fixes.
• They can connect their work to the system’s outcomes.

Basically, they understand the who, what, where, when, why, and how of a system without having to know all the dirty details. When people understand the system, they stop feeling like bystanders and start acting like participants. The shift from passive to active is where real adoption happens.

The Breakdown Framework

To make a system understandable, you need a storyline. Not a metaphor, not an analogy, not a diagram: a storyline. Something that connects the parts in a way that feels natural.

NOTE: Metaphors, analogies, and diagrams all help, but are secondary assets to the understanding. You must start with the story.

There are just a few steps that help make this a reality, and if you think about all good stories, then encompass them.

1. Start with the outcome

What does the system enable? Not what it does — what it makes possible.

2. Identify the actors

Who interacts with the system? Users, data, signals, services, processes — whoever or whatever the “characters” are.

3. Map the flow

How does information move and transform? Flow is the backbone of understanding.

4. Reveal the feedback

Where does insight return to improve the system?

Every meaningful system has a feedback loop. If you don’t show it, people assume the system is static. If you do show it, they understand how the system learns.

Each layer should answer a human question: What happens here, and why does it matter?

A Practical Example

Imagine explaining a monitoring platform. You could list features: metrics, logs, traces, dashboards, alerts, SLOs, anomaly detection – all the things.

Or you could tell a story:

It’s like a nervous system. Sensors detect signals, the brain interprets them, and the body adjusts.

Suddenly, the listener has a mental framework. They understand:

• sensors = telemetry
• brain = analytics
• body = automation
• adjustment = remediation

Once they see the pattern, you can layer in detail without losing them. You’ve turned a technical system into a human one. This is the difference between explaining and translating.

The Hidden Benefit: Confidence

When you break down complexity, you don’t just teach the system; you teach confidence.

Confidence changes behavior:

• People explore instead of avoid.
• They ask better questions.
• They troubleshoot with intent.
• They connect ideas across domains.
• They see how their work influences the whole.

The system becomes part of their thinking, not just their workflow. Whenever I’ve built systems, I’ve always wanted explorers, never drones. Those explorers will probe for answers, self-diagnose issues, craft explicit feature requests/ideas, and help drive the solution forward. They also make excellent community champions.

The Long-Term Effect

When teams consistently and effectively break down complex systems instead of just clicking and showing:

• onboarding accelerates…
  …because the receiver of the information can follow what’s happening at each step and anticipate the next.
• documentation improves…
  …because your documentation following the story and not just the settings
• cross-functional collaboration becomes easier…
  …because an informed consumer can inform other team members at their organization
• decisions become more grounded…
  …because the ramifications are known in advance and guesswork decreases
• innovation increases because people understand the constraints…
  …and know how to work within (or around) those constraints.

Complexity stops being a barrier and becomes a landscape — something people can navigate, explore, and shape.

That’s the power of translation. It doesn’t reduce complexity; it unlocks it.