Shipping the Org Chart

Wednesday morning. The first item on the planning meeting agenda is the FY27 customer experience roadmap. Four directors present, one for each department — Digital, Marketing, Contact Centre, Loyalty. Each has six slides, each has a clean roadmap, each has identified AI as the strategic priority. The Digital director plans to ship a customer-facing AI assistant by Q3. The Marketing director plans to integrate AI into the campaign-orchestration platform. The Contact Centre director plans an agent-assist rollout. The Loyalty director plans a recommendation engine.

I am taking notes. I do this a lot, but today I am taking different notes than usual.

Yesterday, I spent fifteen minutes in a department store reciting my order number to four systems in series. The system that could authorise the refund was the fourth one. None of the other three was connected to it.

Today, four directors are showing me four separate AI roadmaps. The systems they are building are excellent. None of them connects to the others. I have seen this meeting before, in different rooms, at different companies. The roadmaps were called different things — digital transformation, omnichannel, customer 360, the integration platform. They had different vendors and different timelines. They shipped the same architecture every time.

There is a sixty-year-old principle in software engineering that explains exactly why. I am going to name it now.

You ship your org chart

In 1968, Mel Conway published a paper called How Do Committees Invent? It is six pages long. It is the most useful six pages I have ever read about why customer experience does not work.

The paper's central observation, in Conway's words: any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure. In plain English, the version I keep repeating until people get tired of hearing it: you ship your org chart.

If your organisation is four teams that do not talk to each other very much, your system will be four products that do not talk to each other very much. Conway observed this in 1968. The CX industry has been proving it again, in different vendors and different decades, ever since.

In the planning meeting in front of me, the four-team / four-product version is on the slides. Digital owns the website. Marketing owns the email campaigns. The Contact Centre owns the agent desktop and the chatbot. Loyalty owns the points programme and the app. Four directors, four quarterly OKRs, four vendor contracts, four roadmaps. Each is excellent. Each is well-funded. Each has done what was asked of it. The shape of what they produce, taken together, is decided before any of them sits down at a keyboard.

This is not a failing of any individual team. It is a structural inevitability. The four-product, four-vendor, four-decade pattern is not a coincidence. It is what Conway's Law predicts. It is what Conway's Law has been predicting for sixty years.

The only useful question is what you do about it.

Five generations of the same shape

The story of enterprise CX investment for the last twenty-five years has had the same shape every time.

It goes like this. Each department buys its own stack — users, app, knowledge, data, system of record, the whole vertical column. Then the integration team spends three years stitching the stacks together horizontally, because the customer's experience is not a column. The result, on a slide, is each department's stack with a wavy horizontal line drawn between them labelled "integration platform." On the ground, the result is four products that do not talk to each other very much.

Most enterprises I have seen are on their fifth or sixth generation of this. Different vendors. Different acronyms. Different generations of the integration platform that was supposed to fix it. Each time, the buying motion ends with the same architecture and the same wavy line. The line gets thicker on the slide as the years pass. The integration cost stays where it has always been, which is the customer.

This is Conway's Law in technology form. The four departments produce four stacks because the four departments are four departments. The integration line is the seam — the place where Conway's Law leaves a visible scar on the architecture.

The agentic AI substrate changes the shape. Data becomes shared. Knowledge becomes shared. Context becomes shared. Orchestration becomes shared. These collapse into three architectural layers: an agent-facing interface, a persistent context layer, and an orchestration layer. The apps and the departments sit on top as consumers, not as owners. The horizontal line stops being a wavy aspiration and becomes the actual foundation everything else is built on.

That is a different shape. It is also a different kind of buying motion.

The Inverse Conway Maneuver

In 2019, Matthew Skelton and Manuel Pais published a book called Team Topologies that gave the strategic response to Conway's Law its own name. The Inverse Conway Maneuver. The premise is direct. If you cannot escape the architecture-mirrors-org-chart dynamic, do not fight it. Reshape the organisation to produce the architecture you actually want.

For agentic customer experience, the architecture you want is the substrate shape. Three horizontal layers, shared, owned by no department individually. The agent-facing interface, where the customer's agent talks to your agent, regardless of which department behind your agent is being asked the question. The persistent context layer, where the customer's history, intent, and state live across every channel and handoff — read and written by every agent, human or AI. The orchestration layer, the real-time judgment about whether this interaction stays with the AI agent, escalates to a human, triggers a proactive outreach, or routes to a specialist.

These three layers are the substrate. They are what the next piece in this series is about, and I will leave the deep dive there. The point for this piece is structural. A platform agent layer owned by no department is something no department can ship. The Inverse Conway Maneuver is the executive move that makes ownership possible: consolidate the data, the customer model, the orchestration responsibility, and the agent layer itself under a single accountable owner. Not three VPs sharing a roadmap. One.

Klarna, Capital One, and Stripe are three legible examples of companies that have done some version of this. The pattern across them is consistent: one operating model, one customer-data spine, one orchestration responsibility, one executive who can be fired if the customer experience does not work.

That is the maneuver. It is not subtle.

Solving a 2015 problem

Halfway through the planning meeting, the CIO mentions the CRM consolidation project. Six instances down to one. Four years of work. Roughly $40 million when you count the integration partner and the internal hours. The room nods. It is a reasonable thing to do.

It is a reasonable thing to do. It is also solving a 2015 problem.

I do not say this in the meeting. I write it down. The problem the CRM consolidation solves is the four-stack-with-a-wavy-line problem. The architecture it produces is one of the stacks, with a slightly smaller wavy line. The shape on the slide is unchanged. The customer's experience, the year after the consolidation finishes, will be subtly better in ways the customer cannot describe. The seams will move. They will still be there.

The next decade of CX will not be won at the consolidation layer. It will be won at the substrate layer — the agent-facing interface, the persistent context, the orchestration. The substrate is not owned by any department. That is exactly why no department has built it.

The $40 million is not wasted. It is just not the bet.

The meeting ends. I stay in the room for a minute after the others leave, looking at the four roadmap slides still on the screen. Each of them is good. Each of them, taken alone, is a credible quarter of a strategy. Taken together, they will produce the same architecture the company has shipped for the last fifteen years.

The Inverse Conway Maneuver is not a re-organisation. It is a recognition. The architecture you ship is the architecture you have already chosen, whether you sat down to choose it or not. The question is whether you chose it on purpose.

Yesterday I was the customer at the four-system counter. Today I am the executive in the four-roadmap meeting. The shape was the same on both days.

The next piece in this series is about the substrate the four roadmaps cannot see.