Technical Program Management

From one migration to a 28-project portfolio

At LSEG, my initial responsibility was the migration of the US Municipal Market Manager, a roughly 30-year-old market-data product, from a legacy Refinitiv environment to the LSEG Data Platform on AWS.

This was not a clean replacement project.

The existing product still needed to operate. Data had to move safely. New platform capabilities were incomplete in places. Engineering capacity had to be split between migration, KTLO, technical debt and production support. Architecture decisions affected several teams outside the immediate programme.

The job therefore became less about following a migration plan and more about continually translating technical reality into an executable programme.

Turning architecture into delivery

When a technical decision was made, I worked through what it meant operationally:

• Which teams now depended on each other?
• What had to be available before another workstream could start?
• Which solution was an acceptable interim step and which represented the target architecture?
• What technical debt were we deliberately accepting?
• Which risks needed an engineering solution and which required a business decision?
• What constituted sufficient readiness for go-live?
• Who would own each service once the migration was complete?

One example was the use of existing services on AWS Lambda. Rewriting everything into an ideal target architecture would have jeopardised the delivery boundary, so the existing services were migrated with additional testing while the later rewrite was explicitly retained as technical debt.

The important part was not simply choosing a compromise. It was making the compromise visible: why it was acceptable now, what risk remained, who owned it and how it affected the future roadmap.

Responsibility grew with the problem

The migration completed within the approved budget constraints, but the more important career outcome was that the scope expanded.

I moved from responsibility for one migration into recovery and governance across a much wider portfolio, eventually reaching 28 concurrent projects across 22 stakeholder groups.

That progression changed the nature of the job.

At the level of one project, a dependency is something you track.

Across dozens of initiatives, dependencies become a system-design problem of their own: ownership, decision rights, escalation paths, sequencing and information quality determine whether the portfolio can move at all.

Recovering a RED portfolio

When I took broader governance responsibility at LSEG, 18 initiatives were in RED status.

They were not failing for one common reason.

Some had unclear ownership. Others had unresolved cross-team dependencies, blockers that had remained open too long, weak escalation paths or stakeholders working from different interpretations of the same decision.

Trying to solve this with more status reporting would only have created more reporting.

Instead, I focused on the operating system around the programmes.

Make ownership explicit

A surprising amount of programme friction comes from work that is important but not clearly owned.

I made decision ownership, workstream ownership and escalation responsibility explicit. Where services crossed organisational boundaries, we carried ownership questions into the governance process rather than allowing them to remain implicit.

Make dependencies visible

Dependencies were treated as programme objects, not footnotes in individual project plans.

That meant identifying the upstream and downstream consequence, accountable teams, required dates, decision points and what would happen if the dependency moved.

Escalate decisions, not raw problems

Senior stakeholders do not need another list of issues.

They need to understand:

What happened → why it matters → what the alternatives are → what each alternative costs → who needs to decide.

I used concise visual material, delivery and financial evidence, mitigation options and explicit decision records to make those choices easier to resolve.

Establish a common operating cadence

The goal was not more governance. It was enough governance to create predictable decision-making.

Common programme-health reviews, named owners, risk and dependency mechanisms, decision records and clear escalation routes replaced much of the fragmented project-by-project interpretation.

The result was that 17 of the 18 RED initiatives moved to GREEN.

The metric matters, but the reusable lesson matters more:

Programme recovery usually starts by repairing ownership, dependencies and decision mechanisms before it starts by repairing the schedule.

How I run a technical programme

Different programmes require different processes, but the underlying sequence is remarkably consistent.

1. Start with the outcome

Before creating a roadmap, I want to know what must actually change.

A platform migration, for example, is not finished because workloads have moved. It may need to reduce support complexity, improve accessibility, enable common operations or create a stable base for future development.

The outcome determines what should be measured.

2. Understand the system and constraints

I work closely enough with engineers and architects to understand system boundaries, interfaces, data flows, deployment constraints, failure modes and important architectural trade-offs.

I do not try to replace Engineering's design authority.

My job is to understand the technology deeply enough to recognise which decisions affect the programme and to make their delivery consequences explicit.

3. Convert architecture into an executable roadmap

Architecture diagrams do not execute themselves.

They need to become:

workstreams → milestones → dependencies → owners → decision points → readiness criteria

This is where much of TPM value is created.

