How to redesign a broken delivery flow

Estimated reading time: 7 minutes

Key takeaways:

• To fix a broken delivery flow, you first have to make the invisible queueing between steps visible.
• Digital boards hide waiting time instead of exposing it. “In progress” looks the same whether a task is moving or stuck in a handoff gap.
• Redesigning a broken delivery flow only lasts if the team learns to see and own it themselves, not if it’s handed to them by an outside fix.

---

A broken delivery flow rarely looks broken from the inside. One application spent more than a year moving through a deployment pipeline. The team that ran the pipeline did not know that. There was a feeling that it was slow, but nobody had put a number on it.

It was a platform team at a large enterprise. Their job was to help product teams ship applications into a cloud environment. The path to production was all about security, infrastructure, and validation. Leadership suspected the process dragged on even if no one had measured how far.

I ran delivery diagnostics in many sectors. I saw the pattern repeat so often: the work is usually fast, the waiting, which is where the time goes, stays invisible.

So I started with two questions: How do the people who use this process feel about it?  Where, exactly, does an application spend its time?

Nobody had a number

I interviewed the platform team’s internal clients, product owners, and tech leads across several product teams. I asked each of them to score their satisfaction with the service, then to tell me why they picked that number.

The score came back in the low single digits out of ten. The comments were sharp. “I had no roadmap.” “I don’t understand why we are doing half of these steps.” “We did not expect it to take so much time.” None of them were angry. The teams had simply stopped expecting better.

Then I mapped the flow. I tracked every single application, step by step, with the real lead time at each stage. This technique is called “value stream mapping.” On paper it is simple. In practice, and especially in tech, the data did not exist in one place.

There was no single system that tracked an application across the whole journey. So, I pulled timestamps out of tickets. I even reconstructed dates from email threads. I got some numbers by sitting next to people, asking and observing what happened between this approval and that one.

One application took one year through the pipeline. Most of that time was queueing: the application sat, finished with one step, waiting for the next team to pick it up.

That was the entire diagnosis. The work I saw at any single step seemed reasonable. Looking closely, there were gaps in and between working steps, and there was the lost year.

What the map showed

I want to be clear that the causes were not technical. Engineering leaders almost always reach for the technical answer first.

There were redundant validations, several of them checking the same thing. Ownership that blurred at every handoff, so a request would land in a gap that belonged to no one. In addition, no shared definition of “done,” which meant a step could be finished by one person’s standard and unfinished by the next person’s.

None of that shows up in the daily management approach and rituals. Tech teams were using digital boards. I’ve seen tasks “in progress,” but none of them were highlighting the duration of that state and most of the reasons why it was so long. For example, “in progress, blocked for nine days, because two teams each think the other owns the next move.” There was no trigger for people to dive in.

The room pushed back

I brought my approach, including all the collected data, into a two-day workshop with the platform team. We built the map as I did, step by step.

The first morning was resistance. From my experience, this reaction is normal. Whatever is the way you facilitate these sessions, you should plan for it. People do not enjoy looking at a chart that says their work took a year. So first, they explain, then they justify. They tell you why the thing you are pointing at could not have happened any other way. In the end, some of them say “no way.”

I did not argue with the explanations. Arguing hardens them. Instead, I kept moving the conversation from “why it happened” to “how it could work.” Every time someone defended the past, I asked the “why” of what happened and what that step would look like if we designed it from scratch today.

So grasp the why a situation happened, then build on that to design the new way. Slowly the energy turned for some participants. The moment it turns is when someone stops defending the old flow and starts drawing the new one.

We also had incomplete data, and I said so out loud. Technically, you do not need perfect numbers to redesign a process. You just need enough to see the shape of the waste, and the shape was already obvious to everyone in the room.

By the end of day two, the team had a new flow. Having a perfect one was never the objective. That new flow contains fewer validation steps. One fix stood out: the approval step no longer waited for architecture review to finish. It started at intake, running alongside the rest of the flow instead of extending it. They defined a clear owner at every handoff. A definition of ready and a definition of done for each stage, written by the people who do the work.

They also set a target of cutting the end-to-end lead time by at least 50%, the number most teams ask for first in this kind of exercise.

Seeing a broken delivery flow

I have watched the other version of this story many times. A consultant cuts a number by 30%, presents the slides, and then leaves. Three months later, the number has climbed back to where it started. The fix disappeared as soon as the consultant left.

What held this time was that the team and their leaders had learned to see the system they were standing inside.

Before the diagnosis, leadership saw status. There were boards showing “in progress,” so no issue. Leadership could not see that an application was sitting for weeks in a gap between two teams, because nothing made the waiting visible.

After that experience, they could. End-to-end lead time became the number everyone watched, instead of how busy each person looked. Blockers stopped hiding inside “in progress” and surfaced where a leader could actually act on them. People who had argued about “better communication” for months started talking about dependencies, handoffs, and the real shape of their value stream, because for the first time they had seen it drawn on a digital wall.

That shift is what makes the gain durable. A team that can see its own flow will find the next bottleneck without me. The visual board they kept running, the indicators with a named owner, the habit of walking to the real work when something breaks, none of those are the fix. They are the instruments that keep the seeing alive after I am gone.

So this is the difference between a fix and a capability. A fix is a number that improved while you were in the room. A capability is a team that can spot and clear its own next bottleneck once you are not. The target only means something if they can hold it without me. They could, because they could finally see what they were holding.

Your AI tools made the coding faster. They did nothing to help anyone see where the work actually waits. For that, you need to build the ability to see it.

The bottleneck is rarely technical

If you suspect your delivery is slower than it should be, you are probably right, and you almost certainly cannot prove it yet. Take one request that went through the system. Map that end to end, with honest lead times, even if you have to dig the numbers out of emails. The map will point at the gaps between your steps. That is a real starting point on where the waiting is hiding.

Then redesign it with the people who do the work, and build it so they own it. A process the team owns is the only kind that outlives the person who fixed it.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.