Defects are a typical form of NRFT in software development. I see them like receipts because it is like paying twice for something you already knew. When that happens in engineering teams, we typically point to insufficient testing, insufficient review, or a lack of experienced devs.

For me, NRFT occurrences and costs are still hidden within engineering teams. They rarely show up on dashboards. They are difficult to measure. Typically, teams rework about a quarter of their code before shipping.

I believe AI in software development is making NRFT cheaper to create and easier to miss at the same time. Change failure rate looks fine because in most of the cases, engineers catch AI’s errors before production. But they still burn many hours on rework, even if they avoid the failure. The waste now happens in review queues and rewrites, since those rework hours never touch production, so no delivery metric records them.

In addition, the NRFT compounds across the queue. Every bounce-back costs more than a rewrite. It re-enters the workflow and waits in line again, behind everything else that arrived while it was being fixed. That’s one reason your lead time creeps up, even when everyone is busy.

Diagnosis: Four conditions that guarantee rework

In tech, when work comes back wrong, we add tests, reviewers, or, if required, we hire seniors. But every time we tightened inspection, the rework just changed shape. The reason is that inspection treats symptoms.

Here are the four systemic reasons I observe:

Work arrives ambiguous: a development task arrives with vague acceptance criteria. For example, we may have undefined edge cases or unstated assumptions. So the engineer fills the gaps with their best reasonable guess, which is wrong. The reviewer finds out a week later. So the defect you see in review is often a translation problem that happened upstream, two handoffs earlier.

Feedback arrives too late: a rework exists as soon as you discover the mistake. The repair might be expensive, but you also incur compounding costs between the mistake and its discovery date. Unfortunately, when a reviewer takes two days to respond, the engineer has already moved on mentally. By the time the comments arrive, reconstructing the context costs more than the fix. So the longer the delay, the higher the bounce rate. The delay is a property of the system.

Batches are too big: honestly, nobody truly reviews a 900-line pull request. You skim it. Big batches also amplify the previous cause. Indeed, the larger the change, the longer the review queue, so the slower the feedback.

AI inverted the ratio between generating and checking: AI output is generous and mostly free, but the verification still runs at human speed. That imbalance guarantees NRFT. You can generate five implementations faster than you can review one. Errors pile up in the gap.

I am not saying that some engineers are lazy and hence approve bad code. In my opinion, regarding NRFT, they’re approving code that disguises its wrongness.

Those four causes together lead to the pattern I see in teams with a stalled lead time: ambiguous work in, slow feedback loops around it, oversized batches flowing through, and an AI engine amplifying the volume.

Countermeasure: Keep Work Visible and Small

The fix is one rule with three consequences: work enters the flow clear, moves in small pieces, and stops the moment something is wrong.

Work enters clear: a development task doesn’t enter the flow unless it has explicit acceptance criteria. Edge cases are properly listed, and the dev team has had the right discussions with the requirements owner. Recall that when an engineer fills gaps with guesses, the defect is created before the first line of code. So the gate is to keep ambiguous work outside the system.

Work moves in small pieces: cap the size of what flows through review. The principle: small enough that a reviewer actually reads all of it in one sitting. Small pieces are cheap to fix. Smallness is also what makes AI output survivable. A 100-line piece has better chances of being verified instead of skimmed.

Work stops when something is wrong: the moment a defect appears, anywhere, by anyone, the item it belongs to stops moving. It gets fixed immediately while the context is fresh, with all dependencies on sight. It can also be returned to the person who created the ambiguity while they still remember. That stop has only one objective: learn and avoid the same mistake going forward.

The whole point is the distance between the mistake and its discovery. Every mechanism above exists to collapse that distance to minutes.

Clear entries mean fewer wrong first attempts. Small pieces mean mistakes surface fast. Stopping means you fix mistakes where they were made. The team that applied this rebuilt the conditions the code flowed through.

These three are a system to build.

Problem-solving keeps them alive. For that purpose, it has to be the team’s reflex for every bounce-back. When work comes back wrong, the collective question is always “why,” so which condition failed us.

Real Case: Twenty Percent Right First Time

Thirty developers had a defect backlog that refused to shrink despite weeks of correction sprints.

So together with the tech lead, we followed the full lifecycle of ten consecutive defect corrections to see whether the fix held the first time or came back.

Eight out of ten came back, so the team corrected the issue right the first time only 20% of the time. They spent 80% of their bug-fixing capacity fixing their own fixes.

Diving into the ten’s lifecycle told us why:

The analysis was only partly implemented. The person doing the correction implemented what they understood of the diagnosis. Those devs were genuinely trying to close their tickets. But when the root cause touches something outside your comfort zone, you fix the part you can reach and hope it covers the rest.

Unit tests were minimized. Developers wanted to get to the code and treated the tests as the tax. Rushed tests, written after the fact, verify almost nothing. So the fix was “done” before anyone knew whether it worked.

Nobody identified the root cause before correcting. Several fixes addressed symptoms. If you don’t know why the bug exists, your correction is a guess with a ticket number. Guesses bounce.

One defect took six re-tests. Each re-test was run on incorrect data. Nobody had sat with the business to understand what the real cases looked like, so the team validated its fixes against invented ones.

Requirements were misinterpreted. Same root, different branch: nobody had gone through the requirement with the people who wrote it. The team was working from its own reading of the document. Plausible reading, wrong one.

In those five, a pattern emerges. One is about competence. The other four are about the same missing ingredient: conversation. With the system, the tests, the business, the requirements. The team was working alone against bugs that lived in shared understanding.

We applied the countermeasure exactly as described above, plus one thing this team needed: before touching any defect, identify and write down the root cause, then sit with the business to confirm the data and expected behavior before correcting. No fix started without that. The first reaction was “we don’t have time for this.” Within two weeks, they had time. The re-testing loops disappeared.

Three months later, NRFT was at zero. Defects dropped from 92 to 8 per month. All that happened with the same thirty people and no additional tooling.

Now, let me be clear and honest here. Defects are still a problem. Eight per month is still painful. Eliminating those means working on the defect root causes, design, architecture, etc.

The same pattern is spreading. Teams whose change failure rate looks fine while their developers burn half a day correcting model output. You’ve now seen how one team stopped paying twice. It’s time to look for yours.

In every team I’ve coached so far, I’ve observed the same thing. It is not only about FinOps. Testers, for example, who don’t file clean defects. Or tech who don’t respect a 24-hour SLA. Or even developers who don’t run the required root cause analysis.

The question is not why people don’t act. It is what in their work makes acting the obvious next step.

The diagnosis: no target means no gap

44% of the defects declared by a team of software testers I observed were false. They were not lazy or unaware. They just had no “standard” for completing a defect report. That standard would have included a check or verification against specs, which would reduce false defects. Instead, testers had no way to spot their own deviations, and nobody noticed.

The causes there are the same for cost tracking and actions regarding FinOps:

• No target, so no gap is visible. A cost is just a number until there is an expected value next to it.

• The related actions aren’t specified anywhere. They are vague and belong to everyone, so, as usual, to nobody.

• No manager has a cadence and a structure for reviewing the gap with team members. It means there is no specified know-how for them.

• Feedback arrives weeks after the decision, aggregated and sent to the wrong person, so nobody can connect the cost to the choice that caused it.

So, the consequence is the monthly bill you want to avoid. By then, it is usually too late to change course.

The FinOps Foundation diagnosis highlights awareness and motivation. That vision leads to tactics focused on information and encouragement. But information without a standard (a way to act) is just meaningless. The same goes for encouragement without a ritual to see and understand the situation: it’s just a message. No one in the team will remember that message in a few weeks.

The countermeasure: standards to act and learn

