What Value do we Seek and Why Can't we Find it?
Dromologue was created to answer a simple question asked by many leaders today, “Why is AI not generating as much value as we thought?”
Unpacking this question produces two underlying questions,
- “How much value were we expecting?”
- “Where did we apply AI, in order to produce that value?”
In most cases, the value expected was rather vaguely defined. The industry and its hype suggested major productivity benefits from AI in the build phase of (software) product development. This is somewhat true - developers can get much more done, more quickly than ever before but the DORA report from April 2026 shows that delivery has reduced:
“AI currently hurts software delivery performance: Contrary to expectations, a 25% increase in AI adoption is associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. Because AI allows developers to generate code much faster, it often leads to larger batch sizes, which are slower to review and more prone to creating system instability.”
So if a leader was expecting greater delivery then they may be disappointed. Delivery is really the issue isn’t it? So we may reframe the expected value question with, “What do we hope to deliver?” In my recent experience, the answer within technology was, “nothing (don’t quote me) - we just want to prove the capability.” The answer within business was different, usually very focused on getting a specific task done faster, without much thought about the underlying engineering (or, frankly, security issues). If ever there was a gap between business and technology expectations, AI has surely exacerbated them. But the fact remains that some technology infrastructure needs to be built - to manage security, data access permissions, track the costs of using AI, and so on. In many of the clients I speak to, these are very different tracks with different expectations and plans, which in most cases the technology function hopes will converge, or in the language of business, when technology catches up.
Technology functions have started to build the infrastructure foundations for AI and agent based work has begun in earnest. But, as the AI Platform has developed and the safety and governance of AI has been shored up, the question of value delivered remains in the air, like a giant lead speech bubble.
In our view, a critical practice for AI development is for the redefinition of the historical boundaries between business and technology.
This has two important benefits:
- A shared understanding of value to be delivered, and its priority.
- A shared understanding of changes required to how the business operates, in order to see the value delivered as hoped.
In discussing these benefits, especially the first, we need a quick digression. What was the agile revolution all about? It was never velocity. The purpose of agile - at its core - going all the way back to its lean and TPS roots, was to reduce waste (muda). “Optimizing the whole” to use the lean term entails development in such a way as to respond most efficiently to customer needs. This can result in higher velocity because you are not working on what doesn’t matter. Jim Coplien is really good on this. But, implementing agile, scaling it, requires getting better at getting feedback from customers and optimizing for that whole, not just the invisible (to customers) engineering process behind it. Digression over.
Putting business and technology skills into a single small team - what I have called an Intelligent Pizza Team - keeps the feedback tight and regular between those who specify, build and run. But perhaps not for the reason you think. Not necessarily because we have business, technology, security, architecture people in every team, but because every person in that team, with their background experience and skills, is a builder.
With AI, everyone builds.
But, what gets built? Many organisations start to build the platform on top of the offerings of the hyperscalers. It is as if, the basic fallacy of “build it and they will come” in technology has been forgotten in all the excitement. A Platform for what exactly? In recent memory, data platforms have been built (on Snowflake, Data Bricks, Big Query etc.) and every single one that anticipated the use cases to be developed, got it just wrong enough to either impact the choice of a valuable use case (“we can’t do that yet”) or requiring a redesign of some features of the platform itself. The same will be the way with AI platforms. Usually they start with governance and security, aimed primarily at agent use. Building on top of the foundations provided by these platforms implies making critical choices about the scenarios that need coverage - what do we need to add to? Without specific use cases that match what needs to be built with what needs to be redesigned in how policy is defined and operated technologists tend to design for how (any) policy was implemented rather than how it should be. I am not suggesting that innovation on top of, or in addition to, or indeed instead of, hyperscaler platforms is not required. Merely that sufficient foundations already exist today to vitiate the need to build in anticipation of basic requirements and that innovation in adopting firms needs to be laser focused on building platform capabilities one use case at a time. Very few firms will have the investment required to out-invest the hyperscalers in building and extending these foundations anyway and so I would argue that in general, extending and finding gaps in the hyperscaler platforms needs to be driven by very specific use cases in the business itself. Therefore, the building needs expertise in the business problem being solved and not only the technical challenges with it. The platform is just an example of how poorly value is often traced to business need and articulated.
It may look, on the face of it, like AI is no different from other previous technology ‘revolutions’. Being customer driven and responsive to feedback has always been the target.
For agile, cloud, SRE and DevOps we have invariably compromised the value the technology or method promised by fitting it into how our organisation operates instead of making the changes the new way of building required and tracing them back to the basic operating model of the firm.
The difference this time, as outlined in a previous essay, is that the cost and risk of building experiments is so low now that creating ‘exceptional’ structures and processes for AI no longer seems that risky to your average executive.
The kind of experiments that need to be run target 3 fundamental changes:
- Organising Resources for teams and value
- Building Processes to enable feedback at far greater speed and fidelity than before
- Assuring Outputs when they are produced in a new mix of both humans and machines.
In our view, the delivery of value by AI in a firm is constrained by the extent to which the organisation changes how these three areas function. Experiments need hypotheses to be proven. Making hypotheses about how your operation changes with AI in each of the areas opens up a firm wide conversation about value and a coalition of the informed and willing to consider the changes required in the light of new evidence.
‘Change’ programmes love metrics. Lots of them. In our experience, most don’t drive behaviour change or tactical revisions in how the programme is run. We propose only four key metrics:
- Are we improving at adding value? Value per cost per customer release, where value is the revenue attributed to the release plus the costs it reduced.
- Are we improving at building? The average elapsed time from an item entering the backlog to its production release.
- Is our confidence improving? Of the obligations bearing on this team’s work, how many were provably discharged? This requires codification of policy (and not just security rules).
- Is our operating model improving? Practice conformance per team, counting only what was observed. Our 9 Discipline framework is an example of a starter set of those target practices, but these will always need to be tweaked for the firm.
So, the reason AI often fails to meet expectations is that expectations are ill defined and usually constrained by some organisational scope (e.g business v tech). Each project should be scoped as an opportunity to test the four questions above across the firm, with provisional targets for the next release.