By: Kumar Dattatreyan

"The spider doesn't start in the inside, the spider starts on the outside, looks for things to connect it to." Glenn Marshall said that on the show while we worked through the seventh permaculture principle, and it describes the reverse of how most organizations get designed.

Most organization design runs inside out. Someone buys a tool and staffs a team around it, and only later does anyone ask which market the arrangement serves. Each piece looks reasonable on its own, so nobody objects, and the trouble shows up in the aggregate, where parts that each make sense start fighting each other.

The pull toward the visible makes this worse. A launch gives people something to point at, while the shape of the streams underneath it gives them nothing to show, so attention goes to the launch every time. That bias doesn't correct itself. You'll have to correct it on purpose, and principle seven of the permaculture series, design from patterns to details, is the correction.

What Is Breadth-First Organization Design?

Breadth-first organization design means you settle the pattern before you commit the particulars. The pattern is the shape of the work: which markets you serve, which value streams cross them and where the seams and gaps fall. The particulars are everything that would land on a roadmap, from the tool you buy to the charter you write for a team. You commit firmly to the pattern and loosely to the particulars.

XSCALE's ecosystems thinking adapts the permaculture principle this way: "Design breadth-first. Step back to see patterns in and between markets and value streams. These inform designs we can only detail as we learn more." The final sentence carries the discipline. Patterns inform the design, and the details wait until the work has taught you enough to draw them.

That makes it a sequence and not a plan you finish before you start. You see the pattern, you commit to it, and you fill in details as you learn them and not before.

Why Inside-Out Design Keeps Failing

Inside-out design fails for a simple reason: each detail gets chosen while the whole is still unknown, so it can only be judged against itself.

James Taylor builds decision systems, and his account of machine learning is the cleanest example of detail-first design I've come across. When he started in the field, about 80 percent of models never reached production. Twenty years later he says the rate hasn't moved much, even though companies build far more models and spend far more money on them. His explanation is that "people build the models forward." They take the data on hand, build whatever model that data supports and then go looking for someone with a problem it might fit. The model is a detail, picked before anyone settled the pattern, which is the decision the model is supposed to improve. His correction is blunt: "you have to begin with the decision in mind."

Taylor tells a second story that makes the same point from the other direction. An insurer told his team that its claims were 100 percent digital. Every claim moved through the system electronically, and a claims adjuster still looked at every one of them. The company had digitized the details around the work and never designed the decision at the center of it, which is why Taylor's team scored the result as zero percent digitization.

Patricia O'Shea reaches the same failure from the leadership side. She began her career raising money for cancer research through a telemarketing center, and the automated dialing system she ran there was never the point. The mission was the point, and the system served it. She told me that "it's very easy to get caught in technology for technology's sake." Her second observation moves the pattern up a level. Companies that treat a product operating model as a technology matter get little from it, because in her words "you need to work across multiple groups within your company." The pattern includes the groups that have to build together, so a design that stops at the edge of the technology team stops too early.

Glenn's picture for the same failure was a farm. Traditional farms get planted piece by piece, a crop here and a crop there, and the soil degrades until someone pumps in fertilizer to rebuild it. Then he turned to organizations: "we don't really think about designing organizations this way, they're sort of built haphazardly." The organizational fertilizer is the next reorg or the next tool, bought to repair damage the last detail created.

Put the three accounts side by side and the sequence repeats. In Taylor's case a model came first, and on Glenn's farm a crop came first, and in both the whole arrangement got worked out afterward, if it got worked out at all. O'Shea's dialing center worked because the mission came first and the technology followed it.

What the Pattern Looks Like When It Works

Glenn and I traced the principle through two companies in that episode. Apple's iPod grew out of iTunes, and the iPhone grew out of the iPod, and a whole ring of chip makers and software companies now exists because of how one company shaped the field around it. Tesla took the battery work it built for cars into energy storage, a market next door that its first product already pointed toward, and at the time we recorded (early 2024) it had opened its charging network to rival automakers. Both stories are about seeing the adjacent market and building into it afterward, with the earlier product acting as the frame for the next one.