In a team, a “standard” is the current best way to do a task, written by the people who do it. It is short and visible to everyone. A standard helps to reduce variability. Using it leads to predictable results, creating a baseline so deviations become visible and improvement becomes possible. To be clear, the standard is not a policy. It is the procedure that sets the point you compare reality to.
You can use it in two ways here. The first is the team’s standard for achieving the desired cost outcome. The other is the manager standard. It is how he hands the problem to the team and ensures learning. For example, it covers what he checks, with whom, and at what cadence; what he does when it’s red. It’s the routine he follows to make a problem visible and put a person in front of it, on a schedule.

• No target means no gap. So engineers need a written target per team for what “normal” cost looks like, especially for what they run. For example, expected monthly range, cost per deploy or per thousand requests, tag coverage. Write it with the team, keep it short, and revise it as they learn. From that, a cost is a deviation an engineer can explain.

• Cost belongs to everyone, but means nothing without ownership. Each team needs a named FinOps champion, with a standard for the role: what they check, when, and what counts as red. It is a routine role, revised like any other standard.

• No cadence means no habit. The engineering manager and the champion have a weekly improvement ritual, and it has a standard. This is the manager’s standard work. It includes how to set up the ritual, the intro, how to run it precisely, and the why behind each step.

• The real cost feedback arrives too late to learn from. In an enterprise context, it takes a long time for finance to aggregate costs, among other things, and get back to tech teams. By then, engineers are on other work, and the context is gone. The reported numbers cover many things. That kills learning. So, your engineers, using their dashboard, have to raise deviations immediately. The dashboard works here only because the target defines what’s normal. Then the engineer raises the deviation the day he sees it.

Let’s be clear: guidelines and policies don’t work because a central team owns them and enforces them. A team owns a standard and revises it as it evolves.

The case

The four moves became three documents - standards - and one KPI set.

We were in a big services organization. That tech department had roughly 60 engineers.

We had three engineering managers. Each of them managed two tech teams. On top of that, a director of engineering who raised the cloud costs issue in the first place. Cloud costs had never been in scope there, so putting that on the table wasn’t well received by the tech teams.

From an organizational perspective, we created one FinOps champion per tech team. A team member voluntarily took the role. On the cost matter, he worked with the engineering manager he reported to. In addition, each tech team’s FinOps champions had the same single FinOps point of contact from the central organization’s FinOps initiative. That relationship was informative and focused more on awareness of new directions or lessons learned at the company level.

In liaison with the director, we created standards for everything.

• First, onboarding: how an engineering manager onboarded himself to the FinOps initiative. It covers the full process, roles, and stakeholders. It includes how to bootstrap the initiative with a tech team until you identify a FinOps champion. Then it includes a standard for onboarding a new FinOps champion on a tech team.

• The role of a FinOps champion: it covers what he does within his team about FinOps. It includes evangelization, cost KPI management, a problem-solving approach (PDCA), and cost-optimization techniques.

• How to drive the initiative: one part covers the weekly ritual the engineering manager had with each FinOps champion. Then there was a continuous improvement dimension covering both the approach and the optimization techniques. Engineering managers run continuous improvement (PDCA) autonomously on FinOps and raise it in their weekly meeting with the director.

Now, the mechanism is that engineering managers run it weekly. After initial onboarding, they enable tech teams to drive costs through a structured problem-solving approach. On the other side, they run a continuous learning loop among themselves and with the director. This lets them learn cost-optimization techniques and adapt in real time.

The rituals ran on one global cost KPI with its target, and one per tech team.

Here is how I implemented it. I built the system in liaison with the director. Then I bootstrapped it by onboarding one engineering manager. He then ran the whole thing with his teams: he ran information sessions and identified and onboarded two FinOps champions. Onboarding a champion meant the team’s cost KPI was in place and managed within the team. Then we did a continuous improvement session together, where we updated the standards he used based on what happened in reality with the teams. From that first improvement iteration, we got a new version of everything and agreed he would then onboard another colleague engineering manager. Then I left them to it. My part of building that was done. Whether the loop held is not mine to claim.

Standards reduce variability in task outcomes, regardless of who uses them. Standards trigger the right problem-solving at the right time for the right reasons.

This champion program runs on standards. Organizations meter their token billing daily, so the feedback can be same-day. With a target, a standard, and a ritual, you tackle the deviation the day it appears, not on the bill.

I have watched that version many times, and I have been the consultant in it. I have also been the one whose fix was still running long after I was gone. The difference showed up in how the fix got built.

The diagnosis: leadership was reading status, not time

The team ran the path to production at a large enterprise. As usual, the process involved other specialized teams such as security, infrastructure, and cloud. One application took more than a year to get through it. Nobody inside the pipeline knew that, and everybody was doing their job.

No single step was wrong. Whoever you asked had a good reason for their part. The time went somewhere else: the application sat, finished with one step, waiting for the next team to pick it up. Some of it also sat after somebody had taken it, before anything actually moved. Nothing followed it across the whole journey. Each team’s tools showed their own steps. The waiting between them belonged to no one, so no one measured it.

Leadership saw boards full of work in progress and read it as fine. There was nothing saying “in progress, blocked nine days, because two teams each think the other one moves next.”

The countermeasure: build the seeing, do not deliver the map

I could have mapped that alone and handed in a report. Faster for me. It would have just ended up buried in a folder.

So I built the map with the team. We walked one real application from inception to go-live. For each step, we collected when the request arrived in the queue, when somebody actually started, and when it was done. Nobody could hand me those numbers. I assembled them from tickets, old email threads, and conversations at people’s desks. The year disappeared between arrival and start, and inside the steps themselves.

The data was incomplete, and I said so loudly. You do not need perfect numbers to redesign a process. You just need enough to see the shape of the waste. That was already obvious to everyone.

The first morning of that workshop was resistance. Plan for that. Nobody enjoys a chart that says their work took a year, so they explain, then justify, then somebody says it could not have gone another way. Do not argue with the explanations. Arguing hardens them. Instead, ask what the step would look like if you designed it from scratch today.

The situation turns when one person stops defending the old flow and starts drawing the new one.

The case: what changed in the room

They got rid of redundant checks. The approval step no longer waited for architecture review: it started at intake and ran alongside everything else.

They gave each handoff a clear owner, and they wrote their own definitions of ‘ready’ and ‘done’ for every stage.

Then they set their own target: cut lead time by at least half.

That is the part everyone quotes back at me, and it is the least interesting thing that happened.

By the end, the question had moved from who is busy to how long this takes. Blockers stopped hiding inside “in progress” and surfaced where a leader could act on them. People who had argued for months about better communication started talking about handoffs and dependencies. All because they finally saw the flow drawn on a digital wall.

I left instruments behind. A board that shows waiting, not just status. Indicators with a name against each one. The habit of walking to the actual work when something breaks. Those are not the fix. They keep the seeing alive once I am gone.

On the last day, they were the ones pointing at the next thing to fix. A fix is a number that improved while you were in the room. A capability is a team that spots and clears its own next bottleneck once you are not. What I can tell you is what changes when the team builds the map instead of receiving it, and it is not subtle.

Your AI tools made the coding faster. They did nothing to help anyone see where the work actually waits. You cannot buy that capability. You build it in a room, with the people who do the work.

Try this question on your last transformation. Who noticed what was wrong next, and could they say it out loud? Do not ask whether the number moved. Everybody’s number moves while the money is being spent.

Reply and tell me what you found.

A longer version of this case was published on LeadDev in August 2026: How to redesign a broken delivery flow.

The dashboard drops everything that never became a number. It records events, and most of a workday happens between them. For example, a ticket moves to “In Progress” at 9 and to “Done” at 16. In those seven hours, the tester spent twenty minutes figuring out which environment was current and waiting while it rebuilt. So the tool records two events, and the day happened between them.

