Mid-market product company — modernization that had stalled

The client was a mid-market product company with roughly 1,180 engineers, working on a platform that had been built over the previous twelve years. They had been acquired by a private equity firm two years before the engagement, and a platform modernisation had been one of the post-acquisition commitments to the board.

Two years in, the modernisation was visibly behind. The original plan was to migrate the core platform off a legacy stack onto a more modern services architecture across thirty-one workstreams. Seven had completed. Nine more were "in flight," meaning they had started, had teams assigned, but hadn't shipped meaningful changes in months. The rest hadn't been started yet.

The CTO had taken the role eight months earlier, brought in by the PE firm specifically to address the stalled programme. He'd spent the first six months understanding the situation. By the time he reached out, his diagnosis was fairly settled: the workstreams that had completed were the ones with clear ownership and limited cross-team dependencies. The workstreams that had stalled all sat at boundaries between teams that had been organisationally consolidated under the platform group but were operationally still running as separate fiefdoms.

The CTO didn't want a strategy. He wanted help running two of the stalled workstreams to completion as a model for the rest, while the underlying process changes that would unstick the others were worked out alongside.

Three weeks of baseline work, focused on the two specific workstreams the CTO had picked and the broader process patterns surrounding them.

Pass 1 — Workstream archaeology. We mapped each of the two stalled workstreams in detail: original scope, what had been delivered, what was still open, where the dependencies were, and most importantly where the work had actually stopped and what reason had been given internally for the stop. In both, the work had stopped at a point where ownership was unclear. Workstream A's data layer migration had been assumed by the original plan to belong to the data engineering team; the data engineering team had assumed it belonged to the platform team that originally built the legacy data layer. Neither side said no, neither picked it up, and the workstream had sat at that boundary for 11 months. Workstream B was stuck on a contract redesign between two services, with each side wanting the other to redesign their half first — that one had been parked for 7 months.

Coordination patterns across the modernization. We sat in on the modernisation steering meeting (weekly, attended by leads from twelve teams) for three weeks and mapped what was actually happening: decisions reached or deferred, hand-offs initiated, blockers raised and resolved. The meeting had become largely a status-reporting forum. Decisions that needed cross-team alignment were typically deferred to "follow-up offline" conversations that rarely happened, or happened weeks later when the moment had passed. It had been set up to coordinate the modernisation; by the time we sat in on it, modernisation issues were briefly mentioned and then quietly parked.

A third pass pulled time-tracking and ticket data for the two workstreams, producing an estimate of how much engineering time had been spent on each since stalling, and on what. Each workstream had consumed roughly 8–12 person-months of engineering time over the period it had been stalled, almost entirely on planning, re-planning, dependency discussions, and documentation. Effective implementation work in that window was close to zero.

The engagement ran on two fronts for six months: embedded delivery on the two stalled workstreams, plus a separate set of process changes around the broader modernisation.

Workstream A. We worked with the platform team and the data engineering team to redraw the ownership boundary on the stalled work. The CTO authorised the decision: the data layer migration would be owned by a small dedicated team made up of members from both groups, accountable directly to the platform engineering director for the duration of the migration. Ownership would revert to the data engineering team after completion.

A principal embedded with that team for the four months of the migration. The actual work was standard platform engineering — schema migration, dual-write patterns, then gradual cutover with monitoring. The block had never been engineering complexity; it was the ownership question.

Workstream B. Similar shape. We ran a focused contract-redesign workshop between the two services involved (three days, both engineering teams, the two engineering directors, the principal architect). The output was a written contract specification both sides agreed to, plus a delivery plan with explicit ownership for each side of the change. A principal embedded with the two implementing teams for the three months that followed. Standard contract migration work — versioned APIs, dual-running, gradual cutover. Here the negotiation had been the bottleneck rather than the implementation.

Alongside the embedded work, three process changes around the broader modernisation were proposed and adopted by the CTO over the course of the engagement.

The first restructured the modernisation steering meeting. Status reporting moved to a written async channel updated weekly. The meeting itself was repurposed as a decision forum with a clear input-output discipline: issues arriving at the meeting needed a proposed decision, not just a problem statement. Issues that left the meeting without a decision were assigned to a named owner with a deadline.

The second made workstream ownership at boundaries explicit in the modernisation tracker. Every workstream now had a named primary owner accountable for its completion, even when the work crossed team boundaries. Where the primary owner was unclear, the platform engineering director made the call rather than leaving it ambiguous.

The third was simpler: a handful of workstreams that were no longer the right work got formally cancelled. Three of the in-flight workstreams had been started under assumptions that had since changed. Closing them out and redirecting the people freed up two senior engineers and took some load off the steering meeting.

After six months:

Workstream A. Completed and live in production. The migration ran from April through August on the agreed plan and shipped within two weeks of the target date.

Workstream B. Completed and live in production. Contract migration completed three weeks after the target date, with one delay we'd flagged but underestimated, on a separate dependency.

Broader modernisation throughput. Of the nine in-flight workstreams, three completed during the engagement: the two we ran, plus one that got unblocked by the process changes. Three more had cleared their previously-stuck boundaries and were progressing on agreed plans by the time the engagement ended. Two were re-scoped or cancelled.

Steering meeting effectiveness. The CTO's qualitative read at the end: decisions that had previously taken three weeks to surface, debate, and resolve were typically getting resolved within a week of being raised. The number of workstreams blocked on cross-team coordination dropped from 9 to 2.

The two completed workstreams were both held up internally as templates for the remaining modernisation work. The platform engineering director went on to use the same ownership pattern (small dedicated team, explicit primary owner, time-bounded scope) for the next three workstreams that started after the engagement ended.

The engagement did not address:

• The remaining fifteen workstreams of the modernisation, beyond the process changes that affected all of them
• The product engineering organisation's day-to-day roadmap, which ran independently
• The platform's longer-term architecture decisions, which were the province of the principal architect and the CTO

The two workstreams we ran were picked specifically because they were representative of the broader pattern. The engagement scope was built around the assumption that the patterns demonstrated on those two would be applied to the rest by the client team — which is what happened.

The engagement shape in this study tends to work for organisations where a programme has visibly stalled at coordination boundaries rather than at engineering complexity. If the answer to "where does the work stop?" looks more like "at the seam between two teams" than "in the middle of a hard implementation," process re-engineering is usually the better-targeted intervention.

If that pattern sounds familiar, the first step is a half-hour call about the specific programme.