Leapfrog was written for one person: the engineer inside a large company who can see what AI makes possible and cannot get anywhere near it.
That engineer is told constantly what AI can do — by management, by vendors, by the innovation department. They are shown frontier models of extraordinary sophistication and reminded that the company must deliver on the AI promise. Integrate it. Find the savings. Show the results.
The effect is not motivation. It is paralysis. Underneath the announcements sits a genuine fear of failing, and that fear has a history.
Anyone who worked in IT through the SaaS years watched the knowledge leave the building. It went to contractors, to consultancies, to vendors. What remained was a team held responsible for outcomes it no longer had the skills to produce. Now that same team is asked to deliver AI. No wonder nobody volunteers.
So the question worth asking is not whether AI is powerful. It is: what does an internal team actually need to know?
For a long time the answer has been the cloud. The move to cloud is one of the key enablers for approaching AI today. Not the only one — and not an invitation to buy everything the cloud provider tells you that you need. The real gift of cloud was self-service: the ability to solve your own problem without asking permission first. AI makes that faster still. Put the two together and you have, in my opinion, a perfect storm.
Meanwhile the frontier model companies are busy defending their rankings on a benchmark. Latest, greatest, biggest. But we passed the point of sufficiency a while ago. The capability needed to do the simple things — the things that would actually change your company — has been sitting there for some time.
Take the invoice exercise in Leapfrog. Reviewing travel expenses is not a glamorous problem. Changing it so that nobody has to review them at all is a real one, and it is solvable today. How you implement it is your business. Should you buy a SaaS product for it? I don’t think so. Many of these workflow tools already have AI built in, and some are open source. Why pay a monthly bill for something you can have out of the box?
That is what the first book is for. Leapfrog is the practical one — the book for the person with some cloud knowledge who wants to get on the AI train.
Submerged asks a different question. Why do we see so little innovation coming out of employees?
I believe innovation has to come from the people doing the work.
This is not a complaint about innovation departments. Their job is real, but it is a different job: scouting, watching what is happening outside, running the occasional proof of concept, cataloguing it, keeping other teams roughly aligned on what is on the radar. That has value. It is simply decoupled from the delivery of value. Nobody in that chain is the person with the problem.
Innovation needs to happen where it is used. The job of everyone else is to equip the people who use it — to put genuinely powerful technology in their hands, safely, without requiring a budget cycle to test an idea.
Which brings me to the problem I have watched inside companies I have worked for, seen in companies I haven’t, and then found waiting for me in the research.
Submerged innovation. Hidden innovation. Submarine innovation.
There are more submarine projects running in your company than you think. The question is why. There are several answers, but the first one is simple: people are afraid of failing.
Here is an unscientific way to put it. Some of us, walking into a shop, don’t want to talk to anybody. We want to look around first, at our own speed, and work out what is there. Only when we have a question do we go and find someone. Innovation works the same way. A team has an idea. They don’t yet know whether it is any good. They need room to find out before anyone asks them to justify it.
But fear is only the beginning. When somebody surfaces a new project, the politics of departments arrives with it. Why did they do that? I had the budget for that. I didn’t deliver it — and now they have. Then comes the cycle of friction and destruction.
Destruction is the right word. These projects are not politely ignored. They are stopped. And the person who surfaced one and watched it die has learned something they will not unlearn: don’t do that again.
So the loss is never one project. The loss is every idea that person will never bring you. It dies quietly, and you will never know it existed. What follows is worse than fear — it is futility. Fear is loud and gets the attention. Futility is quiet, and it is the one that does the damage.
I should include myself here. I have been building small tools with frontier models — some for work, some just for home. Nothing dramatic. And at some point the obvious thought arrives: if I am doing this, and the colleagues sitting behind me are doing this, then there must already be an enormous amount of innovation built and hidden inside this company. A whole submarine fleet, waiting to be found.
But what if it never surfaces?
There is also the money. Companies think in cycles — budget planning, approval, allocation. Innovation does not run on that clock, and it never has.
And here is the part for the executives, which is the heart of this book. If you force the fleet up, if you go hunting for it, you will not find it. You will kill it. People will dive deeper. They will stop using company machines. They will build on their own phones, in their own accounts, at home, where your search and your controls cannot reach. You will not have sunk the submarine. You will have pushed it into international waters — and now you have lost the visibility, lost the control, and gained a data problem you cannot see.
Not everything needs to surface, either. Some of these tools are one person’s helper, and that is fine. If it helps nobody else, let it be. The point was never that everything must come up. The point is that surfacing should be a door people are offered, not a net thrown over them.
So the answer is not to hunt. Give people a safe place to build underwater, at their own speed. Then build the thing that lets a good idea come up when it is ready.
That is what this book is about.
The research led me first to a concept called bootlegging, and from there to a question: has this always been happening? What does the evidence actually say — and is there anything in it for large manufacturing companies in particular, where the capital is heaviest and the doors only swing one way? How do we help them?
That was the work. I did it with AI, of course. I collected a great deal of research, argued with it, and built it through the chapters of this book, trying to get to a better position — and to get the fleet to surface.
Enjoy it, as always. There will be a companion site with the research behind the book, and beyond it, where I will keep offering my opinion and the opinions of others as we go.
That’s it. Have fun.