The retro drops everything nobody thought to mention. Naturally, people tell you what they remember, and they edit while they remember. I am not saying they hide things. Weeks are long, and our minds keep what felt like an issue and throw away what felt normal.

I believe the second filter, which most managers trust more, is worse than the first.

The diagnosis: 20 minutes looking for the right environment

I saw this in a testing team working on an insurance platform. Productivity was low, and nobody could explain why. When I sat and watched them work, much of the answer was the time spent figuring out what environment they were actually in, and the time spent waiting for one.

None of that was in any tool. Cycle time would have caught a ticket sitting in a state. Here, it was twenty minutes inside a task that was officially in progress, and it happened several times a day to several people.

The last time I went and looked at a delivery flow, the wait was sitting in one approval step nobody in the room had mentioned. It was not hidden. Nobody owned that step, so it never appeared in a report.

Ask that team in a retro whether anything blocked them, and they say no, honestly. It had been that way for months. That is how it stopped being an event and became the conditions.

The countermeasure: one hour watching one activity, unprepared

Pick the one team whose number looks strange.

Watch one activity for an hour. Focus on the work itself, as it happens. This is not a status conversation, nor a demo. Be clear about that. You might ask questions occasionally, but it’s better to wait until the end for a conversation based on what you are seeing.

Tell them you are coming and ask them to prepare nothing. The latter matters because if they prepare, you create overhead for them, and you will see the prepared version. So if nothing is prepared, the overhead lands on you, which is where it belongs.

Bring the reporting chain with you. When the manager is in the room, the layer above the team wants to be there too. You have to brief them; they are there to listen and learn from the way you act.

Now here are the rules, which are the whole difference between this working and this being an audit:

• Announce it. A surprise visit gets you one hour of the real thing; then the team knows you turn up unannounced, and you never see the real thing again.

• Ask to see the actual thing. Then ask again. The second showing is usually where the workaround appears.

• Do not solve anything in the room. The moment you fix something, you become the person who fixes things, and they stop showing you problems.

• Do not look for someone to blame. Keep a straight face when it gets uncomfortable.

• Say thank you before you leave. Give one thing you saw that was good, and one question you left with.

• Debrief with the chain at the end. Don’t do it in front of the team.

You are there to understand, not to confirm. What you will realize: an hour of watching gives you more than an hour of people remembering.

The case: a monthly hour on the floor for productivity

Let’s go back to the testing team. The client was unhappy: they missed deadlines, and test execution couldn’t keep up.

The manager started because a number would not explain itself. It became monthly because it worked. He sat next to a tester and watched them run test cases for an hour. His point was to see and understand what the productivity numbers he knew were made of. That is where he saw for himself the twenty minutes I had found in the diagnostic. Reading it in my report had not moved him. Watching it did. After an hour of watching, he started asking.

He asked what she was doing and what she needed to finish it. She was waiting on an environment. He asked how she knew which one was current, and she said she asks a colleague, or she tries it and finds out. He asked what had just happened when she went looking. Then how many times that had happened today. Four, she said, and it was not a bad day.

Then the two that hand it back: what would have to be true for that not to happen at all, and what would you try next time?

The last question is the turn. Up to that point, he is understanding but, most of all, leading the tester to acknowledge the real problem. At that point, he hands it back.

He did not solve anything. The team worked out what to try and what they thought it was worth, and one of them said a waiting reduction number out loud. He asked them to show him next time.

The month after, they showed him during another visit. Then they picked the next thing.

The first visits didn’t go smoothly. Half the team was skeptical about such a visit from management. The team leader was openly doubtful. Being watched reads like an audit until the manager proves otherwise, and the only proof is what he does. He does not solve their problem for them. He doesn’t even look for someone to blame; that wasn’t the point. He comes back the following month, which is what convinces them.

A manager who watches and leaves is a tourist. Here, he watches, asks until they see it, then steps back and lets them prove it to him next time he comes in.

That manager did his hour every month, and the team saved him the thing they want him to see. If you try it, the first visit will feel awkward for everyone. Move on to the second one. You will start to find out whether they believed you.

1. Someone in support could have resolved it. For example: missing access rights, missing knowledge, no written standard for what a complete answer contains. Another situation I saw was that the ticket landed with the wrong person because the routing ran on assumed specialty, instead of actual skills and workload. Those are defects in the support system, so the support manager is responsible for them.

2. Nobody in support could have resolved it because the software produced it. The answer lies in the code, in the data, or in a design decision made years ago. So the ticket climbs, level one to level two, then to level three. At the top of that ladder sits a maintenance team or a squad that inherited the codebase. Sometimes, it is nobody at all. Those are defects in the delivery system. You own them, and you almost never see them.

The diagnosis: 20%, filed as one team’s problem

A director looks at 20% escalation rate for his support team and reads competence. So, for him, it is time to put money into training, a tenth technician, or a better ticketing tool. But tickets from software issues keep coming in. They get answered, but they keep arriving. The critical point is that, in most of the cases, nobody upstream, in the development team, ever learns they existed.

I’ve learned this in banks, in energy, in public services. The support team absorbs a defect the builders never receive. That absorption even looks like a service. It is actually a broken feedback loop. It holds because the people who could close it are looking at a dashboard that does not contain it.

The countermeasure: two bins, then walk to the team that wrote it

Sort one month of escalations into two bins.

Bin one: fixable inside support. After a root cause analysis for each ticket, fix it with two things. First, a written standard for what a response must contain before a ticket closes. Then, within the team, ticket routing based on real skills and current workload instead of assumptions.

Bin two: what survives. Take it to the team that wrote the code. It has to land on their board as their own number; otherwise it reads as support complaining.

Do not treat bin one as the win. You clear it so you can see what is underneath. You cannot clearly read your support queue as a defect report (on your product) while that queue is still full of escalations about your support process. Clear bin one first. Then you will see that unglamorous, continuously updating list of things your software does to people. Most organizations have never produced that list once.

The case: what nine points bought, and what stayed

At an energy company, nine technicians handled billing software issues for business teams.

During the diagnostic, I found the following numbers: on-time resolution: 40%, escalation rate: 20%, client satisfaction: 7 out of 10. Looking at the actual ticket replies, I saw that 36% were unclear, incomplete, or missed the question. One client said he had explained his problem three times. Forty-four tickets sat unassigned, some for over a month. During an observation, I discovered that assignment ran on a supposed specialty, and nobody could see the queue ageing.

Everything we did was on the support side. We created quality standards for the responses. We ran a pull system instead of pushing tickets to people. We set up a visible board with every ticket, its age, and its owner. The one rule was that nothing sits unassigned for more than 24 hours (per our SLAs).

Three months later, the on-time resolution reached 68%. Escalations fell to 11%. Satisfaction moved to 8 out of 10. There was no headcount change.

Now, let me share the part I would do differently today.

Nine escalation points came out with the support-side work. So eleven points survived everything we did to that support system. Nobody sorted that residual. That was the defect report. Everyone was happy with 8 out of 10. Nobody asked what was left.

One caution before you go pull your own numbers. A support queue only shows you what customers bothered to report. It is not your whole quality picture. It is just the part that arrives already paid for by customers, in their own time.

In a tiered organization, a bin two escalation goes to a third line or a maintenance team. They didn’t build it. The builders never receive their own defects, so the behavior that produced it never changes. Tiers rebuilt the old wall between the people who write software and the ones who live with it. You build it, you run it was one answer to that wall.

Sort one month of your escalations into the two bins. If the second one is bigger than you expected, reply and tell me what you found.

A team of fifteen testers was working on an insurance claims platform. There was nothing anywhere to say which delivery or feature was behind or where the work had stalled. The client had just returned a version carrying seven regressions that were supposedly fixed months earlier, and the manager wanted to know why his team could not keep pace.

