Designing workflows and work systems seems pretty straightforward.

We need to go from W to Z, with stops at X and Y along the way.

But we often forget that each stop the system makes is a system unto itself. Maybe stop X is a whole team with its own workflows and people who need to move things through that system. Maybe Y is a particularly persnickety QA reviewer.

There’s an old story about a lecturer explaining the universe when someone objects that the Earth is actually resting on the back of a giant turtle.

“And what is the turtle standing on?”

Another turtle.

And beneath that?

“It’s turtles all the way down.”

Systems Inside Systems

I increasingly think organizational design works something like that.

Each stop along a system interacts with people whose own internal systems are going to influence how likely the system at large is to succeed.

That individual’s system is influenced by their history, their experiences, their particular biochemical makeup at that moment. And any meaningful change to the system adds another layer. AI is an obvious example.

AI is a topic so loaded that effectively nobody has no opinion. One person in that workflow might be thrilled to get rid of the tedious execution work so they can focus on the parts of the job they enjoy. The person sitting next to them might see the introduction of AI as the final move toward the layoff they’ve been expecting for months.

When humans are in a system, the system gets messy because humans are messy clusters of their own systems, responding differently depending on what happens to be salient, threatening, rewarding, or exhausting in that moment.

That’s not a reason to simply hand everything over to AI. We need humans. We want our systems not simply to feel human, but to be human. But somewhere at the bottom of every beautifully designed process is a tired person interpreting a sentence.

So we have these complex systems at work that rely on potentially dozens or even hundreds of individuals who embody necessary stops along the way, but also embody their own impossibly complex systems—systems that, quite often, even they aren’t fully aware of.

And those systems are, in turn, designed by a person or collection of people who are designing from the perspective of their wildly complex internal systems and whatever happens to be influencing those systems on the days, weeks, or months spent designing them.

And then we can’t figure out why the systems don’t work the way we intended.

The Whiteboard Isn’t the Workflow

You’ll never design the perfect workflow in a vacuum. It has to be exposed to all of those intertwined systems to become real.

Good system design means understanding the systems that feed into the one we’re trying to build.

  • What conditions make information easy or difficult to surface here?
  • Who needs what kind of context before they can act?
  • What incentives make silence safer than disagreement?
  • Which personalities or histories make this meeting format work for some people and fail for others?

And perhaps most importantly, we need to stop treating these systems of work as though they are composed of interchangeable parts. This is part of why familiarity matters—and why unfamiliarity can be equally valuable. Someone who understands the existing system can navigate it efficiently. Someone who doesn’t may immediately notice assumptions everyone else stopped seeing years ago.

Every process lands inside a person with their own habits, incentives, fears, history, attention patterns, assumptions, status concerns, goals, and ways of making sense of the work. Then those people interact with one another, and all those variables can either collide or collaborate.

So you can’t really optimize a system in a vacuum. You can’t assume that the perfectly designed system on paper is the one that will actually deliver the results you’re looking for.

You have to work to understand the people. How they work and how they work together.

Then you have to put the process into the world and watch closely: where it bends, where it breaks, where people work around it, and where the actual flow differs from the one you drew.

This is why most enterprise AI problems aren’t really AI problems. The workflow may be the thing we draw on the whiteboard. But underneath it are teams, incentives, relationships, habits, histories, and individual nervous systems.

Turtles all the way down.

Understanding those people isn’t the squishy part of system design.

It’s part of the architecture.