AI coding agents have changed how software gets shipped. The old development bottlenecks vanish overnight because an agent can now write a feature or refactor a service in seconds. But that rapid execution exposes a whole new class of problems. The new code runs successfully in the developer’s environment. The automated pipeline runs tests, linting, and build checks. Everything passed. The code gets approved in review. That new feature does exactly what was asked. ...
We’re in a medium-sized tech services company. It is a quarterly review meeting. The management team is reviewing the delivery milestones as committed. When they get to the release calendar, the CEO asks why it’s the same. Indeed, a few months earlier, upon a perfect slide deck from the VP of Engineering and the product leaders, the CEO committed to another investment budget for AI. That deck was about AI adoption. The shared benefit highlighted was everyone using it, with an implicit delivery performance improvement as a consequence. There was no more precision, but everyone saw the need to go all in on AI. ...
Non Right First Time (NRFT) refers to work already done that requires rework, correction, or remediation after the initial attempt. It is a quality problem. 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. ...
FinOps teams struggle to get engineers to take action. This isn’t new. In a FinOps Foundation survey, 40% of respondents rated this issue as their top challenge. The diagnosis was that engineers are unaware of costs. They feel cost is not their responsibility. In addition, they work in environments where delivery deadlines drive effort. The conclusion was that it is an awareness and motivation problem. 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. ...
A consultant cuts a number by 30%, presents the slides, and leaves. Three months later, the number is back where it started. 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. ...
Most of what a manager knows about the work arrives through two filters. 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. ...
From what I saw, the escalation rate is the most misunderstood metric in tech operations. Every escalation is one of two things: 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. 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. ...
I observe engineering teams at work. It is the way I see where the work actually breaks. Here, I was in the room but could not tell who was working on what. 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. ...
One question has trailed the AI wave into every product conversation this year: why bother with customer discovery when you can build the thing in a weekend? 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 number had just hit zero. 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. ...