I pulled the defect data. Of every hundred defects the team sent back to development, forty-four came back rejected. Almost half of what that team produced created work for other people and closed nothing.

I continued to watch testers at work for a few days. Some ran the same test again and again without reaching a conclusion. One spent two hours investigating before telling anyone.

I needed to dive into the defect data. I took ten rejected reports and read them one by one.

Thirty percent were real bugs, already fixed in a version the tester did not have. Twenty percent were duplicates of reports nobody could see. Twenty percent came from testers who did not know the expected behavior and had no quick way to confirm it. The rest was smaller: a thin knowledge of one subsystem, a misread result, a browser serving pages from cache.

Every cause on that list is a missing piece of shared information.

The usual countermeasure here is a review gate: someone senior checks each report before it is filed. But here, it fails, because it puts a queue in front of a problem that was never about carelessness.

With the team manager, the move we made is an “andon”. It is a signal that stops the work and calls for help. For that, we set one basic rule: when you are unsure something is a bug, you do not file it. Instead, you raise the signal, and the functional expert walks to your desk and looks at the screen with you. The typical resolution we observed was five minutes.

Two design choices decide whether this holds or becomes one more interruption.

Raising the signal is a requirement. Permission is not enough, because filing a ticket is free, but saying “I am not sure” might not be.

The expert also treats every call as twenty minutes of teaching. He shows the expected behavior and why. Then he shows you how you verify it yourself next time. So the same doubt stops coming back.

The andon reaches three of those six causes, roughly forty percent of the false reports. Asking an expert cannot refresh a stale environment or reveal a duplicate. The other sixty percent closed because the team built a visual management system. Every lot, delivery date, and problem already reported sat in one place anyone could read, with a target for the day. When the actual fell short of the target, that gap started a problem-solving cycle. That wall was empty the day I arrived.

April, 44%. May, 8%. June, 4%. There was no new headcount over those three months. The one thing added was the functional expert’s time, and he did not stay for the whole run.

The full root cause analysis and the problem-solving cycles behind these numbers are in the case study.

What your team reports is not a measure of how carefully they work. It is a measure of what they can see at the moment they have to decide. Fix what they can see, and the number moves on its own.

If you want to see where your own system leaks, the Delivery Scorecard takes two minutes. Ten questions, and you know where to look first.

The answer got clearer, and it points somewhere most teams are not looking. AI multiplied every team’s capacity to act. We get more code shipped, and more tickets closed. It added nothing to our capacity to know where to act. Over half of new features still fail to deliver the value teams expected. Mostly because they aim at the wrong problem, faster.

The scarce skill moved from acting to aiming. Aiming has one discipline that survives everything: never ask customers what they want or what they would do. People answer politely and imagine a better version of themselves. The answers mislead you without a single lie in them. Instead, ask what they did the last time the problem actually hit. Observe it if you can. Past or present behavior is the only evidence that holds up.

I have applied that discipline inside engineering and operations teams for over 15 years. This one engagement here shows exactly how it plays out.

The diagnosis

An IT operations manager at a financial institution ran 17 technicians across a dozen office buildings, handling phone and printer incidents. Clients were unhappy and he knew it. Complaints reached him through directors, forwarded emails, hallway remarks. But he had no data on what exactly was broken and no way to prioritize. There was frustration everywhere, but he did not see any leverage.

I’ve met support and platform teams living that situation. Feedback reaches them constantly. They never get a signal they can act on.

The countermeasure

We built a structured Voice of Customer collection with the team. It contained eight questions, asked by phone, each anchored to one specific incident that had just closed:

1. What did you ask for, and what did you get in the end?

2. Where and how did the exchanges happen on this incident? What would have suited you better?

3. What has happened since the fix?

4. Walk me through the timing, from when you reported it to when it was solved. How did that fit what you needed?

5. What did you have to do yourself to get this resolved?

6. Rate this resolution, 1 to 10.

7. If under 10, what was missing to reach 10?

8. From your side, how should this ideally have been resolved?

Let’s focus on the design of the questions. There is nothing that asks for an opinion about “our service” in general. Question 6 rates one resolution, at one moment. Questions 7 and 8 pull out the hidden need behind the stated one: a client who asked for a faster printer fix actually wanted to know his ticket was not lost.

The mechanic matters as much as the questions. I called clients the same day their incident closed. I reached thirty of them over a few days. Same-day memory gives you concrete detail and zero recall bias. For me, it’s interviewing while the truth is still warm.

The case

The calls produced the first real baseline: satisfaction at 6.4 out of 10, 17% of incidents resolved within two hours (which was the SLA), 19 incidents per day (the volume). Two issues dominated the verbatims: clients never knew where their ticket stood; and too many incidents should never have happened in the first place.

Each fix answered one of the two findings. Clients didn’t know where their ticket stood, so the team put up a live board showing the status of every open incident, visible to technicians and managers at all times. Repeated calls stopped. Too many incidents were happening, so a structured root-cause cycle (PDCA) traced a large slice of the daily volume back to cabling problems. The team put preventive measures in place. On top of that, technicians started assigning work by impact instead of arrival order, and trained themselves on a “standard” diagnosis routine so resolution quality stopped depending on who picked up the ticket.

Three months later, client satisfaction stood at 8.7, a 45% jump. The two numbers underneath explain why it moved: two-hour resolution climbed from 17% to 31%, and daily incidents fell from 19 to 12. Those are exactly the two frustrations the calls had surfaced, and they were pushed in the right direction. All that happened with zero new hires, and zero new tools.

That engagement predates the AI wave. The manager’s constraint was not capacity. He had 17 technicians and no shortage of effort. His constraint was signal: he could not see where the system leaked, so he could not aim. Today’s teams have more capacity than he ever did, and more telemetry too. They have the same missing signal. Seven questions and thirty phone calls still beat any dashboard at that job.

If you want to see where your own system leaks, the Delivery Scorecard takes two minutes. Ten questions, and you know where to look first. And if defining value from your customer’s side is the wall your team keeps hitting, I run a half-day working session with leadership teams. Reply to this email, or message me directly on Substack, and I’ll send you the outline.

P.S. AI made acting cheap. It did nothing to the cost of acting on the wrong problem. Voice of Customer is how you find the right one.

For the first time in months, the number of release failures reaching production was zero. Three months of digging had gotten the team there. I could have written up the win that same afternoon and gone home.

One month later, it was back up.

I have watched this shape play out on enough teams to trust it. A team fixes the real thing, the number falls, everyone breathes out, and then it drifts back. Here is the story of one team that lived exactly that, and the part that finally held.

Where the failures came from

The team was tracking one number, month by month: release failures that reached production. In the first month I was there, it sat at its high point. Let’s call that the baseline. A release failure here means a change that had to be applied again because the first attempt broke something. For example, a piece of code that would not compile, a script that failed, or a step that was wrong.

Then it started to fall. By the second month, it was under a fifth of the baseline. By the third, zero. The number showed the team started fixing things.

Under that number sat a second one nobody watched as closely. Over that same stretch, fourteen releases failed in the lower environments before they ever reached production. Six in the acceptance environment, the rest spread across three integration environments. Those failures were the early warning. The impact line in the analysis said it plainly: more failures below meant more risk above.

So when the production number climbed back in the fourth month, I sat with the team and we ran a root cause analysis on the confirmed failures. It was not a blame round. For each failure, we clarified what broke, why, and whether the dev team confirmed it by observation.

More than half traced to one thing. A database upgrade that had fallen behind. Some environments had it, one did not, and the same code passed where the upgrade was done and failed where it was behind.

The rest came from somewhere else. None of them was a developer being careless. Each of them was a gap that no single person owned.

Why “roll it back and move on” doesn’t work

