The Fox proposed the reorganization himself, which nobody had expected, least of all the Crow.

What he proposed was that his own function should get smaller. The delivery teams he had built up over two years, one per major initiative, each with its own engineers and its own roadmap and its own relationship with a territory, should be collapsed into a single platform group and a much smaller product function. His headcount would fall. His direct reports would fall. The number of things with his name on them would fall considerably.

It was the correct proposal and it was against his own interests in every visible dimension, which is a rare enough combination in an enterprise that the room did not immediately know what to do with it.

The Mandrill did something equally unusual. He did not oppose it politically. He opposed it honestly.

“This makes my costs less controllable,” he said. “Right now if I want something I fund it and I get it. Under this, I join a queue that someone else prioritizes. I understand why it is cheaper for the jungle. I want to be clear that it is worse for me, and I would like that acknowledged rather than explained away.”

Which was fair, and true, and the reason most of these transitions fail. The saving is organizational. The cost is local, immediate, and lands on people who are not being consulted so much as informed.

The distinction, precisely

A project has a scope, an end date and a benefits case. It is funded to complete something, it is staffed for a period, and it is disbanded on delivery. Enterprises are extremely good at this. Everything from the approval process to the reporting to the career structure is built around it.

A capability has an owner, a roadmap and a persistent budget. It serves many consumers over time, it is never finished, and its whole value comes from continuing to exist. Enterprises are structurally hostile to this, not out of stupidity but because every mechanism they have for allocating money assumes an end date.

Almost every organization I have worked with says it is building capabilities. Most are running projects with a longer name. The test is one question: is there a budget line that continues next year without anybody submitting a case for it? If not, you have a project with optimistic language attached.

Where the saving actually comes from

Four sources, and the fourth is the one nobody mentions.

Fixed costs paid once. This is the Lesson 5 arithmetic with a solution attached. The setup tax that every pilot paid separately gets paid once by the platform and amortized across everything that uses it.

Learning that compounds. The same team sees the twentieth use case, and by then it knows which patterns fail, which integrations are painful, and what to say no to. That knowledge exists nowhere in a project model, because the team that learned it was disbanded.

A curve that bends. The marginal cost of use case number twenty is a fraction of use case number four, because the foundation is already there. This is the entire economic argument and it is the one thing a project portfolio can never produce.

Retirement becomes possible. A capability can stop serving a use case without anyone losing their job. In a project model, killing the project kills the team, which means nothing ever gets killed. This turns out to matter enormously and it is the subject of Lesson 22.

Three layers, and the one everyone skips

Platform. The shared technical foundation. The gateway, retrieval, evaluation, guardrails, the operational team. Most organizations build this, and build it competently.

Product. The interfaces, patterns, documentation and support that make the platform usable by people who did not build it. Most organizations skip this, and then are surprised when territories describe the platform as unusable and quietly build their own.

Portfolio. Deciding which use cases get served, in what order, and which do not get served at all. Almost nobody builds this, and it is the layer that produces the saving.

The portfolio layer is where somebody has to say no. In a project model nobody has the standing to, because every initiative has its own approval and its own sponsor and there is no forum where two of them are compared. Consolidate the delivery and skip the portfolio function, and you get a platform that serves every request anyone makes, growing without limit, which is the same cost problem as before with an extra governance layer on top.

The eighteen month problem

Say this out loud, in month one, to the most senior person in the room.

Capability-led is cheaper at scale and more expensive for roughly the first eighteen months. You are building shared foundations before there is enough consumption to amortize them. You are absorbing a transition. You are running the old thing and the new thing simultaneously for at least two quarters, because you cannot switch a live estate over on a date.

Programs that promise immediate savings from this shift get killed in month nine, when the curve is at its worst and the promised improvement has not arrived. It has not arrived because it was never going to arrive that early, and everybody knew that except the person who wrote the business case.

The Crow’s view on this, which I thought was exactly right: “I can defend a curve that gets worse before it gets better. I cannot defend a curve that was supposed to get better immediately and did not, because by then nobody believes the rest of the model either.”

The accountability trade

The Mandrill’s objection has to be answered, not managed, and the answer is an exchange rather than a reassurance.

Territories give up control over how. They no longer choose their own stack, their own model, their own patterns. That is a real loss of autonomy and it should be named as one.

In exchange they get three things, and all three have to be real. A service commitment with actual numbers in it, so the queue has a defined shape. A published roadmap, so they can plan around what is coming. And a seat at the portfolio table with genuine influence over sequencing.

Without the exchange, this reads as centralization dressed up as efficiency, and it gets resisted, correctly, by people who have seen centralization before. With the exchange, it is a trade that reasonable people accept, and the Mandrill accepted it in the following quarter once the service commitment had numbers rather than adjectives in it.

Three ways this goes wrong

Platform without product. Technically excellent, genuinely well engineered, unusable by anyone who did not build it. Adoption stalls, territories rebuild their own, and you now pay for the platform and the duplication.

Capability as a renamed project. Same annual funding cycle, same end date, same approval process, new word on the slide. This is the most common outcome and it is completely invisible from the outside for about a year.

No portfolio function. The capability serves everything anyone asks for, because nobody has the authority to refuse, and the cost curve does not bend because the demand curve has no ceiling.

The Field Kit

Concrete things to do this week.

If you sit in the Crow’s chair, fund the capability rather than the use case, and state the eighteen month curve to the board in month one. The honest version of the shape is the only version that survives month nine.

If you sit in the Crocodile’s chair, build the product layer alongside the platform, not after it. Adoption is the business case, and adoption is an interface problem long before it is a capability problem.

If you sit in the Mandrill’s chair, trade control of the how for a service commitment with numbers in it and a real seat at the portfolio table. Then hold both to account. The trade is fair if the other side is real and worthless if it is not.

For everyone: name the portfolio owner. If nobody in your organization can say no to an AI use case and be listened to, you have built a more expensive version of what you already had.

Jungle Lesson 16

A project is funded to end and a capability is funded to continue, and only one of them gets cheaper the twentieth time you use it. Everyone claims to be building capabilities and most are running projects with a longer name, which you can test in one question: who is allowed to say no, and does anybody listen when they do.

Next time: budget season arrives for the second time, and the Watering Hole question that has been open since Lesson 7 finally gets settled, by the last animal anyone expected to propose the answer. The Sloth’s framework arrives, and for once it is exactly on time. Lesson 17 is about persistent funding and quarterly reallocation.

The proposal in this piece exists because somebody was willing to argue for a structure that made their own function smaller. That is rarer than any framework and no amount of methodology substitutes for it.