AI is the biggest disruptor since electricity. AI will make developers 10x more productive. Coding is becoming a commodity. AI will allow small teams to build what previously required large teams. Software engineering is becoming agentic. The future is vibe coding. What are our AI adoption numbers? How many AI use cases do we have?
As an engineering leader, I was sceptical of many of these claims, worried about some and did not understand many. And it was my curiosity but also a fear of becoming irrelevant that set me on this path of exploring the world of AI in more depth.
Here is where I landed, before I explain how I got there. Putting AI in the hands of engineers turned out to be the easy part. The tools work, adoption happens, individual productivity genuinely improves. What doesn't happen on its own is any of it reaching the business. AI creates capability. Organisations create value. The distance between those two sentences is the whole problem.
It started with doing some personal projects using AI. I built a personal assistant, automated my quarterly portfolio review, a multi model research system and a few others. I was really surprised with the speed and accuracy with which I built some of these solutions (in some cases under 1 day). By the end of it, I got convinced that AI significantly improves individual productivity.
And then came a push for my teams to adopt AI more and more. Unsurprisingly, most of the engineers had already started using AI in their day to day work. While their individual productivity was improving, there was still no evidence that the same translated into velocity at the organisation level (not significantly and definitely not 10x).
The pattern was easy to see once I went looking. A change that took a few days to build would sit for weeks waiting for a decision, then sit again before it could ship. Nobody was doing anything wrong. The queues on either side of the work had been sized for a world where writing the code was the slow part.
I now had some knowledge of AI and more questions than when I started. I was again worried whether I was the only one struggling with this conversion or whether I had company. I started reaching out to some fellow engineering leaders in the industry to learn whether they were facing similar challenges too. Every one of them could tell me their AI adoption number. No one could tell me what it had bought the business. I was slightly disappointed at still not having the answers but honestly very happy as well to discover I wasn't the only one. Then, I took help from my new friend (Perplexity) and started researching the subject in more depth.
After my many experiments within and outside my teams, my interactions with a lot of engineering and product leaders and the research on various related subjects, I came to this conclusion. It is not just AI but everything around it including your operating model that needs a shift in order to bridge the gap between individual productivity and the business value.
The bottleneck was never the typing. It was everything on either side of the typing, and that is where it still is.
Try this on your own organisation. You probably know your adoption percentage. Now try to say in one sentence what it changed for a customer. If the second is harder than the first, that gap is what this book is about.
The book is my attempt to work all of that out properly, in six parts:
Part 1 - The Paradox: AI is reducing the execution time and there is a clear spike in developer productivity but at the same time most businesses are reporting no significant changes in business outcomes. It is not a paradox and both these things could be true together. The reconciliation is a constraint that moved, and this part is about finding where it went.
Part 2 - The Diagnosis: An honest diagnosis of the value flow and the identification of metrics that give you real visibility into velocity. This is where I introduce "The Five Level Measurement Hierarchy"
- AI Adoption
- Individual Productivity
- Team Effectiveness
- Organisational Throughput
- Business Outcome
Each of these levels has its own metrics. Most organisations instrument the first two, report the last and measure nothing in between.
Part 3 - The Substrate: The foundational work needed to build an AI-Native team: the economics of AI value, team topologies, platforms and data treated as infrastructure. Most of this work is unglamorous but none of this is optional.
Part 4 - The Operating Model: The journey from AI assistants to having agents do the execution. For agents to run autonomously, both upstream and downstream of execution have to evolve. Product has to get better at discovery and at documenting it, because ambiguity a human engineer would quietly resolve is ambiguity an agent will confidently get wrong. Governance sits here too: decision rights, security, Responsible AI.
Part 5 - Leadership and Change: This is the part I found most interesting to write, the human side. Where is the value shifting when execution is getting cheaper? An interesting question I kept coming back to: Where does accountability sit in the agentic era? It closes on change management, which is perhaps the hardest thing to execute.
Part 6 - Becoming AI-Native: What it takes to build an AI-Native Enterprise, ending with a maturity model and a 90 day plan which you can start working on without buying any additional tool or seats.
If any of this resonates with you, do read the book and share your feedback. I'd love to hear if it brought any change for you within your organisation.
If there is one thing you should take back from this article, take this. The engineers are doing their part, it is time leadership did its part too.