A 900-person engineering organisation funds work as 9-month projects. A project receives a budget and a team drawn from a resourcing pool; both dissolve at go-live. Run costs land on a central operations group of 30 people who support about 140 services. The CTO wants durable product teams that own their services in production. Sequence this change over four quarters without stopping delivery.

The sequence

The common failure is reorganising first. The funding model, not the org chart, is what makes project teams dissolve, so it moves first or the new teams dissolve too.

1. Quarter 1, change one budget line. Create a standing run allocation — typically 15% to 25% of engineering capacity — funded from the operations group's existing budget rather than from new money. Nothing reorganises. Reversible: cancel the allocation.
2. Quarter 1, pick three services with real ownership gaps. Choose ones whose incidents the operations group cannot resolve without calling a project alumnus. Those services already prove the model's necessity. Reversible: hand them back.
3. Quarter 2, move the pager with the budget. The three teams take out-of-hours responsibility and the run allocation that pays for it. A team given the pager without the capacity is being punished, not empowered, and that is the single most common way this migration dies. Reversible: operations group resumes the rota.
4. Quarter 2 to 3, change the planning unit. Fund the team for a period, not the project for a scope. Each team gets a durable budget with a stated outcome and the right to decline work that does not fit. This is the step that makes the change real and the step finance resists.
5. Quarter 3 to 4, shrink the operations group deliberately. Its 30 people know the production estate, so move them into product teams as the operational skill those teams lack rather than treating them as a cost to remove.
6. Quarter 4, retire the resourcing pool for new work. New initiatives go to existing teams or justify a new permanent team.

Where it can diverge, and how you would know

Watch three numbers monthly, per team:

• Unplanned work as a share of capacity. Rising past 30% means the run allocation is too small and the team is about to stop shipping.
• Services with no named owner. With 140 services and roughly 30 teams, the arithmetic is 4 to 5 services each. The orphan count is the migration's true progress measure — adoption of the new structure means nothing while 40 services sit unowned.
• Out-of-hours pages per on-call shift. If this rises above two for any team, that team is about to lose someone, and the migration will be blamed.

The point of no return

Step 4. Once teams are funded for a period rather than a scope, the resourcing pool has no work to allocate and the project-management function has no object to manage. Before step 4 everything can be unwound in a planning cycle. After it, reversing means re-creating a pool from people now embedded in teams, which in practice does not happen.

The rollback at each stage

Steps 1 to 3 roll back inside one quarter. Step 5 is partially reversible: a central operations group can be re-formed, but the people who left it will not all return. Step 6 is not a rollback point so much as a declaration, and should be made only after two quarters of the numbers above holding.

How long it really takes

Four quarters gets the structure and the funding. Behaviour takes two to three years, because the organisation's promotion criteria, hiring profiles and vendor contracts were all written for project delivery. Expect at least one high-profile initiative to demand a temporary project team: grant it, name it as an exception with an end date, and do not re-open the model.

When this is the wrong answer

When the work genuinely is project-shaped: a regulatory programme with a fixed end state, or a one-off data-centre exit. Durable teams are the right default for systems that keep living, and overhead for work that genuinely finishes. An organisation whose portfolio is mostly the latter should fix the run-ownership gap directly rather than restructure around a model it does not need.