Search how to handle a run of release failures, and you will see the advice converge fast. Roll back to the last good version. Tell the users. Automate the pipeline so people touch it less. Add health checks and gates that stop a bad build. Put the change failure rate on a dashboard and watch it fall. Run a post-mortem on the ones that hurt.

Most of it is sound. It still would not have found this problem.

It fails because it does not go beyond the fix that gets production working again. Recompile the tag, rerun the script. The service is restored, and the cause untouched. The next release stays exposed.

Every one of those standard moves makes survival faster: roll back sooner, detect earlier, shrink the blast radius. All of it is worth having. None of it asks why the failure was born. A rollback turns production green again and says nothing about the version gap between the two environments that caused the code break. A dashboard tells you the release failed. It will not tell you the same code compiled fine one environment over.

The post-mortem gets closer, and the good teams run one. But most run it only on the failures that reach production and hurt someone, then stop once the incident is closed. The failures on this team were not all in production. Fourteen of them sat in the release path, across four environments, and never reached a user. You do not find those by watching production only. You find them by watching the whole path and treating every failure as a question rather than focusing only on the loud ones.

Build the root-cause reflex

The fix was a habit, not a tool. Take every failure back to its root, and to do that, watch the entire release path rather than focusing just on the end.

So the team lead sat with the confirmed failures, one at a time, and refused to stop at the symptom. “The tag failed” is a symptom. The real work was the next question down. Why.

The first tag would not compile. Why? It used database functions that existed only in the newer version. Why did that matter? One environment’s upgrade had fallen behind, so the same code met two different databases. The cause was not the tag. It was version drift across environments.

The second failed on a variable declared in a form that the older version did not accept. It is the same family: code written for one version, run against another.

The third was a grant command with the wrong syntax in a table script. Trace it down, and the cause was a script that was never validated against the environment it would actually run in.

The fourth ran against incorrect information during a post-install step. The cause: the deployment instructions were trusted and never checked against reality.

Four failures, and under them two causes: the test and production environments were on different database versions, and some release work shipped without a check against where it would run. Trace those down one more step, and they meet in the same place. Nobody owned the release path between environments, so nothing verified that the environments matched, and nothing validated the work against its target. That gap was the root. You see it only when you line the failures up and trace each one past the fix, down to the reason. Every cause was confirmed through observation with the dev team before anyone built a countermeasure for it. There was no guessing.

Out of that analysis came the changes that stuck.

Fixed the drift at the source. The late upgrade got done, and code that needed the newer version was compiled and validated against the version it would actually run on.

Front-loaded the slow work. Anything with a known wait, an upgrade or an access right, now gets requested at the start of a deployment. It runs in parallel instead of blocking the release at the end.

Put the whole path under watch. Every environment, not just production. A failure below production now counts as signal, not noise, which is how the fourteen quiet ones became visible in the first place.

Made the analysis mandatory. In any month when the failure count is not zero, the team systematically conducts root cause analysis on all issues.

Watch a professional tennis player return a serve. They do not decide to move. The reflex fires before the conscious thought, trained by ten thousand repetitions until it runs on its own. Root cause analysis is the same muscle. The first one this team ran was slow, deliberate, and a little awkward. By the fifth, they were tracing a failure to its root without being asked. That reflex is the countermeasure. The tracking, the rule, the front-loading, all of it is scaffolding around the one thing that matters: a team that meets a failure with “why,” automatically.

Four months later

Here is what the four months looked like.

The first month is the baseline. By month two, the team had cleared more than 80% of the failures. By month three, all of them. The reduction read 100%. If we had stopped then, this would have looked like a clean win.

Month four handed half of it back.

The reduction fell from 100% to 50%. Not all the way, but far enough to count as a miss again. The gain did not hold on its own.

A number that touches zero once is not a system that holds zero. The month-three zero was real. It was also fragile. The moment a fresh batch of changes went out against the same version gaps, some of them came back as failures.

But the reflex held. A miss meant the dev team ran the analysis, and they did. That fourth-month spike is not the story failing. It is the story working, because the spike triggered exactly the response it was built to trigger.

50% removed and holding by the fourth month, with a peak in the middle, and a slip that taught the team more than the peak ever could. Improvement is not a line sliding down. It is a number that climbs back, a team that runs the analysis again, and a countermeasure that holds a little better each pass.

The pattern

Four failures came down to two causes, and both of them came from the same place. The path between the environments was not on sight, so nobody checked that they matched.

No AI wrote any of those four failed releases. Put AI in that pipeline and the same gap between environments gets hit more often. AI does not know your environments are out of sync. It writes against whatever version it is handed and uses the newest feature it can, whether or not the environment next door can run it. It does not just send more releases at the gap between your environments. It widens the gap faster than a human would, and the failure still shows up late, when the date is already close.

There is a harder truth, and the fourth-month bounce carries it. Fixing a number is easier than holding it. You can cut release failures in a quarter. Keeping them down is a different job, and it’s the team’s responsibility. The tracking and the rule are what you set up in an afternoon. The reflex that meets every failure with “why” is what takes months, and it is the only thing that keeps the number down after I leave.

On month four, they ran the analysis on their own without anyone asking. That habit is the real result. The zero in month three was just a good month. If you want to start, take your last failed release and keep asking why until you reach something nobody owns.

The delivery board told one story. The team, asked one by one, told another. The NPS was minus 15.

The first measurement

I brought an instrument I run on my engagements: the Voice of Employees. It takes the same discipline I apply to customers, pointed at the team itself, once at the start of the project and once at the end. I ran it with an internal coach I was training to carry the method.

We ran individual conversations with every engineer, anonymous by contract, scored the way you score customers: promoters minus detractors.

Why “boost morale” doesn’t work

The standard response to a number like that is a program: the annual HR survey, an offsite, a recognition scheme.

All of them aim at the wrong layer. Morale is an output, not a mood you can lift directly. Behind a negative team NPS, you will find system defects wearing an emotional costume: no onboarding standard, no handover design, no priority rules, no shared hours across time zones. You cannot team-build your way out of a broken handover. The instrument’s job is to make those defects speakable, then fixable.

The instrument

Define the themes first, before writing a single question. The themes are what you commit to hearing about, including the answers you will not like. Here are the five I use, and what each one listens for.

Interactions. Where the work rubs between people: other teams, users, or project managers. Friction here is almost never personal; it is structural, and this theme is where handover and boundary problems surface first.

Training. The gap between what the company expects of someone and what it has actually given them. Onboarding debt lives here, and it is invisible on every delivery dashboard.

Work and life. The overtime, the weekend interventions, or the always-running feeling. This theme counts what the job spills into people’s evenings and weekends, which no delivery dashboard will ever show you.

The rating. The score itself, 1 to 10, computed as an NPS. Then the question that matters more than the score: what would it take to make it a 10? The answers to that question are your improvement plan, written by the team.

The ideal. The magic wand: the one thing they would change, and to what level. It reveals priorities no ranking exercise will give you.

Now the methodology hint that decides whether the instrument works: assess every theme with open questions. Open means no question that a yes or a no can answer, and no question that suggests its own answer. You are fishing for real examples and stories, because examples carry the system defect with them, and opinions do not. Two questions I used on that engagement, verbatim from my guide: “Who were the last five people you interacted with? Were any of those interactions complicated? Walk me through one.” And on work and life: “How much overtime did you do last week?” Last week, specifically. Ask about overtime in general, and you get a shrug. Narrow it to last week, and the shrug becomes a number.

Run the same questions with every engineer, one-to-one, with anonymity guaranteed. A team of twenty means twenty conversations. Do not use a survey link, it is not the same instrument.

Consolidate the verbatims into weighted themes, positive and negative both, and compute the NPS from the ratings. Share the whole board with the whole team, names removed, nothing softened. Then put the top negative themes on the delivery board as problems, next to incidents and lead time, and run them through the same problem-solving cycles as everything else.

