How to Redesign a Broken Delivery Flow  🔗 **Source:** [How to Redesign a Broken Delivery Flow](https://leaddev.com/technical-direction/how-to-redesign-a-broken-delivery-flow) > [!note]+ Document Notes > --- > tags: [value-stream-mapping, delivery-flow, queueing-waste, engineering-leadership, organizational-change, lead-time] > author: [MISSING] > source: LeadDev > reference: https://leaddev.com/technical-direction/how-to-redesign-a-broken-delivery-flow > date created: 2026-08-24 09:00 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: How to redesign a broken delivery flow > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [LeadDev](https://leaddev.com/) — publisher; engineering leadership audience > - Value stream mapping — the Lean technique the diagnosis is built on, named in the piece > - Definition of ready / definition of done — the Agile artifacts adopted in the redesign > - Little's Law and queueing theory — the formal basis for why waiting dominates lead time, not cited > - Toyota Production System / *gemba* — the "walk to the real work" habit, uncredited > ## 📝 Summary > - **What happened.** A consultant recounts diagnosing a platform team's deployment pipeline at a large enterprise. One application took **more than a year** to move through it, and the team running the pipeline did not know. Most of that year was **queueing** — work sitting finished at one step, waiting for the next team to pick it up. > - **Why it matters.** The central observation generalises well beyond this engagement: **"the work is usually fast, the waiting, which is where the time goes, stays invisible."** And the mechanism for that invisibility is specific and familiar — **digital boards show "in progress" identically whether a task is moving or stuck in a handoff gap that belongs to nobody.** > - **Key stakeholders.** Platform and enablement teams whose internal clients have quietly stopped complaining; engineering leaders who see status boards and mistake them for flow visibility; anyone commissioning delivery improvement work that they need to survive the consultant's departure. > - **Risks and tradeoffs.** Single anonymised case study, self-reported by the person who did the work, with the outcome measured as a *target* rather than a result — a 50% lead-time reduction goal is stated, never a figure achieved. The durability claim that makes the piece distinctive is asserted, not demonstrated. > - **Bottom line.** Two ideas earn the read. **The causes were not technical** — redundant validations checking the same thing, ownership blurring at every handoff so requests land in gaps belonging to no one, and no shared definition of done. And the distinction the whole piece is built toward: **"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 closing jab lands too: **"Your AI tools made the coding faster. They did nothing to help anyone see where the work actually waits."** > ## 📖 Main Content > The opening line is the thesis: **"A broken delivery flow rarely looks broken from the inside."** Then the fact that makes it concrete — one application spent more than a year moving through a deployment pipeline, and **the team that ran the pipeline did not know that.** There was a feeling it was slow. Nobody had put a number on it. > The setting is a platform team at a large enterprise whose job was helping product teams ship applications into a cloud environment, with a path to production built around security, infrastructure, and validation. Leadership suspected the process dragged but had not measured how far. > The author's stated experience across sectors gives the generalisation: **"the work is usually fast, the waiting, which is where the time goes, stays invisible."** That is queueing theory restated in practitioner language, and it is correct — in most delivery systems, touch time is a small fraction of lead time, and the remainder is invisible because nothing renders it. > Two diagnostic questions open the engagement, and the pairing matters: **"How do the people who use this process feel about it?"** and **"Where, exactly, does an application spend its time?"** One qualitative, one quantitative, and neither sufficient alone — sentiment without numbers gets dismissed as complaining, numbers without sentiment miss what people have stopped expecting. > **The interviews produce the most quietly devastating detail in the piece.** Satisfaction scores from internal clients, product owners, and tech leads came back in the **low single digits out of ten**. The comments are specific: *"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."* > And then: **"None of them were angry. The teams had simply stopped expecting better."** > That is the finding worth carrying. Anger is a signal that someone still believes improvement is possible. Its absence is not satisfaction — it is a service whose users have adjusted their expectations downward and stopped reporting. Any platform team with quiet internal clients should read that sentence twice. > **The mapping is where the honesty about method shows.** He tracked every application step by step with real lead time at each stage — **value stream mapping**, named explicitly. "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: timestamps pulled out of tickets, dates **reconstructed from email threads**, and numbers obtained by "sitting next to people, asking and observing what happened between this approval and that one." That is unglamorous archaeology, and reporting it is more useful than a clean methodology section would have been. The absence of end-to-end tracking is itself a finding — you cannot see what no system records. > The result: one application, one year, **"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."** > Note what that means. **"The work I saw at any single step seemed reasonable."** Every team was doing its job competently. The waste lived entirely in the gaps between them — which is precisely why nobody inside could see it, since nobody owns a gap. > **The causes, and the warning attached to them.** He is explicit: **"the causes were not technical. Engineering leaders almost always reach for the technical answer first."** Three findings: > - **Redundant validations**, several checking the same thing. > - **Ownership blurred at every handoff**, so "a request would land in a gap that belonged to no one." > - **No shared definition of "done"** — "a step could be finished by one person's standard and unfinished by the next person's." > Then the diagnosis of why the existing management system could not surface any of it: **"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."** The example he wants on the board instead is precise: **"in progress, blocked for nine days, because two teams each think the other owns the next move."** And the consequence: **"There was no trigger for people to dive in."** > That is a sharp critique of a near-universal tool. Boards make *status* visible while leaving *duration* and *cause* invisible, and status is the least useful of the three. A card t [](https://leaddev.com/technical-direction/how-to-redesign-a-broken-delivery-flow)[article hero rollercoaster-08](https://leaddev.com/technical-direction/how-to-redesign-a-broken-delivery-flow) **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](https://leaddev.com/velocity/balancing-delivery-speed-engineering-health) 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](https://leaddev.com/technical-direction/building-cloud-architecture-can-scale-any-challenge). The path to production was all about [security](https://leaddev.com/culture/why-security-everyones-responsibility), 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? #### Your inbox, upgraded. Receive weekly engineering insights to level up your leadership approach. #### Nobody had a number I interviewed the platform team’s internal clients, product owners, and [tech leads](https://leaddev.com/leadership/being-tech-lead-doesnt-mean-having-all-answers) 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](https://leaddev.com/technical-direction/whatever-happened-big-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](https://leaddev.com/the-engineering-leadership-report-2026/) 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](https://leaddev.com/career-development/the-reality-of-being-an-engineering-manager) 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](https://leaddev.com/leadership/the-engineering-leadership-skill-no-title-can-give-you). 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](https://leaddev.com/technical-direction/ai-made-platform-engineering-strategic-again). 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”](https://leaddev.com/communication/how-communicate-executive-audience) 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](https://leaddev.com/ai/best-ai-coding-assistants) 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. LDX3 New York is live #### 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., How to Redesign a Broken Delivery Flow, leaddev.com, 01m0sx1bwzpwhgjzjstthy5kyv.