4. Make risk actionable

A risk register that simply records risks is not particularly useful.

For material risks I want to know:

• what signal tells us the risk is becoming real;
• who owns mitigation;
• what decision will be needed;
• what the latest responsible decision point is;
• what fallback exists if the preferred path fails.

5. Treat launch as a decision

Go-live is a technical and business decision, not merely the date at the end of a plan.

I use explicit readiness criteria across Engineering, QA, DevOps, Product, support and business stakeholders so that the discussion becomes about evidence and accepted risk rather than optimism.

6. Keep ownership through stabilisation

I do not treat production deployment as the end of a programme.

After the LSEG migration, production incidents fell from approximately weekly to two over the following six months as testing, release controls, observability, ownership clarity and support/engineering coordination improved.

Production behaviour is one of the best tests of whether the programme actually delivered its intended result.

Technical judgement without pretending to be the architect

A TPM needs enough technical depth to challenge assumptions without creating confusion over engineering ownership.

An example came at Refinitiv.

The existing environment relied heavily on synchronous SOAP/REST integrations in a shared, tightly coupled ecosystem. Changes by one engineering team could affect many others, and I was coordinating dependencies across as many as 18 engineering teams working within fixed release cycles.

The programme moved toward asynchronous AWS messaging and event-driven integration.

Rather than accepting the architectural direction only on theory, we used a dedicated prototype project to validate it before broader production rollout.

My role sat between architecture and execution:

• understand the implications of synchronous versus asynchronous integration;
• participate in AWS/GCP option analysis;
• turn the selected architecture into sequencing and dependency decisions;
• coordinate release readiness across teams;
• follow the solution through deployment and operational/TCO assessment.

The outcome was greater service decoupling and release independence.

That is the kind of technical involvement I expect from a TPM: not claiming to be the strongest implementation engineer in the room, but being technically credible enough to connect architecture decisions with programme consequences.

Programme intelligence instead of status administration

As programme scope increased at LSEG, another problem became obvious: the information needed for decisions was distributed across different systems.

Delivery, resource, budget and risk information existed, but assembling it repeatedly was manual and made it harder to see the portfolio as a whole.

I built an internal TypeScript/JavaScript delivery-intelligence solution that combined information from sources including Clarity PPM and programme data through APIs and exports.

It reduced recurring manual reporting effort by approximately 80%.

The more important benefit was not the automation itself.

It changed the conversation from:

“Can everybody update their status?”

to:

“What does the combined evidence tell us, and what decision needs to be made?”

I think of this as programme intelligence: using data, operating mechanisms and concise communication to improve the quality and speed of programme decisions.

Scale is useful only when it creates better judgement

The largest organisation I led was at Deutsche Bank: 108 FTE across seven projects, including 26 first-line HR reports and a wider organisation led through Project Managers and Engineering/QA Leads.

That experience taught me something important about scale.

Larger programmes do not become manageable by creating proportionally more coordination.

They become manageable by designing better interfaces between teams:

• clear ownership;
• useful management layers;
• common information;
• explicit dependencies;
• predictable decision mechanisms;
• delegation at the right level;
• escalation only when authority genuinely needs to move upward.

The same principle applies whether the dependency network contains seven projects or eighteen engineering teams.

Why current engineering still matters to my TPM work

My current work includes production engineering in Java/Spring and TypeScript/JavaScript, architecture, APIs and integrations, automated testing, CI/CD, database performance work, production support and AI-assisted development.

I do not expect a TPM to be the primary implementation engineer.

But staying close to real software changes the quality of programme conversations.

It makes it easier to recognise:

• when an estimate hides an architectural assumption;
• when a “small change” crosses a system boundary;
• when technical debt is genuinely acceptable;
• when testing is insufficient for the production risk;
• when an incident points to an ownership problem rather than only a code problem;
• when AI-assisted development accelerates implementation but does not remove the need for validation and engineering accountability.

That technical currency is one of the reasons I describe my profile as a technically fluent Technical Program Manager, rather than a generic programme manager.

Where I add the most value

My strongest programmes tend to have several of these characteristics:

The operating principle

The programme should have enough structure that everyone knows:

what outcome matters, what has to happen next, what depends on what, who owns each decision, what risk is being accepted and how we will know whether the result worked.

Everything else is supporting machinery.