Part III — Cultivating Organizational Flow · Chapter 50 · 6 min read · First Public Draft

Funding

Funding What Doesn't End

The project is a funding decision with a dissolution date attached, and the dissolution date is where most of the trouble lives.

Reduces frictionCreates valueOwnership clarity

The project closed on a Friday. There was a slide with a green square on it, a short round of thanks, and a cake that somebody had clearly bought on the way in. By the following Wednesday the people who built the thing were spread across four other initiatives.

About seven months later a question came back. Had it worked — the thing we spent a year and a good deal of money on, had it actually changed anything for the people it was built for?

Nobody could say. Not because anyone was hiding, and not because the answer was bad. There was simply no longer anyone whose job it was to know. The team that would have noticed had been dissolved on schedule, which is what teams are supposed to do when a project ends. Everyone had followed the process exactly.

I have watched that closing Friday a lot of times, and what is worth noticing is that the process was working perfectly and producing the outcome anyway.

What a project actually bundles

We use the word project for something quite specific: a scope, a budget, a group of people, and an end date, tied together and approved as one decision. That bundle is useful. It makes work legible to finance, it gives someone something to report on, and it lets an organization say yes to one thing rather than to everything.

It also decides, at the moment of approval, that this will stop. And once you look at the bundle as a piece of structure rather than as an administrative wrapper, it is doing a great deal more than accounting.

A project draws a boundary around itself, because that is what a scope is. Everything outside the boundary now has to be reached across, which is the definition of a handover. It stands up a steering group, because a boundary needs somewhere for decisions that cross it to go, and that forum meets monthly, which sets the pace of every question that reaches it. It appoints an owner whose ownership expires. And it names a moment called done, which occurs before anyone outside the organization has had a chance to react to what was built.

That is not an unfortunate side effect of projects. That is what a project is. The Introduction says a transformation programme manufactures friction while it runs; this is the same observation at a smaller scale, and it applies to a €200,000 initiative as neatly as it applies to a three-year programme.

The part that is harder to see

The handovers and the steering group are visible enough that people complain about them. The dissolution date is the expensive one, and almost nobody complains about it, because it looks like tidiness.

Value arrives late. That is not a failure of anyone’s planning — it is a property of the thing. People have to adopt something, get used to it, work out what it is actually good for, and change what they do. Six months is quick. A year is normal.

Projects end before that. So the moment where the answer becomes available is, reliably, several months after the last person who cared about the question was reassigned. The organization does not decide to skip learning. It funds a structure that makes learning arrive at an empty room.

And because nothing contradicted anyone, the next initiative gets chosen the same way, by the same people, with the same confidence.

The other unit

The alternative is not complicated, which is part of why it is hard. You fund a team, for a period, against an outcome, and you let the work come to the team instead of assembling a team around the work.

The team persists. It carries the context rather than documenting it, so the handovers that a project needs simply are not there to be paid for. It is still around when the outcome shows up, which means somebody can be asked and can answer. And because it has no end date to sprint toward, the question of whether the current work is still worth doing is one it is allowed to raise, which is the question a project is structurally incapable of asking about itself.

This is well-trodden ground outside this paper — it is roughly what product organizations mean by a product team, and roughly what Team Topologies means by a long-lived stream-aligned team. I have nothing to add to either description. What I would add is that most of the benefit shows up as friction that stopped happening, which makes it very difficult to point at in a business case.

If you want to see the size of it in your own organization, pick something delivered eighteen months ago and try to find the person who can tell you what it changed. Not what was delivered — what changed. How long that takes, and how many people you have to go through, is the measurement.

Where this gets applied badly

Some work genuinely ends. A data centre migration ends. A regulatory deadline ends. Merging two payroll systems ends. Running those as projects is correct, and an organization that has decided everything is a product will eventually make a mess of the things that were finite all along.

The test is not whether the work has an end. It is whether the outcome has one. Nobody keeps asking whether the payroll merge is still delivering value; the value was a working payroll system and it either works or it doesn’t. But a customer portal, a claims process, a service anybody uses more than once — those have outcomes that keep going, and if the team ends while the outcome carries on, the outcome is now nobody’s.

The other failure is renaming. An organization keeps annual funding rounds, keeps the scope-shaped approval, keeps the completion report, and calls the result a product team. Nothing has changed except the noun. The team still has a fixed scope, still has to go to a forum for anything outside it, and still gets rearranged at the end of the year. Whether the change is real is decided in the funding model, not in the org chart, and the funding model is owned by people who mostly do not read papers about architecture.

What it costs to do properly

A durable team has no end date to point at, which makes it look, on a spreadsheet, like a permanent cost with no defined return. A project looks like a bounded one. That comparison is wrong in a way that is genuinely difficult to argue against in a budget meeting, because the project’s boundedness is exactly the thing producing the loss, and the loss is invisible.

I have not found a clever way around this. The version that has worked is unglamorous: keep one team standing for two funding periods, be strict about asking what changed at the end of each, and let the answers be the argument. The first period produces very little worth showing. The second is usually where somebody senior notices that this is the only part of the organization that can answer the question.

This cultivates: What Survives the Reorg, in Part II.