At the end of the project, re-measure, keeping the themes, the questions, and the method identical to the first round, because changing anything breaks the comparison. The instrument earns trust the day people see their words turn into countermeasures.

The second measurement

At the end of the project, we ran the same conversations again. The NPS had moved 65 points, from minus 15 to plus 50. On the delivery board, the delivery numbers I was there for had moved too. Production incidents had halved.

The why is not a mystery. What moved was, almost line for line, what the team had said would make them a 10. Their answers had been posted as the improvement plan, and the plan had been worked on like any other problem on the delivery board. Nobody shipped a rewards scheme or organized an offsite. The system got fixed, and the number that looks like a feeling moved with it.

The second measurement still carried negative themes. Knowledge transfer had broken when a senior engineer left, and the team said so bluntly. The asks that remained were structural: coverage, knowledge, and workload. Recognition came last.

Read that carefully. At plus 50 NPS, the team did not go quiet. It got more precise. A trusted voice sharpens, it does not soften. Plus 50 is not a happy team. It is a team that tells you exactly where the next problem is.

The pattern

That minus 15 was a list of things broken in how the team worked, and every engineer could name them the day someone asked. They can describe that system with precision the day you ask individually, anonymously, and show them what you heard. The description is not the result here. It is the raw material of the improvement plan.

In 2026, the tools make your team faster while the burnout number stands still, exactly as DORA measured. So measure the voice of the engineer next to the lead time. It reads the system from the side your dashboards cannot see.

If you want to try this, sit down with each engineer before your next big delivery push and put what they tell you next to your lead time numbers.

I watched this break in a support team for a set of online services, years before AI was in the room, which is why I trust the pattern. Six people, one shared queue, a 24-hour promise. Here is what I saw, and what works.

Where the backlog came from

I called the last ten whose requests had been closed. The message was the same from almost all of them: too slow. Most had waited more than two days. Some waited a full week. Half had never received a reply at all.

Then I shadowed the team. With the team leader, we counted 320 pending requests. Some were over a year old, sitting untouched in a queue nobody opened.

The problem was never the headcount. Each tech pulled work from whichever corner of the queue they happened to know, whenever they thought it was right. Routing rules were broken, so requests landed wherever. The 24-hour target lived in nobody’s eyeline. The team worked in isolation, and no one could say who was handling what. Work was pushed at people who could not see the whole flow, so the oldest, quietest requests simply aged in the dark.

More agents, same backlog

Buried under tickets, every instinct says hire. It fails for one reason. It treats a backlog as a capacity problem, and it isn’t.

Drop a seventh person into a queue nobody can see, picking work in no order, and you get a faster way to bury requests. I have watched a company hire three agents, then three more, then three more. The backlog grew with the team every time. More hands on a push system push harder. They don’t decide what matters.

Set the rate, not the headcount

First, we made the incoming flow visible. One simple table: incoming, waiting, processed, where everyone could see the numbers. We built it with paper, not a tool.

Then the one move that changed everything. We switched the team from push to pull. The team leader became the dispatcher, assigning by expertise and taking the simple cases herself. And we set a rate. We knew the daily volume and the backlog target, so we knew exactly how many requests to clear each day, and each hour, to dig out and stay out.

The rest held that move in place. The 24-hour SLA went on the wall and into her daily language. When the team missed the day’s number, they ran a short problem-solving cycle the next morning instead of moving on. One person called five requesters a day to keep the outside view in the room. Nothing here needed a new tool or another hire.

Three months later

The backlog went from 320 to 92 to 20. A 94% drop, with the same six people.

One thing didn’t come for free, and it is the part most case studies cut. Clearing the backlog was the fast part. Holding it is the part no system installs. The pull rate and the morning problem-solving only hold while the team owns them. The day the team stops working the rate, the queue starts refilling. That ownership took longer to build than the number took to move, and it was still being built the day I left.

The pattern

Support teams don’t have a capacity problem. They have a push system that hides what matters and buries the rest.

The same push system runs your bug intake, your incident follow-ups, your on-call queue. Nobody decides what gets worked next, so the oldest, hardest items sink.

That team had no AI in its toolchain. Yours does. AI clears the easy tickets fast, which sounds like relief. What stays in the human queue is the dense, bouncing work AI can’t close, and the tickets it marked “resolved” that quietly come back through another channel. A push system handles that harder mix worse, and now half of it is invisible, hidden behind a dashboard that says the volume dropped. AI didn’t empty the queue. It hid the part that was always the problem.

Pull the work, don’t push it. The backlog follows.

If you suspect your backlog is hiding what matters, start with the Delivery Scorecard. Two minutes, ten questions, and you know where to look first. And when AI tooling is part of the picture, I run a half-day working session with leadership teams on exactly this. Reply to this email, or message me directly on Substack, and I’ll send you the outline.

P.S. The team that hired three agents, then three more, then three more, still had a backlog. The team that set a rate cleared 94% of it with the same six people. Headcount was never the lever.

This was a bank's engineering team, years before AI was in anyone's toolchain.

What the flow was doing to them

Developers worked hard, and the system around them produced defects faster than they could clear them. In a single month, they logged more than they could fix.

The deeper pattern was uglier. The same code was being patched by several people in turn, each correction degrading it further. Analyses kept changing mid-build, drifting from the original client’s request. When a developer received a faulty analysis, there was no way to stop it. They built from it anyway, and it came back as a defect. Each fix created the next defect.

The developers were doing their job. The work reaching them was broken, and nobody could see where it broke.

Why “add more QA” doesn’t work

The standard response to a team drowning in defects is to add testers, tighten the gate at the end, run a bug bash, buy a defect-tracking tool.

This approach fails because it treats defects as something to catch at the developer’s desk. They were born upstream, in the analysis, before code existed. Add testers at the end, and you end up inspecting more rework. A new tool full of tickets nobody reads is the same blindness with a license fee. You cannot test quality back into work that arrived broken.

Rebuild the intake, not the team

The point was not to teach developers to code more carefully. The team rebuilt what reached the developers, and where quality got checked. They moved the control point from the end of the work to the start.

Most defects traced back to a faulty analysis, so no analysis entered development on its own anymore. The analyst and the developer sat down together and turned it into a test plan before a line of code was written. That became a fixed step in the flow, not a favor asked when someone had time.

When an analysis came in wrong or unclear, it stopped being quietly worked around. It went into a red bin, in the open, and back to whoever wrote it. Sending bad work back became normal and visible instead of awkward. And because analyses kept changing after work began, any change now triggered a fresh review before the work moved on.

One more thing kept the defects coming. The analysts who wrote the specs kept getting pulled onto new projects, so when a developer needed to check something, the one person who could answer had moved on. The developer guessed instead, and the guess came back as a defect. The dev team made it a standing rule to escalate to the project manager and keep the analyst on until the work shipped. The person who owned the spec stayed reachable.

None of this was a new tool or a reorg. It was a handful of standing rituals at the front of the line, all of it tracked on one visual board the team stood in front of each morning, reading a single number: how many new defects had come in the day before. They stopped catching defects at the end and started refusing them at the start.

Two months later

Two months later, the team had cut its defects by 91%. Right-first-time fixes went from fewer than one in ten to nearly all of them. They did it without new people, new tools, or a single line of AI, on legacy banking software written and maintained by hand.

The numbers moved fast. The first root-cause analysis started within a week. But the number is not what matters most. It is what I saw on the wall on the second month.

By the second month, something shifted that I did not install. Developers started walking to the board during the day, unprompted. They moved their own work. Handwritten problem-solving sheets appeared on the wall, some half-finished, that nobody had asked them to post. When managers visited, the developers walked them through the metrics and the open problems themselves. They were not doing that to impress anyone. It was because the board was theirs now.

