Your Org Chart Has a Cyclomatic Complexity Number. AI Is About to Change It.

"Every human institution, including the technology giants of Silicon Valley, has a means of organizing personnel, and such organization will often require the elevation of certain individuals over others. The difference is the rigidity of those structures, that is, the speed with which they can be dismantled or rearranged, and the proportion of the creative energy of a workforce that goes into maintaining such structures and to self-promotion within them."
— Alexander C. Karp and Nicholas W. Zamiska, The Technological Republic

Karp and Zamiska are making an argument about institutions. We'd like to make it about arithmetic. Because there is, buried in a corner of software engineering that almost nobody talks about anymore, a fifty-year-old metric that describes exactly what they're describing — how much of an organization's energy goes into maintaining its own structure — and it turns out to be one of the more useful lenses we've found for thinking about what AI actually does to a company. Not the demos. Not the copilots. The structure.

Bear with us. This one starts in a codebase and ends in your boardroom.

A metric from the era of real engineering discipline

One of us — Peter, in this case — first ran into the Cyclomatic Complexity Number about thirty-five years ago, deep in a phase of reading everything ever written about how large software systems are actually designed and why most of them go wrong. Mention it to a working developer today and you'll mostly get a polite blank look. Which is a shame, because the idea is one of those small, sharp tools that explains far more than it was built to explain.

Here's the concept, minus the graph theory. Take a piece of code — a single subroutine, say — and count the number of independent paths through it. Every decision point, every branch, every "if this, then that" adds a path. That count is the Cyclomatic Complexity Number. A routine with a CCN of one is a straight road. A routine with a CCN of twenty is a hedge maze, and somewhere in that maze is the bug you'll be hunting at 2 a.m. three years from now.

The practical rule of thumb, back when this was taught seriously: if a routine's CCN crept past ten or so, you broke it into smaller pieces. Not because the machine cared — the machine will happily execute a maze. You broke it up because you couldn't hold it. And that's the part of the story people miss: the threshold was never really about software. It maps almost directly onto the limits of human working memory. Your short-term memory can hold roughly seven to ten things at once. Push a piece of code past the number of branches a person can keep in their head simultaneously, and it becomes unmaintainable, untestable, and — the word that matters — un-understandable. The metric was a measurement of code, but the limit it guarded was the width of the channel into the human brain.

Hold that thought, because it's the whole essay.

The law of conservation of complexity

Before we leave the codebase, one more lesson, and it's the important one. Suppose you take that maze of a subroutine and dutifully refactor it into forty tiny routines, each with a CCN of one. Congratulations: every individual piece is now trivially simple, and the system as a whole is still a nightmare — arguably a worse one, because now the complexity lives in the calls between the pieces instead of inside any one of them. You haven't destroyed the complexity. You've relocated it.

Every experienced engineer eventually internalizes this, usually the hard way. Complexity behaves like a conserved quantity. The problem your system solves has some irreducible amount of it, and your only real choices are where it lives and whether you can see it. Move it, restructure it, rename it — fine. But anyone who tells you they made it disappear is either lying or about to have a very educational quarter.

Now look up from the code and out at the org chart.

Your organization is a program

Why do organizations have layers at all? Not because anyone loves hierarchy. Layers exist for precisely the reason the CCN threshold exists: the channel into the human brain is only so wide. A manager can genuinely manage about seven to ten direct reports — the same number, and that is not a coincidence, it's the same brain. You'll occasionally meet the executive who claims to manage forty people. What they actually have is a few excellent managers underneath them who don't need managing, which is a lovely thing to have and a different thing entirely.

So we layer. A company of a hundred people runs three or four levels deep. A major enterprise runs ten, sometimes fifteen. And every one of those levels exists to do the same job the subroutine boundary does in software: chunk the problem down to something a human can hold.

Here's where it gets interesting, and where the software metric turns out to travel better than it has any right to. The naive way to measure organizational complexity is to count the layers. The better way — the way that actually predicts how decisions move — is to graph it. Make every person a node. Draw an edge for every touchpoint a decision actually passes through: the sign-offs, the consultations, the "loop in Legal," the dotted lines, the steering committee that meets on alternate Thursdays. Now count the independent paths through that graph, exactly the way you'd count them through code.

In a real organization — matrixed, cross-functional, vertical structures interlocking with horizontal ones — that number is not high. It is astronomical. A decision that looks like it should take one conversation routinely traverses a graph with dozens of decision points, and the org chart shows you almost none of them, because the org chart is the documentation and the meeting invites are the running system.

This is also why the classic restructuring move fails so reliably. Some leadership team looks at ten layers of middle management, deletes three, and declares the company faster. Conservation of complexity would like a word. The coordination those layers performed didn't vanish — it got smeared across the survivors, who now do it worse, informally, and without anyone tracking it. You didn't refactor the organization. You deleted the subroutines and left the calls dangling.

What middle management actually is

To see what AI changes, be precise about what those layers actually do all day. Strip away the ceremony and middle management is, to a first approximation, a summarization engine. Information flows up, and at every level it gets compressed so the level above can hold it in — say it with us — a working memory of seven to ten things. The CEO does not need to know what a line of code looks like in a three-million-line application, and thank goodness. Each layer's job is to decide what the next layer up doesn't need to know.

It's a genuinely necessary function, given human hardware. It is also brutally lossy, in two distinct ways.

