Delivery transformation across 20+ product teams: time for 85% of initiatives down 64%

This case is not about implementing Kanban

At the beginning of 2025, the delivery system had limited visibility. Teams worked at different cadences, cross-team dependencies were managed manually, and goals often amounted to lists of scope. Metrics were either missing or remained reports that did not affect decisions.

To the business, technology looked like a black box. It was difficult to answer three basic questions: what is happening to an initiative now, where is the constraint, and when should we expect an outcome?

The natural response is to introduce more correct practices. We also started with Kanban and delivery rituals. That created a shared vocabulary, but quickly exposed a limitation: rituals do not create value by themselves. If they do not solve a real business problem, teams learn to perform a process while the system stays the same.

The pivot: from practices to business problems

In August 2025, we changed the problem statement. Instead of “implement processes,” the goal became “make technology manageable and useful to the business.”

The focus moved to specific constraints: low visibility of team work, unmanaged dependencies, no objective metric view, goals replaced by scope, long gaps between stages, and tightly coupled systems.

From that point, every practice became a hypothesis. A change needed a problem signal, a likely cause, an expected effect, and a way to verify it.

A shared unit of flow

Discussing delivery at business level required a unit larger than an individual task.

An RFC became an initiative — a change request and a unit for planning value flow. An Epic represented a deliverable part of that initiative. We measured two times for both:

• SLT, System Lead Time — from entering analysis to completion;
• LT, Lead Time — from being planned into todo to completion.

We tracked the median and the 85th percentile. The median shows a typical case; P85 shows the completion time for 85% of initiatives and exposes the longest cases.

Stage one: create a shared language

Five elements formed the foundation by late 2025.

Pulsar became the shared delivery-data layer. Basic boards, events, artefacts, and planning rules were aligned, making data comparable while teams kept the local differences they needed.

Goal conversations moved from “what are we going to do?” to “what outcome do we want?” A Team Maturity Model was used to find the next constraint rather than rank teams, with a development roadmap for each team.

At the same time, operational run processes started moving back to Tech Leads and teams. This freed Delivery Managers from dispatching work and created capacity for systemic change.

Stage two: use the data in management

In the first half of 2026, the baseline process was extended to most digital teams. Management attention shifted from task lists to Epic and RFC as real units of planning and value flow.

Dependencies became systematically visible, and manual Miro control was replaced by a more durable Structure-based view. Regular data-driven reports covered initiative status, goals, risks, a Tech Lead digest, and a dedicated dashboard for the CTO and leadership team.

An economic layer was added to RFCs: approximate cost, expected result, and a field for the actual effect. This was not yet a complete initiative P&L, but it connected delivery speed to business value.

What changed in the numbers

Compared with 2025, the flow became both faster and more productive:

• RFC SLT at P85 fell from 295 to 106 days — down 64.1%;
• RFC LT at P85 fell from 223 to 78 days — down 65%;
• median Epic SLT fell from 67 to 38 days — down 43.3%;
• Epic SLT at P85 fell from 145 to 112 days — down 22.8%;
• average RFC throughput rose from about 4 to 6.7 per month;
• average Epic throughput rose from 16 to 54 per month;
• Q2 plan completion reached 77% against an 80% goal.

Epic LT at P85 moved slightly up, from 98 to 101 days. We kept it in the case because metrics should reveal the next constraint even when it weakens the success story.

The P85 reduction means fewer initiatives remain stuck for an unpredictable length of time. Delivery became more predictable as well as faster on average.

How the Delivery Manager role changed

In 2025, Delivery Managers mostly introduced practices because they were considered correct. By the first half of 2026, the role had shifted toward decisions based on real business problems and metric behaviour.

The Delivery Manager moved from process executor to owner of change in the delivery system. Run processes gradually moved to teams, while the DM focused on the next systemic constraint.

The next constraint is further left

Once delivery inside technology improved, it became clear that development practices alone could not produce the next acceleration. The next work sits before an initiative enters delivery:

1. make prioritisation and initiative expectations more explicit;
2. improve the expected-outcome estimate before work starts;
3. improve business processes that affect total Lead Time;
4. run fast, inexpensive tests before committing to large RFCs;
5. move ownership of stable team processes to Tech Leads;
6. shift Delivery Management attention from development to the full business-function flow.

The central lesson is that delivery maturity inside technology is necessary but not sufficient. Faster value flow requires changes in prioritisation, RFC formation, dependency management, and business decision speed.