When the Numbers Are Green, Nobody Asks How
The water for my tea was already hot.
I was standing at the window, watching the orchids on the sill. They had been germinating for weeks, each one moving at a pace that only patience can follow. I was reviewing my notes for a new engagement on the tablet beside me; a CTO in Germany, financial sector, who had asked for a deep dive after completing the AI Readiness Assessment online.
The assessment results were already in front of me. The conversation was an hour away.
I did not yet know that he had come in expecting one conversation and would leave having had a completely different one.
He had done everything correctly.
This is the first thing to understand about him, and about the situation he was in. Agile. DevOps. Scaled Agile. AI adoption. Each wave of transformation arrived, and he had moved with it, the way experienced leaders do; not late, not panicked, but deliberately, following the pattern that had worked before. His organization had resources. His board was aligned. His team had tools.
When the financial indicators stayed green, there was no reason to look deeper. In the world of organizational transformation, there is an understanding that settles in quietly: when the numbers are good, the question of how they got there feels unnecessary. The soup is rich. Why examine the recipe?
The AI Readiness Assessment changed that.
He had taken it expecting confirmation. What he received instead was a map of a terrain he had not known existed. By the time we sat down to talk, something in him had already shifted. The certainty that had organized his thinking for the past year was quieter than it had been. Not gone; but quieter.
The first thing the assessment surfaced was attention.
His team was moving fast. AI tools were generating output at a pace that no previous tool had approached. But the people responsible for reviewing that output were operating in the same environment they had always worked in; interrupted constantly, context-switching between priorities, carrying the ambient load of a transformation still in progress.
Recovering full focus after an interruption takes more than twenty minutes. The average developer is interrupted every eleven. AI does not wait for focus to return before generating the next output. The gap between what is produced and what is genuinely understood by the humans who deploy it is not a gap of capability. It is a gap of attention; and attention is not something you close with a new tool.
He had not thought of it in those terms before. He thought about it now.
The second thing was technical depth.
Not skill; depth. The distinction matters. His developers were skilled. They could work with AI. They could generate, integrate, deploy. What they were less prepared to do was challenge. To look at what AI had produced and interrogate it; not accept it, not refuse it, but verify it against independent assumptions, test it against adversarial conditions, hold it to a standard that did not depend on the confidence of the output itself.
The assessment showed a picture of technical excellence that was a few notches below what AI amplification requires. When AI amplifies what a team can do, it amplifies everything; including the things the team has not yet learned to question.
The third thing was product clarity.
His product organization was moving at a speed that made sense before AI. Discovery cycles, backlog refinement, specification work; all of it operating at a human pace, because that had always been the constraint. The developers could only build as fast as they could type. Now they could build faster than the product team could think.
The specifications reaching the developers were vague in the way that specifications have always been vague; clear enough for a human who can ask questions, fill gaps, apply judgment. Not clear enough for AI, which does not ask questions. It fills the gaps itself, with plausible assumptions, and builds what it infers you meant.
The code that resulted passed review. It deployed. It ran. What it solved was sometimes the right problem and sometimes an interpretation of the right problem; and at AI speed, the distance between those two things compounds quickly.
The fourth thing was the feedback loop.
Between a release and a clear signal from the market, there was a lag. This had always been true. Before AI, the lag was acceptable because the release cadence was slow enough to contain the cost of a wrong turn. With AI, the release cadence had accelerated. The feedback loop had not.
Each vague specification fed an AI that produced plausible code. The code shipped. The feedback arrived slowly. By the time the signal came back that something was off, the codebase had moved. The product direction had moved. The customer experience had moved. Reversing it required not just a correction but an inversion; and flywheels, once moving in the wrong direction, do not stop easily.
Customer satisfaction had been declining in a way that looked gradual from inside and felt sudden from outside. The mechanism that would eventually slow the decline was already almost too slow to catch it.
When he described this in the conversation, he used the word inertia. Not as a metaphor. As a precise description of what had happened.
The distance between where they were and where they needed to be was not what he had expected.
He had expected a gap in tooling. What the assessment had found was a gap between the tooling they had and the readiness of the people using it. The tools were there. The capacity to use them well; across all four dimensions, focus, technical depth, product clarity, feedback speed; was not yet there to match them.
This was the starting point of the last mile.
What happened next surprised him in a way that might surprise you too.
The work that followed did not begin with the developers.
It began with the product people.
Because AI does not allow you to separate product thinking from engineering execution anymore. The two have always been connected; everyone in software knows this, in the abstract. AI makes it concrete. Vague product thinking produces vague AI output produces vague software produces slow feedback produces compounding debt. The chain is visible, measurable, and faster than any previous tool made it.
The product organization needed support on the same four dimensions as the engineering team. The developers could not be ready if the product managers were not ready. They were two sides of the same coin, and you cannot spend a coin with only one side.
Agile; with a small a, the agility that lives in the core tenets rather than in the ceremonies; became the organizing principle. Not a framework to implement. A mode of working to recover.
Then something happened that neither of us had fully anticipated.
The developers re-started enjoying their work.
Not performing enjoyment. Not reporting satisfaction in a survey. Actually looking forward to what they were building, the way that people look forward to things when the work feels meaningful and the tools feel like amplifiers of what they already know how to do rather than accelerators of what they do not.
The disengagement that had settled into the organization; the particular flatness that arrived after the pandemic and never fully left; started to lift. Not everywhere at once. Gradually, the way orchids germinate; at a pace that only patience can follow.
This required something from the leadership that they had not expected to need.
An organization moving faster than its management can govern is not a technology problem. It is a leadership problem. A new kind of leadership problem; one that requires understanding how to lead when the pace of output has changed but the capacity for oversight has not.
The management layer went through an AI-governance program. Not compliance training. Not a policy workshop. An honest engagement with what it means to be responsible for an organization that produces at AI speed; and what governance looks like when the thing you are governing is not just people, but the systems those people are directing.
This was the last mile. Not the one anyone had expected. But the one that was actually there.
The reason I am telling you this story is not the outcome.
The outcome is still in progress. The flywheel is moving in a better direction. The customer satisfaction indicators are recovering. The codebase is more legible. The product organization and the engineering team are working in something closer to tandem.
The reason I am telling you this story is the question the CTO asked me at the end of our first conversation.
He asked:
“If I had not taken the assessment, how long do you think it would have taken us to see this?”
I did not give him a number. But I thought about the organizations that have not taken it yet. The ones where the financial indicators are still green. The ones where nobody is questioning the recipe because the soup still tastes rich.
The assessment does not find what is wrong. It maps where you are; so that the distance between here and a governed, sustainable way of building with AI is something you can see and walk, rather than something that arrives as a crisis after the flywheel has already turned.
It takes five minutes. It costs nothing.
If you have not yet asked your own version of his question, that is where to start.
Next week: what happens when every indicator says green, the team believes it completely, and the data says something different. The cost of blind trust is not always visible until the flywheel has already turned.