That ownership is the part no framework installs. You can copy the board and the intake rule in an afternoon. You cannot copy the two months it takes a team to learn to solve and own its own work, and that is the only thing that keeps the number down after I leave.

The pattern

More than half of those 25 defects were already wrong before a developer saw them. Nobody was checking the analysis before it went into development.

Every line of that code was written by hand. Now imagine the same analysts sending the same broken specs to a team with AI coding tools. AI tools accelerate whatever your system already does. If your system lets bad analysis through, AI helps you turn it into code faster. More volume means more rework, and more defects moving through the same blind flow. The slip arrives before anyone sees it coming.

Seeing the defects was not the fix. What fixed it was the team digging into its own defects, finding the cause, and building the countermeasure itself. The intake gate was this team’s answer to its own cause. Yours will be different, and only a team that can solve its own problems will find it. AI will not do that for you.

The 91% is the quick part. The one that lasts is a team that runs its own board and solves its own problems. That took the full two months.

If you want to check your own team, take the last 25 defects and find out where each one started. You may be surprised how many never reached the code.

I watched this break before AI was in the room, which is why I trust the pattern. It is about two project managers I was working with. They were managing nearly 20 BI projects across several continents. The on-time delivery rate was 24%.

When I arrived, I asked one question: where can I see the status of all the projects together? Nobody could point to a single view. Each manager tracked their own work in spreadsheets and email threads. Neither could say how their timelines overlapped or identify a potential delivery issue risk.

Here is the pattern I see, and what works.

The division head was not short on reporting. He had plenty of it. But, status reports arrived late, told different stories depending on who wrote them, and never showed a milestone collision until the damage was done. Client satisfaction sat at 5.5 out of 10, trending down. One of four projects hit its deadline.

The standard response to this situation is more reporting: a new PMO tool, a weekly steering deck, a dashboard pulling from Jira.

It fails for one reason: it treats visibility as a data problem, which it isn’t.

The data existed. It lived in a dozen places, formatted in many different ways; each one true and none of them whole. What was missing was visibility into milestones, dependencies, and potential projects’ collisions. That visibility only appears when everything sits on one surface. These project managers lacked the ability to see a problem before it became a crisis.

So we built an Obeya. It is a room where the whole portfolio lives on the walls. It has three zones. A strategy wall tying every project to the CIO’s targets; a performance dashboard, six handwritten charts updated weekly: on-time delivery, defects per delivery, satisfaction, pace, risk, budget; and a macro planning wall, the whole portfolio on one timeline, planned milestones marked, actual progress in sticky notes.

Building the first version took a two-day workshop, paper, and markers. No software was bought.

The wall paid for itself in the first week. Projects were competing for the same testing resources in the same weeks. Go-lives piled up at quarter end because nobody had ever seen the full picture. One project manager said it out loud: “Now I understand why we keep missing dates.”

The conversations changed too. Before, “are we on track” depended on who you asked. After, the division head stood at the defect chart, saw the trend laid out week by week, and asked a different question: what is causing this?

Visibility alone fixes nothing, though. The wall surfaced the problems; structured problem-solving closed them. Three PDCA cycles ran in that room. One rescued a major go-live that the math said would slip. One fixed a defect-quality problem in testing, after I sat next to a developer and watched him mark a broken PDF export “OK” because the test script only said, “verify PDF export.” One turned a client complaint about a local project into a checklist the team still uses.

Three months later, with the same people in place, on-time delivery increased from 24% to 55%. Defects per delivery dropped from 38 to 19. Client satisfaction climbed from 5.5 to 9.4. Delivery pace tripled, from 9 projects delivered in October to 27 by December.

One number on that chart is still a miss. The strategy wall set the on-time target at 60%. The team reached 55. That chart was still red when I left, visible to everyone who walked in every week. I count that as a feature. A system that keeps your remaining gap on the wall beats one that lets you declare victory early.

Those two project managers were good at their jobs. They did not had a single place to see twenty projects at once, so the collisions stayed hidden until a date got bumped.

That team team worked with spreadsheets and emails. If you add AI to a portfolio like that, the only thing that changes is how many projects you have in flight. The collisions are the same; there are just more of them, and they stay invisible until a date is already gone.

The 60% target, that was still red, is a good thing. You probably have more projects running today than that team ever did. I would guess you still have no wall, even digital. Building one takes two days, some paper and a few markers.

The three cycles that produced those numbers are written out in full in the case study.

The team ran Scrum well. Two-week sprints, standups, retrospectives, and stable velocity. None of it could see where the request was actually sitting.

The framework you are using is not the problem. Neither is the tooling. Your symptom is the gap: the teams look fine, the delivery does not. The slow part lives between teams, in places no standups or ceremonies reveal.

Where the time went

A deployment was never this team’s alone. The request crossed four or five teams before any developer could begin.

The business wanted environments in thirty days. Their infrastructure deployments took roughly two months. Development teams waited that long for an environment to build on. Projects stalled. The DevOps team blamed external dependencies. Networking, security, architecture validation, the usual suspects. Retrospectives produced action items about improving communication with other teams and better planning. It was the same items, sprint after sprint, and nothing moved.

Here is what the request actually ran into.

A team member needed access rights to proceed. The only person who could grant them was unavailable. Days lost. A team unfamiliar with a recently introduced process inadvertently removed a resource. Re-validation from architecture. More days lost. A request for access controls bounced between two teams because neither knew which ticket to create or where to route it. Over a week, on a single request. A document template for a critical provisioning step was wrong. The replacement template was wrong too. Nobody knew the correct process.

None of these problems appeared in standups. None showed up on the visual board. The ceremonies captured “waiting on networking” as a blocker, but never revealed why.

Then I put the whole thing on one sheet. The map showed something the team had never seen.

About half the lead time disappeared in one queue.

That queue was the access control and network provisioning step. Requests sat there for weeks. Nobody was working on them. The team had assumed the time was spread across the whole flow. It was concentrated in one place.

The value stream map was the moment everything shifted. Up to that point, the conversation had been about effort and commitment, about who wasn’t talking to whom. Once the map appeared on the Miro board, the conversation became about routing, templates, and handoffs. These are tangible and fixable things. Every department head who opened the map asked the same question. Why is that queue so long? That was the start of the change.

Why “improve communication” doesn’t work

The standard advice for a team with long deployment lead time is always the same. Communicate better. Plan earlier. Add a Scrum of Scrums. Maybe a coordination ceremony.

This advice fails for one reason. It treats coordination as a willingness problem. It isn’t.

People want to coordinate. They just don’t know which ticket to create, where to route it, which template to use, or who has the access they need. “Better communication” between teams who don’t share a vocabulary, a routing convention, or a template library is two people talking past each other more often.

The deeper problem is in the workflow that crosses four or five teams, where each crossing is a chance for something to bounce, sit, or get re-done. Scrum makes one team’s work visible. It cannot see the seams between teams.

Across engagements, the root causes consistently fall into four groups.

Access and permissions stall the flow. The people who can grant the access needed to move forward are a bottleneck of one. When they are unavailable, the work waits.

A process exists that not everyone knows. Something changed, and not every team got the memo. Teams act on outdated assumptions and break things that need to be rebuilt.

The handoffs are not documented. Entry points for cross-team requests live in someone’s head. Routing decisions are tribal knowledge. New people, or people new to that boundary, lose days figuring out what should take minutes.

Templates and resource definitions are wrong or unclear. The team trying to do the right thing fills in the wrong template, or creates the wrong resource type, because the boundary between systems was never made explicit.

None of these are team problems. They are system gaps that produce team problems. Add up four small structural holes at four different handoffs. You get a team whose two-month lead time is invisible to every ceremony it runs.

Rebuild the handoffs, not the team

The team I traced made five moves. Together they cut the lead time by more than half.

