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 bank ran 17 technicians across 12 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.

Here is the part most case studies cut. 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

Engineering teams don’t have a release problem. They have a system that lets environments drift apart, then hides the drift until a release fails on top of it.

That team had no AI anywhere near its toolchain. Yours does. 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.

Trace the failures to their root first. The releases follow.

If you suspect your release failures are hiding between your environments, 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 on Substack, and I’ll send you the outline.

This story is based on a real coaching project. Some details have been changed to ensure confidentiality.

The tools will not fix how your team feels. Neither will the perks. I learned to measure what does before AI was in the room. Here is what I saw, and the instrument, so you can run it yourself.

The first measurement

An infrastructure team ran production across four time zones. I was there for the delivery numbers: production incidents, alarm volume, and the requests’ backlog. I also 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.

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

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.

Put the two boards side by side, and 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.

Here is the part most case studies cut. 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

Engineering teams don’t have a morale problem. They have a system that produces one. 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.

Fix the system first. The morale follows.

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 you want to run a Voice of Employees with your own leadership team, I run a half-day working session on this exact topic. Reply to this email, or message me directly on Substack, and I’ll send you the outline.

This story is based on a real coaching project. Some details have been modified to ensure confidentiality.

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.

I watched this break in a bank’s engineering team years before AI arrived, which is why I trust the pattern. Here is what I saw, and what works.

Where the defects came from

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.

So I sat with the team, and we analyzed the last 25 defects that had already been corrected. One by one, we uncovered why they were really born. More than half traced to a single place: the analysis handed to developers was wrong before anyone wrote a line of code. The rest came from source-code errors and unit tests that were missing or too weak to catch anything.

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 here is the part most case studies cut, and it is the part that actually matters.

The numbers were never the hard part. Holding them was.

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

Engineering teams don’t have a defect problem. They have a system that lets broken work in upstream, then hides it until it piles up, bounces, and comes back.

That team had no AI in its toolchain. Yours does. 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.

Build the problem-solving first. The quality follows.

If you suspect your defects are bouncing through a flow nobody can see, 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, and I’ll send you the outline.

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 needs a second look, and it’s the one most case studies would round up. 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.

Project portfolios don’t have a skills problem. They have a system that hides the collisions, and the collisions eat the dates.

That team had no AI anywhere in its toolchain. Yours does. The collisions are the same; there are just more of them, and they stay invisible until a date is already gone.

Put the work on one wall first. The delivery follows.

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

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 your portfolio looks like this one, 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.

I’ve been in that situation with many engineering teams. Here is the pattern I see, and what works.

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. Faster code does not reach the slow part because the slow part lives between teams, in places no standups or ceremonies reveal.

Where the time went

The DevOps team ran Scrum. Two-week sprints, daily standups, sprint planning, retrospectives, all of it. They tracked velocity. By every internal habit, they were doing it well.

But 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.

I followed one deployment request from the moment it was submitted until the environment was ready for use. The official process had a handful of steps. The reality I saw had dozens of failure points inside those steps.

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 mapped that value stream end to end. The map showed something the team had never seen on a single sheet.

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.

One thing didn’t come for free, and it’s the part most case studies leave out.

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

Engineering teams don’t have a velocity problem. They have a system that produces a lead-time problem, and most of it lives between the teams, not inside them.

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.

Map the flow first. The speed follows.

If you suspect your lead time hides between teams too, start with the Delivery Scorecard. Two minutes, ten questions, it points at the queue. 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 and I'll send you the outline.

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

Engineering managers don’t have a time problem. They have a system that produces a time problem.

The calendar reflects the system. So does the burnout.

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.

Design the system first. The time follows.

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