§ CAPABILITY

Technical Program Management

One accountable owner across work that spans several teams and more than one quarter. Migrations, replatforms, compliance programmes — the shape where every team is doing its part and the whole is still late.

Who
Led by the founder, hands-on for the duration.
Request a call How the work runs

What you're seeing

Every team is delivering its part and the whole is still late.
Usually means The risk lives between the teams and nobody owns it. This is the defining symptom — individual accuracy and collective failure are entirely compatible when nothing spans the gaps.
The old system and the new one have both been running for longer than planned.
Usually means The parallel-running window is the largest hidden cost in any migration, and it extends by default because ending it requires a decision nobody is accountable for making.
A cutover was attempted and rolled back, and nobody has proposed a second date.
Usually means There was no staged plan, so cutover was one large irreversible event. After it fails once, the appetite to try again does not return without a different shape.
Leadership asks how the migration is going and gets a Jira board.
Usually means There is no reporting aimed at the people funding it. A backlog is not a progress report, and asking a board to read one is how programmes lose their funding at the worst moment.

Where programmes are actually lost

Not inside a team. At the seams.

The interface neither side considered theirs. The shared table two teams altered in the same sprint. The cutover that assumed a dependency had already landed because the roadmap said it would have. The data migration that was somebody’s task in one team’s backlog and a precondition in another’s.

Every one of those is invisible from inside a single team’s plan, which is why a programme where every team reports on track can be a quarter behind. Ownership of the seams is the substance of this role, and it cannot be delegated back into the teams because by construction it belongs to none of them.

Parallel running is the cost

In any migration the expensive line is how long the old and the new have to be maintained together.

While both are live, every change is made twice, every bug is reproduced twice, the operational surface is doubled, and the team’s attention is split. It is rarely on anyone’s budget because it is not a project cost — it is an absorbed one, paid out of delivery capacity that would otherwise have gone somewhere else.

Sequencing is mostly the work of making that window short. That order is frequently not the one any individual team would choose, which is why it needs an owner with the standing to hold it.

Staged, with a way back

A single irreversible cutover is a bet placed on one evening.

The failure rate for that shape is not low, and the second-order cost is worse than the first: after a failed cutover the organisation loses its appetite to schedule another, and the programme stalls for a quarter while confidence is rebuilt. Meanwhile the parallel-running window keeps costing.

Staging it — by tenant, by traffic share, by capability, whatever the system allows — converts one large risk into a series of small ones, each with a rollback position. It costs more engineering and it is the difference between a programme that finishes and one that becomes permanent.

Where it sits

This capability sits inside Delivery Implementation, which is itself a multi-quarter programme across process, hiring, compliance and platform, and is where this role most often appears.

It works with three neighbours. Delivery Management owns an individual commitment inside the programme; this owns the whole and the order. Team Topology & Org Design is frequently what the seam analysis points at — a seam that keeps failing is usually a boundary drawn in the wrong place. And Architecture Review is what establishes whether the target state is sound before several quarters are committed to reaching it.

How the work runs

  1. Define the end state and how it is recognised

    In terms someone outside engineering can check. A programme without an agreed finish line runs until the budget decides.

  2. Sequence the work across teams

    The order that minimises how long two systems have to be maintained in parallel, which is usually the largest hidden cost in a migration.

  3. Own the cross-team seams

    The interfaces, the shared data, the cutover moments. Individual teams reliably deliver their own part; the seams are where programmes are lost.

  4. Report to the people funding it

    Progress against the end state, spend against plan, and the decisions being asked for — in the language of the board rather than of the backlog.

What arrives

  • A written end state with acceptance criteria anyone can check
  • A cross-team sequence with the parallel-running window costed
  • A staged cutover plan with a rollback position at each stage
  • A monthly report aimed at whoever is funding the programme

What it costs your team

A kickoff workshop, then around three hours a week from each participating team's lead.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • The end state is written in terms someone outside engineering can check

    Costs Agreeing it takes weeks and surfaces disagreements that were comfortable while unstated.

    A programme without an agreed finish line runs until the budget decides, and then it stops halfway with both systems still live. Acceptance criteria a non-engineer can verify are what make completion a fact rather than an opinion — and writing them is what reveals that two stakeholders had different programmes in mind.

  • Sequencing optimises for a short parallel-running window

    Costs It is often not the order any individual team would choose for itself.

    In a migration the dominant cost is how long the old and the new have to be maintained together — double the operational surface, every change made twice, and every bug reproduced in two places. Local optimality per team reliably lengthens that window. Somebody has to own the global order and defend it.

  • Cutover is staged, with a rollback position at each stage

    Costs It is more engineering work than a single switch, and it extends the calendar.

    A single irreversible cutover is a bet placed on a night. When it fails — and the failure rate is not low — the organisation loses the appetite to try again, and the programme stalls for a quarter while a new plan is built. Stages that can each be reversed convert one large risk into several small ones.

Frequently Asked Questions

Owning a piece of work that spans several teams and more than one quarter — a migration, a replatform, a compliance programme, an acquisition being integrated. The distinguishing feature is that the risk sits between the teams rather than inside any one of them, so the job is sequencing, seams and cutover rather than task management.
Scope and where the risk lives. A project has one team and one deliverable, and its risks are internal to it. A programme has several teams over several quarters, and almost everything that goes wrong goes wrong at the interfaces. Different work, and the second one cannot be done by adding up the first.
Platform migrations, replatforms, a compliance programme touching every service, an acquisition being integrated into an existing stack. The reliable signal is that every team reports on track and the whole is behind, which means the problem is in the seams.
No. Scaled-agile frameworks bring a large amount of ceremony and their evidence base is contested, and importing one is usually a way to avoid designing the coordination this specific programme needs. Where you already run SAFe, we work inside it rather than arguing about it — the framework is rarely the binding constraint either way.
Until the end state is met, and the reporting is built so someone internal can take it over sooner than that. An open-ended programme role is usually a sign that the end state was never agreed, which is a problem to fix rather than a schedule to accept.

Sources

Page reviewed