↓ Download as PDF

The shape of the situation is familiar. Revenue has doubled, headcount has doubled, and every problem now arrives with a proposed fix attached: a hire, a tool, a reorganisation. Each fix is reasonable on its own. Nobody can say what the sum of them is for. Ask the leadership team what the operating structure is meant to carry and you get the org chart back — which is a list of people, not an answer.

The firm’s line is act fast, add simplicity faster — faster than the business adds complexity. That is a rate, not a one-off exercise. Drawn, the claim looks like this: unchecked, the coordination cost curve crosses revenue and everything past the crossing is value destruction; held, the cost curve flattens and the business stays profitable.

Holding that rate takes three different moves, and the whole trick is telling them apart. The test is coupling: what else depends on this. Complexity that is uncoupled and unprofitable is sediment — nothing leans on it, nobody chose it, and it can stop. Complexity that loses money but is attached to a relationship that makes money gets separated and re-costed, with a date to look at it again: stop it on its own numbers and the loss turns up two lines away, in the account it was quietly holding. What is left is load-bearing — it is the price of the customers you want — and it needs a structure built to carry it.

Most simplification programmes own only the first move. Stopping works cleanly at consumer volumes, where you can pull a part and see what breaks. In industrial business-to-business it is destructive testing you cannot afford, and the low-margin product is often the reason the high-margin customer calls first.

This paper is about the third move. When I need to explain which structures a business like this has to build, and in what order, I draw a temple. It is a metaphor, and I say so up front, because it has a seam a sharp reader will find. But the structure underneath it has proved more durable than the picture. Here is the picture, then the seam.

The numbers on the pillars are positions on the figure, not identifiers — I cite pillars by name.

The crown: what the structure is for

The figure was pillars-only for a long time, and it was a taxonomy of competences — six things a supply chain organisation should be good at. Useful, and inert. A list of competences does not tell you which one to build first, or why, or when to stop. The crown fixes that. It is the business outcome the structure exists to carry: the value creation plan, stated as a named set of changes with owners, dates and a worth. Once it is there, the pillars stop being a list and become load-bearing members. Any pillar that carries no load is a pillar that should not be there.

The plan gets written by the sponsor and the finance team, reads beautifully, and is unconnected to the operations that have to deliver it. Nobody owns Monday. Naming the crown first is how the rest of the figure gets its load.

The pillars, in the order the decisions get made

The six pillars used to be numbered in the order I wrote them, and the numbering kept coming back in documents years later as if it were an argument. It was not. The order that means something is the order the decisions actually arrive in, from what to sell through to what could go wrong.

Product strategy and portfolio. Decide what to sell, and why they will buy it. The working tool is a grade I learnt inside ITW: A and B customers against A and B products, four quadrants. A products for A customers are the fort — build the business around that quadrant and defend it. A B product attached to an A customer is a necessary evil; it is not the same object as a B product attached to nobody, and it gets priced and served accordingly. An A product sold to a B customer is a maybe. B products for B customers are a waste of time and resources, and that quadrant is where the sediment from the opening lives. A roadmap that is what engineering was going to build anyway is not a strategy; a roadmap that names the fort, and what gets stopped to defend it, is. This pillar is first because every other decision is downstream of it, and it is the one most often skipped in a company that grew up on projects rather than products.

Product definition and change control. Know exactly what you ship. The bill of materials is the control artifact; whoever owns it owns the product. Part numbers, drawing standards, tolerances, a change process that distinguishes a cosmetic tweak from an interface change. You cannot scale a product nobody has written down.

Manufacturing strategy and footprint. Decide where you build it — and how you can defend the decision. From product to factory, sequenced, so the answer survives the first change in volume. What to make and what to buy, and why, is decided here, along with the location model and its landed cost.

Sourcing, outsourcing and contract manufacturing. Decide who builds it, and whether the price is right. Outsource the operation; never outsource the knowledge of how the operation works. In a tight market the supplier chooses you, so this pillar is about earning allocation, not just negotiating price — and about owning the interface when you no longer own the drawings.

Scale-up. Congratulations, you won the order. Can you build it? Ramp readiness as an auditable gate, and an operating governance rhythm that survives a bad quarter.

Planning, visibility and risk. Find out in time. Plan before the crisis, not during it, and know your net exposure rather than your gross. This is the closing pillar rather than the middle one because it has two jobs: the planning that makes the forecast useful even though it is wrong, and the downside planning for when orders do not taper but fall off a cliff.

Read as a line they make an argument, not a list, and a client can place their own problem on it without being told where it goes. That is what the old numbering never did.

Where the picture stops being true

Two things, and I would rather say them than have them found. First, the seam. Real pillars are identical and interchangeable. These are sequential and different, and the band above them says so. A reader hunting for the flaw finds it in seconds. That is why the figure lives in conversation, and in a paper like this one where it is the subject and can be argued with — not on the pages where the work is offered, which write the same three layers out in plain words. Spoken, a metaphor is negotiable — the client frowns and you adjust. In print it has to survive alone. Speak the figure; write the plain statement.

Second, what is missing. There is no pillar for winning the order and none for the installed base. That is deliberate. The temple is a structure diagram: it answers what capability must exist. Order pursuit and after-sales service belong on the second drawing every business needs, the process map, which answers in what order the work happens. One has structure on its axis, the other has time. They are the same business drawn twice, and the mistake is to merge them. The order matters: draw how the work runs first, then map the systems onto it. Buy the system first and it will define the process by default, in the implementation, chosen by whoever configures it.

The foundation is the client’s, not mine

The stone the pillars stand on names five functions: HR, IP, Quality, IT and Finance. I am not any of those functions, and the figure should not be read as a claim to them. They are the functions a client already has and depends on, and naming them is an acknowledgment that the work stands on them and does not replace them. What I sell into that layer is narrower: building a function from scratch — procurement, quality, logistics — and getting the tools decision in the right order.

In 1998 I drew a process map as the introduction to a procedures manual for a business running an all-in-one system. Its supporting block listed personnel, patents and copyrights, quality management, information systems, and finance and administration. In 2026 I drew one for a client that had chosen best-in-class tools instead, and the unconnected boxes at the edge were HR, IT and the document and CAD archives. Five for five, twenty-eight years apart, arrived at independently.

The foundation is built in order: people first, tools last. That sounds like a contradiction — a foundation is what you pour first, and my standing advice is to buy the system last. It is not a contradiction once you separate the design from the purchase. The process architecture is the architect’s drawing; do that early. The ERP, PDM or PLM purchase can then safely come late, precisely because the drawing exists. Buying late is fine. Designing late is not.

Pillars are not methods

The figure is not a price list, and the two should not be confused. A pillar is a structure the business needs whether or not it hires anyone. A method is how a client buys help building one. A structure can carry several methods: planning, visibility and risk carries two, because the forecast and the downturn are different deliverables with different buyers. The mismatch in the counts is not a defect. The test is traceability in both directions: every method traces to a structure, and every structure has at least one method a client can buy. If a pillar has no method, either the method is missing or the pillar is decoration.

That is what the figure is for: not to be admired, but to be checked against. Which layer is the current problem in, which structure is missing or weak, and what does the crown say it is worth to fix. When a structure is missing, I build it with the client’s managers, so it stands up and runs on Monday without me.

That is the work I do.