The first loss is honest. Summarization discards detail by design, and nuance is usually the first thing over the side. Ten layers of good-faith compression and the picture at the top bears about as much resemblance to ground truth as the tenth whisper in a game of telephone. Everyone has sat in the executive review where the slide said green and the project was, to anyone within fifty feet of it, on fire. No one lied. The truth just didn't survive the compression.

The second loss is subtler and worse. When a person summarizes for you, they choose what matters using their heuristics — built from their training, their experience, their scars, and yes, their interests. A manager who believes in the product will summarize its prospects one way; a manager positioning for the next reorg, another. None of it need be malicious. But the filter is theirs, not yours, and you have no way of knowing what it removed. The information you most needed may have died three levels down, not because anyone hid it, but because it didn't look important through someone else's lens. Add the overhead of moving anything across silos — the chains of command, the pre-meetings for the meetings, the sheer emotional friction of humans coordinating with humans — and you get what we'd call the communication tax. Every large organization pays it. Almost none of them itemize it.

Enter a working memory the size of a warehouse

Now change one assumption — the load-bearing one. For the entire history of organizations, the seven-to-ten limit was a constant of nature. Every layer, every summary, every committee is downstream of that single constraint. What happens when a participant shows up whose working memory is, for practical purposes, unbounded?

A frontier model doesn't hold seven things. It holds the contents of your document stores, your project histories, your policies, and this morning's numbers, simultaneously, without fatigue and without a lunch meeting. In a hundred-thousand-person company, it can notice that a decision made in one silo is about to land on someone three silos away — the kind of connection that today requires four escalations, six weeks, and a small miracle of corporate diplomacy.

And it inverts the summarization problem, which is the part we find most interesting. Today you consume the summary you're given, filtered through heuristics you didn't choose. With the organization's information in a queryable layer, you interrogate it yourself. What am I missing? What's the exposure nobody's flagged? Show me this program's actual status, not the slide about its status. The executive stops being a consumer of other people's compression and becomes an interrogator of the underlying reality. Nuance stops dying in transit, because there is no transit — the detail is still there, at full resolution, when you want it.

Run that through the graph. Whole clusters of nodes and edges — the coordination meetings, the relay layers, the summarize-and-forward apparatus — collapse into queries against a shared layer. The decision path shortens. The decision CCN, if you'll allow us the coinage, drops. Not marginally. Structurally.

Conservation still applies — read the fine print

If you've been paying attention, you already know we owe you a caveat, and here it is: the law of conservation of complexity does not have an AI exemption. When you collapse those layers into a model, the complexity does not evaporate. It moves — into the prompts, the policies, the retrieval pipelines, the model's behavior itself. You have refactored the complexity out of human heads and into a system. That can be an enormous win. It is not a free one.

Because here's what you've traded: the old complexity was slow and lossy, but it was inspectable. You could ask a middle manager why they decided something. You could, at least in principle, follow the chain. A model layer that can't explain how it reached a conclusion is a maze you've merely stopped being able to see — the same opacity, relocated, with better latency.

Which is why we'd put it bluntly: an organization that gets this right will be observability-first about it. Versioned prompts and policies. Tested model behavior, the way you'd test any system that makes decisions that matter. Decision logs a human can audit. The discipline that software engineering spent fifty years learning to apply to complex systems — the discipline the CCN came from in the first place — applied to the new decision layer from day one. Skip that, and you haven't flattened your organization. You've compressed all ten layers of it into a black box and handed the black box a title.

The part where we don't fire everybody

Our regular readers can probably recite along with us, because we mean it every time: this is not a workforce-vaporization argument. We reject that framing when the hype merchants sell it and we reject it here. Collapsing layers of coordination is not the same as discarding the people who did the coordinating — most of whom, frankly, are wasted on it. The manager who spent sixty percent of their week summarizing upward and relaying downward has a working brain that the relay work was actively squandering. Those people become managers of the new layer — supervising, auditing, and correcting the agents that took over the plumbing — or they return to what most of them were before the org chart promoted them out of it: domain experts, contributing at full resolution. More people doing real work, fewer people forwarding it. That's the humane version of this, and not incidentally the profitable one.

Human intermediaries have interests — pet products, turf, moods, mornings. A model holds no grudge from the budget cycle and isn't angling for the VP slot; some genuinely valuable neutrality comes with that. But let's not be naive in the other direction either: models have their own failure modes, their own biases baked in from elsewhere, and no stake in the outcome — and a system with no stake in the outcome needs humans around it who have one. Judgment stays. The relay races go.

The thought experiment, stated plainly

So here is the question we're leaving on your desk, stated the way we'd state it in your boardroom. Take your organization's real decision graph — not the org chart, the actual one, with every touchpoint drawn in. Its cyclomatic complexity is a real number. You've never measured it, but you pay it, every day, in the tax. And let's face reality - it's usually a massive tax on efficiency.

Can AI lower that number? We believe it can — done right, with the complexity moved deliberately into an observable, versioned, tested layer instead of leaking into an opaque one. The prize is not a smaller company. It's a flatter one that remains navigable at sizes where flatness used to be physically and humanly impossible — where the constraint of seven to ten finally stops being the constant every structure bends around, because the coordination load now lives in a layer everyone can query and no one has to be.

A fifty-year-old software metric, walking into the boardroom. We told you it would get there. What's your number?

---

All In On Data helps leadership teams turn AI ambition into business outcomes — by getting the data, strategy, and people foundations right. If you'd like to talk about what your organization's decision graph actually looks like — and which parts of it belong in a model — send us a note. We'll tell you honestly what's worth doing and what isn't, and if we're not the right people to help, we'll tell you that too.