Mapped the value stream. Before anything else, the team needed to see what they couldn’t see from inside a sprint. The map showed exactly where the time went. The department heads stopped arguing once they could point at a queue. The map became the team’s first piece of shared truth.

Documented the handoffs. Every cross-team boundary got a written description. Which ticket type goes where, which template applies, who owns the routing decision. Tribal knowledge became standard work. New people stopped losing days at boundaries.

Front-loaded the long lead-time requests. The team established a rule. Anything with a known long wait time, access controls, service accounts, or security validation, gets requested at the start of the deployment, not when it’s needed. Those requests now run in parallel with the rest of the work instead of extending the critical path.

Built an infrastructure-as-code pipeline. One pipeline, customized per environment. The team stopped setting them up by hand. The errors that used to eat days disappeared, because the configuration was now code, reviewed and reproducible.

Moved the handovers earlier. Handovers used to happen at the end of deployment, when the receiving team discovered what was missing. The team moved them before completion, so missing access rights or unclear configurations surfaced while there was still time to act.

None of these required a new tool. None required a reorganization. The team kept running Scrum. What changed was the work between the teams, which had never been anyone’s job to look at.

Three months later

Back to the team we started with. Three months after the interventions were in place, the deployment I had traced was tracking under thirty days. Down from roughly two months. More than halved.

They were inside the target the business had set. Development teams stopped waiting for environments to start their projects. The constraint that had been the loudest complaint across the organization quieted down.

There is one thing I need to say about this team, because it became a problem once the lead time dropped.

The gain was real. Holding the gain is harder. The team that built the checklists, the pipeline, the handover rhythm, and the documentation knows the system because they built it. The next person who joins doesn’t. The team across the wall who handles access controls knows the new routing convention. The next person on that team doesn’t. Onboarding into the new way of working isn’t standard yet. Turnover, even ordinary turnover, threatens what’s been built.

None of this is a failure of the intervention. It’s the next problem the system surfaces, made visible only because the first one was solved. A team that delivers in two months can’t even see this problem. A team that delivers in under thirty days has to.

The lead time number moved. The capability to keep it there is still being built.

The pattern

Scrum showed this team everything that happened inside the sprint. It showed them nothing about the weeks a request spent waiting in someone else’s queue. That is where half the lead time was.

Sprint dashboards make team-level work visible. They show what one team is doing. They cannot show what happens when work crosses a boundary, sits in someone else’s queue, bounces back because of a wrong template, or waits for an access right that one person can grant.

The fastest way to find where delivery actually breaks is not to optimize what you can see. It’s to trace one real request, end to end, through every team it touches. Map the wait time, not just the work time. The numbers on that map have started more conversations in my engagements than any retrospective ever has.

The lead time is under thirty days today. Whether it stays there depends on how well the next new hire on the access team learns the routing. Nodody has written that down yet. If you want to try this, pick one real request and follow it across every team it touches. Write down how long it waits at each step, not only how long someone works on it.

Here is the pattern I see, and what works.

The calendar is the symptom. The fix is not productivity hacks. It starts with auditing where the hours actually go.

Where the hours went

Running this audit with one manager, three teams under him, five buckets emerged.

• Direct management: time spent supporting the tech teams.

• Alignment: time with the wider organization, including upper management.

• Personal work: time for the manager’s own job — thinking, planning, learning.

• Bookable time: time available to work with others, including the tech teams.

• Code reviews: time spent reviewing the team’s code.

The manager’s free time lived in two of those buckets: bookable and personal.

For one observed week, direct management ate 8 hours. Bookable time, another 9. Code reviews, 3. Alignment, 5. Personal work, the hours he needed to think, to write, to plan, to learn: only 4. The smallest bucket was the one his growth depended on.

The system around him had no other way to function. The teams brought every question, every blocker, every decision. He absorbed them. The calendar followed.

Why “block your calendar” doesn’t work

The standard advice for an engineering manager drowning in meetings is the same one I hear everywhere. Block focus time. Say no to meetings. Decline anything not urgent and important.

This advice fails for one reason. It treats time as a personal discipline problem. It isn’t.

If you block two hours of focus time on Tuesday morning and the team has no other way to unblock a deployment decision, what happens? Someone Slacks you. You context-switch. The block is broken. You either answer and lose the focus, or ignore and the team waits while delivery slips. The block doesn’t survive contact with the system that needs you.

The deeper problem isn’t on your calendar. It’s in the workflow that funnels every decision through the manager. You can refuse meetings all you want. The underlying demand doesn’t go away. It shows up as a 47-message Slack thread instead. AI compounds it. Your engineers produce more code and more decisions every week. Every one of them still routes through you.

When you audit the system underneath the calendar, four causes consistently show up.

Role expectations are fuzzy. Nobody on the teams knows exactly which decisions belong to them and which belong to the manager, so the safe move is to bring everything up.

There is no mechanism to see how the teams are actually doing. No clear flow metrics, no visible blockers, no shared signal. The only way to know is to ask. The only person to ask is the manager.

The teams have different needs from the manager, and nothing surfaces those needs. So the manager gives each team the same support. That means over-serving some and under-serving others.

And the manager’s time with each team isn’t tracked. The gap between perceived time and actual time is invisible until you measure it.

None of these are calendar problems. They are system gaps that produce calendar problems. Add up four small structural holes. You get a manager whose week is no longer his own.

Rebuild the system, not the schedule

Here is what works. The four moves I’ve seen implemented that reverse the situation.

Visual management and KPIs visible to you and to the team. It shows how work flows through each team, updated automatically. The team can see its own progression and blockers without booking a meeting. You become the leader who responds to signals instead of inbound noise.

Clear role boundaries with each team. It is about what decisions stay yours and what belongs to the team. How to ask for help, and what help actually means. Thirty minutes per team, replacing months of fuzzy expectation.

Delivery objectives, replacing recurring alignment slots. The objectives drive the meetings. The resulting performance gaps trigger problem-solving and learnings. No objective, no meeting.

Sanctuary blocks defended on the calendar. Personal work and bookable time, both reserved as real appointments, declined when something tried to override them. Bookable time stays open for the team to book when they have a clear ask. Without one, it stays defended.

Six weeks later

Back to the manager we started with. Six weeks after the four moves were in place, his numbers had moved. Personal work more than doubled, from 4 hours to 9. Code reviews dropped from 3 to 1, because the team was unblocking itself. Alignment eased from 5 to 4 as recurring syncs gave way to purpose-driven ones. Across the week, he reclaimed about four hours outright.

Two numbers in the chart need a second look. The simple reading misses what they mean.

Bookable time fell, from 9 hours to 5. On paper that looks like a loss: the manager less available, the team less supported. In practice it was the opposite. The teams used less of his bookable time because they needed it less. Better autonomy showed up as a smaller number. Read only the chart, and you’d flag it as a problem. Read the system, and it’s one of the strongest signals in the data.

The opposite pattern shows up in direct management. It dropped from 8 hours to 6, far from solved. This is the part most case studies would quietly drop. I’m leaving it in, because it’s the truth. Six weeks rebuilt the system enough to reclaim his personal time and to let the teams carry their own load. It did not solve direct management. That bucket needs a different intervention, and it was still open when this snapshot was taken.

The pattern

His calendar was not the problem. Every hour he lost went through one of those four gaps. No amount of declining meetings closes a gap.

Real system work moves some things fast, some slowly, and some not at all in the first cycle. The manager who expects a clean win in six weeks is the manager who gives up in week three. This one didn’t get a clean win. He got his thinking time back, teams that needed him less, and one stubborn bucket still on the list. That’s what progress actually looks like.

Direct management is still at 6 hours a week, so this story is not finished. I will write about that bucket when it moves. In the meantime, count your own hours for one week and see which bucket is the smallest. I would bet it is the one you need most.