The same logic works at longer range. Where the economics of a market are heading tells you which detailed bets will still stand in a few years, so you read the pattern between markets before you commit to the build.

It also works inside one company, where the markets are internal and the value streams hand work to each other. I've written about why reorgs fail at the coordination layer, and the cause is usually that every box got optimized while nobody designed the seams between them. One theme from our Coaching and Facilitation Dojo points the same direction for culture: you can't bolt trust on one policy at a time, and it forms when the pattern of how people relate and decide gets set before the particulars.

Isn't Breadth-First Design Just Big Design Up Front?

The emergent-design school has a fair objection, and it deserves a fair statement. Kent Beck's rule is to do the simplest thing that could possibly work. Martin Fowler's writing on evolutionary design argues that structure grows out of small working pieces when automated tests and refactoring sit behind them. The Agile Manifesto holds that the best architectures emerge from self-organizing teams. On that view, the patterns you see before building are guesses, and a survey from a whiteboard buys you analysis paralysis and a design that customers contradict within weeks. Fowler adds a warning in Monolith First: the lines between services are hard to draw correctly at the beginning, even for experienced architects.

Each of those positions is right about the failure it describes. Speculative detail drawn up front does break on contact with customers, which is why the XSCALE wording says designs can only be detailed as you learn more. Breadth-first design isn't big design up front with a new name; it makes the opposite move, because big design up front commits the details early and breadth-first commits only the pattern.

Fowler keeps a frame himself. He says evolutionary design works for him most of the time, and he still argues that some decisions are faster to make at the start, such as whether a system needs a database at all. Emergent design needs something to emerge inside of. Without a frame you get local optima that each made sense and don't compose, which is the reorg that optimized every box and broke every seam. Beck and Fowler supply the details-loosely half of the discipline, and principle seven insists on the breadth-firmly half.

His warning about service lines sharpens the point instead of blunting it. Where to divide services and how to charter teams are details, and they're hard to get right early, so leave them loose. The pattern sits a level above them: which markets you serve, which streams run through those markets and where the gaps fall. A map like that costs a few conversations to redraw, where a staffed team and a purchased tool cost far more, so the pattern is the cheaper thing to be wrong about. Hold it firmly enough to build against and revise it when evidence says to, and not when the mood shifts.

Two Moves Before the Next Build Decision

Draw the pattern on one page before anyone approves the next detail. Put the markets you serve and the value streams that run through them on a single page, then mark the seams where work changes hands. Hold the next tool purchase and the next team charter until that page exists, and ask Taylor's question of each one: what decision does this serve, and who makes that decision today? Show the page to the people who are most excited about the demo. It's dull on purpose, and the dullness is the sign that you're looking at the foundation.

Mark every detail as provisional and attach the evidence that would change it. Beside each tool and each team charter, write what you'd have to see before you'd revise it, and review those notes at your normal planning cadence. The detail stays loose until the work earns it, and the page from the first move gives you something to check each change against.

Related Podcast Episodes

Episode 80: Designing Connected Ecosystems with Glenn Marshall. This is the anchor for the post. Glenn takes principles seven and eight through the spider web and the farm, and his point that organizations get built haphazardly is the problem this whole piece works on.

Episode 173: The AI Decisions Are Wrong (And Your Data Isn't the Problem) with James Taylor. Taylor shows what breadth-first looks like in knowledge work: the decision comes first and the technology is a detail you choose once the decision is clear. His story about the insurer with 100 percent digital claims is worth hearing in full.

Episode 166: Intentional by Design with Patricia O'Shea. O'Shea carries the pattern up to the whole company, where a good product depends on groups outside the technology team. She also tells the telemarketing story that keeps the mission ahead of the tool.

Principle seven decides which streams exist and where they meet. The previous post in the series worked inside a stream, and this one works on the drawing that put the stream there. Principle eight takes up the relationships between the streams, so the parts support each other instead of sitting in silos. It uses the same episode and the XSCALE idea of collaborating rather than delegating.

If a build decision is pending and the pattern isn't on paper yet, bring that one decision and we'll draw the pattern around it in a 30-minute conversation.