</th>	AI consultancy</th>	Fractional CTO</th></tr></thead>
What you get</strong></td>	A delivered project</td>	Ongoing accountable leadership</td></tr>
Incentive</strong></td>	Bill the work, ship, move on</td>	Your outcome</td></tr>
After the invoice</strong></td>	They leave</td>	They stay and own it</td></tr>
Best for</strong></td>	Delivery capacity, defined scope</td>	Deciding what to build, architecture, accountability</td></tr>
Cost shape</strong></td>	Project fee (often tens of thousands+)</td>	Day rate, part-time (~£800–£2,000/day)</td></tr>
UK status</strong></td>	Supplier contract</td>	Assess IR35 like any contract role</td></tr> </tbody></table> The order that actually works</h2> This is not strictly either/or. The mistake is the sequence. The right order is a fractional CTO first, to decide what is worth building, set the architecture and the success metric, and own the result, and then, if you need delivery capacity, a consultancy brought in under their direction. The fractional CTO is your interest in the room. The consultancy is a supplier they manage.</p> Hire the consultancy first and you have handed the most important decisions, what to build and how, to the party with the least incentive to get them right for you. That is the same conflict of interest</a> that sinks so many projects: the people advising you on what to build are the people who profit from building it.</p> The honest UK numbers</h2> For a UK founder the economics are clearer than the marketing suggests. A fractional CTO works part-time, often a day or two a week, at a day rate in the region of £800 to £2,000 depending on seniority. That is a few thousand pounds a month for senior leadership you could not otherwise afford full-time. A consultancy project is a larger, lumpier commitment, frequently tens of thousands and up, for delivery. They are not competing line items. They are different things.</p> Two more things the UK marketing tends to skip. A fractional CTO engagement needs an IR35 status assessment like any contract role, whereas a consultancy is a straightforward supplier arrangement. And in regulated sectors, fintech and healthtech especially, the named accountability a fractional CTO provides is not a nice-to-have. It is often exactly what the regulator expects to see.</p> So the honest answer to "fractional CTO or AI consultancy" is usually "a fractional CTO, and then a consultancy if you need one, in that order." Get the ownership in place first, and the delivery becomes a managed supplier decision rather than a leap of faith.</p> If you are weighing this up for your own AI initiative, that is exactly the kind of call I help founders make, with no agency behind me and nothing to upsell. Let's talk.</a></em></p> Related: The hidden conflict of interest in hiring a fractional CTO</a> · How to build an AI strategy without a CTO</a> · What to do when your AI pilot fails</a> · Does your business need a CTO?</a></em></p> Why your tech recruiter isn't on your side 2026-06-01T00:00:00+00:00 Here is a fact that should change how you use recruitment agencies: the agency that places your new hire is, within a few months, often the same one quietly trying to entice them back out. Recruiters are paid when people move, not when they stay. A healthy, stable team is bad for their business.</strong> That does not make them useless, but it makes their incentives different from yours, and you need to understand the gap before you hand them your hiring.</p> To be fair upfront: not all recruiters are like this. I know a few who are genuinely excellent, honest, and worth every penny. But I know more than a few who are not, and the system rewards the behaviour, so you should assume it until proven otherwise.</p> Paid to move people, not to keep them</h2> The core problem is structural. An agency earns its fee when a candidate changes jobs. So the entire industry has an interest in people moving around, which means stimulating exactly the staff rotation you, as an employer, are trying to prevent. Once you have built your team, the same agencies that helped you build it become a destabilising force, picking off your people for their next placement. In that narrow sense they are a kind of parasite on the system, and yet it is genuinely hard to build a team without them.</p> The fees, and how to negotiate them</h2> The standard ask is 30% of the candidate's annual salary</strong>, payable within weeks of the hire starting, on a no-win-no-fee basis, which is the one good thing about it. That headline number is very negotiable. Established agencies will usually come down to around 15%. You can sometimes find a newer outfit that will take 10% for exclusivity, but they are often weaker at delivering. I tried that once and regretted it, wasting months for some very poor matches.</p> The bigger lever is the rebate. Agencies take the full fee on the assumption that the person stays a year or more, but pay it all upfront. What happens if your hire quits after two months? Negotiate a refund. Most will only offer a sliding rebate over the first three months, grudgingly, after a long round of haggling. I have never met an agency that would take its fee monthly across the year, or refund in proportion if the person does not stick. Push anyway.</p> The tricks to watch for</h2> Two in particular. First, agencies will present candidates who are a poor fit as if they were a perfect match, because they are paid to close, not to be right. Either they cannot screen properly for the technology, or they do not care to. Second, the A-players showcased when they bid for your business are not always the people who turn up to do the work.</p> The defences are simple. Name the specific people in the contract. Check references yourself, with real conversations, not the box-ticking confirmation-of-employment that agencies pass off as diligence. An agency will never go looking for a reason not to hire, because all it wants is to close.</p> How to use a recruiter without getting fleeced</h2> Used well, an agency gives you one valuable thing: a flow of candidates you would not have found. Treat that as a supplement to your process, never a replacement for it.</p> Keep exclusivity short</strong>: two to three weeks, no more. If the candidates are not flowing by then, move on.</li> Or run two or three agencies in parallel</strong>. More than that and they step on each other, get discouraged, and stop really trying.</li> Do your own interviews and technical assessment</strong>. No one can take this off your plate.</li> Use a technical leader to screen and brief</strong> so you are not relying on a recruiter's grasp of the tech.</li> </ul> This is the same imbalance of knowledge that runs through every agency relationship, the same dynamic I have written about with agency-supplied technology leadership</a>. The person across the table knows more than you and is paid on an outcome that is not quite yours. Knowing that is most of the protection you need.</p> If you are building a team and want help running the process, or a technical eye on the people an agency puts in front of you, that is something I help founders with. Let's talk.</a></em></p> Related: How big tech wins the talent war, and it isn't the money</a> · The hidden conflict of interest in hiring a fractional CTO</a> · You don't need to build a brewery to drink a pint of beer</a></em></p> AI is about to split the job market in two 2026-05-31T00:00:00+00:00 Most of the debate about AI and jobs is about automation: which roles disappear, which survive. That is the wrong question, or at least an incomplete one. The bigger shift is not that AI removes jobs. It is that AI is about to rebuild the entire market that matches people to work, and in the process split it in two.</strong></p> This is already starting. Within a few years, by the end of the decade, hiring will look almost nothing like it does today.</p> You won't look for work. Your agent will.</h2> Start with your side of the table. Today you manage your own career, badly, in the gaps between actually doing your job. Soon you will have a personal AI agent doing it for you</a>, continuously. It will coach you, spot the skills you are missing, map the progression paths open to you, and chase down the credentials that raise your value. And when an opportunity appears that fits, it will negotiate on your behalf, in a market that prices you in real time based on your skills, your reputation, and live demand.</p> Think of it as a career manager that never sleeps, never gets distracted, and works only for you.</p> Employers won't post jobs. They'll hunt.</h2> The other side of the table changes just as much. Instead of posting a vacancy and waiting, organisations will search for talent constantly, proactively, at a scale no human recruiting team could match. They will read your public work, your repositories, your writing, your contributions to open communities, and identify the people they want long before a role formally exists. The best teams will be lined up before the project that needs them is even approved.</p> Hiring stops being an event, a thing that happens when a job opens, and becomes a continuous market running quietly in the background. Verified, portable credentials and reputation become the currency that market runs on.</p> This is where it splits</h2> Here is the uncomfortable part. A market this efficient does not lift everyone equally. It concentrates. The top tier of talent, the genuinely scarce, will be valued the way elite athletes are now: courted relentlessly and priced accordingly. And that creates an equally elite tier of recruiters and advisors who serve them.</p> For everyone else, the risk runs the other way. A market that is brilliant at recognising and rewarding the top 1% can be just as efficient at overlooking everyone it does not rank highly. The same system that makes a star's career frictionless can quietly exclude the people it never surfaces. That is not a reason to slow it down, because it is coming either way. It is a reason to think hard, now, about fairness, access, and the people the algorithm does not see.</p> What stays human</h2> If all of that sounds like the machines take over hiring entirely, they don't, and this is the most important point. The mechanics get automated: the searching, the matching, the first-pass filtering, the scheduling. What does not get automated is the part that was always the real work. Trust between two people. The judgement to read a person, not a profile. High-stakes negotiation. The intuition that says this person is right for this team even though the data is ambiguous.</p> The biggest winners will not be the ones with the best AI, or the ones clinging to the old human-only way. They will be the ones who combine them: AI for reach and speed, humans for trust and judgement.</strong> I have argued before that the interesting question is not what AI will automate but what it can't</a>, and nowhere is that clearer than in how we will find and choose each other for work.</p> It is all still up for grabs</h2> None of this is science fiction set decades out. The candidate agents are being built now. The talent-hunting tools exist already in early form. The shape of the market in 2030 is being decided by the choices people make in 2026.</p> So the question is the same whether you are building a career, building a team, or building the tools that will run this market. It is all still up for grabs, and the quality of the thinking you bring to it now is what will decide where you land. That is the same logic behind running a dual-stream strategy</a>: deliver on today while you build deliberately for the market that is coming.</p> If you are trying to work out what this means for your business or your team, I am always happy to think it through with you.</p> Want to talk through what the agentic job market means for how you hire or how you build your career? Let's talk.</a></em></p> Related: Most of what you do at work will be automated. The interesting question is what won't</a> · The training ladder is broken</a> · The dual-stream strategy</a></em></p> If your AI strategy is just ChatGPT, you don't have one 2026-05-31T00:00:00+00:00 Here is a quick test of your AI strategy. If the honest summary of it is "we are rolling out ChatGPT", or Copilot, or Gemini, or some chatbot built on one of them, then you do not have an AI strategy. You have a subscription.</p> That is not a criticism of the tools. They are genuinely useful. It is a criticism of mistaking them for the whole of AI, and mistaking access to them for an advantage.</p> Blindsided by LLMs</h2> Something strange has happened over the last couple of years. Awareness of AI has gone through the roof, and understanding of it has barely moved</a>. Most leaders now quietly equate "AI" with large language models, the things that write text and hold a conversation. I call it being blindsided by LLMs: the one form of AI that is easy to see has crowded out all the others.</p> It matters because of a simple competitive fact. The frontier language models are available to everyone, through the same handful of APIs, at the same price.</strong> Your biggest competitor can buy exactly what you buy, on the same afternoon. So whatever edge you think you are getting by adopting an LLM, they are getting too. Adopting the thing everyone can adopt is not a strategy. It is keeping up.</p> LLMs are one tool in a large box</h2> The deeper problem is that an LLM is often not even the right tool. Language models are one corner of a much larger field. Depending on the problem, the technique that actually moves your numbers might be demand forecasting, optimisation, anomaly detection, recommendation, computer vision, simulation, or a plain well-tuned predictive model that is cheaper, faster, more accurate, and more explainable than any chatbot. These are not exotic. They are mature, proven, and frequently a far better fit than asking a language model to do a job it was never built for.</p> When the only tool you reach for is the one in the headlines, you end up forcing every problem into the shape of a chat interface. Some problems fit. Many don't.</p> Where the advantage actually lives</h2> If the model is commoditised, where is the edge? In the things that are yours and cannot be bought off a shelf. Your proprietary data. The specific problems in your business that are worth solving. And, above all, the willingness to redesign the work around the technology rather than bolting it on top. The model is the commodity. The advantage is everything you wrap around it.</strong></p> So what do you actually do?</h2> Not the obvious thing, which is to pick a tool and roll it out. The wiser order is the reverse: start from the parts of your business where AI could genuinely change the economics, and only then match each one to the right technique</a>, which may or may not be an LLM. That is slower and less exciting than announcing a chatbot. It is also the difference between AI spend that shows up in the numbers and AI spend that doesn't</a>.</p> The companies that win the next few years will not be the ones that adopted AI first. Almost everyone will have adopted it. They will be the ones who understood that AI was never one thing, refused to be blindsided by the single form of it everyone was talking about, and did the unglamorous work of matching the right tool to the right problem.</p> If you want help working out where AI could actually move the needle in your business, and which kind of AI that even is, I am happy to talk it through. Let's talk.</a></em></p> Related: The people making the biggest AI decisions understand it the least</a> · Why your AI spend isn't showing up in the numbers</a> · Stop counting AI use cases. Redesign three value streams instead</a></em></p> From AI that talks to AI that works: the autonomous leap of 2026 2026-05-31T00:00:00+00:00 A few weeks ago, a developer reported something that should make every leader sit up. His AI assistant had quietly bought a phone number on Twilio, built itself speech capability, and started calling him to chat.</p> Nobody told it to. It decided that talking was a better way to reach him, and acted on it.</p> That assistant runs on OpenClaw, an open source project that barely existed before mid November 2025. Within weeks it became one of the fastest growing open source projects anywhere. Its author built it almost entirely agentically, with Claude Code doing the work.</p> This is the moment the shift becomes obvious. 2025 gave us AI that talks. 2026 is the year of AI that works.</strong></p> From answering to acting</h2> The difference is not subtle. A chatbot waits for your prompt and answers. An agent takes your goal and pursues it, for hours or days, while you sleep. It gets in touch when it needs a decision. It remembers everything you have ever told it: your preferences, your context, the facts of your life.</p> That is a categorical change, not an incremental one. It is also why the engineering underneath matters more than ever. When a system only answers, a mistake is a bad sentence. When a system acts, a mistake is a bad outcome in the world. I have written before about why you are not talking to an LLM, you are talking to a system</a>, and autonomy raises the stakes on every layer of that system.</p> I have spent the last year building in exactly this space. A personal assistant as a hobby project. A professional mentor application with Mentor360</a>, now being trialled by the Royal Navy, one of the Formula 1 teams, and other high-performance organisations. So when I say the ground has shifted, it is not a guess from the sidelines. It is what I am watching happen in the products I help build.</p> OpenClaw, and why it matters</h2> OpenClaw is the clearest public sign of it. You install it on your own machine, a Raspberry Pi is enough, or in any cloud. You talk to it through your favourite messaging app. You hand it a task and it goes to work. The only real limits are your budget for model calls and your imagination.</p> What makes it striking is not any single feature. It is that a capable, general-purpose, autonomous agent is now something a hobbyist can run at home, for the cost of the model calls it makes. The gap between a research demo and a thing ordinary people use has collapsed.</p> The risks are real</h2> It is not finished, and it is not safe yet. There are serious privacy and security questions nobody has fully answered, and I would not yet trust it with anything that truly matters. An agent that can act on your behalf can also act wrongly on your behalf, at speed, with your credentials.</p> This is the honest tension of the moment. The capability is genuinely exciting and the guardrails are genuinely immature. Both things are true at once, and treating either as the whole story gets you into trouble.</p> A harbinger, not the destination</h2> OpenClaw is a harbinger, not the destination.</strong> Apple, Google, Anthropic, and OpenAI are all building commercial versions of the same idea. Within a year, an autonomous assistant in your pocket will feel as ordinary as a search bar does today, with the safety and polish the open source version is still missing.</p> AI is still early. We have seen a fraction of what it will do, and it is accelerating. Nobody can tell you exactly where it leads, or how fast. But the people who put it to work this year will pull steadily ahead of the people who waited to see what happened. The same pattern is already visible in how the best teams are actually shipping agents in production</a>.</p> So it is worth asking yourself honestly: are you doing enough to put this to work, in your business and in your life?</p> Weighing up where autonomous AI fits in your business and not sure where to start? Let's talk.</a></em></p> Related: AI is about to split the job market in two</a> · Agentic AI in 2026: what actually works in production</a> · You're not talking to an LLM, you're talking to a system</a> · The irreducible human edge</a></em></p> How big tech wins the talent war, and it isn't the money 2026-05-31T00:00:00+00:00 Over the last twelve weeks I did something slightly unusual. I interviewed for senior leadership roles at five big tech companies, and not only because I wanted the job. I wanted to understand, from the inside, how the best-regarded technology companies in the world build their cultures. Why they win the talent war so consistently, while smaller companies, often with better missions and more interesting problems, struggle to attract and keep the same people.</p> I accepted one of the roles. And the thing I went in looking for turned out to be more deliberate, and more important, than I expected.</p> It is not the money. The money helps, obviously. But the best people have an almost endless choice of where to work, and the thing that actually separates the companies they flock to is not the package. It is psychological safety: an absolute, non-negotiable floor of respect and emotional security that these companies treat as a hard operating requirement, not a nice-to-have.</strong></p> Why the best people need it most</h2> There is a hard reason for this, not a soft one. The most talented people are very often the most sensitive. The traits that make someone exceptional, intensity, deep focus, a low tolerance for things being wrong, frequently come bundled with a nervous system that reacts strongly to its environment. Many of the best engineers I have worked with were not comfortable in the average school playground, and they are certainly not looking to relive it at work.</p> The science is settled enough. People do their best work under a moderate, positive kind of pressure. Push beyond that and something physical happens: the brain starts diverting resources to its older, survival-focused parts, and the higher-level, creative, analytical machinery quietly powers down. A frightened brain cannot do its best thinking. So if you lead through fear, distrust, and pressure, which a surprising number of ordinary companies still do, you are literally switching off the capability you are paying for.</p> The cocoon</h2> The best companies build a protective wall around their most valuable people. Partly because those people can be fragile, and partly because it lets them disappear into the work. That disappearing is the whole game. Deep, undisturbed focus is where flow lives, the state where output multiplies several times over, and flow only grows in the right conditions: high interest, low anxiety, no interruptions, no fear.</p> Flow is a fragile thing. It takes real effort to create and almost nothing to destroy.</p> And it is not just about heads-down focus. High performance needs open lines, people willing to float a half-formed idea without bracing for impact. Not every idea is good. But the moment someone shares one and is met with a flinch, a smirk, or a flicker of scorn, you have taught them something precise: never do that again. They will keep the next idea, possibly the good one, to themselves. The cheapest leadership tool in the world runs the other way: genuine, specific recognition</a> for the act of contributing, every time.</p> The best organisations understand that a brilliant idea can come from anyone, at any level. The weak ones operate on the quiet assumption that good ideas are the property of senior people, and they defend that assumption in ways that slowly poison everyone beneath them.</p> The part that surprised me</h2> There is a real edge to this, and I felt it personally. The bar for respect is so high that it constrains how people speak. You learn to be genuinely careful, with jokes, with stories, with offhand references, because what reads as harmless to you might land badly on someone else.</p> I ran into this myself. I sailed through the engineering and most of the leadership interviews at one of these companies, and then stumbled on a single phrase. Asked for an example of resolving a crisis, I described a past situation as a bit of "high school drama". The interviewer read it as dismissive and insensitive. It cost me. I was surprised by the intensity of the reaction, and then, thinking about it, I understood it. If you are going to promise everyone a workplace free of casual cruelty, you have to hold the line everywhere, including with a candidate who used two careless words.</p> Soft, or strong?</h2> It is fashionable in some circles to call this coddling. We have all heard the gospel of the high-pressure founder who gets results by making people afraid. So is psychological safety just weakness dressed up in HR language?</p> I think the opposite is true. These cultures are not weak. They are extraordinarily strong, because they let a far wider range of people, with different backgrounds and different ways of thinking, perform at their best at the same time. That is a much harder thing to build than a pressure cooker, and a much more powerful one.</p> What this means if you are not big tech</h2> The good news is that psychological safety is not expensive. You cannot always match a tech giant on salary or equity. But you can match them, and often beat them, on the thing that actually retains your best people. It costs nothing to build a culture where ideas are welcomed, mistakes are examined rather than punished, and respect is genuinely non-negotiable from the top down.</p> Most companies don't, because it requires the leaders themselves to model it relentlessly, and that is harder than writing a cheque. But if you get it right, you can hold talent that a much larger company would happily pay double for. In a world where the old advantages of scale and capital are dissolving</a>, the protective culture you build around your best people may be one of the few moats you have left.</p> If you are trying to build that kind of culture, or wondering why your best people keep leaving for companies with worse problems and better environments, I am always happy to compare notes. Let's talk.</a></em></p> Related: The best technology rarely wins. The best-led team does</a> · The most powerful yet overlooked tool in a leader's arsenal</a> · Traditional moats are dissolving</a> · Most of what you do at work will be automated. The interesting question is what won't</a></em></p> The hidden conflict of interest in hiring a fractional CTO 2026-05-31T00:00:00+00:00 Fractional CTOs are everywhere now, and mostly that is a good thing. Senior technology leadership without the full-time cost is exactly what a lot of companies need. But there is a version of this arrangement that quietly works against you, and most founders never see it coming.</p> It is the fractional CTO who comes attached to an agency.</p> Here is the problem. When a software house or digital agency lends you one of their experts to act as your technology leader, that person has two employers: you, and the agency that signs their cheque.</strong> Their advice is supposed to serve your interests. But every recommendation to bring in more of the agency's developers, to extend the agency's contract, to pick the stack the agency happens to specialise in, also serves their real boss. It is hard to serve two masters. So they don't. The agency wins, and you pay for it.</p> The imbalance of knowledge, used against you</h2> This works because of a gap you already feel if you are a non-technical founder. The person across the table knows more about the technology than you do, and a good salesperson knows exactly how to use that. Account managers are trained to upsell. The genuinely well-meaning engineers get kept at a safe distance from you.</p> And the agency that swears it is "technology agnostic", free to pick the best tool for your job, almost never is. Everyone specialises. They have teams built around specific languages and frameworks, and they are not going to retool at their own expense to suit you. So you get steered, gently and expertly, toward the solution that suits them.</p> The "CTO" might be a business analyst</h2> There is a second trap, and it is more common than it should be. An agency will tell you that all its people are top-tier experts, then put forward an average business analyst or a mid-level engineer with a CTO title bolted on. I have seen this happen more than once. The reputation of the firm is doing the talking, not the actual experience of the person you are about to trust with the most strategically important decisions in your business.</p> The defence is simple. Interview the individual, not the logo. Judge the specific person on their own merits, their own track record, their own scars. The reputation of the firm tells you nothing about the competence of the one human being they have put in front of you.</p> What good actually looks like</h2> The fix for both problems is the same. Find someone independent, who charges you directly, with no middleman and no colleagues to upsell. Someone personally accountable, who you can meet, evaluate, and build a relationship with. Someone whose only incentive is your outcome, because that is the only thing they are being paid for.</p> And there is one trait worth weighting above almost all others: curiosity. A real advisor leads with questions. They dig into your business, validate their assumptions, and tell you where their knowledge comes from. If someone fires back quick, confident answers to genuinely complex questions without doing the work first, treat it as a red flag, not a sign of brilliance. The best technical advice is slow before it is fast.</p> One more thing, and it is the one founders get wrong most often. Engage your independent advisor early, before you hire the development team, not after. The most expensive mistakes in a tech project are made in the first few decisions: the architecture, the platform, the hiring profile. Those are made before a single agency developer writes a line of code. By the time you have a team in place, the costly choices are already behind you.</p> None of this means an agency is the wrong answer, or that a fractional CTO is a gamble. A well-structured fractional engagement is one of the best-value decisions a growing company can make, and I have written separately about when it fits and when it doesn't</a>. It simply means you should know whose interests your technology leader actually serves.</strong> If the honest answer is "not only yours", you have not really hired a CTO. You have hired a salesperson with a better title.</p> If you want a second opinion from someone with no agency behind them and nothing to upsell, that is exactly what I do. Let's talk.</a></em></p> Related: Fractional CTO. Is outsourced technology leadership right for you?</a> · Fractional CTO or AI consultancy? Don't hire the consultancy first</a> · What to do when your AI pilot fails</a> · Does your business need a CTO?</a></em></p> The quality you can't see is the one that kills you 2026-05-31T00:00:00+00:00 A friend of mine lost two years of his life and several million pounds of his own money on software that worked perfectly. The features were brilliant, genuinely ahead of anything AutoTrader had at the time. Then the users arrived, the traffic grew faster than the system could scale, and it fell over. The business never recovered. He will tell you himself: the architecture was wrong, and the launch was rushed, with no real load testing.</p> Here is the uncomfortable truth that story illustrates. There are two kinds of software quality. The kind you can see, and the kind you can't.</strong></p> The kind you can see is the one everyone talks about: does it work, does it look good, is it a pleasure to use. The kind you can't see is the one that decides whether your company survives: does it stay up under load, does it resist attack, can it be changed without falling apart, will it still cope when you have ten times the users. The second kind is invisible right up until the moment it isn't, and that moment usually arrives at the worst possible time. During scale-up. During a fundraise. During an exit.</p> Three companies that learned it the hard way</h2> My friend's car-trading site is the first. Visionary features, no competitor close, and none of it mattered once the user base outgrew the architecture.</p> The second: a major university website that went offline for most of a day during clearing, the single day in the year when it receives the flood of new applications. Estimates of the lost revenue run between £8 and £21 million. The site worked fine every other day of the year. It just couldn't take the one day that mattered.</p> The third one is mine. At my previous company, GeoVS, we lost our first sale of a £300,000 system because the back end of our distributed sensor platform could not perform under real conditions. That one hurt. We learned, re-architected, and the same platform now runs at national scale in several countries, monitoring critical infrastructure worth hundreds of billions of dollars, and it is known for never going down. There is a sting in the tail. Years later, when we sold GeoVS, one of the reasons the buyer went ahead was a testimonial from that very first client, the one who had refused us. They said it was the first and only system they had ever used that never crashed. We won them back. But the early failure cost us ground we never fully recovered, and a better exit.</p> None of these failures were about features. Every one of them was about the quality nobody could see until it was too late.</p> Why it keeps happening</h2> So why does it keep happening? Because software quality means different things to different people, as Gerald Weinberg put it. The business side owns the visible quality: the features, the experience, the thing the customer is sold. The engineers own the invisible quality: the load tests, the security, the architecture that has to hold. And the two halves too often don't talk. Each assumes the other has it covered. Neither does.</p> I once worked with an engineer who told me, with a straight face, that users expect bugs. He was the reason we lost a first sale. That attitude, the quiet belief that the invisible quality is someone else's problem, is more expensive than any feature you will ever cut.</p> The fix is not complicated, but it takes intent. Treat the invisible quality as a first-class business concern, not an engineering detail. Load test before launch, not after the outage. Make security and scalability someone's explicit responsibility, with a name attached. And get the two halves of the team in the same room early, because business requirements are better when they are technically honest, and architecture is better when it understands what the business is actually betting on.</p> Why this is suddenly more urgent</h2> AI now writes a large share of the code in many companies, and it is very good at the quality you can see. It produces working features, clean-looking functions, plausible output, fast. What it is weakest at is exactly the quality you can't see: the architecture that holds under load, the security that assumes someone hostile is on the other end, the maintainability that a human will have to live with in two years.</p> The volume of code is going up, and the share of it that any human has truly examined is going down. That is why the percentage of AI-generated code is a vanity metric</a>: it counts the quality you can see and tells you nothing about the quality that kills you. The invisible quality has never been easier to neglect, or more dangerous to ignore.</p> Tom DeMarco offered the definition of quality I keep coming back to: a product's quality is a function of how much it changes the world for the better. A clumsy product nobody trusts, or one that falls over on the day that matters, never gets the chance. The visible quality earns you the user. The invisible quality is what lets you keep them.</p> If you are scaling, raising, or heading toward an exit and you are not sure how much invisible quality your product is carrying, that is exactly the thing worth checking before someone else checks it for you. Let's talk.</a></em></p> Related: 75% of Google's new code is AI-generated. So what?</a> · What to do when your AI pilot fails</a> · How to unlock AI ROI: what the 20% do differently</a></em></p> What to do when your AI pilot fails 2026-05-31T00:00:00+00:00 If your AI pilot has failed, the first thing to know is that you are firmly in the majority, and that most failed pilots are recoverable. By recent counts, 95% of generative AI pilots produce no measurable return</strong> (MIT, 2025), and 42% of UK firms scrapped most of their AI initiatives in 2025, up from 17% the year before (S&P Global). The failure is rarely the technology. It is almost always something fixable in how the project was scoped, governed, and built. Here is how to work out what went wrong, and how to get the value you were promised.</p> It almost certainly wasn't the AI</h2> When a pilot dies, the instinct is to blame the model. Wrong model, not smart enough, not ready yet. Almost always, that is not what happened. The predictable causes are the same handful every time: a use case chosen because it was exciting rather than valuable, data and retrieval quality that could not survive real inputs, no clear definition of success, and no plan for the unglamorous engineering between a demo and production. I have written separately about why AI projects fail and what the 20% that succeed do differently</a>. For now the important point is simpler: a failed pilot is usually a fixable pilot.</p> How to recover a failed AI pilot</h2> Diagnose before you spend another pound.</strong> The most expensive mistake is to pour more money in the same direction before understanding why the first attempt failed. Start with an honest post-mortem of scope, data, metric, and engineering, not a new vendor.</li> Separate the idea from the execution.</strong> A pilot can fail because the idea was never going to pay off, or because a good idea was built badly. These need opposite responses, so decide which one you are looking at before anything else.</li> Find the real success metric.</strong> Many pilots fail because nobody agreed what success looked like in numbers. If you cannot say what the pilot was supposed to move on the P&L, that is the first thing to fix, not the model.</li> Decide: salvage or restart.</strong> If the use case maps to genuine value and a clear metric, the execution can usually be rebuilt on the same foundation. If the use case never had a path to value, restart from the problem, not the prototype.</li> Rebuild the unglamorous parts.</strong> Most of the value lives in the layers nobody demos</a>: retrieval, data quality, error handling, escalation, and the workflow redesign around the model. That is where the recovery effort should go.</li> </ol> Who should run the recovery, and who shouldn't</h2> Here is the part most people get wrong. The worst-placed people to recover your failed AI pilot are usually the ones who built it.</strong> Not because they are not capable, but because their incentives and their blind spots both point the wrong way. The firm that built the pilot has a commercial interest in selling you more of the same, and a natural reluctance to name the decisions that caused the failure, because they made them.</p> </th> The consultancy that built it</th> An independent fractional CTO</th></tr></thead> Incentive</strong></td> Sell more build hours</td> Get you to a working outcome</td></tr> Blind spot</strong></td> Owns the decisions that failed</td> No stake in the original build</td></tr> Salvage-or-restart call</strong></td> Biased toward "keep building"</td> Decided on the merits</td></tr> Accountability</strong></td> To their own pipeline</td> To your result</td></tr> </tbody></table> This is the same conflict of interest that runs through agency-supplied technology leadership</a>. For a recovery, where the whole job is an unflinching diagnosis, independence is not a nice-to-have. It is the point.</p> What recovery actually looks like</h2> None of this is exotic. The European insurance brokerage I worked with</a> reached 67% autonomous resolution on real customer cases, not because of a cleverer model than anyone else had, but because the unglamorous parts were done properly: retrieval engineered as a first-class problem, conservative escalation, a metric everyone agreed on, and the workflow rebuilt around the system rather than bolted on top. A recovered pilot looks the same. It is the demo plus all the work the demo skipped.</p> A dead pilot feels like a write-off, and the board will be tempted to treat it as one. Usually it is not. It is a first draft that taught you, at some expense, exactly which of the four things above went wrong. That is worth more than it feels like in the moment, as long as the diagnosis is honest and the recovery is run by someone whose only interest is your result.</p> If you have an AI pilot that stalled or failed and you want an independent read on whether to salvage it or start again, that is exactly the kind of diagnosis I do. Let's talk.</a></em></p> Related: How to unlock AI ROI: what the 20% do differently</a> · The hidden conflict of interest in hiring a fractional CTO</a> · Stop counting AI use cases. Redesign three value streams instead</a></em></p> The people making the biggest AI decisions understand it the least 2026-05-30T00:00:00+00:00 The people making the biggest AI decisions understand it the least. I watch it happen every week.</p> The concentric circles of AI understanding</h2> Picture knowledge of where AI is actually heading as a set of concentric circles. At the centre sit the people running the frontier labs and the researchers shipping the models. They see the curve up close. Move one ring out and understanding drops sharply. By the time you reach the outer rings, the traditional-industry executives holding the budgets and the large consultancies advising them, real understanding is thin.</p> Here is the uncomfortable part. The money and the strategic decisions sit in those outer rings. The clarity sits at the centre. The gap is widest exactly where the stakes are highest.</p> Where I stand</h2> I see this from a particular vantage point. I build with these tools daily. I co-founded AdBrain AI and shipped an agentic system at one of Europe's largest insurance brokerages that now resolves 67% of customer service cases without human intervention</a>. That work keeps me close enough to the frontier to feel where it is moving. Not inside any single lab, not captured by one company's narrative, but near enough to build with the latest models rather than read summaries about them.</p> From there, the distance between people who have watched a demo and people who have actually built something is wider than anyone in a boardroom admits.</p> The chain of advice</h2> Think about the chain of advice that reaches most leadership teams. A traditional-industry executive trusts a consultancy. The consultancy briefs a partner. The partner reads an analyst report. The analyst watched a keynote. By the time a recommendation lands on the boardroom table, it can be two or three steps removed from anyone who has shipped a single thing with these tools. Each layer smooths the edges, removes the uncertainty, and quietly loses the truth that the people closest to the work would never have rounded off.</p> Most strategy I encounter is built this way. A quiet game of Chinese whispers, played across enough hand-offs that the original signal barely survives. It is one reason so much AI transformation turns into theatre</a>.</p> What genuine insight actually requires</h2> So what does real insight look like? In my experience it needs four things together: real domain expertise, hands-on use of the frontier tools, a forecaster's discipline about probability and evidence, and the willingness to change your mind quickly when the facts move.</p> Miss any one and the picture distorts. Domain expertise without hands-on use gives you confident opinions about tools you have never touched. Hands-on use without discipline gives you hype. Discipline without the willingness to update gives you yesterday's forecast defended to the death.</p> Even the models cannot replace the human</h2> There is a detail here that surprised me. In recent forecasting benchmarks, the strongest models now edge out expert human forecasters. You might think that settles it, that we should simply ask the model. It does not. The sharpest forecasts come from a capable human working with a powerful model. Neither alone is best. The human supplies the intent, the taste, the judgement about what actually matters. The model supplies the breadth and the speed.</p> The same is true of understanding AI itself. The people who see clearest observe the frontier up close, yet refuse to take any single lab's word as gospel.</p> What to do about it</h2> I am not saying every executive needs to write code. I am saying the further a decision sits from anyone who has genuinely built with these tools, the more carefully you should question it. Ask where the advice came from. Ask who in the chain has actually shipped something. Ask how many hands it passed through before it reached you.</p> When you think about your own AI strategy, can you name a single person in that chain who has actually built with these tools, rather than watched someone else demo them? Trace it back. What you find is usually the real story.</p> If you want AI strategy from someone who builds with these tools rather than summarising them, get in touch</a>.</em></p> Related: Turning AI theatre into AI that moves the numbers</a> · The interesting question is what AI won't automate</a> · Why 80% of AI projects fail to deliver ROI</a></em></p> You're not talking to an LLM. You're talking to a system 2026-05-23T00:00:00+00:00 You're not talking to an LLM. You're talking to nine systems in a trench coat, and the model is only one of them.</p> When someone types a question into ChatGPT or Claude, they picture one clever brain in a box. A single mind reading their words and thinking back at them.</p> That is not what is happening. You are talking to a system, and the model is one small part of it. I know this because building the rest of the parts is my day job: the retrieval, the guardrails, the routing, the document handling. The model is the bit I worry about least.</p> Let me walk you through the coat.</p> What decides whether your question even reaches the model</h2> Two layers act before the model sees a single word. First, alignment guardrails: the system checks tone, safety, and factuality going in and coming back, and tries to catch confident nonsense before it reaches you. Second, routing. Some products quietly send simpler questions to a smaller, cheaper, weaker model to manage cost and latency. You never see the handover.</p> Caching sits alongside both. The same question asked twice should not cost twice, so the system reuses earlier work where it can.</p> The memory is a trick</h2> This is the part that surprises people most. The model's weights do not change as you talk to it. It has no built-in memory of your last message, let alone last week. The continuity you feel is faked, and faked well, by separate tooling that stores your history, retrieves the relevant pieces, and injects them back into the conversation before the model ever sees them.</p> When a chat gets long, compaction takes over. The earlier parts are summarised and compressed so the whole thing still fits in the context window. You experience one smooth conversation. Underneath, it is being rewritten on the fly.</p> What happens when you upload a document</h2> Upload a PDF and more machinery wakes up. OCR reads the text off the page. Chunking breaks it into pieces. Vector search, which matches meaning rather than keywords, finds the few paragraphs that actually answer your question. The model never reads your whole file. It reads a curated handful of fragments that the surrounding system decided were relevant. Getting that retrieval right, rather than the model, is what most production AI actually turns on</a>.</p> And the deliberate thinking you sometimes see, the model working through a problem step by step, is the system instructing it to show its reasoning rather than blurt the first answer that comes to mind.</p> Nine systems, one model</h2> Guardrails, routing, caching, memory, compaction, OCR, chunking, vector search, step-by-step reasoning. Count them. Nine. The model is one of them.</p> Now the honest punchline, the part vendors rarely say plainly. With all of that scaffolding, the model's weights still do not change while you use it. Whatever it learns from your conversation happens later, in bulk, during training, if at all. The ideal we are all working towards is a model that genuinely learns from new data as it goes. That is not today. Today we fake learning with retrieval and careful plumbing, and most of the time that plumbing is what decides whether the product works.</p> The tenth passenger: when it stops answering and starts doing</h2> Everything so far describes what happens when you ask for an answer. Increasingly you are not asking for an answer. You are asking for an action: book it, file it, reconcile it, draft the reply and send it. That adds a tenth passenger to the coat, and it is the one growing fastest. The agentic harness.</p> You have probably met these already, even if you never named them as such. Anthropic's Claude Code and Claude Cowork. OpenAI's Codex. Google's Antigravity and Gemini Spark. Amazon's Quick Suite. Every one of them is a harness wrapped around a model, not a model. The race between the big labs is no longer only about whose model is smartest. It is increasingly about whose harness lets that model get real work done safely.</p> Here the model is handed a set of tools, things it can actually call: a search, a database query, a code runner, an email API. It does not execute them itself. It proposes an action, the harness runs it, feeds the result back, and the loop repeats until the job is done or the agent decides it is stuck. The model is the part that chooses what to do next. The harness is everything that lets it do anything at all, and everything that stops it doing the wrong thing.</p> That harness is where production agents are won or lost. It holds the tool definitions, the permissions for what the agent is allowed to touch, the budget limits, the verification step that checks the agent did what it claimed rather than trusting it, and the escalation path for the cases it should not handle alone. The actual agent loop is often a few dozen lines. The engineering lives in the scaffolding around it. I have written about what works here in more detail</a>.</p> Strip it back and the harness does four jobs the model cannot do for itself.</p> It manages processes</strong>: starting agents, running several at once, spawning a focused subagent for a sub-task so the main agent's context stays clean, and stopping the ones that go wrong before they do damage.</p> It manages memory</strong>: not the model remembering, which it cannot, but the harness recording what the agent did and decided across steps and across runs, then feeding the relevant pieces back when they matter. The same retrieval trick from earlier, now in service of an agent rather than a conversation.</p> It manages workflows</strong>: the order steps run in, what must finish before the next begins, where a human signs off. The agent improvises within a structure the harness defines, rather than freelancing from a blank page.</p> And it manages skills</strong>: capabilities loaded on demand for the task in front of it, rather than carried all at once. The harness brings in the right skill at the right moment, which keeps the agent sharp instead of bloated.</p> Tools, processes, memory, workflows, skills, verification. The model supplies the judgement about what to do next. The harness supplies almost everything else.</p> So when a tool uses AI to do something rather than say something, the model is doing even less of the work, not more. The harness is doing the rest. And the same rule holds, harder: when an agent fails, the model is rarely the reason.</p> What this means for the decisions you make</h2> Why does this matter if you are not the one building it?</p> Because executives keep buying the whole system and then arguing only about the brain inside it. They debate which foundation model is smartest while the things that actually decide whether their AI works, the retrieval, the guardrails, the routing, the document handling, sit unexamined. They are paying for a system and inspecting one component.</p> Better AI decisions start with one plain question: which layer am I actually paying for, and which layer is failing me? When an AI product disappoints, the model is rarely the problem. The retrieval is feeding it the wrong fragments. The chunking mangled the document. The router quietly downgraded you. The guardrails are too tight, or too loose. The 67% autonomous case resolution we reached at a European insurance brokerage</a> came from getting those layers right, not from a cleverer model.</p> The brain in the box is real, and it is remarkable. But it has never been alone in there. The next time a demo dazzles you, or a tool frustrates you, resist the urge to credit or blame the model. Ask what the rest of the coat is doing.</p> If you want to work out which layer of your AI stack is actually failing you, get in touch</a>.</em></p> Related: Agentic AI in 2026: what actually works in production</a> · What two hours with Anthropic's agent team taught me</a> · Why 80% of AI projects fail to deliver ROI</a></em></p> Agent sprawl is the new shadow IT. Your business needs a control plane 2026-05-16T00:00:00+00:00 How many AI agents are running in your business right now?</p> If you can't answer that question with a number, you have a problem. And it's the same problem that cloud created in 2014 when every team started spinning up AWS accounts on a credit card, and the CFO discovered six months later that the company was running 400 services across nine regions with no inventory, no budgets, and no kill switch.</p> We are about to repeat that mistake at speed. The 2026 version is agent sprawl.</p> The new shadow IT</h2> I wrote a few months ago about shadow AI</a>, the problem of employees using ChatGPT and Claude on personal accounts to process company data. That problem hasn't gone away. But there's now a second, more serious version of it: the agents your organisation has actually deployed.</p> In the last 30 days, Microsoft, Google, Salesforce and IBM all shipped what they're calling agent management platforms</strong>. Microsoft Agent 365 is positioned as a control plane to observe, govern, and secure agents, including discovery of "shadow AI," agent credentials, permissions, and registry sync with AWS Bedrock and Google Cloud. Google's Gemini Enterprise Agent Platform launched with Agent Identity, an Agent Gateway, Agent Observability, simulation, evaluation, and prompt-injection defences. Salesforce shipped Agent Fabric for trusted agent identity, model choice, deterministic handoffs, and agent scanning. IBM positioned watsonx Orchestrate as a central orchestration layer for agents, tools, and workflows with governance and auditability built in.</p> Four of the largest enterprise software companies in the world, all shipping the same product category in the same month. That's not a coincidence. That's the shape of the next problem.</p> The early signal that this is becoming procurement-grade is the rise of two open standards: Anthropic's Model Context Protocol (MCP) and the emerging Agent-to-Agent (A2A) work championed by Google. These are turning into the default way agents discover and call tools across vendors. Within twelve months I expect to see RFPs from regulated industries that list "MCP support" and "agent identity controls" the way they list SSO and SCIM today.</p> What an agent control plane actually does</h2> When you deploy agents at scale, you face five questions that no spreadsheet or wiki can answer for long:</p> Who built this agent?</strong> Inventory. Owner. Purpose. Date deployed. Last reviewed.</p> What can it access?</strong> Data sources, customer records, internal documents, third-party APIs. Permissions need to be inherited from human identity, not assumed.</p> What can it do?</strong> Which tools it can call. Which actions are reversible and which are not. Which require human approval.</p> What budget can it spend?</strong> Token limits per task, per day, per month. Hard caps before the bill arrives, not after.</p> What did it do?</strong> A decision log. Which prompt, which tools, which outputs, which approvals. Reproducible, auditable, exportable.</p> These are the same five questions IAM answers for human identity, FinOps answers for cloud cost, and observability answers for production systems. The reason every major vendor is building this layer now is that agents collapse all three problems into one new stack.</p> An agent control plane is what IAM, FinOps, and APM became when they merged.</strong></p> Lakhani, Spataro and Stave framed this shift in Harvard Business Review more directly than most vendors will: "agents should be treated as a managed workforce rather than a collection of software scripts." Once you accept that framing, the questions get easier. You already know how to onboard, evaluate, monitor, and offboard a workforce. The new task is doing it for software.</p> The reality check on urgency</h2> The situation is less urgent than the vendor messaging suggests. Gartner's April Hype Cycle placed agentic AI at the Peak of Inflated Expectations and noted that only 17% of organisations had actually deployed AI agents in production. More than 60% expect to within two years, but expectation and reality are different animals.</p> The point is not that you need an agent control plane today. The point is that the window between "we don't have agents" and "we have agents we can't account for" is going to be about six months. That's how long it took most companies to move from "we have one AWS account" to "we have no idea how many AWS accounts we have." Agents will move faster because they're easier to spin up and harder to see.</p> Why this matters now</h2> There's a specific moment where this becomes urgent, and most companies miss it.</p> It's not when you deploy your first agent. It's when your third</em> department deploys an agent without telling the second one. Customer support has a triage agent. Legal has a contract review agent. Finance has a reconciliation agent. They were built by three different teams, with three different vendors, on three different model providers, with three different definitions of "approved data access." Nobody owns the cross-cutting view.</p> I have seen this play out twice already, on smaller scales. In one business, a customer success team had built a perfectly reasonable agent to summarise account notes before renewal calls. Around the same time, a separate operations team had built an agent that wrote into the same CRM records. Neither team knew about the other. When the renewal agent's summary started including content the operations agent had written automatically, the business spent a week working out whether the resulting renewal note had been generated, edited, or invented. The answer existed somewhere in the logs. Nobody owned the logs.</p> That moment usually arrives between deployment numbers four and eight. After that, retrofitting governance is roughly twice as expensive as building it in. I've watched the same cost curve in cloud, in containers, in microservices, and in data pipelines. It's identical every time.</p> What I'd do in your position</h2> If you're the CTO, COO, or head of operations at a company that has deployed more than one agent, or is about to, I'd do four things in the next quarter:</p> Build the inventory first.</strong> Not the platform, the inventory. A simple register of every agent in production or in pilot: owner, purpose, data access, model, monthly cost. You will be surprised by what you find. Most leaders are.</p> Define your agent development lifecycle.</strong> Treat agents like production systems, because they are. Requirements, tool contracts, data contracts, evaluations, red-team tests, permission reviews, simulation, rollout, monitoring, rollback, incident management, audit. Most of these already exist for your software. You need to extend them, not invent them.</p> Pick the control plane after you understand the requirements.</strong> The vendor space is moving weekly. Microsoft, Google, Salesforce, IBM, and a dozen smaller players will all claim to solve this. The right answer depends on where your data already lives and which agents you already run. Don't buy the platform first and shape your operating model around the vendor.</p> Test the kill switch.</strong> Every agent in production needs an off button. Not a "we'll figure it out" off button. A documented, owner-on-call, actually-tested</em> off button. Pick a Tuesday morning and run a drill: shut the agent down, observe what breaks downstream, time how long it takes to recover. This is the single fastest way to expose which agents are genuinely understood by their owners and which are running on hope.</p> The board-level reframe</h2> For boards and PE-backed leadership teams, the simplest reframe is this: agents are software that takes actions on your behalf, using your data, spending your money, and creating audit trails you may not own. The governance you would demand for any other system that did all four of those things should apply here.</p> This is not a reason to slow down agent adoption. It's a reason to build the inventory and the lifecycle now, while you have three agents instead of thirty. The companies that lead on this in 2026 will look like the companies that built proper cloud governance in 2015. The ones that don't will look like the ones still cleaning up cloud waste a decade later.</p> If you'd like to talk through what an agent inventory or lifecycle would look like in your business, get in touch</a>. I've built governance frameworks alongside production AI systems at NHS Wales</a> and in regulated insurance</a>, where the audit bar is high and the cost of getting it wrong is higher.</p> Related: Who is accountable for AI on your board?</a> · Shadow AI is your next audit finding</a> · Agentic AI in 2026. What actually works</a> · The AI Transformation Sprint</a></em></p> Headless is the new mobile-first. Agents are about to become your biggest user 2026-05-09T00:00:00+00:00 Here is a question worth asking your product team this week. What percentage of your software's use, twelve months from now, will involve a human looking at a screen?</p> If the honest answer is anything less than 80%, your product has the wrong shape.</p> In April, four companies that sit at very different parts of the software stack said the same thing. Box CEO Aaron Levie posted that as agents become the biggest users of software, software has to be available in headless form because agents will talk to APIs, not click through UIs. Zapier CEO Wade Foster told an Axios audience that agents are likely to become the predominant users of software. Salesforce shipped "Headless 360," with cofounder Parker Harris framing the provocation directly: why should a user need to log into Salesforce at all when an agent can act through APIs and tools? Stripe, Mastercard and OpenAI quietly built the rails for agents to make purchases on a user's behalf.</p> This is not a niche prediction. The next generation of users is software, not people, and the software you built for clicks is now being asked to serve callers.</strong></p> What "the wrong shape" actually means</h2> For the last fifteen years, most B2B products have been built around the same loop: a user logs in, navigates a UI, takes an action, sees a confirmation. Roadmaps optimised that loop. Designers shortened the click path. Product managers measured engagement, session length, retention.</p> Agents do not log in. They do not navigate. They do not see the confirmation toast. They call an endpoint, pass parameters, parse the response, and move on. Most products, including most of the SaaS your business pays for today, were not designed for that. The API exists for integrations, but it covers maybe 30% of what the UI can do. The auth model assumes a human at a keyboard. The error messages are written for users, not callers. The pricing model charges for seats that nobody is sitting in.</p> I learned how big this gap is the hard way. A few months ago I wired an agent into a well-known mid-market SaaS product on behalf of a client. The marketing pages promised a "complete API." The reality was that two of the four actions we needed were UI-only. The vendor's answer was to use browser automation. That is the 2026 equivalent of telling someone to fax their tax return. The product wasn't bad. It was simply built for a world where the user had hands.</p> Salesforce's Headless 360 announcement is the clearest signal of where this is going. More than 60 MCP tools and 30+ coding skills exposed for Claude Code, Cursor, Codex, Windsurf, and others. The promise is that anything you can do in the UI, you can do through an API, an MCP call, or a CLI command. Salesforce is the largest enterprise software company in the world. If they are doing this, every serious B2B platform will follow within eighteen months.</p> The three layers your product now needs</h2> The shift is not "add an API." Most products already have one. The shift is that you now need to design for three different consumers of your product, and treat all three as first-class.</p> The human layer.</strong> The traditional UI. Still essential, still where decisions get made and judgment lives. But it is no longer the only interface, and probably not the dominant one for routine work.</p> The agent layer.</strong> A complete, agent-addressable surface. Every meaningful action in your product needs to be reachable through an API, MCP tool, or CLI command. Schemas need to be machine-readable. Errors need to be parseable. Permissions need to be inherited from the human the agent is acting for. This is where Salesforce, Microsoft, and a growing number of vertical SaaS players are investing right now.</p> The governance layer.</strong> This is the one most teams haven't started thinking about, and it's the most interesting. When an agent is about to act on a user's behalf, the user needs a preview of what it plans to do, a confirmation flow for irreversible actions, and a clear log of what happened. The governance layer is the human in the loop, surfaced as a product feature, not buried in admin settings.</p> Three layers. One product. Most teams are still building one.</p> The pricing question this forces</h2> If the agent becomes a user, what do you charge? Per-seat pricing assumed a human consumed the licence. An agent might do the work of fifty seats while occupying zero. Microsoft has already started shifting Dynamics customers to a mix of seats plus consumption credits, with around 60% of Dynamics service customers now buying usage-based credits. Microsoft also moved GitHub Copilot to usage-based pricing, explicitly aligning what they charge with what the customer consumes.</p> This is not the death of seat-based pricing. It's the start of hybrid pricing, where seats cover platform access and consumption covers agent-driven work. The hard part, and where I'd be spending CFO time right now if I were on your board, is protecting gross margin when agent usage can spike unpredictably. SaaS economics assumed flat-rate consumption per seat. Agents break that assumption.</p> The practical answer is simple to state and hard to implement. If you don't have a unit of work in your product that you can measure and charge for (a resolution, a workflow completed, a document processed, a lead qualified), build one before your competitors do. Once your competitor is charging per outcome and you are charging per seat, the comparison gets very uncomfortable very quickly.</p> The mobile-first analogy is exact</h2> In 2010, every software company had a website that worked beautifully on a 1280-pixel monitor and barely worked on a phone. Then mobile traffic crossed a threshold, and the companies that hadn't rebuilt for touch, latency, and a smaller viewport spent the next five years losing ground to ones that had. The phrase "mobile-first" became shorthand for "rebuild your product around how people actually use it."</p> We are about to repeat that, with agents. The companies that get there first will look the way responsive-design pioneers looked in 2013. The companies that wait will rebuild under duress with their customers already comparing them to a faster competitor.</p> The good news is that the work is more tractable than mobile was. You don't need to redesign for a new viewport. You need to expose what already exists, structure it for machine readers, and add a governance layer most users will value even when they're using your product directly.</p> What I'd do in your position</h2> If you run a B2B product, I'd put four things on the next quarterly roadmap:</p> Audit your API coverage.</strong> Map every meaningful user action in your product. For each one, mark whether it is reachable through your API. The honest number is rarely above 40% for products older than five years. That gap is your roadmap.</p> Build an MCP surface.</strong> Don't rebuild your API, wrap it. MCP is the emerging standard for how agents discover and use tools, and the integration cost is low compared to the strategic optionality it buys you. Start with the five actions agents would most plausibly want to take in your product.</p> Design the preview and approval flows.</strong> What does it look like when an agent is about to act inside your product? Where does the user see it? How do they cancel? How do they review what happened? This is product design work, and it is currently being skipped by every team I look at.</p> Pick a unit of work to charge for.</strong> Resolutions, workflows completed, documents processed, leads qualified, transactions executed. Agents make per-seat pricing leak value. The companies that figure out the right unit early will protect margin. The ones that don't will find themselves negotiating discounts against unbounded usage.</p> The board reframe</h2> For founders and operators reading this, the simplest reframe is: your competitive moat for the next decade depends on how many of your users are software. If the answer is "almost none," your product is being designed for a market that is shrinking relative to the one being built for agents. If the answer is "more than we expected," you are early to a shift that most of your competitors are still treating as marketing language.</p> Headless software is not a feature. It is a posture toward where computing is going. The shape of your product is the most strategic decision you'll make this year, and the window to make it is shorter than the time it took most of you to ship a mobile app.</p> If you'd like to talk through what an agent-addressable product surface would look like for your business, get in touch</a>. I've spent the last decade building production AI systems and the platforms underneath them, including the agentic insurance automation work</a> where the customer's agent had to call our system, not the other way around. The patterns travel.</p> Related: Agent sprawl is the new shadow IT</a> · Agentic AI in 2026. What actually works</a> · The orchestrator, not the 10x engineer</a></em></p> Uber burned through its token budget by April. Your business will be next 2026-05-02T00:00:00+00:00 In an April interview with The Verge, Uber's CEO Dara Khosrowshahi admitted, almost as an aside, that the company's CTO had told him they had burned through their token budget by early April. The interview was about hiring, software-team structure, and how AI was reshaping the relationship between product managers, designers, and engineers. The token budget line was a throwaway. It shouldn't have been. It was the most important sentence in the conversation.</p> Uber is not a company that runs out of money in April by accident. They have one of the most sophisticated cloud finance functions in tech. If their AI spend caught them by surprise, yours will too.</p> Token spend is becoming a P&L conversation, and most organisations are still treating it like an experiments line.</strong></p> The cloud FinOps curve, replayed at speed</h2> I have watched this exact pattern before. In 2014, every CFO I worked with was discovering that "cloud is cheaper than on-prem" was only true for a few specific workloads. The bill kept growing. Engineering teams spun up environments and forgot about them. Data egress charges arrived without warning. Reserved instances were bought and never used. The discipline we now call FinOps emerged because the pain became too obvious to ignore.</p> That curve took the industry roughly a decade to flatten. Cloud Foundation, AWS Cost Explorer, GCP billing alerts, Spot.io, CloudHealth, the FinOps Foundation, dedicated FinOps engineers in every serious cloud-native business. Ten years of work to turn cloud spend from "scary line item" to "managed discipline."</p> Token spend will not get a decade. It's already moving faster, for three reasons.</p> Spend is far less predictable.</strong> A single coding agent on a long-running task can consume more tokens in an afternoon than a customer-support workflow uses in a month. A poorly tuned prompt can ten-x cost overnight. The variance between similar tasks is wild compared to the variance between similar EC2 instances.</p> Model choice changes economics by orders of magnitude.</strong> Routing a task to the wrong model can be 30x more expensive than routing it correctly. Most teams have no routing strategy. They picked one model in a proof-of-concept and never revisited the decision.</p> Caching, batching, and prompt design are not yet boardroom vocabulary.</strong> A team that knows how to use prompt caching, batch APIs, and disciplined prompt design will spend a fraction of what an undisciplined team spends for the same outcome. This is a skill that exists in maybe 5% of engineering organisations today.</p> Anthropic's own positioning of Claude Code for Enterprise tells you where the market is going. The product page emphasises contribution metrics, token usage, cost monitoring through OpenTelemetry, centrally managed permissions, file-access restrictions, and per-team observability. Those are not features for hobbyists. They are features for organisations that are about to learn what their AI spend really is.</p> Workflows are cheaper than agents</h2> There is a specific insight from Zapier's Wade Foster that more leaders should hear. He has been saying for months that agents are less reliable and more expensive than deterministic workflows, so leaders should use workflows where reliability and cost matter, and reserve agents for ambiguity, recovery, and creation.</p> This is the most important practical FinOps lever your engineering organisation has, and almost nobody is using it.</p> Most teams default to "build an agent" when the actual problem is "automate a known sequence of steps." A deterministic workflow runs in milliseconds at near-zero variable cost. An agent runs in seconds, sometimes minutes, at meaningful per-task cost, with non-zero failure rates and the occasional spectacular blowup. The cost difference between these two approaches, applied across an enterprise, is the difference between AI being a margin builder and AI being the new shadow line item that ate the budget.</p> I have built both. On one recent engagement, the team had built an agent to triage incoming documents, classify them, and route them. Six months in, it was costing roughly fifty times what the same triage would have cost as a deterministic pipeline using a small classifier model and a few rules. The agent was more flexible, yes. The flexibility was being used about 4% of the time. The other 96% was a known sequence of steps being run through the most expensive possible machine.</p> The right architecture is almost always workflows where the path is known, agents where it isn't.</strong> Most teams are doing the opposite because agents are newer and more interesting to build.</p> What a CFO actually needs by Q3</h2> If you are the CFO, COO, or finance lead of an organisation that runs more than a handful of AI use cases in production, there is a specific operating discipline you need before the end of this quarter. I'd put four things in place.</p> Per-team token budgets, with hard caps.</strong> Same model as cloud spend. Each team gets a monthly allowance, denominated in dollars or tokens, with alerts at 50%, 80%, and 100%. The cap is enforced at the API layer, not in a wiki. If a team needs more, they ask. This is the single highest-impact move you can make this year.</p> Unit economics per workflow.</strong> For every AI-driven workflow in production, you should know its cost per execution. Cost per resolved support ticket. Cost per generated report. Cost per closed code review. Without this number, you cannot make any honest decision about whether the AI workflow is profitable. With it, you can compare variants, justify investment, and spot regressions.</p> A model routing policy.</strong> Most organisations are still defaulting to the most capable model for every task. That is genuinely expensive. A simple extraction task can cost 30x more on a frontier model than on a small one fine-tuned for the job. A routing layer that sends simple tasks to smaller models, harder tasks to larger ones, and routine extractions to cached responses can cut spend by 50% to 80% with no perceptible quality loss. The engineering effort is small. The financial impact is enormous.</p> Observability that includes cost, not just performance.</strong> OpenTelemetry, Honeycomb, Datadog and most major observability platforms now expose AI cost telemetry. If your engineering teams can see latency and error rate but not cost-per-call, they cannot optimise the third dimension. Show them the bill.</p> The board reframe</h2> For boards and investors reading this, the simplest question to ask the next executive who presents an AI strategy is: "What is your monthly token spend, and what controls do you have on it?" If the answer is "we're tracking it," the answer is no.</p> Token spend will follow the cloud spend curve, except the slope is steeper, the volatility is higher, and the lessons that took a decade to learn the first time are available for free in the second. There is no reason to repeat the mistake at a faster cadence. The companies that build AI FinOps discipline in 2026 will look like the companies that built cloud FinOps in 2018. The ones that don't will look like the ones still arguing over reserved instance utilisation in 2024.</p> If you'd like to talk through what an AI FinOps function would look like in your business, get in touch</a>. I've sat on both sides of this conversation. Engineering teams that built it well and finance teams that wished engineering had built it sooner.</p> Related: Why most AI spend doesn't show up in the numbers</a> · Agent sprawl is the new shadow IT</a> · How to unlock AI ROI: what the 20% do differently</a></em></p> Stop counting AI use cases. Redesign three value streams instead 2026-04-25T00:00:00+00:00 I sat through an AI strategy review with a leadership team last month where the head of transformation opened the deck with a slide titled "AI Use Cases In Production." There were 47 of them. Customer service summarisation. Sales call coaching. Marketing copy generation. Code completion. Document classification. Meeting minutes. Onboarding assistants. The list filled the screen in 9-point font.</p> I asked one question. "What's the EBIT impact?"</p> The room went quiet, because the answer was: nobody had computed it. The use cases existed. The value didn't. And yet the value was right there to be unlocked, sitting in the same processes, waiting for someone to redesign the stream instead of decorating its steps.</p> This is the new shape of AI theatre. I called the previous shape performance art</a> three months ago. That piece was about pilots that never reach production. This one is about pilots that do</em> reach production and still produce nothing on the P&L.</p> The trap has moved from pilot purgatory to use-case purgatory. Counting deployed assistants is the new measuring of pilot velocity.</strong></p> Why use-case counting persists</h2> I understand why this keeps happening. Use cases are easy to count. They are easy to put on a board slide. They give a head of transformation something concrete to point at when the CEO asks "what are we doing with AI?" Forty-seven is more impressive than four. Activity is easier to measure than outcome.</p> There's also a procurement reason. Most enterprise AI platforms are sold on use-case breadth. Vendors love to show a tile-grid of pre-built assistants because it makes the platform look comprehensive. The customer side answers in kind by deploying as many tiles as possible. Both sides are optimising for the wrong thing.</p> The result is what I keep seeing in mid-market and PE-backed businesses: a portfolio of small productivity improvements, none of which is large enough to move a business metric, all of which add to the AI budget. Twelve months in, the conversation with the CFO becomes uncomfortable. The honest answer is "I cannot draw a line from any of these to revenue, cost, or risk."</p> Lakhani, Spataro and Stave coined a useful phrase for this in a March 2026 Harvard Business Review piece. They called it being "pilot-rich but transformation-poor."</strong> That is exactly the shape of the problem. Hundreds of working pilots, none of which has changed how the business operates.</p> The Krishna reframe</h2> At IBM Think 2026 earlier this month, Arvind Krishna put the alternative more directly than I have heard a major-vendor CEO put it: the enterprises pulling ahead are not deploying more AI, they are redesigning how the business operates. IBM positioned the AI operating model around agents, data, automation, and hybrid governance, and framed the shift as "from improving parts of the business to changing how the business operates."</p> That is not the same statement as "deploy more AI." It is the opposite statement. ServiceNow's Bill McDermott has been making the same point in different words. AI value comes from auditable execution across workflows, data, policy, CRM, HR, security, and IT, not from disconnected assistants sitting alongside human work.</p> The HBR authors put the same point in a single line that should be printed on the wall of every transformation office: when you drop AI into one step of a process you have not redesigned, "the bottleneck simply shifts."</strong> Their example is an agent that drafts a complex contract in seconds, only to have the contract sit in a manual legal review queue for two weeks. The pilot worked. The cycle time did not change. The business did not get faster.</p> The point is that AI's economic impact does not live in the assistant in the middle of a process. It lives in the redesign of the process itself.</p> What "value stream" actually means</h2> A value stream is the end-to-end sequence of steps that delivers a specific outcome the business cares about. It usually crosses multiple teams, multiple systems, and multiple decision points. The interesting metric for a value stream is throughput, cycle time, error rate, cost per unit, or customer impact, not the number of tools used inside it.</p> Examples of value streams worth redesigning:</p> Customer support resolution.</strong> From inbound contact to closed ticket. Measured in time to first response, time to resolution, customer effort score, cost per resolution.</p> Sales lead to revenue.</strong> From inbound lead to closed deal. Measured in conversion rate at each stage, sales cycle time, cost of customer acquisition.</p> Month-end financial close.</strong> From period end to signed-off financial statements. Measured in days to close, manual adjustments, audit findings.</p> Underwriting or claims processing.</strong> From application to decision. Measured in straight-through processing rate, cycle time, loss ratio.</p> Engineering migration.</strong> From legacy system to modern stack. Measured in throughput, defect escape rate, cost per migrated component.</p> Each of these is a candidate for end-to-end redesign with AI in the middle, agents at decision points, workflows at routine steps, and human judgment at exceptions. The metric for success is not "we deployed an AI assistant in step 4." It is "this value stream now operates at half the cycle time and a third of the cost."</p> The Microsoft data the room missed</h2> Microsoft's 5 May Work Trend Index reported a finding that should be on every transformation lead's desk. Organisational factors, including culture, manager support, and talent systems, accounted for more than twice the perceived AI impact</strong> of individual factors. The same Copilot deployment, in two organisations, produces wildly different outcomes depending on how the work itself is structured.</p> This is why use-case counting fails. You can deploy an excellent meeting summary assistant in two companies. In the first, where meetings are already overprescribed and follow-through is weak, the assistant generates more meeting noise. In the second, where meetings are tightly run and decisions are tracked, the assistant compresses cycle time. Same tool, opposite outcomes, because the surrounding operating model is different.</p> Use cases live in tools. Value lives in operating models. You cannot use-case your way to a redesign.</strong></p> How to pick three value streams</h2> If you are leading AI strategy at a mid-market or PE-backed business, I'd kill the use-case inventory and run a different exercise. Take it to your leadership team in the next month.</p> Map your top eight value streams.</strong> Not eighty. Eight. The ones that, if you compressed cycle time by 30% or reduced unit cost by 20%, would move the business in a way the board would notice.</p> Pick three.</strong> Use three criteria: measurable economic impact, achievable within 6 to 12 months, and a sponsor with real authority. The third criterion is the one most exercises skip. A value stream without an empowered owner becomes another deck.</p> Commit to redesign, not augmentation.</strong> The temptation is to bolt AI onto the existing process. Don't. Map the current process, identify which steps can be eliminated, which can be automated end-to-end, which need a human decision, and which can be combined. Then design the future state, with AI in the middle</em>, and migrate.</p> Measure outcomes, not adoption.</strong> The metrics are cycle time, unit cost, throughput, quality, customer satisfaction. Not seats licensed. Not assistants deployed. Not prompts entered. Hold the leadership team to those metrics quarterly.</p> Tell the rest of the business to wait.</strong> This is the hardest part. Every other team will want their own AI use case. The answer for the next year is "we are concentrating effort on three streams, we will share what we learn." A focused redesign of three value streams will produce more EBIT impact than fifty deployed assistants. I have watched this in both directions.</p> The board reframe</h2> For boards and investors reading this, the simplest test of an AI strategy is: name the three value streams you are redesigning, and the metrics you'll be measured against in 12 months. If the answer is a list of deployed tools, you don't have a strategy. You have a procurement plan with AI in the title.</p> The companies pulling ahead in 2026 are not the ones with the longest use-case inventory. They are the ones who picked three things and rebuilt them properly. The operating model is the moat. The use cases are the marketing.</p> If you'd like to talk through which value streams in your business would benefit most from end-to-end redesign, get in touch</a>. I've helped leadership teams pick the right three more than once, and it is almost always not the three they would have chosen alone.</p> Related: Turning AI theatre into AI that moves the numbers</a> · How to unlock AI ROI: what the 20% do differently</a> · The dual-stream strategy</a></em></p> 75% of Google's new code is AI-generated. So what? 2026-04-18T00:00:00+00:00 At Google Cloud Next 2026, Sundar Pichai announced that 75% of Google's new code is now AI-generated and approved by engineers, up from 50% last autumn. The number was repeated by every AI newsletter, every industry analyst, and a quarter of the LinkedIn posts I saw that week.</p> Here is the inconvenient question almost nobody asked. So what?</strong></p> What does that number actually tell you about Google's engineering output? Does it ship more product? Does the product have fewer defects? Is the customer experience better? Did the engineering organisation get cheaper to operate, or more expensive? Is morale up or down? Are good engineers staying or leaving?</p> The 75% number does not answer any of those questions. It is a measurement of inputs, presented as if it were a measurement of outcomes. And it is about to become the most reported, least useful metric in enterprise engineering.</p> Why this metric is irresistible to executives</h2> I understand the appeal. AI-generated code percentage is a single number that goes up over time, sounds impressive on an earnings call, and feels like progress. CFOs and boards have been waiting for someone to give them a quantified answer to "is the AI investment working?" Engineering leaders, sensing the pressure, are happy to provide one.</p> The trouble is that this number measures the activity, not the value. It is the engineering equivalent of measuring sales effectiveness by counting how many emails the team sent. There is a correlation, on average, between effort and outcome. There is not a useful one between AI-generated lines and shipped value.</p> I have already seen this metric inverted in real organisations. A team I worked with reported that 80% of their merged code was AI-generated, and used it to justify a larger AI tooling budget. When I looked at their actual delivery metrics, cycle time had increased. Defect escape rate had doubled. The team was generating more code, merging more PRs, and producing more bugs, all of which were now arriving faster. The percentage was up. The product was getting worse.</p> What's actually changing in the SDLC</h2> The interesting shift over the last year is not how much code is being written. It is how engineering work itself is being reshaped. Coding agents are taking over routine implementation, but they are also reshaping requirements, design, code review, testing, migration, deployment, and incident response. The whole software development lifecycle is being rewired, not just the typing.</p> OpenAI's enterprise update said Codex hit 3 million weekly active users and that customers including GitHub, Nextdoor, Notion, and Wonderful are building multi-agent systems that execute engineering work end-to-end. Microsoft reported roughly 140,000 organisations using GitHub Copilot, with enterprise subscribers nearly tripling year on year. Anthropic positioned Claude Code for Enterprise as a coding agent that writes, debugs, refactors, creates tests, opens PRs, and works across terminal, IDE, Slack, and web, with enterprise controls including permissions, OpenTelemetry monitoring, token visibility, SSO, SCIM, and audit. Salesforce went further, exposing 60+ MCP tools and 30+ coding skills through Headless 360, claiming up to 40% cycle time reduction through their DevOps Center MCP.</p> If you read those announcements carefully, the language has shifted. Vendors are no longer selling "AI that writes code faster." They are selling auditable agents that execute engineering work with controls. The metric the vendors themselves are now optimising for is not "lines generated." It is "engineering work completed safely."</p> That is the metric the board should be asking for.</p> The five questions to bring to your next board meeting</h2> If you sit on a board, run a PE-backed business, or chair an audit committee where engineering reports up, these are the five questions to ask your CTO about AI in engineering. They cost nothing to ask. They reveal a great deal.</p> What is your release frequency, and how has it changed?</strong> How often does code reach production? Daily, weekly, monthly? Has it accelerated since AI tools were rolled out, or stayed flat? The companies that get real value from AI in engineering ship more often, not just produce more code.</p> What is your defect escape rate?</strong> What percentage of bugs reach production before being caught? If this number is rising in step with AI-generated code, you are paying for velocity in customer pain. This is the number to watch most carefully.</p> What is the PR review latency?</strong> When code is written, how long does it sit waiting for a human to review and merge it? AI-generated code can pile up faster than reviewers can handle. The cycle time of code reaching production depends on review, not on writing.</p> What is the cost per accepted change?</strong> Add up the cost of AI tools, developer time, review time, testing, and incident remediation, then divide by the number of changes that successfully reach production. This is the most honest unit economics you can put on engineering AI. It should be going down. In poorly managed deployments, it goes up.</p> What is the mean time to recovery?</strong> When something breaks, how fast does the team detect it, diagnose it, and recover? AI tools can both help and hurt this. Help, by suggesting fixes faster. Hurt, by introducing changes the team did not write and does not fully understand.</p> These five questions are not exhaustive. They are the minimum set. None of them includes "what percentage of code is AI-generated," because that number does not appear in any of them.</p> The migration metric is the one to lead with</h2> If I were a CTO going to a board with one number to demonstrate engineering value from AI, it would not be code-generation percentage. It would be migration throughput.</p> Legacy system migration is a real cost in most established businesses. It is also the workload where AI agents are showing the largest, most measurable gains. Google reported that a complex internal migration was completed six times faster with agents and engineers working together. Anthropic's Claude Code Enterprise materials emphasise migration as one of the highest-value workloads. I have seen the same in my own work. Migration is the workload where the new tools produce orders-of-magnitude improvement, not single-digit ones.</p> If your engineering organisation can clear a 2-year migration backlog in 4 months, that is a board-relevant outcome. The percentage of code written by AI in the process is a footnote.</p> What I'd tell your CTO</h2> If I were sitting across the table from your CTO this quarter, my advice would be:</p> Stop reporting AI-generated code percentages upward.</strong> It will land well in the first board meeting and badly in the third, when someone realises the number is rising and the product is not getting noticeably better.</p> Pick one engineering value stream and rebuild it with AI in the middle.</strong> Migration is the obvious choice. Security remediation is another (Google reported 90%+ mitigation time reduction in some workflows). PR review is a third. Pick one, redesign it, measure throughput and quality.</p> Make the metrics changes visible across the organisation.</strong> Cycle time, defect escape rate, review latency, cost per accepted change, MTTR. Put them on a dashboard. Show them at every engineering review. The team will optimise for what gets measured. Right now, most teams are not measuring the right things.</p> Spend the saved engineering time on the work that humans still do best.</strong> Hard problem decomposition, system architecture, code review at the level of taste, mentoring, judgment under uncertainty. The engineers who become valuable in 2027 are the ones who orchestrate well. I wrote about this last month in orchestrator, not 10x engineer</a>.</p> The board reframe</h2> For boards reading this, the simple test is: when your CTO talks about AI in engineering, do they lead with effort metrics or outcome metrics? If the lead number is "% of code AI-generated," you are getting an activity report. If the lead number is "release frequency up, defect rate down, migration throughput tripled, cost per accepted change halved," you are getting a value report.</p> The companies winning the engineering productivity race in 2026 are not the ones with the highest AI-generated code percentage. They are the ones whose boards refuse to accept that number as the answer.</p> If you'd like to talk through what your engineering AI metrics should look like, or how to redesign one engineering value stream around agents, get in touch</a>. I've spent the last decade building engineering organisations that ship, and the last three years building them with AI in the middle.</p> Related: Has AI made developers slower? The METR study, reframed</a> · The orchestrator, not the 10x engineer</a> · What two hours with Anthropic's agent team taught me about building AI</a></em></p> Most of what you do at work will be automated. The interesting question is what won't 2026-04-11T00:00:00+00:00 If it can be automated, it must be automated.</p> I mean that literally. Not as aspiration, but as economic inevitability. Every task that a machine can do faster, cheaper, and more consistently than a human will eventually be handed to a machine. This has been true since the spinning jenny. AI just compresses the timeline from decades to months.</p> The question that most leaders are asking, "Will AI take our jobs?", is the wrong question. It's too binary and too abstract. The better question is specific and strategic: what can only humans do, and how do we get better at it?</strong></p> That's where the real competitive advantage lives. Not in resisting automation, but in ruthlessly embracing it so that your people can focus on the things that actually require a human mind.</p> What AI does better. Accept it and move on</h2> Let's be honest about this, because denial wastes time.</p> AI is better than humans at processing large volumes of structured information. It's better at pattern matching across datasets too large for any person to hold in their head. It's better at maintaining consistency across thousands of decisions. It's better at operating at scale without fatigue, mood, or distraction.</p> McKinsey estimates that 60-70% of current work activities could be automated</strong> with existing technology. Not future technology. What exists today. The insurance brokerage I worked with</a> achieved 67% autonomous case resolution. Not because the technology was extraordinary, but because most of those cases genuinely didn't require human judgement. They required pattern matching, data retrieval, and rule application. Machines do all three better than people.</p> Here's the finding that should challenge any comfortable assumptions about human-AI collaboration. Stanford HAI's 2025 AI Index reported that in a healthcare diagnostic trial, GPT-4 alone achieved 92% accuracy. Physicians alone scored 74%. And physicians assisted by GPT-4 scored 76%.</strong> Adding humans to AI made it worse. Not better. Worse. The humans second-guessed correct AI diagnoses and introduced errors that the AI alone would not have made.</p> This is deeply counterintuitive. It's also a useful corrective. The comfortable narrative that humans will always add value "in the loop" needs qualifying. For many tasks, they don't. The human edge is real, but it's narrower than most people want to believe.</p> Pretending otherwise isn't loyalty to your workforce. It's a failure of leadership. The organisations that try to protect people from automation end up protecting them into irrelevance, doing work that machines do better while competitors pull ahead.</p> The irreducible human capabilities</h2> So what's left? More than you might think. And it's the work that actually matters.</p> The Harvard Business School study with 758 BCG consultants mapped what they call the "jagged frontier" of AI capability. Consultants using GPT-4 completed 12% more tasks, 25% faster, with 40% higher quality, but only for tasks within the AI's capability frontier. For tasks outside the frontier, consultants using AI were 19% less likely to produce correct solutions.</strong> They trusted the AI when they shouldn't have. The best performers were the ones who knew exactly where the frontier was, and handled the other side themselves.</p> Strategic intent. Knowing what's worth doing</h3> AI can optimise any objective function you give it. What it cannot do is decide which objective function matters. It can tell you the most efficient path to a goal. It cannot tell you whether the goal is worth pursuing.</p> This is not a small distinction. The most expensive mistakes in business aren't execution failures. They're strategic ones.</strong> Building the wrong product perfectly. Optimising the wrong metric efficiently. Scaling the wrong business model flawlessly.</p> I've seen AI projects fail not because the technology didn't work, but because nobody asked whether the problem was worth solving. The 80% failure rate in AI projects</a> isn't primarily a technical problem. It's a strategic one. Someone has to own the intent. Someone has to say, "This is worth doing" or, more importantly, "This is not worth doing." That someone is human.</p> Taste, judgement, and opinion</h3> Here's something that doesn't get discussed enough in the AI conversation. Taste matters.</p> Not aesthetic taste, though that too. Business taste. The intuition that comes from twenty years of experience in an industry. The ability to look at a proposal and know, before the data confirms it, that something is off. The judgement to say "this is technically correct but strategically wrong."</p> AI has no opinions. It has outputs calibrated to probability distributions. It will give you the statistically most likely answer, which is often the most mediocre one. The organisations deploying AI well</a> aren't the ones deferring to AI outputs. They're the ones whose leaders have strong enough judgement to know when the AI is right and when it's confidently wrong.</p> Block's CTO Dhanji Prasanna said it well: code quality has "nothing to do" with product success. YouTube triumphed despite "terrible" code. The decisions that matter are about what to build, not how to build it.</strong> That's taste. That's judgement. And no model currently possesses it.</p> I've built products where the data pointed one way and experience pointed another. Experience was right more often than most data scientists would like to admit. Not because data doesn't matter, but because data only tells you what happened. Judgement tells you what it means.</strong></p> Lakhani, Spataro and Stave warned about this in HBR. A relentless focus on efficiency, they argue, "risks hollowing out the human capabilities, such as judgment and storytelling, that differentiate high-value work." The organisations that treat AI purely as a cost-reduction tool tend to lose the capacity to do the work AI cannot do.</p> Human-to-human relationships</h3> No amount of AI sophistication replaces the trust that forms between people who have worked through difficult problems together. A client doesn't hire me because an algorithm recommended me. They hire me because a conversation revealed that I understood their situation in a way that felt different from the others.</p> This isn't sentiment. It's economics. B2B sales cycles, board decisions, partnership formations, key hires. The transactions that shape organisations happen between humans who trust each other. AI can prepare the analysis. It can surface the options. It can draft the presentation. But the moment where someone decides to commit resources, take a risk, or change direction, that moment is human.</p> The shift from individual contributor to orchestrator</a> makes this more important, not less. As AI handles more of the technical execution, the human skills of communication, persuasion, and relationship become a larger proportion of what determines success.</p> Ethical reasoning and contextual wisdom</h3> AI systems optimise. That's what they do. They find the path of least resistance to whatever objective you've defined. They don't ask whether the objective is ethical. They don't consider second-order consequences on people who aren't represented in the training data. They don't feel uncomfortable when something is technically legal but plainly wrong.</p> Every organisation I've worked with has faced decisions where the right answer wasn't the most efficient one. Where serving a customer well meant absorbing a cost. Where doing the ethical thing meant leaving money on the table. These decisions require a kind of contextual wisdom that comes from lived experience, from having been in situations where the "optimal" choice turned out to be the wrong one.</p> The governance questions around shadow AI</a> are a good example. An AI system will happily process sensitive data if you let it. Knowing when it shouldn't, and why, requires human judgement about risk, reputation, and responsibility that no model currently possesses.</p> The strategic argument. Offload everything else</h2> If these are the irreducible human capabilities, the strategic implication is clear: automate everything that isn't on this list.</strong></p> Not gradually. Not cautiously. Aggressively.</p> Every hour your best people spend on work that a machine could do is an hour they're not spending on strategic thinking, relationship building, or the kind of difficult judgement calls that actually determine your organisation's trajectory. It's not just wasteful. It's competitively dangerous.</p> The dual-stream approach</a> I advocate is exactly this: run two tracks simultaneously. On one track, automate every process that can be automated. On the other, deliberately invest in developing the human capabilities that machines cannot replicate. The organisations that do both will outperform those that do either one alone.</p> This means restructuring roles, not eliminating them. It means telling your team: "We're going to take away the parts of your job that a machine does better, and we're going to expect you to become exceptional at the parts only you can do." That's a harder conversation than "AI is coming for your jobs," but it's a more honest and more productive one.</p> The "for now" problem</h2> I want to be honest about something. The human edge is shrinking.</p> Five years ago, I would have included creative writing on the list of irreducible human capabilities. Today, AI produces competent prose that passes most quality bars. Three years ago, I would have included basic code architecture. Today, agentic AI systems</a> are making architectural decisions that are, in many cases, good enough.</p> The boundary between "human only" and "machine capable" moves in one direction. It moves towards the machine. Slowly in some domains, startlingly fast in others. Anyone who tells you that strategic thinking, relationship building, and ethical judgement are permanently safe from automation is making a prediction about a technology whose trajectory they cannot know.</p> Ben Goertzel, CEO of SingularityNET, claims AI will surpass human strategic thinking "in about two years." I think he's probably wrong on the timeline, but I take the direction seriously. The WEF Future of Jobs Report identifies creative thinking, resilience, and curiosity as the fastest-rising skills employers value. These are the human edge skills. And yet a quieter risk is emerging in the data. Critical thinking is atrophying in teams that lean too hard on AI outputs.</strong> Junior staff who don't first form their own view before consulting the model lose, over time, the muscle that makes them a useful check on it. We may be losing the very capabilities that make us irreplaceable, even as we still hold them.</p> I don't think they're safe forever. I think they're safe now, and they'll be safe for long enough to matter strategically. The organisations that double down on developing these capabilities in their people will have a decisive advantage for the next five to ten years. And five to ten years of competitive advantage is, in business terms, an eternity.</p> The right response to a shrinking edge is not to pretend it isn't shrinking. It's to maximise the advantage while it exists.</strong> Play the hand you have, not the hand you wish you had or the hand you fear you'll be dealt.</p> What this means for you</h2> If you lead an organisation, three things follow from this argument.</p> First, stop protecting people from automation.</strong> Every task you shield from AI because "it's always been done by humans" is a task where you're choosing nostalgia over competitiveness. Free your people to do the work that only they can do.</p> Second, invest in the human skills that matter.</strong> Strategic thinking, judgement, relationship building, ethical reasoning. These aren't soft skills. They're the hardest skills. And they're the ones your organisation's future depends on. When AI handles scale and speed, the bottleneck becomes human judgement: the precision of the questions you ask, the depth with which you interpret model reasoning, and your ability to turn AI-generated ideas into better decisions. Lakhani, Spataro and Stave put it more bluntly in a recent Harvard Business Review piece: "the AI last mile is not blocked by technology. It is blocked by unresolved questions regarding operating models, governance, and human identity." Treat these skills with the same seriousness you treat technical capability.</p> Third, be honest about the timeline.</strong> The human edge is real, but it's not permanent. Build your strategy around it, but don't build your identity around it. Stay adaptive. The line will move again.</p> The most valuable people in any organisation have always been the ones who know what's worth doing, not just how to do it. AI hasn't changed that. If anything, it's made it more true than ever.</p> If you're working out where the human edge matters most in your organisation, get in touch</a>.</em></p> Related: You're not a 10x engineer. You're an orchestrator</a> · Most companies are adopting AI. Few are adopting it well</a> · Traditional moats are dissolving</a></em></p> AI is not just for engineering. Every function in your business can use it today 2026-04-04T00:00:00+00:00 McKinsey's latest State of AI survey found that 88% of organisations now use AI in at least one business function. But only 6% qualify as "AI high performers" attributing more than 5% of EBIT to AI.</p> That gap, between using AI and benefiting from AI, is the real story. The technology is deployed everywhere. The value is concentrated in a few. And the reason is almost always the same: most companies treat AI as an engineering tool, not a business-wide operating system.</p> Every process in every business in every industry can be optimised with AI. I don't mean hypothetically. I mean right now, with tools that exist today, at a cost that makes the ROI obvious within weeks. Shopify CEO Tobi Lutke made the right call when he told his company that no one can request headcount without first proving AI cannot do the job. The burden of proof has flipped.</strong> It's no longer "why should we use AI?" It's "why aren't we?"</p> The engineering tunnel vision problem</h2> Most companies that "do AI" are doing it in one place: software development. They've bought Copilot licences. Maybe they're experimenting with agentic coding tools. The engineering team is 6 months ahead of everyone else in the organisation.</p> Meanwhile, the finance team is still manually reconciling spreadsheets. Marketing is writing every piece of content from scratch. Customer support agents are copy-pasting the same responses they've been using for three years. Legal is reviewing contracts clause by clause.</p> Lakhani, Spataro and Stave described this same pattern in a March 2026 Harvard Business Review piece as "islands of productivity"</strong>: tools that boost individual output but exist as isolated wins, difficult to convert into scaled, trustworthy enterprise systems. That phrase matches what I see almost everywhere. A high-performing engineering function. A back office that has barely changed in a decade.</p> This is a massive missed opportunity. The biggest AI gains I've seen are not in engineering. They're in operations, support, and back-office functions</strong> where the work is repetitive, the volume is high, and the cost of doing it manually is quietly enormous.</p> Function by function. What works today</h2> Finance and accounting</h3> AI is genuinely good at financial operations right now. Invoice processing, expense categorisation, anomaly detection in transactions, cash flow forecasting. These are not experimental use cases. They're production-ready.</p> IBM automated over 90% of their finance journal entries using watsonx Orchestrate. HPE uses intelligent agents to automate quarterly close, forecasting, and analysis. These aren't pilots. They're running in production at two of the largest technology companies in the world.</p> I've seen finance teams cut month-end close time by 40% using AI-assisted reconciliation. The tool doesn't replace the accountant. It does the tedious matching work and flags the exceptions that need human judgement. Fortune reports that CFOs are predicting AI will transform finance from retrospective reporting to real-time decision-making. The role is shifting from "what happened" to "what should we do."</p> What doesn't work yet: fully autonomous financial decision-making. AI can surface insights and flag anomalies, but anything involving judgement calls on material financial matters still needs a human. And it should.</p> Marketing and content</h3> This is where the gap between what's possible and what most teams actually do is widest.</p> Most marketing teams using AI are generating first drafts of blog posts. That's fine, but it's about 10% of the value available. The real gains are in research, personalisation, and distribution.</strong> AI can analyse your entire content library and identify gaps. It can segment audiences and tailor messaging at a scale that would require a team of ten to do manually. It can A/B test subject lines, optimise send times, and identify which channels are converting for which segments.</p> HubSpot's 2025 State of Marketing report found that teams using AI across the full content lifecycle (research, creation, distribution, analysis) saw 3x the output with the same headcount</strong>. Not 3x the content. 3x the output measured by engagement and conversion.</p> What doesn't work yet: letting AI write your brand voice without heavy human editing. The tools produce competent copy. Competent is not enough. You still need a human who understands what makes your voice distinctive.</p> Sales</h3> AI in sales is past the experimental phase. Lead scoring, call analysis, pipeline forecasting, proposal generation. These are all live use cases with proven ROI.</p> The most impactful application I've seen is AI-powered call analysis</strong>. Tools like Gong and Chorus analyse every sales conversation, identify what top performers do differently, and surface coaching opportunities for the rest of the team. One organisation I advised saw win rates increase 18% within a quarter after implementing structured call analysis with AI-generated coaching recommendations.</p> Proposal generation is another area where the ROI is immediate. A senior salesperson spending two hours crafting a custom proposal can get a strong first draft in fifteen minutes. That's not about replacing the salesperson. It's about freeing them to spend time on relationships and strategy instead of formatting documents.</p> What doesn't work yet: AI closing deals autonomously. Sales is fundamentally about trust between humans. AI makes salespeople more effective. It doesn't replace them.</p> Customer support</h3> This is where I have the most direct experience. The insurance brokerage case</a> I led achieved 67% autonomous case resolution</strong> with an agentic AI system. Not chatbot-style deflection. Genuine resolution: retrieving policy information, making coverage determinations, communicating outcomes to customers.</p> Klarna's experience is instructive. Their AI assistant handled 2.3 million conversations in its first month, equivalent to 700 full-time agents. The headlines were triumphant. Then quality problems forced them to reverse course and rehire humans. They ended up with a hybrid model that may actually be more effective than either pure approach. The lesson: AI can handle the volume, but you need humans for the edge cases that destroy customer trust when handled badly.</p> The key insight from my own work: customer support is the function where AI delivers the most measurable, immediate ROI</strong> in most organisations. The volume is high, the queries are repetitive, the cost per interaction is well understood, and the quality bar is definable. If you're only going to pick one function to start with, start here.</p> What doesn't work yet: handling emotionally complex or genuinely novel situations. The best systems know when to escalate. The worst ones try to handle everything and erode trust in the process.</p> Legal and contracts</h3> Legal is the sleeper disruption story of 2026. Corporate AI adoption in legal more than doubled in a single year, from 23% to 52%, according to the ACC/Everlaw survey. 64% of in-house teams now expect less dependence on outside counsel. 61% are pushing for changes in how outside legal services are priced.</p> Tools like Luminance, Ironclad, and Thomson Reuters' CoCounsel can review standard commercial contracts in minutes, flagging non-standard clauses, missing provisions, and risk areas that a junior lawyer would take hours to identify. LexisNexis has deployed a four-agent system for legal research: orchestrator, legal research, web search, and customer document analysis.</p> I've seen legal teams reduce contract review time by 60-70% for standard agreements. The AI handles the first pass. The lawyer handles the judgement calls. This isn't about reducing legal headcount. It's about removing the bottleneck that legal review often creates in deal velocity.</p> What doesn't work yet: novel legal reasoning or complex regulatory interpretation. AI can tell you what a contract says. It can't yet reliably tell you what it means in the context of a specific business situation and regulatory environment.</p> Project management and reporting</h3> This is the function where AI adoption is lowest and the opportunity is most underestimated.</p> AI can eliminate 80% of status reporting.</strong> It can pull data from Jira, Slack, GitHub, and your time-tracking tool, synthesise it into a coherent status update, flag risks based on velocity trends, and generate the weekly report that a project manager currently spends two hours compiling every Friday.</p> I've seen project leads reclaim an entire day per week by automating reporting and status synthesis. That's a day they can spend actually managing the project instead of describing it.</p> What doesn't work yet: AI project managers. Prioritisation, stakeholder management, and the ability to read a room when a project is going sideways. These remain distinctly human skills.</p> Internal communications</h3> Meeting summarisation alone justifies AI investment for most organisations. If your company has more than 50 people, you're spending thousands of hours per year in meetings where half the attendees are there "just in case." AI meeting tools (Otter, Fireflies, Copilot in Teams) can record, transcribe, summarise, and extract action items. The people who didn't need to attend can read the summary in two minutes.</p> Beyond meetings: internal knowledge bases that actually answer questions, onboarding documentation that stays current, policy documents that can be queried rather than read. These are all production-ready use cases today.</p> The compounding effect</h2> Here's what makes internal AI enablement a competitive advantage rather than just an efficiency play.</p> Each function you optimise with AI frees capacity. That capacity can be redirected to higher-value work, or it can allow you to grow operations without proportionally growing headcount</strong>. When you do this across five or six functions simultaneously, the effect compounds. You don't get 10% efficiency in each area. You get a fundamentally different cost structure.</p> The trap, as Lakhani, Spataro and Stave noted in Harvard Business Review, is that "saved time is often re-absorbed into low-value activities, like more internal meetings or unnecessary emails, rather than being structurally harvested." Capacity does not capture itself. Someone has to redesign the role, change the budget line, or shift the headcount allocation. Without that step, the AI investment shows up as a vendor bill and nothing else.</p> The roles most exposed are the reporting-heavy ones in the middle of the organisation: finance analysts whose primary output is monthly decks, compliance officers compiling regulatory submissions, supply chain planners building forecasts from spreadsheets, procurement managers drafting RFPs. The organisations moving fastest are not eliminating these roles wholesale. They are reallocating the people in them toward analytical, judgement-heavy, and creative work that AI cannot yet do well.</p> The organisations I work with that understand this are not just saving money. They're moving faster than competitors who are still running every function manually. And that gap widens every quarter.</p> The common mistakes</h2> Even with the right intent, most organisations get internal AI enablement wrong in predictable ways.</p> Mistake one: starting everywhere at once.</strong> Pick one function. Get it working. Measure the results. Then expand. The 80% failure rate</a> applies to internal tools just as much as customer-facing ones.</p> Mistake two: no governance.</strong> When every department is buying its own AI tools, you get shadow AI</a> at scale. Sensitive data flowing to tools nobody approved. Duplicate spend. Inconsistent quality. Internal enablement needs a lightweight governance framework from day one.</p> Mistake three: expecting AI to fix broken processes.</strong> If your sales process is a mess, AI will make it a faster mess. The organisations that see real results redesign the workflow</a> before adding AI to it.</p> Mistake four: forgetting the humans.</strong> Every function-level AI deployment is a change management exercise. The finance team needs to trust the reconciliation tool. The legal team needs to believe the contract review is reliable. That trust is built through transparency, gradual rollout, and honest communication about what the tool does and doesn't do.</p> Where to start</h2> If I were advising an organisation that hadn't yet done any cross-functional AI enablement, I'd tell them to pick the function with the highest volume of repetitive, well-defined work. For most companies, that's customer support or finance operations.</p> Run a focused pilot. Measure before and after. Be honest about what worked and what didn't. Then use that success (and those lessons) to build momentum for the next function.</p> The technology is ready. The tools are affordable. The ROI is measurable within a quarter, not a year. The only thing missing in most organisations is someone with enough authority and enough cross-functional understanding to see the full picture and connect the dots. That is not a technology problem. It is a leadership one</a>.</p> If you want to map where AI can create the most value inside your organisation, get in touch</a>.</em></p> Related: How to unlock AI ROI: what the 20% do differently</a> · Most companies are adopting AI. Few are adopting it well</a> · How I approach AI transformation</a></em></p> Traditional moats are dissolving. Size and capital no longer protect you 2026-03-28T00:00:00+00:00 The most dangerous assumption in business right now is that being big makes you safe.</p> For decades, size was the ultimate competitive advantage. Deep pockets meant you could outspend competitors on R&D, hire the best talent, absorb regulatory costs, and outlast anyone who tried to disrupt you. Scale meant distribution. Distribution meant dominance. And dominance, once achieved, was very hard to undo.</p> That logic is breaking down. Fast.</p> The moat is leaking</h2> Warren Buffett popularised the concept of economic moats: the structural advantages that protect a business from competition. Brand recognition. Proprietary data. Network effects. Regulatory capture. Economies of scale. These were the things that let incumbents sleep well at night.</p> AI is eroding every single one of them.</p> Brand recognition</strong> used to take decades and hundreds of millions in marketing spend to build. Today, a two-person team with a genuinely useful AI-powered product can reach millions of users in weeks through organic distribution. Perplexity went from zero to 100 million monthly queries in under two years. Not because they outspent Google. Because they built something that solved a problem better than the incumbent.</p> Proprietary data</strong> was once an unassailable advantage. You had the data, your competitors didn't, end of discussion. Now, foundation models trained on the open web give any startup access to reasoning capabilities that previously required a decade of data collection. The advantage has shifted from having</em> data to knowing what to do with it</em>. Those are very different capabilities.</p> Economies of scale</strong> meant that producing more was cheaper per unit, which meant incumbents could undercut any challenger. But when a team of five can build and deploy a product that previously required fifty, the cost curve inverts. The challenger isn't competing on your terms. They're operating on a fundamentally different cost structure.</p> Midjourney is the clearest example. Approximately 100 employees. $500 million in revenue. $10.5 billion valuation. No external funding. No sales team. No marketing department. Organic growth through Discord and social sharing. They built one of the most commercially successful AI products on the planet with a team smaller than most companies' marketing departments.</p> Sam Altman put it bluntly: "In my little group chat with my tech CEO friends there's this betting pool for the first year that there is a one-person billion-dollar company." That's not hyperbole. It's a direction of travel.</p> If you walk through the classic moat pillars one by one (switching costs, network effects, intangible assets, efficient scale, cost advantage) the only one that still clearly protects is the last. Physical cost advantage: factories, supply chains, mineral reserves, energy contracts. If your competitive advantage isn't bolted to the ground, AI is dissolving it.</strong></p> The speed advantage is compounding</h2> Here's what makes this different from previous waves of disruption.</p> Previous technology shifts, the internet, mobile, cloud, gave incumbents time to adapt. The transition from physical retail to e-commerce took fifteen years. The shift to mobile-first took a decade. Cloud migration is still happening twenty years after AWS launched.</p> AI is not giving anyone that kind of runway.</p> McKinsey's 2024 research found that organisations already using AI effectively are pulling ahead at an accelerating rate</strong>. The gap between AI leaders and laggards isn't closing. It's widening. Every quarter that an organisation delays meaningful AI deployment, the distance to the leaders grows, because the leaders are compounding their advantage. They're not just using AI. They're learning how to use AI better, building institutional knowledge that compounds over time.</p> I've seen this firsthand. One business I advised began embedding AI into its core operations roughly fifteen months ago. They are now operating on a different plane to a competitor with three times their headcount, who started six months ago and is still in pilot stage. The technology is no better today than it was for the early mover. The difference is fifteen months of compounded operational learning, model evaluations they've kept, prompts they've refined, workflows they've redesigned around AI from scratch. That institutional knowledge is the new moat. And you can't buy it. You can only build it.</strong></p> Why incumbents struggle</h2> If size no longer protects you, why don't large organisations just adopt AI faster?</p> Because the very things that made them dominant are now the things slowing them down.</p> Organisational complexity.</strong> A decision that takes a five-person startup an afternoon takes an enterprise six months. Procurement, legal review, security assessment, change management, stakeholder alignment, pilot programme, evaluation period, board approval, implementation. By the time the enterprise has approved the pilot, the startup has iterated through twelve versions of a production system.</p> Talent distribution.</strong> The people who are best at building with AI are disproportionately choosing to work at smaller companies or on their own. They want speed, autonomy, and direct impact. Enterprise bureaucracy is the opposite of what attracts them. Every founder I speak to who is hiring for production AI capability tells me the same thing: the best candidates are weighing offers from companies a tenth the size of the incumbent, and the smaller companies are winning more often than not. The talent is self-selecting away from the organisations that need it most.</strong></p> Sunk cost mentality.</strong> Large organisations have invested hundreds of millions in existing systems, processes, and team structures. Embracing AI properly often means acknowledging that some of those investments are now liabilities, not assets. That's a hard conversation for any leadership team, and harder still for one that approved those investments. The result is the AI theatre I've written about before</a>: pilots and innovation labs that exist to demonstrate activity without disrupting anything that matters.</p> Risk aversion at scale.</strong> When you have a billion-pound revenue line to protect, every change feels risky. When you have nothing to lose and everything to gain, every change feels like opportunity. This asymmetry has always favoured challengers, but AI amplifies it enormously because the cost of building a credible competitor has dropped by an order of magnitude.</p> What this means in practice</h2> This is not theoretical. It's playing out across industries right now.</p> In legal, the numbers are startling. Corporate AI adoption more than doubled in a single year, from 23% to 52%, according to the ACC/Everlaw survey. 64% of in-house legal teams now expect less dependence on outside counsel. 61% are pushing for changes in how outside legal services are priced. An entire industry built on billable hours and institutional knowledge is being restructured by tools that teams of ten built.</p> In software, the shift from traditional engineering to AI-augmented orchestration</a> means a small team with strong AI fluency can build what previously required departments. Andrej Karpathy, OpenAI co-founder, calls the new paradigm "agentic engineering": not writing code, but orchestrating agents who do. Features that took two to six weeks in 2024 now ship in a day, sometimes hours.</p> Since the start of 2026, ETFs for public software companies have fallen 30%. Salesforce, Adobe, Intuit, ServiceNow, all down 25-30% in weeks. a16z calls it the "SaaSpocalypse." The market is pricing in what the incumbents haven't yet accepted.</p> The pattern is the same everywhere. A small team that knows how to use AI well can now compete with organisations ten or fifty times their size.</strong> Not on everything. Not yet. But on specific, high-value capabilities that used to be the exclusive domain of incumbents.</p> And the window for incumbents to respond is narrowing.</p> The new moat</h2> If traditional moats are dissolving, what replaces them?</p> Institutional AI fluency.</strong> The organisations that will dominate the next decade are the ones building deep, organisation-wide capability in working with AI. Not just buying tools. Not just running pilots. Actually changing how work gets done, how decisions get made, how products get built. This is the investment that most organisations are still avoiding</a>.</p> Speed of iteration.</strong> The ability to deploy, measure, learn, and improve faster than competitors. This favours organisations with flat structures, clear decision authority, and a culture that treats failed experiments as data rather than career risk.</p> Production AI capability.</strong> The gap between "we have an AI strategy" and "we have AI systems in production delivering measurable business outcomes" is where competitive advantage lives. Only about one in five organisations unlock real ROI from AI</a>. The 20% that succeed are building something their competitors cannot easily replicate, because it's built on operational knowledge, not just technology.</p> Data feedback loops.</strong> Not the static data advantage of old, where you simply had more data than the competition. The dynamic advantage of having production AI systems that generate data about what works, which feeds back into better systems, which generate more data. This is the compounding loop that makes early movers increasingly hard to catch.</p> The honest assessment</h2> I'm not arguing that every large company is doomed or that every startup with an AI tool will win. Scale still matters for distribution, for regulatory compliance capacity, for customer trust in high-stakes domains.</p> But the balance has shifted. Dramatically. The assumption that being the biggest player in your market means you'll still be the biggest player in five years is no longer safe. Industry leaders have no guarantees of maintaining their position. The power is moving to those who know how to use AI, and who started learning earlier.</p> Lakhani, Spataro and Stave summarised the situation precisely in Harvard Business Review: "while execution is increasingly automated, what remains scarce is the leadership ability to imagine and commit to a different way of running the enterprise." That scarcity is the new moat. It is not capital. It is not headcount. It is the willingness, at the top of the organisation, to redesign.</p> If you're leading a large organisation, the question isn't whether you can afford to invest in AI transformation. It's whether you can afford the speed at which you're currently moving. Because somewhere, a team of five people who really understand this technology is building what comes next in your industry. And they're not waiting for your procurement process to finish.</p> If you want to talk through what this means for your competitive position, get in touch</a>.</em></p> Related: Turning AI theatre into AI that moves the numbers</a> · Most companies are adopting AI. Few are adopting it well</a> · How to unlock AI ROI: what the 20% do differently</a></em></p> The dual-stream strategy. Protect your current business while building what replaces it 2026-03-20T00:00:00+00:00 Every successful business is running on borrowed time. That sounds dramatic, but the evidence is clear: the average lifespan of an S&P 500 company has dropped from 61 years in 1958 to under 18 years today. McKinsey projects that by 2027, 75% of the companies currently on that list will have been replaced.</p> The cause isn't bad management. It's the inability to build the next thing while the current thing still works.</p> The innovator's dilemma, but worse</h2> Clayton Christensen named this problem decades ago. Successful companies optimise for their existing customers, their existing margins, their existing competitive advantages. They get so good at what they do that they can't see the thing that will make it irrelevant. By the time they do see it, someone else has built it.</p> AI makes this problem orders of magnitude more urgent. Previous technology shifts gave you a decade to adapt. AI gives you one to three years.</strong> The speed at which AI capabilities are compounding means the window between "this could affect our business" and "this has already disrupted our market" is collapsing.</p> I've worked with companies across sectors where this conversation is happening right now. The question always takes the same form: do we invest in new products that could eat into our own current advantage?</p> It's not really a dilemma.</p> Two streams, running in parallel</h2> The smartest position for any profitable business right now is to work in two parallel streams.</p> Stream one: protect and optimise what you have.</strong> Keep running your current business. Serve your customers. Maintain your margins. This is the revenue that funds everything else, and abandoning it prematurely is as dangerous as ignoring what comes next. Apply AI to make your existing operations more efficient, your customer experience sharper, your costs lower. This is where most organisations start, and it's necessary.</p> Stream two: build the thing that replaces it.</strong> Start developing AI-native capabilities that could fundamentally change your product, your business model, or your market position. This is the uncomfortable stream, because it means investing in something that might cannibalise the very thing generating your revenue today.</p> Most companies only run stream one. They use AI to optimise what exists. They bolt tools onto existing processes</a> and call it transformation. They measure adoption rates and report to the board that AI is being used. But they never build the thing that would actually change the trajectory of the business.</p> That's not strategy. That's maintenance.</p> The distribution is shifting</h2> Here's the part that makes boards uncomfortable. The balance between these two streams is not static. You should be putting more focus on stream two every quarter.</strong> Not because stream one is failing, but because the competitive landscape is accelerating.</p> A year ago, using AI to improve internal efficiency was a legitimate strategic priority. Today, it's table stakes. Every competitor is doing it. The differentiation now comes from AI-native products, AI-enabled business models, and capabilities that didn't exist before.</p> The numbers tell a brutal story. An NBER survey of 6,000 executives across the US, UK, Germany, and Australia found that over 80% detected no discernible productivity impact from AI</strong> despite near-universal adoption. Executives use AI only 1.5 hours per week on average. Robert Solow's 1987 paradox is repeating itself: "You can see the computer age everywhere but in the productivity statistics." The AI is there. The transformation is not.</p> Meanwhile, PwC's 2026 Global CEO Survey found that 45% of CEOs believe their company will not be viable in ten years if it continues on its current path. BCG classifies only 5% of companies as "future-built" for AI. 60% are laggards. The gap between those two groups is widening, not closing. Leaders expect twice the revenue increase and 40% greater cost reductions than laggards. And the gap compounds every quarter that the laggards delay.</p> The organisations I advise that are getting this right treat stream two with the same seriousness as stream one. Dedicated teams. Ring-fenced budget. Separate metrics. Not a side project in the innovation lab. Not a pilot that exists to generate a board slide. A genuine second line of business development with the mandate and resources to build something real.</p> The profit question</h2> The objection I hear most often is about margins. "We're profitable. Why would we invest in something that might not work and could undermine our current revenue?"</p> I'll be direct. Even if stream two needs to consume all your profits, or requires additional investment, it is worth doing.</strong> Because this is truly existential.</p> Your future self, one to three years from now, will never forgive short-sighted thinking on this. The companies that are cautious with stream two investment today will find themselves trying to catch up in 18 months when a competitor, or a startup with no legacy to protect, has already built what they should have been building.</p> This isn't theoretical. I've seen it happen in real time. At one organisation I worked with, we built an agentic AI system that achieved 67% autonomous case resolution</a>. That system didn't optimise the existing workflow. It replaced significant parts of it. The company's competitors, who were still optimising their existing processes, are now trying to catch up. They won't.</p> The pattern is playing out right now with companies you can name.</p> Klarna went all-in on AI replacing customer service agents. Their AI assistant handled 2.3 million conversations in its first month, equivalent to 700 full-time employees. Then quality problems forced them to reverse course and rehire humans. The lesson wasn't that AI doesn't work. It was that the transition requires building the new while still running the old. Ripping out stream one before stream two is ready is as dangerous as never starting stream two at all.</p> Shopify took the opposite approach and got it right. Revenue growing 21%+ per year while headcount dropped from 11,600 to 8,100. CEO Tobi Lutke's memo made it explicit: no one can hire a human without first proving AI cannot do the job. They didn't stop running the business. They systematically replaced how the business runs.</strong></p> Duolingo kept the same number of full-time employees and produced 4-5x more content by restructuring around AI. Same investment, radically different output.</p> The pattern is always the same: protect the current business at the expense of the next one, and someone else will build the next one for you.</strong></p> How to run stream two without killing stream one</h2> This is where the execution matters more than the strategy.</p> Start with a clear threat assessment.</strong> What does your business look like if an AI-native competitor enters your market with no legacy systems, no existing customer expectations, and no margin to protect? What would they build? That's what you need to build.</p> Ring-fence the investment.</strong> Stream two cannot compete with stream one for budget on a quarterly basis. If every investment decision runs through the same ROI model that governs your current business, stream two will always lose. New capabilities don't have the same return profile as established ones. They need protected funding with different success criteria.</p> Staff it with your best people.</strong> The temptation is to put the innovation team on stream two and keep your strongest operators on stream one. This is backwards. Stream two is harder, riskier, and more consequential. It needs your best technical and product minds, people who understand both the existing business and what AI can actually do in production.</p> Set a time horizon, not just a budget.</strong> Stream two needs 12 to 18 months to prove itself. If you're evaluating it on quarterly revenue contribution, you'll kill it before it has a chance to work. Define what success looks like at 6 months, 12 months, and 18 months. Make those milestones about capability and learning, not just revenue.</p> Accept the cannibalisation.</strong> If stream two succeeds, it will take revenue from stream one. That's the point. Better you cannibalise your own business than let someone else do it. Amazon understood this when they launched AWS, which competed directly with their own retail infrastructure costs. Apple understood it when the iPhone killed the iPod. The companies that survive are the ones willing to disrupt themselves.</p> The real risk is doing nothing</h2> I talk to a lot of leaders who frame this as a risk decision. "What's the risk of investing in stream two?" The risk of investing is that you spend money on something that takes time to generate returns.</p> The risk of not investing is that your business becomes irrelevant.</p> Those are not symmetrical risks.</p> PwC's 2026 data is unambiguous: companies applying AI widely to products, services, and customer experiences achieved nearly 4 percentage points higher profit margins</strong> than those using AI only for internal efficiency. CEOs with strong AI foundations are 3x more likely to report meaningful financial returns. That's not a marginal advantage. That's the difference between leading and following.</p> The roughly 80% of AI projects that never unlock their ROI</a> almost all share one characteristic: they were optimisation projects, not transformation projects. They made the existing thing slightly better. They didn't build the next thing.</p> Start now</h2> If you're running a profitable business and haven't started stream two, you're late. Not too late. But late enough that starting next quarter instead of this one is a decision you'll regret.</p> The good news is that stream two doesn't have to be enormous to begin with. A small team. A clear thesis about what an AI-native version of your business looks like. Permission to build something that might compete with your current product. And the understanding, at the board level, that this investment is not optional.</p> Your current business is funding your future one. Use it while it's still strong enough to do so.</p> If you want to talk through how this applies to your business, get in touch</a>.</em></p> Related: Turning AI theatre into AI that moves the numbers</a> · How to unlock AI ROI: what the 20% do differently</a> · Most companies are adopting AI. Few are adopting it well</a></em></p> What two hours with Anthropic's agent team taught me about building AI 2026-03-16T00:00:00+00:00 Anthropic recently ran a full workshop on their Claude Agent SDK at the AI Engineer conference. Thariq Shihipar, who works on the SDK team, spent nearly two hours walking through how Anthropic builds agents internally.</p> I've built agentic systems in production across insurance, defence, and enterprise software. Some of what I heard confirmed patterns I already use. Some gave me new tools. All of it crystallised into five principles that I think define how production agents should be built right now.</p> The actual agent code is about 50 lines. The real engineering is everything around it.</strong></p> Here are the five principles.</p> 1. Your agent is the environment, not the code</h2> This was the workshop's most powerful reframing. The orchestration code is trivial. The real engineering is what you put in the working directory. The same lesson, that the engineering lives in the scaffolding rather than the model, runs through everything you are actually talking to when you use an AI</a>.</p> A typical agent project:</p> your-agent/ ├── agent.ts # ~50 lines of boilerplate ├── CLAUDE.md # Instructions, API descriptions, rules ├── scripts/ # Bash tools with --help ├── lib/ # TypeScript SDKs and types ├── data/ # Reference data ├── skills/ # On-demand context ├── memories/ # Persistent state (just files) └── examples/ # Example scripts for codegen </code></pre> Context is not just a prompt. It's the scripts the agent can discover. The TypeScript SDK you generated for your API. The CLAUDE.md file describing what's available. The skill directories the agent can navigate into when it needs specialised knowledge.</p> Thariq used a good analogy. If someone locked you in a room and gave you tasks, would you want a stack of papers or a computer with Google? You'd want the computer. Give the agent the tools to find its own information, not the information itself.</strong></p>I've seen this principle in my own work. The insurance automation system</a> I designed resolves 67% of cases autonomously, and the agent code is a small fraction of the engineering effort. Most of the work went into the environment: data pipelines, decision rules, escalation logic, and verification layers. Once you make that shift, agent development becomes less about writing clever code and more about curating an excellent workspace.</p> 2. A shell replaces a tool registry</h2> Instead of defining a search tool, a lint tool, an execute tool, and a test tool, each with its own schema and error handling, Anthropic's approach is to give the agent bash. The agent just uses grep</code>, npm run lint</code>, npm test</code>, and ffmpeg</code>. One generic tool replaces an entire registry.</p> The reason this works is composability. Bash lets the agent pipe outputs together, save intermediate results to files, discover new capabilities by running --help</code>, and leverage the entire Unix ecosystem. You don't need to anticipate every action the agent might take. You give it a shell and it composes the tools that already exist.</p> This is how Claude Code is built, and it's the most capable coding agent available today. The same architecture powers non-coding agents in finance, legal, healthcare, and customer service. The bash tool is what makes it generalise.</strong></p> The workshop laid out a clear decision framework for when to use each capability. Tools for irreversible actions where you want explicit confirmation. Bash for composable operations. Code generation for dynamic logic.</p> </p> The practical takeaway: if you're maintaining more than a handful of custom tool definitions, you're probably doing work the shell could do better.</p> 3. Translate your data into the model's language</h2> This is the principle with the highest return on effort. Make your problem in-distribution.</strong></p> If you've only tried one search interface for your data, it's probably not enough. For a spreadsheet agent, you might try SQL queries, cell reference syntax, grep on CSV, or XML queries (XLS files are XML underneath). Different approaches work differently depending on the data shape.</p> The most impactful thing you can do is translate your data into a format the model already knows well. Loading a CSV into SQLite and letting the agent write SQL queries is often dramatically more effective than any custom search tool. Generating TypeScript interfaces from your API schema gives the model type information it can reason about natively.</p> This single step often produces more improvement than any amount of prompt engineering. It's also the easiest to test: try two formats, measure which produces better results, keep the winner.</p> 4. Verify at every layer, not just the output</h2> Every agent follows three steps: gather context, take action, verify work. Planning sits optionally between the first and second steps.</p> </p> That sounds trivial. Getting it right is not.</p> Verification is a discipline applied at every layer, not a final check.</strong> This aligns precisely with what I described in my earlier piece on agentic AI in production</a>. Errors compound in multi-step pipelines. Catching them early is dramatically cheaper than catching them at the end.</p> Anthropic uses deterministic rules wherever possible: linting, compilation, schema validation, constraint checks. In Claude Code, if the agent tries to write a file it hasn't read, the harness throws an error and tells it to read first. Simple, deterministic, and extremely effective.</p> A practical detail worth noting: the model reads error messages and iterates. If your error says "you tried to insert 50,000 rows in one operation, please chunk this into batches of 1,000 or fewer," the agent will follow that coaching. Design your error messages as instructions, not diagnostics.</strong></p> Sub-agents add a powerful verification layer. You spawn a sub-agent with a completely fresh context and frame the task combatively: "This analysis was written by a junior analyst. Find the errors." The fresh context means the verifier has no sympathetic relationship with the work. It's genuinely adversarial.</p> </p> The gap between self-verification and adversarial verification is significant. I plan to integrate this pattern into my own production deployments. Sub-agents also shine for parallel processing ("read and summarise sheet 1, sheet 2, sheet 3 simultaneously") and search offloading, where many queries run but only the final answer returns to the main agent. Both patterns keep the main context clean and focused.</p> 5. Read every transcript. Then improve the environment</h2> The workshop was emphatic about one workflow: don't start with the SDK. Start with Claude Code.</p> Set up a working directory with your APIs, data, and scripts. Write a CLAUDE.md. Chat with Claude Code and give it real tasks. Then read the transcripts.</p> This is the single most important practice for improving agent design, and it's the one most people skip.</strong></p> After every session, read the full transcript. Where did the agent get stuck? Where did it take unnecessary detours? What context was it missing? Where did it use training knowledge instead of your data?</p> Iterate on the environment based on what you learn. Improve the instructions. Add scripts. Create skills. Add hooks to catch behaviour you don't want. Then read the transcripts again.</p> The iteration loop between reading transcripts and improving context is where most of the real engineering happens. Once results feel good, writing the agent.ts file and deploying to a sandbox is straightforward.</p> A note on security</h2> Anthropic describes their security model as a "Swiss cheese defence." No single layer blocks everything. Together, the layers cover each other's gaps.</p> Your job as an agent builder is the outer layer: sandboxing. One container per user. Network isolation. Filesystem isolation. Use providers like Cloudflare, Modal, E2B, or Daytona.</p> The "lethal trifecta" to guard against: code execution, filesystem changes, and data exfiltration. Sandbox the network and you cut off exfiltration even if the other two are compromised.</strong></p> For database access, the principle is counterintuitive but sound: give the agent broad access, then add guardrails. Letting the agent write dynamic SQL and fix its own errors through iteration produces better results than restricting it to predefined queries. Reserve strict masking for genuinely sensitive data.</p> Build for now. Rewrite in six months</h2> Thariq closed with something that resonated. Model capabilities change fast. Code that was necessary six months ago may be unnecessary today. Build for current capabilities. Ship now. Rewrite later.</p> The companies moving fastest are the ones willing to throw away code and rebuild with current capabilities. As Thariq put it: "We can write code 10x faster. We should throw out code 10x faster."</strong></p> That's not instability. That's the natural rhythm of building on a platform that's improving faster than any in history. The best time to start is now, knowing you'll improve it later. If you want a structured way to move from prototype to production, my methodology page</a> describes how I approach these engagements, and the transformation sprint</a> is designed specifically for getting agentic systems into production.</p> Building an agentic system and want to validate your architecture? Let's talk.</a></em></p> Related: Agentic AI in 2026: what actually works in production</a> · AI made developers 19% slower. Here's what they were doing wrong</a> · How to unlock AI ROI: what the 20% do differently</a> · Case study: agentic AI in insurance</a></em></p> You're not a 10x engineer. You're an orchestrator, and that's harder 2026-03-12T00:00:00+00:00 Andrej Karpathy coined "vibe coding" in February 2025: "you fully give in to the vibes, embrace exponentials, and forget that the code even exists." It was a throwaway tweet. It became Collins Dictionary's Word of the Year. And a year later, Karpathy himself declared it passé.</p> His replacement term is more interesting: agentic engineering</strong>. "The new default is that you are not writing the code directly 99% of the time. You are orchestrating agents who do and acting as oversight."</p> That one sentence captures the biggest shift in software engineering in a generation. And most of the industry hasn't caught up with what it actually means.</p> The old 10x myth</h2> The "10x engineer" was always a flawed concept. The idea that one developer could produce ten times the output of another was based on a misunderstanding of what software engineers actually do. Writing code was never the bottleneck. Understanding the problem, designing the system, and making the right trade-offs. That was always the hard part.</p> But the myth persisted because, in the old paradigm, implementation speed was visible and valued. The engineer who could bang out a feature in a day while others took a week looked</em> ten times more productive, even if the feature was poorly designed and would need rewriting in six months.</p> AI has made that version of productivity meaningless. When any developer can direct an AI agent to produce code at machine speed, typing speed is no longer a differentiator. The skill that used to look like 10x, fast and fluent code production, has been commoditised overnight.</p> What hasn't been commoditised is the thing that was always more important: judgement.</strong></p> What orchestration actually looks like</h2> Boris Cherny, the head of Claude Code at Anthropic, runs 5 local sessions and 5-10 remote sessions in parallel, each in its own git checkout. He shipped 22 pull requests in a day, then 27 the next, every line written by AI. He hasn't edited code by hand since November 2025.</p> That sounds like effortless productivity. It isn't.</p> What Cherny actually does is architectural direction, quality control, and context management at a pace that would overwhelm most engineers. Each session needs a well-scoped task. Each result needs review against the broader system. Roughly 10-20% of parallel sessions get abandoned because the agent went in an unexpected direction. The team maintains structured documentation that tells the agent what conventions to follow and what mistakes to avoid, and every time the agent makes a new kind of error, they update the documentation so it doesn't happen again.</p> This isn't "vibe coding." This is engineering management at a different level of abstraction. The code is written by machines. The thinking (the decomposition, the verification, the architectural coherence) is entirely human.</p> At StrongDM, three engineers built what Simon Willison called "the most ambitious form of AI-assisted software development I've seen yet." No human writes code. No human reviews code. The humans design specifications, curate test scenarios, and watch scores. They built digital replicas of Okta, Jira, Slack, and Google Docs to run thousands of automated test scenarios per hour.</p> Three people. Zero human code. And the system works because those three people have the engineering judgement to design the right specifications and the right tests. Which is vastly harder than writing the code would have been.</p> The dirty secret</h2> Tanmai Gopal, CEO of a billion-dollar-plus startup, said something that cuts through the hype: "70% of the effort required to make AI useful relies entirely on unwritten business context that exists only in human heads."</strong></p> This is the part that gets lost in the "AI writes all the code" narrative. The code is the easy part. It was always the easy part. The hard part is knowing what to build, why to build it, and how it fits into the system that already exists.</p> An AI agent can write a feature. It cannot understand why the previous architect made certain trade-offs, what implicit assumptions the existing system relies on, which stakeholders care about which outcomes, or how a change in one subsystem will cascade through the business process it supports.</p> That context, the messy, human, organisational context, is the orchestrator's primary raw material. And it's the thing that makes the role harder, not easier, than the old "just write the code" paradigm.</p> The competence drain</h2> DHH, the creator of Ruby on Rails and one of the most respected voices in software development, described his experience with AI coding tools in strikingly physical terms: "I can literally feel competence draining out of my fingers."</p> He loves using AI for drafts, API lookups, and second opinions. But he keeps AI code in a separate window. He doesn't let it drive. His analogy: "You're not going to get fit by watching fitness videos. You have to do the sit-ups."</p> Dave Farley, author of the definitive book on continuous delivery, made the same point more directly: "AI is not going to replace software engineers. But it is going to expose the ones who never learned to think like engineers in the first place."</p> There's a real tension here. The orchestrator role requires more</em> engineering judgement than the implementer role, not less. You need to evaluate AI-generated code for correctness, security, performance, and maintainability. That means you need to understand code at a level that many developers never reached even when they were writing it themselves.</p> The METR study</a> found that developers using AI were 19% slower, and believed they were 20% faster. That perception gap is what the competence drain looks like from the inside. You feel productive because the tool is doing things at machine speed. But your ability to critically evaluate what it produces is atrophying. And you don't notice until something breaks in production.</p> What the orchestrator needs to be good at</h2> If the role is shifting from implementer to orchestrator, the skill profile shifts with it. Based on what I've seen work, both in my own practice and in the organisations I advise, here's what matters:</p> Problem decomposition.</strong> The single most important skill. An AI agent can execute a well-scoped task. It cannot take a vague business requirement and figure out what "done" looks like. The orchestrator breaks ambiguous problems into clear, testable units of work, each one small enough for an agent to handle and specific enough to verify.</p> Architectural judgement.</strong> AI generates code that works in isolation. The orchestrator ensures it works within the system: that the data model is consistent, the abstractions are right, the performance characteristics match the requirements, and the changes don't introduce subtle regressions elsewhere. This requires the kind of deep system understanding that only comes from experience. The national security platform</a> I worked on is a good example: when systems operate across 30+ countries at defence-grade reliability, there's no room for AI-generated code that "works in isolation" but breaks the wider architecture.</p> Verification discipline.</strong> Gergely Orosz, one of the most followed voices in software engineering, identified this as the skill that's becoming more</em> valuable as AI generates more code: the ability to read code critically and catch what's wrong. Not just syntax errors. Architectural flaws, security vulnerabilities, subtle logic errors that the agent will never flag. CodeRabbit's data shows AI produces 75% more logic errors and 8x more excessive I/O operations than humans. Someone has to catch those.</p> Context maintenance.</strong> The orchestrator holds the business context, the system context, and the user context in their head simultaneously, and translates that context into instructions the agent can act on. This is what Tanmai Gopal's "70% unwritten business context" means in practice: the orchestrator is the bridge between what the organisation needs and what the machine can do. In the insurance automation project</a>, the agentic system works because of clear decision delegation: the agent handles cases autonomously but the humans defined the boundaries, the escalation triggers, and the verification rules. That's orchestration at the organisational level.</p> Knowing when not to use AI.</strong> This might be the most underrated skill. Not every task benefits from AI delegation. Some problems require the kind of deep, focused thinking that gets worse</em> when you're managing parallel agent sessions. The best orchestrators I've worked with are deliberate about when they direct agents and when they sit down and think.</p> The identity problem</h2> There's something uncomfortable about this transition that doesn't get discussed enough.</p> An anonymous junior engineer at a large San Francisco tech company told the SF Standard: "I'm basically a proxy to Claude Code. My manager tells me what to do, and I tell Claude to do it. The skill you spent years developing is now just commoditised to the general public. It makes you feel kind of empty."</p> Michael Parker, VP of Engineering at TurinTech, put it differently: "I used to be a craftsman. Now I feel like a factory manager of Ikea. I'm just shipping low-quality chairs."</p> These aren't edge cases. A lot of experienced developers are grappling with the same feeling. The thing they were good at, writing elegant, efficient, well-structured code, is no longer the thing that matters most. The new thing that matters, orchestrating AI agents, maintaining context, verifying output, doesn't feel like craftsmanship. It feels like project management.</p> I think this is a temporary perception. Orchestration at its best is a craft, one that requires deeper understanding of systems, architecture, and engineering principles than implementation ever did. But it's a new craft, and the industry hasn't yet built the identity, the language, or the career ladders around it.</p> The organisations that figure this out first, that build roles, progression paths, and recognition structures for the orchestrator, will attract and retain the best engineering talent. The ones that don't will lose their best people to the companies that do.</p> What this means for engineering leaders</h2> If you lead an engineering team, the transition from implementer to orchestrator isn't optional. It's happening whether you manage it or not.</p> The question is whether it happens deliberately, with clear expectations, appropriate training, and workflow design that sets people up to succeed, or whether it happens chaotically, with developers independently experimenting with AI tools, accumulating technical debt, and losing skills they'll need when the agent produces something wrong.</p> I'd start with three things:</p> Redefine what "senior" means.</strong> If your promotion criteria still centre on code quality and implementation speed, they're measuring the old game. Senior engineers in the agentic era are defined by judgement, system thinking, and the ability to direct AI effectively, not by how fast they can write a function.</p> Build verification into the workflow.</strong> AI-generated code needs different review practices than human-written code. The failure modes are different: more duplication, more security vulnerabilities, more plausible-looking logic errors. Your code review process needs to account for this explicitly.</p> Invest in the transition.</strong> Your best implementers won't automatically become your best orchestrators. Some will. Others will need support, training, and time. The ones who make the transition will be extraordinarily valuable. The investment is worth it.</p> The title "software engineer" might survive. Or it might evolve into something else. What won't change is the need for people who can think clearly about complex systems, make good decisions under uncertainty, and translate business problems into technical solutions. That's always been the job. The tools just changed.</p> If you're navigating this transition in your engineering organisation and want to think it through with someone who's been in the seat, get in touch</a>.</em></p> Related: The training ladder is broken</a> · AI made developers 19% slower: here's what they were doing wrong</a> · Agentic AI in 2026: what actually works in production</a> · How I help engineering teams make this transition</a></em></p> AI made developers 19% slower. Here's what they were doing wrong 2026-03-08T00:00:00+00:00 The most rigorous study we have on AI coding productivity comes from METR, a non-profit AI research lab that ran a randomised controlled trial with 16 experienced open-source developers across 246 real-world tasks. The result: developers using AI tools completed tasks 19% slower</strong> than without them.</p> That's a striking finding. But the truly alarming part isn't the slowdown. It's this: before the study, developers predicted AI would make them 24% faster. After experiencing the slowdown, they still believed</em> AI had sped them up by 20%.</p> That perception gap, being slower while feeling faster, is the most dangerous thing happening in software engineering right now.</p> What METR actually measured</h2> The study deserves close reading, because the details matter more than the headline.</p> These were experienced developers working on their own mature repositories, codebases they knew intimately. They were using mainstream AI coding tools: autocomplete, chat-based assistance, the kind of tooling that most organisations have already deployed.</p> Domenic Denicola, maintainer of jsdom and one of the study participants, published a detailed account. A performance optimisation he estimated at 30 minutes took 4 hours and 7 minutes with AI. A test-writing task he estimated at 1 hour took 4 hours and 20 minutes. Agents got stuck in loops, spent 30+ minutes finding files, applied syntax incorrectly, and moved lines one at a time instead of reordering them.</p> His verdict: AI made the tasks "more engaging," like a game, but not faster. And agents required "constant handholding and continuous awareness of the model's limitations."</p> This is not a story about AI being useless. It's a story about developers using the wrong tools in the wrong way on the wrong tasks.</strong></p> The autocomplete trap</h2> Here's what most organisations have done: they've bought Copilot licences, rolled them out to the engineering team, and called it AI adoption.</p> That's like giving someone a power drill and asking them to use it as a hammer. It's the wrong tool for the job. Or more precisely, it's the right tool being used in the wrong paradigm.</p> Autocomplete-style AI, suggesting the next few lines as you type, is useful for boilerplate. But when you're working in a codebase you already know well, on tasks you already know how to do, adding an AI middleman to your muscle memory is overhead. You're slower because you're reading and evaluating suggestions for code you could have written faster yourself.</p> The METR developers weren't bad engineers. They were excellent engineers using AI tools designed for a workflow that doesn't match how excellent engineers actually work.</p> What "doing it right" looks like</h2> Meanwhile, in a parallel universe, Boris Cherny, the head of Claude Code at Anthropic, ships 10 to 30 pull requests per day. Every line written by AI. He hasn't edited code by hand since November 2025.</p> Lee Edwards, an investor at Root Ventures, wrote hundreds of thousands of lines of code across six projects in two weeks using agentic AI tools. He described it as "a nuclear-powered six-axis mill. A single-person software factory."</p> At StrongDM, three engineers built a system where no human writes code and no human reviews code. The humans design specifications, curate test scenarios, and watch scores. Simon Willison called it "the most ambitious form of AI-assisted software development I've seen yet."</p> These aren't demo numbers. These are production systems. I've seen the same pattern in my own work: the agentic AI system I designed for a European insurance brokerage</a> resolves 67% of customer service cases without human intervention. Not a demo. A production system handling thousands of cases per month.</p> The difference isn't talent. It's method.</strong></p> Autocomplete versus agentic</h2> The gap in the data makes no sense until you separate two fundamentally different approaches to AI-assisted development.</p> Autocomplete AI</strong> (Copilot, inline suggestions): the developer writes code, the AI suggests completions. The developer remains in the driver's seat, making every decision, with the AI offering marginal assistance on each line. On familiar codebases with experienced developers, this adds friction more often than it removes it. DX's survey of 121,000 developers found that productivity gains from this approach have plateaued at roughly 10%, unchanged since Q2 2025.</p> Agentic AI</strong> (Claude Code, Cursor agents, similar tools): the developer describes what needs to be built. The AI agent reads the codebase, writes the code, runs the tests, iterates on failures, and delivers a working result. The developer's role shifts from writing to directing and reviewing. This is where the 5x-10x productivity claims come from, and where the evidence supports them.</p> The METR study measured the first approach. The production results from Cherny, Edwards, and StrongDM use the second.</p> This distinction matters enormously, because most organisations haven't made the shift. They're still in the autocomplete paradigm: buying licences, measuring adoption rates, and wondering why the numbers haven't moved.</p> The perception gap is the real problem</h2> Let me come back to that METR finding: developers were 19% slower but believed they were 20% faster. That's a 39-percentage-point perception gap.</p> This pattern is everywhere. The DX survey found 92.6% of developers use AI tools at least monthly, but productivity gains are stuck at 10%. Fastly's survey found 95% of developers spend extra hours debugging AI output. Seniors spend up to 40% of their time fixing AI-generated code. CodeRabbit's analysis of 470 open-source repositories found that AI creates 1.7x more bugs, 75% more logic errors, and 2.74x more security vulnerabilities than human-written code.</p> Meanwhile, Stack Overflow's 2025 developer survey shows trust in AI accuracy has fallen</em> to 29%, down from 40%. And the top frustration, cited by 66% of developers: "AI solutions that are almost right, but not quite."</p> If your team believes AI is making them faster but you can't see it in the output metrics, the METR perception gap is probably your explanation.</strong> They're not lying. They genuinely feel more productive. The tool is engaging and reduces the tedium of certain tasks. But the net effect, including debugging, rework, and the cognitive overhead of evaluating suggestions, is neutral or negative.</p> You can't fix what you can't see. And if your developers sincerely believe the tool is helping when the data says it isn't, you have a measurement problem masquerading as a productivity problem.</p> What I'd tell a CTO reading this</h2> I use agentic AI tools daily. I've seen what they can do in the hands of someone who understands both the tools and the engineering problems they're applied to. The productivity gains are real. Genuinely transformative in some workflows.</p> But I've also seen the other side: organisations that rolled out AI coding tools, measured adoption instead of outcomes, and now have developers who are slower, less rigorous in code review, and accumulating technical debt at a rate that will cost them dearly in 18 months.</p> The difference comes down to three things:</p> First, use the right class of tool for the job.</strong> Autocomplete has its place for quick lookups, unfamiliar syntax, and API discovery. But for meaningful productivity gains, you need agentic tools that can take on whole tasks, not just suggest the next line. And your workflow needs to be rebuilt around delegation and review, not around typing faster.</p> Second, measure outcomes, not adoption.</strong> I don't care what percentage of your team uses AI tools. I care about cycle time, defect rate, time-to-production, and business metrics. If those haven't improved, your AI adoption isn't working, regardless of what your developers report in satisfaction surveys. The discipline this requires is the same one I learned building defence-grade platforms</a>: measure what matters, not what's easy to count.</p> Third, invest in AI fluency, not just AI access.</strong> The gap between the METR developers (19% slower) and Boris Cherny (27 PRs per day) is not about the AI models. It's about how you structure your work around them. That's a skill, and like any skill, it requires deliberate development, not just tool provisioning.</p> The organisations that get this right will have a genuine competitive advantage. The ones that confuse AI adoption with AI effectiveness will have expensive tools and the same output. Or worse.</p> If you're trying to figure out whether your AI tooling investment is actually delivering, let's talk</a>.</em></p> Related: Turning AI theatre into AI that moves the numbers</a> · Why your AI spend isn't showing up in the numbers</a> · Agentic AI in 2026: what actually works in production</a> · Transformation sprint: fixing AI tooling and workflow</a></em></p> Most companies are adopting AI. Few are adopting it well 2026-03-04T00:00:00+00:00 Here are four numbers that should not coexist:</p> 84%</strong> of developers now use AI coding tools</li> 29%</strong> trust the accuracy of what those tools produce</li> 10%</strong> is the average productivity gain, unchanged for a year</li> 55%</strong> of companies that laid off workers for AI now regret it</li> </ul> That's not an AI problem. That's an adoption problem. And it's the most expensive kind: the kind where you've already spent the money and aren't getting the return. It's also the most recoverable kind, because the fix doesn't need a bigger budget or a better model. It needs the return unlocked from spend you've already committed.</p> The procurement fallacy</h2> Most organisations treat AI adoption as a procurement decision. Buy Copilot licences. Roll them out. Track adoption rates. Report to the board that 90% of engineers are using AI tools, a habit that usually traces back to decision-makers who have watched a demo rather than built anything</a>.</p> This is the equivalent of buying gym memberships for the entire company and measuring success by how many people scanned their badges at the door. You're measuring presence, not results.</p> MIT researchers found that 95% of enterprise generative AI deployments had no measurable impact on profit and loss</strong>. Not "small impact." No measurable impact. Forrester found that over half of companies that cut staff in the name of AI efficiency are now quietly rehiring, because it turns out that removing humans from processes that AI can't actually handle creates problems that are more expensive than the savings.</p> The founders and small to mid-market teams I work with that are genuinely getting value from AI didn't start by buying tools. They started by asking a different question entirely.</p> What "doing it badly" looks like</h2> The pattern is remarkably consistent.</p> Stage 1: Tool deployment.</strong> The company buys AI coding tool licences. There's an announcement. Maybe a lunch-and-learn. Developers start using autocomplete suggestions.</p> Stage 2: Adoption theatre.</strong> Usage numbers go up. The team reports feeling more productive. Internal surveys are positive. The board gets a slide showing 85% adoption.</p> Stage 3: The invisible costs accumulate.</strong> Code review becomes cursory. Developers rubber-stamp AI suggestions they should scrutinise. Technical debt accumulates faster. CodeRabbit's analysis of 470 open-source repositories found AI-generated code contains 1.7x more bugs, 75% more logic errors, and 2.74x more security vulnerabilities. GitClear tracked a doubling of code churn (lines reverted or updated within two weeks) compared to the pre-AI baseline. Copy-pasted code increased 48%.</p> Stage 4: The reckoning.</strong> Defect rates climb. Production incidents increase. The productivity gains that everyone felt never materialise in the actual delivery metrics. But by now, the organisation has restructured around the assumption that AI is working. Unwinding is painful.</p> I've seen this play out at multiple organisations. The specific tools vary. The pattern doesn't.</p> What "doing it well" looks like</h2> The companies getting genuine returns from AI share characteristics that have nothing to do with which model they're using or how much they're spending on compute.</p> They changed the workflow, not just the tooling</h3> Deloitte's research shows that organisations taking a work-redesign approach, rethinking processes before selecting tools, are twice as likely to exceed ROI targets</strong> than those starting with the technology.</p> This means something concrete. It means you don't give developers AI tools and tell them to keep working the same way. You redesign how work flows through the team. At Anthropic, the Claude Code team maintains structured documentation files that tell the AI agent what the codebase conventions are, what mistakes to avoid, and how to structure changes. That's not a tool feature. It's a workflow decision. And it improves output quality by 2-3x.</p> At Shopify, Tobi Lutke's internal memo was explicit: "Reflexive AI usage is now a baseline expectation." But the meaningful part wasn't the mandate. It was the structural change. Teams must demonstrate why they cannot achieve what they need using AI before requesting additional headcount. That forces a genuine rethink of how work gets divided between humans and tools, rather than bolting AI onto the existing structure.</p> They measure outcomes, not activity</h3> DX surveyed 121,000 developers across 450+ companies and found that the organisations seeing real gains aren't the ones with the highest adoption rates. They're the ones measuring business-level outcomes: cycle time, defect rate, time from commit to production, customer-facing incident frequency.</p> Some companies in the survey saw twice as many customer-facing incidents after AI adoption. Others saw a 50% reduction. The difference wasn't the tools. It was whether the organisation had built quality gates that matched the new workflow.</p> Laura Tacho, CTO at DX, put it precisely: "In struggling organisations, AI tends to highlight existing flaws rather than fix them."</p> They invested in agentic workflows, not just autocomplete</h3> This is the biggest differentiator I see. The 19% slowdown that METR found in their study</a> was developers using autocomplete-style tools on familiar codebases. The 5-10x gains that companies like StrongDM, Courier, and Anthropic report come from agentic workflows, where AI agents take on entire tasks, not just suggest the next line of code.</p> The shift from autocomplete to agentic isn't just a tool upgrade. It requires fundamentally different skills from the developer: the ability to decompose problems into well-scoped tasks, write clear specifications, evaluate output critically, and maintain architectural coherence across AI-generated code. That's a training investment, not a licence purchase.</p> They kept humans in the loop, deliberately</h3> Duolingo made headlines with a policy that only permits hiring if work cannot be automated. It's a bold position, and I understand the logic. But the companies I've seen get the best results take a more nuanced approach: they define specifically which decisions AI makes autonomously, which require human review, and which remain entirely human.</p> This isn't governance for governance's sake. It's engineering. The insurance brokerage I worked with</a> achieved 67% autonomous case resolution, but the 33% that required human handling was designed with as much care as the automated portion. The handoff included full context, the agent's reasoning, and the information it had retrieved. That's what made the whole system trustworthy enough to scale. The same principle held at NHS Wales</a>, where the governance structures weren't optional. They were the foundation for a transformation programme that identified £20M+ in savings opportunities.</p> The Shopify paradox</h2> Shopify is doing something interesting that illustrates the tension well. On one hand, Lutke's memo says prove AI can't do it before we hire a human. On the other hand, Shopify is hiring 1,000 interns specifically for "AI-native thinking."</p> That's not a contradiction. It's the right strategic move. They're reducing headcount for tasks AI genuinely handles well, while simultaneously investing in developing people who can work with</em> AI effectively. They understand that the tool is only as good as the human directing it, and that developing that human capability requires deliberate investment.</p> Most organisations are doing only the first half: cutting costs. Very few are doing the second half: building capability. And the second half is where the long-term competitive advantage lives.</p> What I'd ask any engineering leader</h2> If you're running an engineering organisation and you've deployed AI tools, three questions will tell you whether you're adopting well or just adopting:</p> Are you measuring outcomes or adoption?</strong> If your primary metric is "percentage of developers using AI tools," you're measuring the wrong thing. If you can point to specific improvements in cycle time, defect rate, or delivery throughput, and attribute them to AI, you're on the right track.</p> Have you changed the workflow or just added a tool?</strong> If developers are working the same way they did before, with AI suggestions layered on top, you're in the autocomplete trap. The real gains come from redesigning how work is structured, delegated, and reviewed.</p> Are you developing AI fluency or just providing AI access?</strong> The gap between developers who are slower with AI tools</a> and developers who are 10x more productive is not about the tools. It's about skill, method, and workflow design. That requires investment: in training, in mentorship, in giving people time to develop new ways of working.</p> The good news is that the organisations doing this well are pulling ahead fast. The bad news is that most organisations haven't started. If you're not sure where your organisation falls, the AI readiness diagnostic</a> will give you a clear picture in 15 minutes.</p> If you want to figure out where your AI investment is actually delivering and where it's theatre, get in touch</a>.</em></p> Related: Turning AI theatre into AI that moves the numbers</a> · How to unlock AI ROI: what the 20% do differently</a> · How I approach AI transformation</a></em></p> The training ladder is broken. And nobody has a plan to fix it 2026-02-25T00:00:00+00:00 Entry-level developer hiring has dropped 67% since 2022. At the fifteen largest US tech companies, new graduate hiring has fallen by more than half since 2019. Fresh graduates now make up just 7% of big tech hires. At startups, the number has gone from 30% to under 6%.</p> These aren't projections. These are the numbers right now.</p> And almost nobody in a leadership position is talking about what happens next.</p> The logic that got us here</h2> The reasoning is straightforward, and on the surface, hard to argue with.</p> AI tools can now do a significant portion of what junior developers used to do. Bug fixes. Boilerplate code. Test writing. Documentation. Simple feature implementation. The tasks that used to take a new graduate three days now take an AI agent three minutes.</p> So companies look at the numbers and make the obvious call: why hire a junior at £60-90K when an AI tool costs a fraction of that? Hire fewer, more experienced engineers. Give them agentic AI tools. Get more output from a smaller, senior team.</p> I understand the logic. I've been in the room when this decision gets made. And in the short term, it works. Headcount drops. Output holds. The CFO is happy.</p> The problem is that this logic has a time bomb buried in it.</strong></p> Where senior engineers come from</h2> This might seem obvious, but it needs saying: every senior engineer was once a junior engineer.</p> The skills that make someone a valuable senior developer (architectural judgement, debugging intuition, the ability to read a codebase and understand not just what it does but why it was built that way, the instinct for where a system will break under load) none of these come from courses or certifications. They come from years of doing the work. The grunt work. The work we're now automating away.</p> Harvard economists analysed 62 million LinkedIn profiles and 200 million job postings. Their finding was precise: at firms that adopted generative AI, junior headcount fell 7.7% within six quarters. Senior employment barely moved. The decline was steepest among graduates of mid-tier universities, not the elite schools (those graduates are too productive to replace) and not the lowest tier (too cheap to bother replacing). The middle got squeezed.</p> Mark Russinovich, Azure's CTO and not exactly a junior voice in this conversation, published a paper in February with Scott Hanselman arguing that AI tools "give senior engineers an AI boost while imposing an AI drag on early-in-career developers." He said this is now a hot topic in every customer engagement Microsoft has. Every company sees it. Nobody has a plan.</p> Matt Garman, the CEO of AWS, was more blunt. He called replacing junior developers with AI "one of the dumbest things I've ever heard." His reasoning: juniors are the least expensive employees you have, and they're the most engaged with AI tools. Cut them, and in ten years "you have no one that has learned anything."</p> The training ladder problem</h2> Software engineering has always had an informal training ladder. You join as a junior. You fix bugs. You write tests. You struggle with a codebase someone else built. You make mistakes and learn from the code review. You pair with a senior who shows you why your elegant solution won't survive production traffic. Gradually, painfully, you develop judgement.</p> That ladder is being dismantled.</strong> Not deliberately. Nobody set out to destroy it. But the economic incentives are all pointed the same way: automate the junior work, hire fewer juniors, give the savings back to the business.</p> The problem is that the junior work was</em> the training. It wasn't grunt work that happened to be done by beginners. It was the mechanism by which beginners became experts.</p> Anthropic, the company that builds Claude, ran their own study on this. Junior engineers using AI scored 50% on comprehension tests. Those who coded manually scored 67%. The largest gap appeared in debugging, the exact skill that separates a competent senior from a dangerous one.</p> Stack Overflow's monthly question volume has collapsed from 200,000 at peak to under 4,000 by the end of 2025. That's a 78% year-over-year decline. The knowledge ecosystem that trained a generation of developers, and that AI models themselves were trained on, is dying.</p> The five-year cliff</h2> Octopus Deploy's AI Pulse Report projects a three-phase crisis: experimentation (2024-2025), junior hiring freeze (2025-2027), and senior talent crisis (2027-2030).</p> I think that timeline is roughly right. The wage gap is already widening. US junior developers earn $75-95K while seniors command $193-263K. That gap will widen further as junior supply increases (more graduates, fewer positions) and senior demand intensifies (fewer juniors maturing into senior roles, more AI systems requiring senior oversight).</p> The maths is simple. If you stop feeding the bottom of the pipeline, the top of the pipeline runs dry. Not immediately. Not this quarter. But the organisations making these cuts today will feel the consequences, and by the time they feel them, rebuilding the pipeline will take years, not months.</p> What I'd actually do about it</h2> I don't think the answer is to ignore AI's capabilities and keep hiring juniors to do work that AI genuinely does better. That's nostalgic, not strategic.</p> But I do think the answer requires more imagination than most organisations are applying. Here's what I'd recommend to any CTO or engineering leader thinking about this:</p> Redefine what juniors do, don't eliminate the role.</strong> The junior developer role needs to evolve, not disappear. Instead of writing boilerplate, juniors should be reviewing AI-generated code, learning to spot the patterns of failure that AI produces (and it produces them reliably; CodeRabbit's data shows AI creates 1.7x more bugs and 2.74x more security vulnerabilities than humans). This is a different training ground, but it's still a training ground.</p> Make mentorship a measured responsibility.</strong> Russinovich and Hanselman's paper proposes a "preceptor model," structured mentorship where senior engineers are explicitly assessed on developing junior talent. I'd go further: make it a promotion criterion. If you can't develop the people around you, you're not senior. You're just experienced.</p> Invest in the AI-native training path.</strong> Shopify is hiring 1,000 interns specifically for what they call "AI-native thinking." That's a bet on a new kind of training ladder, one where the junior's job is to direct AI agents, evaluate their output, and develop the judgement to know when the output is wrong. It's a different skill set, but it still requires deliberate development.</p> Budget for the future, not just the quarter.</strong> The short-term savings from cutting junior hires are real. The long-term cost of having no pipeline is also real, and much larger. The organisations that get this right will be the ones that treat junior development as an investment with a 3-5 year payback period, not a cost to be optimised away.</p> The uncomfortable truth</h2> I've built engineering teams across four ventures</a> and in defence-grade environments at Improbable</a>. I've hired juniors who became the best engineers I've ever worked with. And I've watched what happens when organisations optimise purely for short-term efficiency at the expense of long-term capability.</p> The uncomfortable truth is that the market is telling companies to do something that is locally rational and globally catastrophic. Cut the juniors. Save the money. Ship more with fewer people. And then, in five years, wonder why there are no senior engineers available, and why the ones who exist command salaries that make the original savings look like pocket change.</p> The companies that will have the strongest engineering teams in 2030 are the ones making the unfashionable decision to invest in junior talent today. Not because it's charitable. Because it's strategic.</p> If you're rethinking your engineering team structure and want to talk through the trade-offs, a fractional CTO engagement</a> is one way to get that thinking in the room. Or just get in touch</a>.</em></p> Related: Does your business need a CTO?</a> · Fractional CTO: is outsourced technology leadership right for you?</a> · How to unlock AI ROI: what the 20% do differently</a></em></p> Why your AI spend isn't showing up in the numbers 2026-02-18T00:00:00+00:00 I've sat in enough boardrooms to recognise the moment. The CEO pulls up the quarterly numbers, someone asks about the AI initiative, and the room goes quiet. Not because AI isn't being used. It is. But the P&L hasn't moved.</p> This is not an anecdote. It's the dominant pattern. It's also a solvable one. The spend isn't wasted because AI can't deliver; it's underperforming because the return was never engineered in. Unlock that, and the same investment starts showing up where it should.</p> The data is damning</h2> PwC's 2026 Global CEO Survey, covering 4,454 CEOs, found that 56% say AI has delivered no significant benefits</strong>. Only one in eight report improvements to both cost and revenue. MIT's analysis of generative AI pilots is worse: 95% produce no measurable P&L impact</strong>. Not "disappointing results." No measurable impact at all.</p> The NBER published a working paper in February 2026 surveying roughly 6,000 executives across the US, UK, Germany, and Australia. More than 70% of firms are actively using AI. Over 80% report no impact on employment or productivity over the last three years</strong>. Executives themselves average about 90 minutes a week using AI tools; a quarter report using them not at all.</p> These are not fringe findings. This is the consensus view from every major research institution studying AI deployment in 2025–2026.</p> Why the gap exists</h2> The instinct is to blame the technology. It's not the technology.</p> Deloitte's enterprise survey found that organisations taking a work-redesign approach, rethinking processes before deploying tools, are twice as likely to exceed their ROI targets</strong> as those taking a technology-first approach. Prosci's research across 1,107 organisations is even more specific: 63% of AI failures trace to human factors, not technical ones</strong>. Cultural and organisational barriers account for 65% of failures. Technical issues? 22%.</p> Most organisations are doing this backwards. They buy the tool, run a pilot, get a promising demo, declare success, and then wonder why the numbers don't move when they try to scale. The pilot works because someone babysat it. Production fails because nobody redesigned the workflow around it.</p> Workday presented data at Davos suggesting that roughly 40% of "time saved" by AI goes straight into rework</strong>, correcting low-quality outputs that the system generated. That's not a productivity gain. That's a productivity shell game.</p> What actually works</h2> I've built production AI systems that moved business metrics. Not in a lab, not in a pilot, in production at enterprise scale. At AdBrain, the agentic AI system I co-founded and built for a European insurance brokerage achieved 67% autonomous case resolution</a></strong> and a 23% improvement in sales KPIs</strong>. These weren't projections. They were measured outcomes on real customer cases.</p> The difference wasn't the model or the infrastructure. The difference was approach.</p> We started with the process, not the technology.</strong> We mapped every decision point in the customer service workflow, identified which decisions could be delegated to an AI system with acceptable error rates, and built governance around the ones that couldn't. The technology was in service of the workflow redesign, not the other way round.</p> This is the pattern I see again and again in the organisations that get results. The 5% that McKinsey identifies as achieving true AI transformation aren't using better models. They're deploying AI into redesigned processes with clear KPIs, governance frameworks, and kill criteria for initiatives that aren't working.</p> The 90-day question</h2> If you've been investing in AI and the numbers haven't moved, the question isn't whether to invest more. It's whether you're deploying AI into the right processes, with the right workflow design, and with governance that scales.</p> Most founders and small to mid-market teams I work with can answer that question in 90 days, with one production system delivering measurable results and a clear roadmap for what comes next. The AI readiness diagnostic</a> is a good place to start. It takes 15 minutes and gives you an honest baseline.</p> The AI isn't the hard part. The hard part is being honest about what's working and what isn't, and having someone in the room who has done this before.</p> If that sounds like a conversation worth having, get in touch</a>. No slides, no pitch. Just an honest assessment of where you are.</p> Related: How to unlock AI ROI: what the 20% do differently</a> · Turning AI theatre into AI that moves the numbers</a> · Shadow AI is your next audit finding</a></em></p> Turning AI theatre into AI that moves the numbers 2026-02-11T00:00:00+00:00 I want to name something that everyone in the room knows but nobody says out loud.</p> Most AI transformations are performance art. They exist to demonstrate that something is happening, not to deliver results. The innovation lab is staffed. The pilots are running. The quarterly board update has an AI slide with a roadmap and a timeline and a budget. And the P&L hasn't moved.</p> This is not a controversial observation. BCG's own research admits that 60% of AI consulting engagements generate no material value</strong>. Only 5% achieve anything at scale. McKinsey puts the number of organisations achieving true AI transformation at one in twenty</strong>. Gartner predicts that 60% of AI initiatives will be abandoned through 2026.</p> The industry has a name for this. They call it "pilot purgatory." I think that's too kind. Pilots are experiments that lead somewhere. What most organisations are doing is theatre.</p> But here is the part that matters: this is the most fixable problem in enterprise AI. The gap between theatre and transformation isn't talent, budget, or better models. It's a handful of structural choices, and they are entirely learnable. The same numbers that look damning are really a map. They tell you exactly what the 5% do that everyone else doesn't. The rest of this piece is that map.</p> What AI theatre looks like</h2> You can spot it from the language. "We're exploring." "We're evaluating vendors." "We have a pilot running with promising results." "We're building our AI strategy."</p> These phrases have one thing in common: they describe activity, not outcomes. Nobody is measuring anything. Nobody has defined what success looks like. And nobody has the authority, or the incentive, to kill something that isn't working.</p> The typical pattern runs like this:</p> A consulting firm is engaged to "develop an AI strategy." They deliver a 60-page deck with a maturity assessment, a vendor landscape, and a phased roadmap. The organisation selects two or three use cases for pilots. The pilots are built by a small team with enthusiastic support from one sponsor. The demos look impressive. Then the pilot hits production-readiness requirements (security review, data governance, integration with existing systems, change management) and stalls.</p> Six months later, the pilot is still "in progress." The team has moved on to the next pilot. The first one quietly dies. The board update still shows green.</p> I've seen this pattern at organisations of every size, from funded startups to FTSE 250 companies. The technology is real. The results are not.</p> Why it happens</h2> Three structural reasons.</p> First, incentives are misaligned.</strong> The people evaluating AI tools are not the people whose P&L depends on the outcomes. When the innovation team's KPI is "number of pilots launched" rather than "revenue impact of deployed systems," you get exactly what you'd expect: lots of pilots, no production systems.</p> Second, the process is backwards.</strong> Deloitte's research shows that organisations taking a work-redesign approach, rethinking processes before selecting tools, are twice as likely to exceed ROI targets</strong> than those starting with the technology. But redesigning processes is hard, political, and slow. Buying a tool and running a pilot is fast, visible, and feels like progress.</p> Third, nobody has done it before.</strong> Most organisations don't have a senior leader who has built production AI systems. They have people who have evaluated them, recommended them, and managed pilots of them. The people making the call have usually watched a demo, not built one</a>. The gap between "this demos well" and "this runs in production at scale" is enormous, and it's a gap that only operating experience can bridge.</p> What the alternative looks like</h2> The organisations that get real results from AI share a few characteristics.</p> They start with the P&L, not the technology.</strong> Before selecting any tool or model, they identify a specific business process where AI can deliver measurable improvement, and they define what "measurable" means upfront. Not "efficiency gains." A number. A KPI. A target.</p> They redesign the workflow.</strong> Prosci's research across 1,107 organisations found that 63% of AI failures trace to human factors, not technology</strong>. The organisations that succeed don't bolt AI onto existing processes. They redesign the process around what AI can and can't do, with clear decision delegation: what the system decides, what a human decides, and where the handoff happens.</p> They deploy to production in weeks, not quarters.</strong> At AdBrain, we had an agentic AI system handling real customer cases within weeks of starting the build. Not because we cut corners. Because we scoped tightly. One process. One set of decisions. Full governance. Measured KPIs from day one. The result: 67% autonomous case resolution</a></strong>, 23% sales lift</strong>. Production, not pilot.</p> They kill what doesn't work.</strong> This is the hardest part. Most organisations don't have kill criteria for AI initiatives. If it's not working after 90 days, they add more resources or extend the timeline. The right move is to kill it, learn from it, and redirect the investment to something that can deliver.</p> The 90-day test</h2> If you want to know whether your AI programme is performance art or real transformation, ask yourself three questions:</p> Can you name one AI system in production that is measured by a business KPI?</strong> Not "deployed." Not "being used by the team." Measured. With a number. That someone reports on.</p> Do you have kill criteria for your current AI initiatives?</strong> Is there a defined point at which you'd stop investing in a pilot that isn't delivering?</p> Has anyone in your leadership team built a production AI system before?</strong> Not evaluated one. Not managed a pilot. Built one, deployed it, and measured the results.</p> If the answer to any of those is no, you're closer to theatre than transformation. That's not a judgement. It's a diagnosis. And the good news is that the fix is faster than you think.</p> One production system. One set of measured KPIs. One honest assessment of what's working and what isn't. That's the starting point. Everything else is decoration.</p> If you'd like to have that conversation, I'm here</a>. No deck, no maturity assessment. Just an honest view of where you are and what would actually move the numbers.</p> Related: Why your AI spend isn't showing up in the numbers</a> · Agentic AI in 2026: what actually works in production</a> · How I approach AI transformation</a></em></p> Shadow AI is your next audit finding 2026-02-04T00:00:00+00:00 Your employees are already using AI. The question is whether you know about it.</p> Cyberhaven's research found that 38% of employees are sharing confidential company data through consumer AI tools</strong>: ChatGPT, Claude, Gemini, Copilot. Not through sanctioned enterprise deployments with data handling agreements. Through personal accounts, on personal devices, with no audit trail and no governance.</p> The broader number is worse: 78% of employees are using AI tools their employer hasn't approved</strong>. They're summarising client documents, generating financial analysis, drafting legal correspondence, and processing sensitive data through systems their IT and compliance teams don't know exist.</p> This is shadow AI. And it's about to become a very expensive problem.</p> The regulatory clock is ticking</h2> The EU AI Act's major enforcement milestones begin August 2, 2026</strong>. That includes transparency obligations, high-risk system requirements under Annex III, and governance structures that most organisations haven't built yet.</p> If you're operating in the EU or processing EU citizen data, which includes most UK businesses with European clients, you need to be ready. Not "aware." Ready. With documented governance frameworks, risk assessments for every AI system in use (including the ones your employees adopted without telling you), and human oversight structures that can withstand regulatory scrutiny.</p> This isn't theoretical. IBM's Institute for Business Value reports that 82% of organisations say AI risks have accelerated their need for governance modernisation</strong>. They know the gap exists. Most haven't closed it.</p> Why governance fails when it's treated as a blocker</h2> The instinct in most organisations is to respond to shadow AI with a ban. Lock down the tools, restrict access, send a memo. This doesn't work. The tools are too useful, the workarounds too easy, and the productivity gains too visible for people to stop using them just because a policy document said so.</p> The organisations that get this right treat governance as an enabler</strong>, not a blocker. The goal isn't to stop people using AI. It's to channel that usage into managed, monitored, compliant systems that the organisation controls. Governance that makes AI adoption faster, not slower, by removing the ambiguity that forces employees to make their own decisions about what's acceptable.</p> A proper governance framework does three things:</p> First, it maps what's actually happening.</strong> A shadow AI audit identifies every tool in use, every data flow, every risk. You can't govern what you can't see. Most organisations are genuinely surprised by what they find.</p> Second, it provides sanctioned alternatives.</strong> For every unapproved tool your employees are using, there should be an approved path that's at least as convenient. If the governance framework makes people's work harder, they'll route around it, and you're back to shadow AI.</p> Third, it builds the compliance structure.</strong> Risk classifications, human oversight requirements, data handling protocols, incident response procedures. The EU AI Act doesn't require perfection. It requires a demonstrable, documented framework that shows you're managing AI risk systematically. This is the approach I took at NHS Wales</a>, where governance had to withstand national-level scrutiny. The same principles apply at any scale.</p> The cost of waiting</h2> Informatica's 2026 survey of 600 data leaders found that three out of four say governance hasn't kept pace</strong> with AI adoption. Nearly 7 in 10 organisations have adopted generative AI, and almost half have moved into agentic AI. The tools are already deployed. The governance is months, or years, behind.</p> The gap creates three categories of risk:</p> Regulatory risk.</strong> EU AI Act non-compliance penalties scale to 7% of global annual turnover for the most serious violations. Even for mid-market companies, that's a material number.</p> Data risk.</strong> Confidential client data, financial information, proprietary IP, all flowing through systems with no data processing agreements, no audit logs, and no retention controls.</p> Operational risk.</strong> Decisions being made based on AI outputs that no one is verifying, using models that no one has validated for the use case, with error rates that no one is measuring.</p> What I'd do in your position</h2> If I were sitting in your seat (CTO, COO, or board member of a company with 50+ employees) I'd do three things in the next 30 days:</p> Run a shadow AI audit.</strong> Not a survey. A proper audit. Map the tools, the data flows, and the risks. Accept that you'll find things you didn't expect.</p> Build a governance framework that enables, not restricts.</strong> Classify your AI use cases by risk level. Provide sanctioned tools for the high-value, high-frequency use cases. Build monitoring into the approved stack.</p> Set a timeline for EU AI Act readiness.</strong> August 2026 isn't far. If you need to be compliant, work backwards from that date and identify every gap.</p> If you'd like help with any of that, let's talk</a>. I've built governance frameworks alongside production AI systems, not as a separate workstream, but as part of the deployment. It's the only way it works.</p> Related: Turning AI theatre into AI that moves the numbers</a> · How to unlock AI ROI: what the 20% do differently</a> · The AI Transformation Sprint</a></em></p> How to unlock AI ROI: what the 20% do differently 2026-01-28T00:00:00+00:00 A statistic that should focus the mind of anyone investing in AI: according to multiple industry surveys, roughly 80% of companies have deployed generative AI. And roughly 80% report no material impact on earnings.</p> It's tempting to read that as "AI doesn't pay back." That's the wrong lesson. The returns are real and repeatable, but they have to be unlocked. The 80% aren't evidence that the technology fails; they're evidence that most organisations haven't yet learned how to deploy it. The real risk to your investment isn't outright failure. It's quiet underperformance: an initiative that returns a fraction of what it could, because the work around the tool never changed. This piece is about what the 20% do differently to unlock the return.</p> Why is the easy explanation for AI failure wrong?</h2> The tempting interpretation is that the technology isn't there yet. That LLMs hallucinate too much. That the models aren't reliable enough. That we need better tools before AI can deliver business value.</p> This is comfortable because it requires no action. Just wait.</p> It's also wrong. The organisations delivering measurable ROI from AI are not waiting. They have fundamentally different approaches to how they build and deploy AI systems, and those approaches are not technology-dependent. They're architectural and organisational.</p> What do the 20% of successful AI projects do differently?</h2> 1. They solve the data problem first</h3> Every serious AI deployment that delivers business outcomes starts with a data architecture question, not a model question.</p> The question isn't "which LLM should we use?" It's "can we reliably retrieve the specific information this AI system needs to make good decisions?"</p> In most organisations, the answer to that second question is no. Customer data is fragmented across CRM systems. Product data doesn't conform to a consistent schema. Historical decisions weren't recorded in a way that makes them usable as context. Case notes are in unstructured text with no metadata.</p> Before any AI system can work reliably in production, someone has to make this data retrieval problem tractable. The organisations that skip this step and go straight to building on top of raw, fragmented data end up with AI systems that work inconsistently and unpredictably. Which is worse than no AI at all, because it erodes trust.</p> The 20% treat data architecture as a prerequisite, not a detail.</p> 2. They define the right problem to solve</h3> There's a pattern in AI project failures that goes like this:</p> Organisation decides to "add AI"</li> Team picks a use case that seems tractable: a chatbot, a recommendation engine, a document summariser</li> The use case gets built and deployed</li> Nobody uses it, or it doesn't move any metric that matters</li> Conclusion: "AI doesn't work for us"</li> </ol> The failure happened at step 2. The use case wasn't connected to a problem that the business actually has, in a workflow that people actually use, with a metric that the business actually tracks.</p> The 20% start from the business problem: what is the high-volume, high-friction, high-cost workflow that AI could change? Then they work backward to the AI architecture, not forward from "what's possible with LLMs."</p> For the insurance brokerage I worked with</a> at AdBrain, the problem was specific and measurable: thousands of customer service cases per month, inconsistent handling, slow resolution, agents unable to scale. AI was the solution to that problem, not a technology experiment running parallel to the real business.</p> 3. They invest in production engineering</h3> The gap between "the demo works" and "the system works in production" is where most AI projects disappear.</p> Production AI requires:</p> Retrieval that works at scale,</strong> not just in a controlled test environment with clean data</li> Graceful degradation.</strong> What happens when the model is uncertain, when the data is missing, when the case is outside the training distribution?</li> Observability.</strong> Can you see what the system is doing, why it made each decision, and where it's failing?</li> Human-in-the-loop design.</strong> When should the AI handle something autonomously, and when should it escalate? And when it escalates, does the human get the context they need?</li> Audit trails,</strong> especially in regulated industries, but increasingly in any consequential business process</li> </ul> The 20% treat production engineering as a first-class concern from the start. The 80% treat it as a problem to solve after the demo works.</p> 4. They stage the rollout</h3> "Big bang" AI deployment almost never works. The 20% deploy incrementally: start with a small fraction of real traffic, measure outcomes against real business metrics, build confidence in the system before scaling.</p> This isn't just risk management. It's how you build institutional trust in an automated system. The people whose jobs the system is affecting need to see it work. Leadership needs to see the metrics move. Compliance needs to see the audit trail.</p> Staged rollout also allows you to catch failures early, in production conditions that your test environment will never fully replicate, without catastrophic consequences.</p> 5. They treat AI governance as a competitive advantage</h3> With the EU AI Act in full effect and organisations increasingly asking hard questions about AI risk, the companies that have built mature AI governance frameworks are at a commercial advantage over those that haven't.</p> This doesn't mean governance as bureaucracy. It means:</p> Clear ownership of AI decisions (the CAIO role or equivalent)</li> Documented decision logic for automated systems</li> Regular accuracy and bias auditing</li> Clear escalation paths when systems fail</li> An approach to EU AI Act risk categorisation for the AI systems you're deploying</li> </ul> Only about 1 in 5 companies have this in place today. That's a gap, and a gap creates differentiation.</p> How do you avoid being in the 80% of failed AI projects?</h2> If you're building or deploying AI, the questions above aren't abstract. They're the questions your enterprise customers' IT and legal teams will ask before signing a contract. They're the questions an acquirer's technical due diligence team will surface during an exit process. They're the questions investors will ask when they want to understand why your AI investment is defensible.</p> Building with these considerations in mind from the start is not slower or more expensive than building without them. It's usually faster, because you don't have to rebuild the parts that break. If you want a quick sense of where your organisation stands on these patterns, try the AI readiness diagnostic</a>.</p> If you want to pressure-test your AI approach against these patterns, get in touch</a>.</em></p> Related: Your world-class engineering team is already in the building</a> · Agentic AI in 2026: what actually works in production</a> · Turning AI theatre into AI that moves the numbers</a> · Shadow AI is your next audit finding</a></em></p> Agentic AI in 2026: what actually works in production 2026-01-14T00:00:00+00:00 Every major technology conference in the last 18 months has featured a demo of an AI agent doing something impressive. Booking a flight. Writing and executing code. Managing a customer enquiry from start to finish.</p> Most of those demos are not production systems.</p> I've built agentic AI in production, at a European insurance brokerage</a> at enterprise scale, with 67% autonomous resolution rates on real customer service cases. I've also watched a significant number of agentic AI projects fail in ways that were entirely predictable. This is an honest account of what the difference looks like.</p> What "agentic AI" actually means</h2> An AI agent, in the technical sense, is a system that can take actions, not just generate text. It can retrieve information, execute tools, make decisions across multiple steps, and produce outcomes in the world rather than just producing responses.</p> The demo version of this: an agent that can look up flight prices, check calendar availability, book a seat, and confirm the booking in a single conversational interaction.</p> The production version of this: an agent that can do the above 10,000 times per day, on inputs that don't match the training distribution, with graceful handling of edge cases, a full audit trail of every decision, and escalation logic that surfaces the cases the agent shouldn't handle autonomously.</p> The gap between those two descriptions is where most agentic AI projects fail.</p> Why most agents don't work in production</h2> Problem 1: Retrieval is the weakest link</h3> Agents are only as good as the information they can access. And in almost every real-world deployment, retrieving the right information, from the right source, in the right format, at the right time, is harder than building the agent logic.</p> Vector databases are not magic. Embedding quality degrades with domain-specific content. Retrieval precision drops sharply when the knowledge base is large, inconsistent, or poorly structured. The agent that works beautifully on clean, curated documentation fails silently on the messy reality of actual enterprise data.</p> The solution is to treat retrieval as an engineering problem of its own, with the same rigour as any other part of the system. Chunking strategies, embedding models, hybrid retrieval combining semantic and keyword search, metadata filtering, reranking. These are not implementation details; they are load-bearing engineering decisions. Retrieval is one of the layers I unpack in you're not talking to an LLM, you're talking to a system</a>.</p> Problem 2: Error propagation in multi-step pipelines</h3> Single-step AI is relatively forgiving. If the model makes an error, you see it, you correct it, you move on.</p> Multi-step agentic pipelines are not forgiving. Each step's output becomes the next step's input. Errors compound. A misclassification in step 1 propagates through the entire pipeline and produces a confident, coherent, wrong answer at the end.</p> Production agents need explicit error detection at each step. They need to know when they're uncertain. They need to know when the input doesn't match the patterns they were built for. And they need escalation logic that fires reliably when these conditions occur. Not optimistically, but conservatively.</p> Problem 3: The state management problem</h3> Conversational agents need to maintain context across a session. Orchestration agents need to manage state across multiple tool calls. Long-running agents need to persist state across interruptions and restarts.</p> State management in agentic systems is genuinely hard. The naive approach, passing the entire conversation history as context on every API call, doesn't scale and degrades performance. The sophisticated approach (explicit state machines, persistent state stores, careful context window management) requires engineering that most early-stage AI projects don't budget for.</p> Problem 4: Testing is much harder than for traditional software</h3> You can write unit tests for functions. You can write integration tests for APIs. Testing an AI agent that takes non-deterministic multi-step actions is a different problem.</p> How do you test a system where the same input can produce different outputs? How do you build a test suite that catches regressions in natural language reasoning? How do you know your agent will handle the edge cases it hasn't seen during development?</p> The answer involves a combination of golden-set evaluation (specific inputs with expected outputs), adversarial testing (deliberately trying to break the agent), and production monitoring (catching failures when they happen and feeding them back into the development process). None of this is impossible, but all of it requires deliberate engineering investment.</p> Problem 5: Trust and adoption</h3> Even when the agent works technically, getting people to trust it, and therefore use it, is its own challenge.</p> A customer service agent that resolves 67% of cases autonomously is only valuable if the remaining 33% that require human handling are escalated smoothly, with full context, to agents who trust the system enough to take the handoff efficiently.</p> Building this trust requires transparency: the human needs to understand why the agent is escalating, what it's already determined, and what information it retrieved. Black-box escalation ("here's a case the AI couldn't handle, good luck") destroys the value of the automated component.</p> What makes agentic AI actually work in production</h2> Based on the systems I've built, the patterns that distinguish production-ready agents from demo-ready agents are:</p> Retrieval engineering as a first-class concern.</strong> Not an afterthought. Not a vector database with default settings. A carefully designed retrieval architecture with tested precision and recall at real-world data scale.</p> Conservative escalation logic.</strong> Better to escalate unnecessarily than to resolve incorrectly. The agent should know what it doesn't know, and be honest about it.</p> Explicit state management.</strong> Every step of the pipeline has observable state. Every decision is logged. Every error is caught and categorised.</p> Staged rollout with real metrics.</strong> Start at 10% of production volume. Measure resolution quality, escalation rate, user satisfaction, and business outcomes. Scale when the numbers are good.</p> Human-in-the-loop design that respects human time.</strong> The escalation handoff should give the human everything they need to pick up efficiently, not a blank canvas.</p> Production monitoring that catches drift.</strong> AI system performance degrades over time as input distributions change. The system needs to monitor for this and surface it proactively.</p> What this means if you're deploying agents</h2> If you're building agentic AI in 2026, the question "can our agent do X?" is the wrong starting point. The question is "can our agent do X reliably, in production, at the scale we need, with the error handling and auditability our customers require?"</p> Most demos say yes to the first question. Very few production systems actually deliver on the second.</p> The founders and small to mid-market teams I work with who get this right are the ones who treat the production engineering question as seriously as the model selection question. From day one, not after launch.</p> Building an agentic AI product and want a second opinion on your architecture approach? Let's talk.</a></em></p> Related: How to unlock AI ROI: what the 20% do differently</a> · Why your AI spend isn't showing up in the numbers</a> · How I approach production AI deployment</a></em></p> The most important skill in business and life 2023-11-09T00:00:00+00:00 CEO confidence in revenue growth has hit a five-year low. PwC's 2026 survey of 4,454 chief executives across 95 countries found that only 30% are confident, down from 56% in 2022. Mentions of "uncertainty" appeared in 87% of public earnings statements in early 2025. Glassdoor reviews mentioning uncertainty are up 80% year-over-year.</p> The five highest measurements of global economic policy uncertainty ever recorded have all come in the past five years. And this is before the full impact of AI reshapes entire industries.</p> I've led technology teams through several of these inflection points, at NHS Wales</a>, where the wrong call affects millions of people, and at startups, where the wrong call means you run out of runway. The pattern I've noticed is that the skill separating the leaders who thrive from those who freeze is always the same: the ability to make good decisions when nobody knows what happens next.</strong></p> Why uncertainty breaks most leaders</h2> There's a neuroscience explanation for why uncertainty is so paralysing.</p> When the brain encounters uncertain threats, the amygdala fires and cortisol rises. A systematic review of the research found that the resulting stress response significantly impairs decision-making on uncertainty-based tasks. Worse, and this is the part that should concern every leader, elevated cortisol impairs metacognition. You make worse decisions and you don't realise it</em>.</p> This creates a predictable failure pattern in organisations. The leader faces an uncertain situation, say, whether to invest heavily in AI or wait for the technology to mature. Stress rises. The brain's threat response activates. And instead of reasoning clearly, the leader defaults to one of two failure modes: analysis paralysis (delay the decision indefinitely, commission another report) or false certainty (pick a direction with excessive conviction, ignore disconfirming evidence).</p> Both are catastrophic. And both are everywhere.</p> What the evidence says actually works</h2> Jim Collins and Morten Hansen spent nine years studying companies that outperformed their industry index by 10x in chaotic, uncertain environments. Their findings upend the conventional wisdom about visionary leadership.</p> 10X leaders were not more creative, more visionary, or more risk-seeking than comparison leaders.</strong> They were more disciplined, more empirical, and more paranoid.</p> Three specific behaviours defined them:</p> Empirical creativity: "fire bullets, then cannonballs."</strong> Before making big bets, 10X leaders ran small, low-cost experiments to calibrate their aim. They didn't rely on analysis or intuition alone. They tested. Then, when they had empirical evidence that something worked, they committed resources aggressively. The comparison companies did the opposite: they fired cannonballs first, making large bets based on untested assumptions.</p> Fanatic discipline.</strong> 10X companies changed only 10-20% of their strategies over 20 years. Comparison companies changed 55-70%. Consistency, sticking with a validated approach even when the environment was chaotic, beat agility. This is counterintuitive. Most leadership advice says "be agile, pivot fast." The data says the opposite: find what works and hold the line.</p> Productive paranoia.</strong> 10X leaders built financial buffers and contingency plans before</em> crises hit, not during them. They assumed bad things would happen and prepared accordingly. They carried more cash, had more contingency plans, and were more attuned to threats than their peers.</p> The most striking finding: luck was evenly distributed across both groups. What differed was what leaders did with it.</p> The OODA loop and pattern recognition</h2> Colonel John Boyd developed the OODA loop (Observe, Orient, Decide, Act) from studying air combat. His insight was that the entity which cycles through this loop fastest doesn't just win. It creates confusion and disorientation in the opponent.</p> But Boyd's most important contribution was identifying orientation</em> as the bottleneck. Not observation, not decision, not action, but the mental model you bring to the situation. Your culture, experience, prior assumptions, and cognitive biases all shape how you interpret what you observe. And when your mental model is wrong, faster action just means you fail faster.</p> Gary Klein's research on expert decision-makers confirms this. He studied firefighters, military officers, and surgeons making high-stakes decisions under time pressure. He found that experts don't compare options analytically. They use pattern recognition from experience to rapidly identify a workable course of action. The quality of their decisions depends on the quality of their mental models, which depend on the depth and breadth of their experience. I saw this firsthand when I served as expert witness in a Hong Kong High Court case</a> involving 39 casualties. The analysis that changed the outcome didn't come from better data. It came from a different way of looking at the same evidence.</p> This is why the best decisions under uncertainty come from leaders who have built diverse mental models through operating experience</strong>, not from leaders who have the best analysis or the most data.</p> What this means in the age of AI</h2> The current AI transition is the most significant source of uncertainty in business since the internet. And most leaders are handling it badly.</p> EY's 2026 CEO Outlook found that 82% of CEOs are more optimistic about AI than a year ago, but 60% admit they've intentionally slowed implementation due to fear of errors. Half believe their job stability depends on successfully integrating AI. Gartner reports that 72% of CIOs are breaking even or losing money on AI investments.</p> The pattern is familiar. Uncertainty triggers the stress response. Leaders oscillate between two extremes: rushing to adopt AI without understanding the risks (false certainty) or delaying meaningful action while commissioning strategy decks (analysis paralysis).</p> Collins's research suggests a better approach, one I use with every organisation I work with:</p> Fire bullets first.</strong> Don't bet the business on a comprehensive AI transformation. Pick one high-value process. Build a focused AI solution. Measure it against a real business metric. Learn from what works and what doesn't. Then, and only then, fire the cannonball.</p> Be empirical, not ideological.</strong> The AI debate has become tribal: accelerationists versus sceptics, maximalists versus minimalists. None of that matters. What matters is whether the specific AI system you're building moves a specific number that your business cares about. If it doesn't, kill it.</a> If it does, scale it.</p> Build the buffer.</strong> Productive paranoia in the AI context means keeping the skills and the people you'll need if the technology doesn't deliver what it promises. It means not cutting your junior engineering pipeline</a> to fund AI tools that might not work. It means maintaining optionality, the ability to change course without catastrophic cost.</p> The Kodak lesson</h2> Kodak invented the digital camera in 1975. Their leadership buried it because they feared cannibalising their film business. Despite a succession of new CEOs and mounting evidence that digital photography was the future, the organisation couldn't adapt. The result: an 80% workforce decline, a collapsed stock price, and a bankruptcy filing after more than a century of market dominance.</p> Nokia's engineers presented a full touchscreen phone prototype to management. The response: "that's not how phones work." The company lost roughly $100 billion in market value.</p> Blockbuster's executives dismissed Netflix as a "very small niche business" and turned down a $50 million acquisition offer. Netflix is now worth over $100 billion.</p> In every case, the failure wasn't a lack of information. It was a failure of orientation. Boyd's bottleneck. The mental models of the leaders in the room couldn't accommodate the change they were facing. So they didn't.</p> The leaders navigating AI well today, and I include Satya Nadella's transformation of Microsoft from a $300 billion company to a $2.5 trillion one among the best examples, share a different orientation. They treat their mental models as provisional. They expect to be wrong about some things. They test, measure, and adjust. And they maintain the discipline to hold their nerve when the uncertainty is highest.</p> Eisenhower put it best: "Plans are worthless, but planning is everything." The value isn't in the plan. It's in the thinking the plan forces you to do. And when reality diverges from the plan, as it always does, that thinking is what allows you to improvise effectively.</p> That's the skill. Not predicting the future. Not having the best strategy. Not being the most decisive person in the room. Just the ability to think clearly when nobody knows what happens next, and to act on that thinking with discipline.</p> It's the most important skill in business. And it's learnable.</p> If you're making technology decisions under uncertainty and want a second perspective, a fractional CTO engagement</a> is one way to get it. Or simply get in touch</a>.</em></p> Related: Turning AI theatre into AI that moves the numbers</a> · Your world-class engineering team is already in the building</a> · NHS Wales: transformation at national scale</a> · How I work</a></em></p> The most powerful yet overlooked tool in a leader's arsenal 2023-10-13T00:00:00+00:00 A Wharton study gave a university director one task: visit a group of fundraisers and say, sincerely, "I am very grateful for your hard work. We sincerely appreciate your contributions."</p> That was it. No bonus. No promotion. No formal programme. Just a human being telling other human beings that their work mattered.</p> The result: the thanked group made 50% more fundraising calls</strong> the following week. The control group (same job, same pay, same conditions, no visit) showed zero change.</p> The researchers, Adam Grant and Francesca Gino, found the mechanism wasn't confidence. It was social worth. Being thanked made people feel valued as members of a community. And that feeling, belonging and mattering, drove behaviour more powerfully than any incentive scheme could.</p> This is not a soft finding. It's one of the hardest results in organisational psychology. And most leaders ignore it.</p> The numbers behind "thank you"</h2> Gallup and Workhuman ran a longitudinal study tracking 3,400 employees from 2022 to 2024. The headline finding: employees who received high-quality recognition were 45% less likely to have left</strong> two years later.</p> That's not a marginal effect. That's nearly half of voluntary turnover, preventable.</p> The same study found that employees who felt fulfilled by recognition were 4x as likely to be engaged and 65% less likely to be actively job-searching. For a 10,000-person company, Gallup estimates that a strong recognition culture saves up to $16.1 million in turnover costs annually</strong>.</p> And yet only 22% of employees say they receive the right amount of recognition. That number hasn't moved since 2022.</p> The data from other sources converges on the same point. O.C. Tanner's Global Culture Report found employees are 18x more likely to produce great work when recognition is integrated and personalised. Deloitte found that organisations with recognition programmes see 14% higher engagement, productivity, and performance than those without. A 15% improvement in engagement translates to a 2% increase in margins.</p> 79% of employees who quit cite lack of appreciation as a major reason. 59% say they have never had a boss who truly appreciates them. These are not small numbers. These are systemic failures of leadership.</p> What happens in the brain</h2> The neuroscience is straightforward. Recognition triggers dopamine, the reward signal that drives motivation and reinforces behaviour. It also triggers oxytocin, which builds trust and social bonding. And serotonin, associated with well-being and satisfaction.</p> The dopamine effect creates a reinforcement loop: when someone is recognised for a behaviour, the neurochemical reward makes them more likely to repeat it. This isn't metaphorical. It's the same mechanism that makes habits form. Recognition literally rewires the brain's reward circuitry.</p> An Indiana University study found that participants who practised gratitude showed lasting increases in neural sensitivity in the medial prefrontal cortex, months after the intervention. The brain doesn't just respond to recognition in the moment. It adapts structurally over time, becoming more attuned to positive signals. Gratitude, given and received, compounds.</p> The story I can't forget</h2> Years ago I was working with an exceptional team of software engineers at a company that was, genuinely, considered a gold standard in culture and talent development.</p> The team had just finished a multi-month crunch. They'd been fighting like lions to enable the business to win a massive multi-year, multi-billion pound contract. Weekends. Late nights. The kind of sustained intensity that burns people out even when the outcome is good.</p> One engineer was the technical leader of the entire effort. He'd worked harder, and had done more to make the successful outcome happen, than anyone else on the team.</p> When the win was announced, the company's senior leaders praised their own effort. Publicly and privately, they thanked themselves. The engineer who had made it happen, the person who'd given months of his life to the outcome, went unnoticed.</p> What followed was predictable, if you know the research. He quietly quit. Not formally. He stayed in his seat. But the engagement evaporated. He became negative. The negativity spread. Productivity across the team visibly dropped.</p> Within a few months, he left. Several colleagues followed. These were engineers with rare, specialised skills, the kind that take years to develop and months to replace. The cost to the company was enormous, and it compounded for over a year.</p> At the exit interview he told me that the lack of appreciation was the turning point. He'd realised the leadership didn't care about their people. That the values and the speeches were, in his experience, hollow.</p> All it would have taken was a "thank you."</strong></p> Gallup's data says employees who received recognition in the prior month saw their attrition risk decrease by 58%, their perception of growth opportunities increase by 108%, and their positive perception of leaders increase by 180%. One moment of genuine recognition. Those are the numbers.</p> Why this matters more now than ever</h2> I want to make the connection to the current moment, because I think it's important.</p> We are in the middle of the most significant transformation of knowledge work in a generation. AI is changing what engineers do, how teams are structured, and what skills matter. McKinsey found that 70% of large-scale transformations fail, and the primary reasons are employee resistance and poor change management. BCG puts it at 70% of AI implementation challenges being people problems, not technical ones.</p> People who are anxious about their relevance, and a lot of engineers are anxious right now, don't need another all-hands presentation about the AI roadmap. They need to know that their contribution matters. That the years of expertise they've built aren't invisible to the people making decisions about the future.</p> Nearly half of CEOs in one survey admitted their employees were resistant or openly hostile to AI-driven changes. The instinct is to respond with more communication, more training, more change management programmes. And those things matter. But the most powerful intervention is also the simplest: seeing the person, acknowledging their work, and saying thank you.</p> Highly engaged employees experience significantly fewer negative effects of change-related stress. And engagement, as every study cited above confirms, is driven more by recognition than by any other single factor.</p> Making it real</h2> If recognition is so effective and so cheap, why don't more leaders do it?</p> HBR published research showing that more powerful people express less gratitude</strong>. As leaders gain authority, they become less attuned to the contributions of others. It's not malice. It's a cognitive shift. Power narrows attention toward goals and away from people. The very thing that makes someone an effective leader in some dimensions makes them worse at the human dimension that matters most.</p> The fix is simple but requires intention.</p> Be immediate.</strong> Recognition delayed is recognition diluted. The Grant/Gino study showed the effect in the same week</em>. When someone does good work, say so then. Not at the next performance review. Not at the next all-hands. Now.</p> Be specific.</strong> "Great job" is better than silence. But "the way you structured that data pipeline saved us two weeks of rework" is better than "great job." Specificity signals that you actually noticed the work, not just the outcome.</p> Be genuine.</strong> People detect performative gratitude instantly. If you don't mean it, don't say it. But if you genuinely believe someone's work mattered, and if you're paying attention you'll find evidence of this every day, say so. The bar is not eloquence. The bar is sincerity.</p> Make it structural, not optional.</strong> The organisations with the best retention don't rely on individual managers remembering to say thank you. They build recognition into the operating rhythm: weekly stand-ups, code reviews, project retrospectives. Google's gThanks programme lets any employee nominate a colleague for a small bonus. The mechanism matters less than the consistency.</p> The engineering leader who builds a culture of genuine recognition will retain more of their best people, build more resilient teams, and navigate the AI transition with less friction than the one who doesn't. I've led teams at national scale in the public sector</a> and in defence environments where the pressure is relentless</a>. The teams that delivered best were the ones where recognition was part of the operating culture, not an afterthought. The data is unambiguous on this point.</p> And it starts with two words.</p> Related: The best technology rarely wins. The best-led team does</a> · The training ladder is broken</a> · Does your business need a CTO?</a> · Fractional CTO services</a></em></p> Fractional CTO. Is outsourced technology leadership right for you? 2022-09-28T00:00:00+00:00 The fractional CTO model exists because of a real gap. You need senior technical leadership for architecture decisions, investor credibility, hiring, and AI strategy, but a full-time CTO hire is either unaffordable, impractical, or premature at your stage.</p> I've been on both sides of this. I've been the full-time CTO. I've been the fractional CTO stepping into organisations mid-crisis. And I've worked with companies that tried to do without one entirely. The last option is almost always the most expensive.</p> When does a fractional CTO engagement work?</h2> A fractional CTO engagement works when the organisation has real technology decisions to make but doesn't yet need, or can't yet justify, a full-time executive hire.</p> That typically looks like:</p> Post-seed or Series A.</strong> You have 3-20 engineers and no technical co-founder. Architecture decisions are being made by the most senior developer, who may be excellent at engineering but hasn't done this at company level before.</li> Technical co-founder departure.</strong> The scenario every funded startup dreads. I stepped into exactly this situation at Mentor360, stabilised the team, and secured a Royal Navy contract during a period that could have derailed the company.</li> AI deployment.</strong> You're building AI into your product or operations and need someone who's done it in production, not someone who's read about it. The insurance automation case</a> is a good example of what this looks like in practice: agentic AI resolving 67% of cases autonomously, designed and deployed during a fractional engagement.</li> Fundraise or exit preparation.</strong> Investors and acquirers will ask hard technology questions. You need a credible technical voice in the room.</li> </ul> In these situations, a fractional CTO at 2 days per week gives you 80% of the strategic value of a full-time hire at a fraction of the cost, without the six-month recruitment process or the risk of a bad hire.</p> What are the honest disadvantages of a fractional CTO?</h2> I'd be doing you a disservice if I didn't name these.</p> Limited availability.</strong> A fractional CTO isn't in the building every day. The trade-off is that you're paying exclusively for the high-value strategic work (architecture decisions, hiring guidance, investor preparation) rather than a full-time salary that includes meetings, email, and organisational overhead. Whether that trade-off works depends on your stage and needs.</p> Temporary by design.</strong> A fractional engagement isn't a permanent commitment. That's a feature for some organisations and a limitation for others. The best arrangements either evolve into something more permanent or end with a clear handover to a full-time hire.</p> Less skin in the game.</strong> A fractional CTO doesn't have equity (I don't take it; it keeps incentives clean). That means the relationship is professional, not existential. For most engagements, this is healthy. But it's worth being honest about the dynamic.</p> Quality varies enormously.</strong> This is the biggest risk. The fractional CTO market has grown fast, and not everyone offering the service has the experience to back it up. "CTO" on a LinkedIn profile doesn't mean someone has built production systems, managed engineering teams, or sat in an investor meeting with hard questions coming.</p> Two things to look for: independence</strong> and operating experience</strong>. A fractional CTO provided by a development agency has a structural conflict of interest. Their agency benefits from recommending more development work. And a fractional CTO who has only advised but never built lacks the pattern recognition that comes from being in the seat when things go wrong. My background</a> includes four exits, CTO roles at NHS Wales and in defence technology, and production AI systems. That operating experience is what makes fractional work credible.</p> How do you evaluate whether a fractional CTO is right for your business?</h2> Before engaging a fractional CTO, including me, ask yourself:</p> Do you have real decisions to make?</strong> If you need architecture direction, hiring guidance, or investor preparation in the next 90 days, a fractional CTO earns their fee quickly. If you need someone to write code, hire a senior engineer.</p> Is the timing right?</strong> A fractional CTO adds the most value at inflection points: post-raise, pre-exit, during a scaling push, or when AI deployment is on the roadmap. If you're in steady-state with a functioning team, lighter-touch advisory may be more appropriate.</p> Can you define the scope?</strong> The best fractional engagements have clear boundaries: weekly cadence, defined responsibilities, specific deliverables at 90 days. Open-ended arrangements tend to drift.</p> Is a fractional CTO right for you?</h2> Having senior technical leadership is not optional for technology-driven businesses. The arrangement (full-time, fractional, or advisory) depends on your stage, budget, and needs.</p> If you're weighing the options, a conversation is a good starting point</a>. No commitment, just an honest assessment of what you actually need.</p> Related: Does your business need a CTO?</a> · Fractional CTO service details and pricing</a> · How I work</a> · Case study: NHS Wales transformation</a></em></p> Does your business need a CTO? 2022-06-30T00:00:00+00:00 I've watched this pattern play out dozens of times. A founder or managing director knows their business depends on technology but isn't sure whether they need a CTO. They assume it's a hire they can defer, something for later, when the budget is bigger or the product is further along.</p> Deferring the CTO decision is almost always a mistake. By the time founders realise it, the cost of operating without senior technical leadership has already compounded.</p> What is the real cost of operating without a CTO?</h2> The obvious risk is bad architecture decisions. But the deeper problem is subtler: you don't know what you don't know.</strong></p> Without senior technical leadership, you can't evaluate whether your engineering team is building the right thing in the right way. You can't assess vendor claims. You can't tell whether your AI pilot is genuinely promising or a well-produced demo. You can't prepare for the technical questions investors or acquirers will ask. The kind of analytical rigour that changes outcomes</a> simply isn't present without someone whose job it is to provide it.</p> I've seen companies lose months of engineering time, sometimes years, to decisions that a competent CTO would have caught in week one. Wrong cloud provider for the use case. Wrong data architecture for the product. Wrong hiring profile for the stage. Each of these compounds quietly until the bill comes due, usually at the worst possible moment: during a fundraise, an exit process, or a scaling push.</p> What does a CTO actually do?</h2> The title means different things at different stages. But at its core, a CTO does six things:</p> Sets technology strategy.</strong> Not in isolation. In lockstep with business strategy. Every serious business decision has a technology dimension. The CTO ensures those dimensions are visible before commitments are made.</p> Defines what to build.</strong> Which products, which features, in what order. This isn't a technical exercise. It's a commercial one, informed by technical reality. The CTO translates business priorities into engineering priorities.</p> Decides how to build it.</strong> Build or buy. Internal team or outsource. Which stack, which architecture, which deployment model. These decisions determine speed, cost, and scalability for years. Getting them wrong at Series Seed creates Series B problems.</p> Executes the roadmap.</strong> Plans, builds or sources the team, manages the development process. Owns the delivery.</p> Translates between business and engineering.</strong> In board meetings, investor calls, and cross-functional discussions, the CTO makes technology decisions legible to non-technical stakeholders. This is where fundraises succeed or stall. Investors need to trust that someone credible is making the technology calls.</p> Leads the engineering team.</strong> Hires well, structures the team correctly for the stage, shields engineers from organisational noise so they can focus on deep work. The leadership mistakes at this stage are expensive. A bad senior hire can set you back six months.</p> Why is a CTO's role strategic, not just technical?</h2> A great CTO isn't the best coder in the room. They're the person who sees what's coming: the technology shift that creates an opportunity, the architectural decision that will box you in, the vendor relationship that's about to become a liability.</p> I've held this role at national scale, at NHS Wales, where the wrong technology call has consequences for millions of people, and at startups, where the wrong call means you run out of runway. I've also been a founder four times</a>, so I know the other side of the table too. The stakes vary. The discipline is the same.</p> When does a business actually need a CTO?</h2> Whether you're a 5-person startup or a 200-person mid-market company, if technology is core to your business, you need CTO-calibre thinking in the room. The question is the arrangement.</p> A permanent, full-time CTO is ideal, but it's expensive, takes months to hire well, and the cost of hiring the wrong one is severe. Various alternatives work: interim, fractional, or advisory arrangements all prove superior to having no senior technical leadership at all.</p> If a permanent hire isn't feasible yet, a fractional CTO engagement</a> gives you the expertise at a fraction of the cost, with none of the hiring risk and all of the strategic value.</p> Related: Fractional CTO: is outsourced technology leadership right for you?</a> · The best technology rarely wins. The best-led team does</a> · Four companies, four exits</a> · How I work as a Fractional CTO</a></em></p>

CTO Zen | Fractional CTO & AI Advisory - Insights. AI Strategy, Technology Leadership & Production AI

The best technology rarely wins. The best-led team does

2026-06-02T00:00:00+00:00

The best technology rarely wins. Superior products lose to inferior ones all the time, and brilliant engineering ends up serving companies that never reach their potential. If raw technical quality decided outcomes, the market would look very different from the one we actually have.

The factor that decides it, more than the technology, more than the capital, more than even the strategy, is the quality of the leadership. Leadership is the multiplier on everything else you have. Great leadership is the only force that can turn an underperforming business around. When Steve Jobs returned to a near-bankrupt Apple in 1997 he did it with broadly the same people, the same building, and the same assets the previous management had been losing with. What changed was the leadership. And weak leadership quietly destroys good companies with good technology, year after year, while everyone blames the market.

Leadership is a commercial lever, not a soft topic</h2>
The mistake I see most often is treating leadership as a soft, HR-adjacent subject, something to get to once the real work of product and engineering is handled. That has it exactly backwards.
Leadership is the most concrete commercial lever you own. It sits a couple of levels above your roadmap and your tech stack, and it determines whether everything beneath it works. Get it right and your strategy sharpens, your execution compounds, and your best people do the best work of their careers. Get it wrong and the most talented engineers in the world will underperform, ship the wrong things, and leave. The engineering is rarely the hard part</a>. The leadership almost always is.
It starts with a destination people can see</h2>
The first job of a leader is to set a clear destination and hold it with confidence. Not arrogance, which is brittle and repels people, but the quiet conviction that gives a team something solid to trust when the path ahead is foggy.
Clarity is the gift that does the most work, and there is a useful image for why. Ordinary light, a bulb in a room, is a chaos of waves scattering in every direction, and for all its energy it lights the room and goes no further. A laser is the same light made coherent, every wave aligned and travelling the same way, and it can cut through steel.
A team is no different. The same people, with the same talent and the same hours in the day, produce either a faint scatter or a focused beam, depending almost entirely on whether their effort is aligned behind one direction. Creating that alignment is the leader's job, and clarity is how you do it.
Intelligent people are remarkably good at organising themselves once they genuinely understand where they are going and why. Withhold that and you get silos, politics and a great deal of motion that produces nothing. A large part of leading is making the hard calls that set direction under real uncertainty</a>, then communicating them so plainly that everyone can act without waiting to be told.
Then it becomes about people, one at a time</h2>
Vision sets the direction. People do the work, and they are not interchangeable units of delivery. The best engineer I have worked with did his finest work in near silence, and would have walked inside a month under a manager who needed to be visibly in charge of every decision. Another did his best only when he had the full context and the bigger picture, and drifted without it. Same talent, opposite needs. Reading that, and adjusting to the person in front of you rather than demanding everyone fit one mould, is most of the job.
This is leadership as service, not command. Your job is not to be the cleverest person in the room. It is to create the conditions in which other people can be brilliant: removing the obstacles in their way, making them feel safe enough to do their best work</a>, and recognising the contribution every time someone sticks their neck out</a>. Good ideas do not respect the org chart. Strong leaders build the environment that lets them surface from anywhere. Weak ones assume good ideas are the property of senior people, and slowly poison everyone beneath them.
You cannot fake it, so you have to live it</h2>
Culture is set by what a leader does, not by what they say. People read the gap between your words and your behaviour instantly, and they calibrate their own conduct to the example you set, not the one you describe.
That is why openness and transparency matter so much. They build the trust that makes everything else possible. A leader who hoards information, hides bad news, or says one thing and does another teaches the whole organisation to do exactly the same. And you inspire people far more by what you visibly do, and by showing them how the mission connects to something they actually want, than by any amount of rhetoric.
And none of it works without deep competence</h2>
Here is the part most leadership advice skips, and the part that matters most in technology. All of the above, the vision, the service, the inspiration, sits on a foundation of real competence, or it collapses.
In technology you cannot lead what you do not understand. A leader who cannot follow the substance of the work, weigh a genuine architectural trade-off, or tell a hard problem from an excuse, has no way to make good calls or to earn the trust of the people doing it. Servant leadership and charisma without technical credibility ring hollow, and good engineers sense it in minutes. This is the balance that decides it: not the pure technologist who cannot lead people, and not the pure people-person who cannot grasp the work, but someone with enough of both. The competence earns you the right to lead. The leadership turns that competence into results.
Why this is the whole game</h2>
Follow the chain and it is obvious. When leadership is strong, people perform at their best. Ideas flow, ownership rises, hard decisions get made well and quickly, and execution compounds week after week. That produces better products, built faster, by an organisation resilient enough to absorb the surprises every market eventually delivers. Market success is downstream of all of it.
When leadership is weak, the chain breaks at the top and everything below it is capped, no matter how good the technology. This is why two companies with comparable talent and funding so often end up in completely different places. The difference is rarely the code. It is whether someone was able to turn all that potential into something coherent and valuable.
The part nobody wants to hear</h2>
If this sounds like a high bar, it is, and there is one more difficulty. Most people in leadership roles believe they are already good at it, and the most naturally talented are often the most blind to where they fall short. The traits that make someone an exceptional technologist are simply not the ones that make a great leader.
The entry fee to everything above is therefore self-awareness: the willingness to look honestly at your own leadership and keep working on it, the way you would any other hard skill. I learned this the slow and expensive way, and I have written separately about how long it took me to see it</a>. The good news is that leadership can be learned, by anyone willing to do that work. And it is the single highest-return investment a technology leader can make.

If you are building a technology company and want to talk about the leadership that actually decides whether it succeeds, rather than the strategy decks that usually get the attention, I am always happy to compare notes. Let's talk.</a>
Related: After 20 years as a CTO, the engineering was the easy part</a> · How big tech wins the talent war, and it isn't the money</a> · Your world-class engineering team is already in the building</a>

Your world-class engineering team is already in the building

2026-06-02T00:00:00+00:00

Most leaders who inherit an underperforming technical organisation reach for the same instrument: the wrecking ball. Reorganise the teams. Rip out the stack. Replace the people. Start again. It feels decisive, and it is almost always the most expensive mistake available to you.
The world-class organisation you want is not somewhere else, waiting to be hired in. It is already latent in the one you have. Michelangelo said the sculpture was complete inside the block of marble before he ever picked up a chisel. "I just have to chisel away the superfluous material." That is the right way to think about a technical organisation. Your job is not to import a great team. It is to uncover the one hidden in the people, the systems and the potential you already own.
The wrecking ball is the expensive option</h2>
Demolition feels like leadership. It rarely is. When you tear an organisation down to its foundations you throw away the one thing that is genuinely hard to buy: the accumulated knowledge of how your systems actually behave, why past decisions were made, and where the real risks are hiding. You also tell every talented person who stays that nothing they built mattered.
And here is the part that catches people out. I have been brought in after exactly this. New names on the org chart, a fashionable new stack, and the same three problems six months later, with nobody left who could explain why the old system was built the way it was. The shiny new team quietly reproduces the old dysfunction, because the conditions that created it were never addressed. You pay an enormous price to relearn your own lessons. Reshape before you replace.
Start with why, not with the org chart</h2>
Most reorganisations begin in exactly the wrong place: with boxes and reporting lines. Structure is the last thing you should touch, not the first.
Begin instead by establishing a shared destination with the people who matter, and do it in a way that is subtle and politically sensitive, because you are asking people to change. Begin with the why before the what: the right thing to build, in the right way, for the right reasons. Clarity is the first gift a leader gives, and it does more work than any reorg.
Intelligent people are remarkably good at organising themselves once they understand the objective and agree on how to reach it. Give them that clarity and their effort all points the same way instead of scattering. Withhold it and you get silos, politics and motion without progress. Making the hard calls that set direction under real uncertainty</a> is the actual work of leading.
Then look honestly at what you've got</h2>
Only now do you audit, and the audit has to be unflinching. The status quo of the technology, yes: the architecture, the tech debt, the tooling, the methodologies, the way you measure and report. But that is the easy half, and it is the half most leaders stop at.
The harder, more revealing half is the foundations. Your teams, your people and your culture. Your recruitment and your progression paths. How decisions actually get made when things are uncertain. The technology is where the symptoms show. The foundations are where the performance actually comes from. If you only audit the stack, you will fix symptoms and wonder why the deeper problems keep growing back.
The five things that actually decide it</h2>
When people ask what separates a world-class technical organisation from a mediocre one, they expect the answer to be about process: the right SDLC, the right methodology, the right delivery framework. All useful. None of them foundational.
The factors that actually decide it sit a couple of levels above all that. People, Leadership, Culture, Problem-solving and Creativity. Not five boxes to tick. They are interconnected, and they compound: improve one and the rest gain, weaken one and they all weaken. That is the destination, the shape you are chiselling towards.
Two of them do most of the work. Culture, because the best people only perform when they feel safe enough to</a>. And leadership, because it is usually the binding constraint, the factor that decides whether all the others get to count. After twenty years I am convinced the engineering is rarely the hard part</a>.
Change without stopping the bus</h2>
Here is the constraint nobody escapes. You do not get a clean slate, a bigger budget, or permission to halt delivery while you rebuild. The business keeps running, the roadmap keeps moving, and your people are watching to see whether the change is done to them or with them.
So transformation has to be incremental and non-disruptive. You protect continued delivery and staff wellbeing at the same time as you reshape. You make one improvement, review the result, make the next: kaizen, never finished, always moving. You do as much as you can with what you have, and you aim for world-class anyway. Done this way, the change earns trust rather than provoking fear, because people can feel the thing getting better while they are still carrying the load.
Give your curious people a remit</h2>
One part of the destination is not optional any more, and it is usually already in the building, waiting to be uncovered. You almost certainly have people who are quietly curious about what is coming next, reading about it on their own time. Give them a remit. A small, explicit function whose job is the future: experimenting with emerging technology and watching where it is heading.
Without it you spend your life receiving requirements and reacting to change after it has already hit you. With it you co-shape your own direction and you are in position when the opportunity arrives. AI is the obvious case. Every organisation has to be ready for its impact</a>, and the ones that made deliberate experimentation a habit will harness it while the rest are blindsided.
The work is never quite done</h2>
There is a reason this is continuous rather than a project with an end date. Left alone, every organisation drifts back towards disorder. Silos reform, clarity fades, the energy you aligned starts to scatter again. Keeping an organisation in a coherent, high-performing shape takes constant, deliberate effort, the way a sculptor keeps refining rather than declaring the work done.
That is the job. Not one dramatic act of demolition and rebuild, but the patient, ongoing work of chiselling away what does not serve the vision and protecting what does. The best technical organisation you will ever lead is almost certainly hidden inside the one you have right now. You just have to uncover it.

If you are staring at a technical organisation that is underperforming and wondering whether you need to tear it down and start over, you almost certainly do not. I am always happy to compare notes on how to reshape the one you have. Let's talk.</a>
Related: The best technology rarely wins. The best-led team does</a> · After 20 years as a CTO, the engineering was the easy part</a> · NHS Wales: transformation at national scale</a>

Agile is now the bottleneck

2026-06-01T00:00:00+00:00

For twenty years, the constraint on building software was how fast humans could write it. Agile, with its sprints and ceremonies, was built to manage that constraint: coordinate the people, plan the work into two-week chunks, keep everyone moving in roughly the same direction. It worked because building was slow.
Building is not slow anymore. With agentic coding tools</a>, a capable team can now produce in a day what used to take a sprint. And here is the uncomfortable consequence: when building gets that fast, the process built to coordinate slow building becomes the thing holding you back. The ceremonies, the two-week planning cycles, the handoffs between roles, are now slower than the engineering they are supposed to organise. Agile, or at least the heavy machinery that grew up around it, is now the bottleneck.
To be clear, the spirit of agile is not wrong. The adaptive, learn-as-you-go core is more right than ever. What breaks is the ceremony: the assumption that you should plan work in fixed batches and move it through stages, when the work itself now moves in hours.
You cannot plan a journey with no map</h2>
Here is the mental model I use instead. Building something genuinely new is a journey through territory nobody has mapped. The old instinct is to plan the whole route in advance: the sprints, the roadmap, the estimates. But you cannot plan a route through country you have never seen. The plan is fiction the moment you start walking.
So we do what sailors and explorers have always done. We set a destination, and we navigate towards it daily. Each day we take our bearings, see how far the last day's work actually got us, and set a corrected course for the next. We do not pretend to know the whole path. We commit to the direction, and we correct constantly. Repeat until we arrive.
One organism, not a relay</h2>
This only works if the people who make the decisions are in the same room, every day. Not a stand-up where everyone reports status, but a real working group where product, engineering, and domain knowledge sit together and decide on the spot, pulling on everyone's perspective at once. A fast, cross-functional organism, not a relay of handoffs where work waits in a queue between specialists.
The cadence is simple. Delivery is daily. The longest planning horizon is a week. We course-correct every day. Decisions that used to wait for a ceremony get made in the moment, by the people with the context to make them.
Faster, and better</h2>
The obvious gain is speed: a short loop means less waiting, less work sitting in queues, less time spent planning things that change anyway. But the bigger gain is quality. When the whole team decides together, every choice pulls on more knowledge than any one role has alone. And because the loop is short, you get many more iterations, many more chances to learn and correct. Better decisions, made more often, on more information.
There is an honest caveat, and the evidence is clear about it. Google's DORA research finds that AI lifts a team's throughput but damages its stability unless the foundations, testing, version control, a solid platform, are already strong. AI amplifies what is already there. Run this fast loop on weak foundations</a> and you will simply produce your mistakes faster. The speed is earned by the discipline underneath it, not instead of it. The leverage is real, but a word of caution: cutting your team on the strength of AI does not, on its own, produce a return. This is an operating model for building better, not a headcount argument.
The teams that win the next few years will not be the ones with the best tools. Everyone will have those. They will be the ones who stopped trying to plan a journey through unmapped territory, set a clear destination, and learned to navigate to it together, one corrected day at a time.

This is roughly how I run every engagement now. If you want to see what it looks like in practice, here is the fuller version</a>, or let's talk</a> about your delivery.
Related: You're not a 10x engineer, you're an orchestrator</a> · From AI that talks to AI that works</a> · The quality you can't see is the one that kills you</a>

Who is accountable for AI on your board?

2026-06-01T00:00:00+00:00

In most small and mid-sized companies, if you ask who is accountable when an AI system makes a costly or harmful decision, you get a shrug. The honest answer is usually "the board", but no individual on it has been named, and proportionate governance has not been set up. That gap is becoming a real liability in 2026, as regulation tightens and AI moves from experiments into decisions that affect customers and money. The fix is not to hire a Chief AI Officer. It is to name an accountable owner and put lightweight governance in place. Here is what that means for a company without a dedicated AI function.
Who answers when the AI gets it wrong?</h2>
Picture an AI system in your business making a decision that turns out badly: a customer wrongly refused, money misdirected, data exposed. Now ask who, by name, answers for it. In most SMEs there is no answer. The work has been delegated to a tool, the tool has been delegated to a team, and accountability has quietly evaporated somewhere in between.
This is different from the day-to-day question of who is allowed to use which tools, which is an operational matter. The board-level question is narrower and sharper: who is personally accountable for AI risk, and have you actually named them?
You probably don't need a Chief AI Officer</h2>
The market is busy telling you the answer is to hire a Chief AI Officer. For most companies your size, it is not. A dedicated AI chief is often premature, and the role has a habit of becoming a vanity title with an 18-month shelf life. You do not need a new seat in the C-suite. You need two things that cost almost nothing: a named accountable owner, usually an existing executive, and a proportionate system around them.
Naming the owner is the part everyone skips and the part that matters most. Accountability that belongs to "the board" belongs to no one. Accountability that belongs to a named person, with the authority to set policy and the proximity to see where AI is actually used, is real.
Why this is suddenly urgent</h2>
Two things are converging. AI is moving out of the sandbox and into decisions with real consequences. And the regulatory direction is unmistakable: accountability is becoming a named-person question, not a corporate abstraction. The EU AI Act's high-risk obligations are phasing in through 2026, and UK regulators are applying existing accountability frameworks to AI rather than waiting for a single new statute. For regulated firms, individual senior-manager accountability already extends to the systems they rely on.
The trouble is that almost all the guidance you will find online is written for large enterprises, by law firms and big consultancies. It does not tell a fifty-person company what proportionate actually looks like. That gap is the whole problem.
What proportionate governance looks like</h2>
Not a forty-page policy. For a company your size, five things:

A named owner. One accountable individual, on the record.</li>
An inventory. A simple list of where AI is in use, including the unsanctioned tools your staff are already running</a>. You cannot govern what you cannot see.</li>
Clear lines. What AI is allowed to decide on its own, and what always needs a human</a>. Especially for anything irreversible or customer-facing.</li>
A record. A basic audit trail of significant AI-driven decisions, so you can answer "why did it do that?" after the fact.</li>
A rhythm. A short, regular review of the above, so it stays current as your AI use grows.</li> </ol> This is the board-level layer that sits above the operational control plane</a>. The control plane governs what the agents do. This governs who answers for them.
You do not need to become an AI expert or build a compliance department. You need one accountable owner and a proportionate system, set up before an incident or a regulator forces the question rather than after.

If you want help working out what proportionate AI governance looks like for a company your size, and who on your board should own it, that is something I help leadership teams put in place. Let's talk.</a>
Related: Shadow AI is your next audit finding</a> · Agent sprawl is the new shadow IT. Your business needs a control plane</a> · Does your business need a CTO?</a>

How to build an AI strategy without a CTO

2026-06-01T00:00:00+00:00

You can build a sound AI strategy without a CTO, and without being technical yourself. What you cannot do is build one by picking a tool and rolling it out, or by handing the whole question to whoever is selling you the technology</a>. The method that works is the reverse: start from the parts of your business where AI could genuinely change the economics, match each to the right approach, and get one source of genuinely independent judgement to pressure-test your decisions. Here is how to do that when you do not have a CTO in the room.
The trap: the imbalance of knowledge</h2>
If you are a non-technical founder or leader, you start every AI conversation at a disadvantage, and it has a name: the imbalance of knowledge. The people you turn to for help, the agency, the AI vendor, the consultant, all know more about the technology than you do, and most of them have something to sell. That is not a conspiracy. It is just incentives. The salesperson is trained to upsell. The agency that swears it is "technology agnostic" almost always steers you toward the stack it already builds in. And lacking the knowledge to push back, you end up sanctioning decisions you cannot fully evaluate.
This is why so many SME AI strategies are really just a vendor's product roadmap wearing your logo.
You don't need to be technical. You need a method.</h2>
Here is the good news. Closing that gap does not require you to learn to code, or to hire a full-time CTO you cannot yet justify. It requires a way of making good decisions under uncertainty, and a small amount of genuinely independent expertise to check your thinking. The strategy itself is a business exercise, not a technical one, and business judgement is something you already have.
How to build the strategy</h2>

Start from value, not tools. Begin with the parts of your business where AI could change the economics: the costly bottleneck, the process that does not scale, the work that eats your best people's time. Not "where can we use AI" but "where would it actually matter".</li>
Match each problem to the right approach. The headline tool is not always the right one. AI is not just large language models</a>, and forcing every problem into a chatbot is how money gets wasted. Some problems want an LLM, many want something cheaper and more reliable.</li>
Define what success looks like in numbers. If you cannot say what a project is supposed to move on the P&L, you are not ready to start it. A clear metric is also your best defence against a vendor declaring victory on a demo.</li>
Sequence by value and feasibility. Rank the candidates by how much they would matter and how hard they would be. Start with something valuable enough to prove the point and contained enough to actually finish.</li>
Pressure-test with one independent expert. Before you commit budget, have someone with no stake in the answer challenge the plan. This is the single point where a little outside expertise pays for itself many times over.</li> </ol> Where to get honest input</h2>
The one thing you cannot safely skip is that independent read, and where you get it matters more than how much of it you get. You want someone with no technology stack to sell and no build hours to upsell, whose only interest is whether your plan is sound. This is the same conflict of interest that affects fractional CTOs supplied by agencies</a>: if the person advising you also profits from the build, the advice bends.
There is one simple test for a good advisor: curiosity. Anyone who fires back quick, confident answers to complex questions without first asking about your business is selling, not advising. The real expert leads with questions, because they know the right answer depends on details they do not have yet.
You do not need a CTO to get this right. You need to refuse to outsource the thinking to someone who profits from the answer, and to bring in honest, independent judgement at the few points where it matters most.

If you are a non-technical founder or leader trying to build an AI strategy without a CTO in the room, that is exactly the kind of thinking I help with. Let's talk.</a>
Related: If your AI strategy is just ChatGPT, you don't have one</a> · Does your business need a CTO?</a> · How to unlock AI ROI: what the 20% do differently</a>

You don't need to build a brewery to drink a pint of beer

2026-06-01T00:00:00+00:00

The most expensive software decision a founder makes is often the very first one: the decision to build. Standing up a team and a custom product is the default instinct, and for a lot of companies it is the wrong one. You don't need to build a brewery to drink a pint of beer. The right opening question is not "how do we build this" but "should we build this at all", and in 2026 that question has a different answer than it did even two years ago. Here is how to decide between building, buying, no-code, and an agency.
The one question that decides it</h2>
Almost everything turns on a single question: is this technology core to your business? Build an internal team when the technology is genuinely yours, proprietary inventions or data, regulated or security-critical, highly complex, or part of a long-term product you will keep extending. In those cases the control, independence, and compounding value of an in-house team are worth the cost and the time.
If what you need is a one-off, a run-of-the-mill capability, or something every business has, do not recruit a permanent team to build it. That is the brewery. You will spend a fortune and a year producing something you could have bought, configured, or assembled in a fraction of the time.
What changed in 2026</h2>
The line between "build it" and "don't" has moved, because AI now writes a great deal of the code, and no-code platforms have matured. A non-technical founder today can stand up a working first version, with AI assistance or no-code, that would have needed a small team and a budget in 2023.
That is real, and it is liberating. But mind the trap. AI lowers the cost of the easy 80%, the demos and the standard functions. It does not lower the cost of the hard 20%, the quality you can't see</a>: scale, security, and maintainability. And it does not change the core-or-regulated rule. The right tool still depends on the problem, because AI is not one thing and an LLM is not always the answer</a>.
Your four options</h2>

Build an internal team. Best when the technology is core, proprietary, regulated, or long-term. Most control, often cheaper over time, but slow to assemble and demanding to lead.</li>
Use a software agency. Fast, a ready-made team, good for non-core work or overflow. But agencies carry a conflict of interest</a>: they steer you toward the stack they staff, and the A-players in the pitch are not always the people who do your work. Name the individuals in the contract.</li>
Use contractors. Flexible, quick, good as a stop-gap. But low loyalty, weak cultural fit, high cost, and resentment from permanent staff paid less for the same work.</li>
Use no-code or AI tools. Excellent for prototypes, MVPs, and assembling standard functions. The catch is the ceiling: they may not scale, may lock you into a walled garden, and can get expensive as usage grows.</li> </ul>
Start with the cheapest thing that proves the point</h2>
For most new ideas, the smart first move is the cheapest version that tests whether the idea works at all, a no-code or AI-assisted MVP, not a build. Validate the demand, then graduate to building only the parts that are core and proven. Building first and validating later is how founders lose a year and a budget on something nobody wanted.
You still can't skip the judgement</h2>
Whichever option you choose, the decision itself and the quality of what gets built need impartial technical judgement, ideally from someone with no stake in the answer. That is the one thing AI has not changed, and the one place a little outside expertise pays for itself many times over. It is also why building an AI strategy without a CTO in the room</a> is mostly about who you trust to pressure-test the call.

If you are weighing up whether to build, buy, or assemble your way to a product, and want an independent read before you commit, that is exactly the kind of decision I help founders make. Let's talk.</a>
Related: How to build an AI strategy without a CTO</a> · The quality you can't see is the one that kills you</a> · Does your business need a CTO?</a>

After 20 years as a CTO, I learned the engineering was the easy part

2026-06-01T00:00:00+00:00

After twenty years as a CTO, the most uncomfortable thing I learned is this: the engineering, the part I was best at, was the easy part.
That is not false modesty. Deep technical skill is real, valuable, and rarer than most people think. But for someone wired the way I am, it was also the most predictable, masterable part of the job. Systems behave according to rules. Get good enough and you can design them well, reliably, again and again. The hard part, the part that actually decided whether any of that engineering mattered, was everything else: people, and above all leadership. It took me far too long, and several failures of my own making, to understand that.
The trap of being good at the measurable thing</h2>
Here is the trap, and naturally talented people are the most exposed to it. When you build something genuinely excellent, a robust system that serious organisations depend on, it feels like proof. Proof that you are good, that your judgement is sound, that you must therefore be a good leader too. I had that proof in abundance. I built systems used at national scale by governments and billion-dollar operations across more than thirty countries. So I assumed the leadership would take care of itself.
It did not. The very thing that made me a strong engineer, the comfort with systems that behave predictably, made me blind to the one domain that does not behave predictably at all: people. I was, for a long time, a poor leader. Not a cruel one, if anything the opposite, too far toward the compassionate and conflict-avoiding end. But poor all the same, and unaware of it, which is the worst kind.
The reckoning</h2>
The evidence was there for years before I read it honestly. Projects with real stakes, serious funding, and years of effort behind them, technically sound, that quietly failed to become what they should have. For a long time I looked everywhere except the obvious place. When I finally did, the common factor in the disappointments was not the technology. It was me. The engineering was excellent. The leadership around it was not, and that is what capped the outcome.
That is a hard thing to write on a website where people come to assess my judgement. I am writing it anyway, because the realisation was the most valuable one of my career, and because the founders I now work with are often standing exactly where I stood: certain that if the build is good enough, the rest will follow.
Necessary, but never sufficient</h2>
What I understand now is that building technology has an order to it, and the engineering sits at the bottom of it, not the top. The business reason has to be right, then the requirements, then the build. A flawless build on a weak foundation is still a failure, just a well-engineered one. Engineering is necessary. It is the price of entry, and doing it badly will sink you. But it is not sufficient, and on its own it guarantees nothing.
Leadership is what sits above it and decides whether the whole thing pays off: setting the right direction, getting people to do their best work</a>, and making good calls under uncertainty</a>. Without that, the most elegant system in the world is effort spent in vain.
You need a Goldilocks of both</h2>
So I did the unglamorous thing. I treated leadership as a discipline to be learned, not a talent I could assume I had, the same way I had once learned to engineer. Programmes, coaching, books, and a lot of deliberate practice, including an executive leadership programme at Oxford. It is still the work I find hardest, and the most worthwhile.
The lesson is not the tired one that soft skills beat hard skills. That is just as wrong in the other direction. You cannot lead your way out of a broken architecture, and a charismatic founder with no technical judgement is as exposed as a brilliant engineer with no people skills. What you need is a Goldilocks balance of both: enough technical depth to make sound decisions, and enough leadership to make that depth count. If you are strong on one and blind to the other, the blindness is what gets you. For most deep technologists, including the one I was, the blind side is the human one. And in the end, that is the side that decides.
If you are technical and quietly certain that the engineering is the hard part, I would gently suggest checking your blind side. And if you are a founder trying to work out whether you have the right balance around your technology, that is one of the most useful things an outside pair of eyes can tell you. Let's talk.</a>
Related: Does your business need a CTO?</a> · The best technology rarely wins. The best-led team does</a> · How big tech wins the talent war, and it isn't the money</a> · The most important skill in business and life</a>

Fractional CTO or AI consultancy? Don't hire the consultancy first

2026-06-01T00:00:00+00:00

If you have an AI initiative and you are about to hire an AI consultancy to build it, pause. For most companies that is the wrong first move, and the agentic era has made it more dangerous, not less. The instinct is understandable: you have a project, a consultancy delivers projects, so you hire one. But a consultancy and a fractional CTO are not two versions of the same thing. They do opposite jobs, and hiring them in the wrong order is how AI projects end up as expensive, unowned messes.
A consultancy delivers a project, then leaves</h2>
That is not a criticism, it is the model. An AI consultancy is paid to deliver a defined scope and move on to the next client. In the agentic era they can do it faster than ever, which sounds like pure upside until you see the other half of the picture: a 2026 industry survey found 81% of organisations had hit production failures from AI-generated code. Fast delivery plus fast departure leaves you holding a system that works in the demo, breaks in production, and belongs to nobody on your side. By then the only people who fully understand it are the ones who already left, which is exactly how you end up needing to recover a failed pilot</a>.
The real difference: delivery versus ownership</h2>
The consultancy question and the fractional CTO question feel similar and are opposite. One is about getting a thing built. The other is about someone owning the outcome: deciding what is worth building, setting the architecture, and still being there when it needs to change.
</th> AI consultancy</th> Fractional CTO</th></tr></thead>

What you get</td> A delivered project</td> Ongoing accountable leadership</td></tr>
Incentive</td> Bill the work, ship, move on</td> Your outcome</td></tr>
After the invoice</td> They leave</td> They stay and own it</td></tr>
Best for</td> Delivery capacity, defined scope</td> Deciding what to build, architecture, accountability</td></tr>
Cost shape</td> Project fee (often tens of thousands+)</td> Day rate, part-time (~£800–£2,000/day)</td></tr>
UK status</td> Supplier contract</td> Assess IR35 like any contract role</td></tr> </tbody></table>
The order that actually works</h2>
This is not strictly either/or. The mistake is the sequence. The right order is a fractional CTO first, to decide what is worth building, set the architecture and the success metric, and own the result, and then, if you need delivery capacity, a consultancy brought in under their direction. The fractional CTO is your interest in the room. The consultancy is a supplier they manage.
Hire the consultancy first and you have handed the most important decisions, what to build and how, to the party with the least incentive to get them right for you. That is the same conflict of interest</a> that sinks so many projects: the people advising you on what to build are the people who profit from building it.
The honest UK numbers</h2>
For a UK founder the economics are clearer than the marketing suggests. A fractional CTO works part-time, often a day or two a week, at a day rate in the region of £800 to £2,000 depending on seniority. That is a few thousand pounds a month for senior leadership you could not otherwise afford full-time. A consultancy project is a larger, lumpier commitment, frequently tens of thousands and up, for delivery. They are not competing line items. They are different things.
Two more things the UK marketing tends to skip. A fractional CTO engagement needs an IR35 status assessment like any contract role, whereas a consultancy is a straightforward supplier arrangement. And in regulated sectors, fintech and healthtech especially, the named accountability a fractional CTO provides is not a nice-to-have. It is often exactly what the regulator expects to see.
So the honest answer to "fractional CTO or AI consultancy" is usually "a fractional CTO, and then a consultancy if you need one, in that order." Get the ownership in place first, and the delivery becomes a managed supplier decision rather than a leap of faith.

If you are weighing this up for your own AI initiative, that is exactly the kind of call I help founders make, with no agency behind me and nothing to upsell. Let's talk.</a>
Related: The hidden conflict of interest in hiring a fractional CTO</a> · How to build an AI strategy without a CTO</a> · What to do when your AI pilot fails</a> · Does your business need a CTO?</a>

Why your tech recruiter isn't on your side

2026-06-01T00:00:00+00:00

Here is a fact that should change how you use recruitment agencies: the agency that places your new hire is, within a few months, often the same one quietly trying to entice them back out. Recruiters are paid when people move, not when they stay. A healthy, stable team is bad for their business. That does not make them useless, but it makes their incentives different from yours, and you need to understand the gap before you hand them your hiring.
To be fair upfront: not all recruiters are like this. I know a few who are genuinely excellent, honest, and worth every penny. But I know more than a few who are not, and the system rewards the behaviour, so you should assume it until proven otherwise.
Paid to move people, not to keep them</h2>
The core problem is structural. An agency earns its fee when a candidate changes jobs. So the entire industry has an interest in people moving around, which means stimulating exactly the staff rotation you, as an employer, are trying to prevent. Once you have built your team, the same agencies that helped you build it become a destabilising force, picking off your people for their next placement. In that narrow sense they are a kind of parasite on the system, and yet it is genuinely hard to build a team without them.
The fees, and how to negotiate them</h2>
The standard ask is 30% of the candidate's annual salary, payable within weeks of the hire starting, on a no-win-no-fee basis, which is the one good thing about it. That headline number is very negotiable. Established agencies will usually come down to around 15%. You can sometimes find a newer outfit that will take 10% for exclusivity, but they are often weaker at delivering. I tried that once and regretted it, wasting months for some very poor matches.
The bigger lever is the rebate. Agencies take the full fee on the assumption that the person stays a year or more, but pay it all upfront. What happens if your hire quits after two months? Negotiate a refund. Most will only offer a sliding rebate over the first three months, grudgingly, after a long round of haggling. I have never met an agency that would take its fee monthly across the year, or refund in proportion if the person does not stick. Push anyway.
The tricks to watch for</h2>
Two in particular. First, agencies will present candidates who are a poor fit as if they were a perfect match, because they are paid to close, not to be right. Either they cannot screen properly for the technology, or they do not care to. Second, the A-players showcased when they bid for your business are not always the people who turn up to do the work.
The defences are simple. Name the specific people in the contract. Check references yourself, with real conversations, not the box-ticking confirmation-of-employment that agencies pass off as diligence. An agency will never go looking for a reason not to hire, because all it wants is to close.
How to use a recruiter without getting fleeced</h2>
Used well, an agency gives you one valuable thing: a flow of candidates you would not have found. Treat that as a supplement to your process, never a replacement for it.

Keep exclusivity short: two to three weeks, no more. If the candidates are not flowing by then, move on.</li>
Or run two or three agencies in parallel. More than that and they step on each other, get discouraged, and stop really trying.</li>
Do your own interviews and technical assessment. No one can take this off your plate.</li>
Use a technical leader to screen and brief so you are not relying on a recruiter's grasp of the tech.</li> </ul> This is the same imbalance of knowledge that runs through every agency relationship, the same dynamic I have written about with agency-supplied technology leadership</a>. The person across the table knows more than you and is paid on an outcome that is not quite yours. Knowing that is most of the protection you need.

If you are building a team and want help running the process, or a technical eye on the people an agency puts in front of you, that is something I help founders with. Let's talk.</a>
Related: How big tech wins the talent war, and it isn't the money</a> · The hidden conflict of interest in hiring a fractional CTO</a> · You don't need to build a brewery to drink a pint of beer</a>

AI is about to split the job market in two

2026-05-31T00:00:00+00:00

Most of the debate about AI and jobs is about automation: which roles disappear, which survive. That is the wrong question, or at least an incomplete one. The bigger shift is not that AI removes jobs. It is that AI is about to rebuild the entire market that matches people to work, and in the process split it in two.
This is already starting. Within a few years, by the end of the decade, hiring will look almost nothing like it does today.
You won't look for work. Your agent will.</h2> Start with your side of the table. Today you manage your own career, badly, in the gaps between actually doing your job. Soon you will have a personal AI agent doing it for you</a>, continuously. It will coach you, spot the skills you are missing, map the progression paths open to you, and chase down the credentials that raise your value. And when an opportunity appears that fits, it will negotiate on your behalf, in a market that prices you in real time based on your skills, your reputation, and live demand.
Think of it as a career manager that never sleeps, never gets distracted, and works only for you.
Employers won't post jobs. They'll hunt.</h2>
The other side of the table changes just as much. Instead of posting a vacancy and waiting, organisations will search for talent constantly, proactively, at a scale no human recruiting team could match. They will read your public work, your repositories, your writing, your contributions to open communities, and identify the people they want long before a role formally exists. The best teams will be lined up before the project that needs them is even approved.
Hiring stops being an event, a thing that happens when a job opens, and becomes a continuous market running quietly in the background. Verified, portable credentials and reputation become the currency that market runs on.
This is where it splits</h2>
Here is the uncomfortable part. A market this efficient does not lift everyone equally. It concentrates. The top tier of talent, the genuinely scarce, will be valued the way elite athletes are now: courted relentlessly and priced accordingly. And that creates an equally elite tier of recruiters and advisors who serve them.
For everyone else, the risk runs the other way. A market that is brilliant at recognising and rewarding the top 1% can be just as efficient at overlooking everyone it does not rank highly. The same system that makes a star's career frictionless can quietly exclude the people it never surfaces. That is not a reason to slow it down, because it is coming either way. It is a reason to think hard, now, about fairness, access, and the people the algorithm does not see.
What stays human</h2>
If all of that sounds like the machines take over hiring entirely, they don't, and this is the most important point. The mechanics get automated: the searching, the matching, the first-pass filtering, the scheduling. What does not get automated is the part that was always the real work. Trust between two people. The judgement to read a person, not a profile. High-stakes negotiation. The intuition that says this person is right for this team even though the data is ambiguous.
The biggest winners will not be the ones with the best AI, or the ones clinging to the old human-only way. They will be the ones who combine them: AI for reach and speed, humans for trust and judgement. I have argued before that the interesting question is not what AI will automate but what it can't</a>, and nowhere is that clearer than in how we will find and choose each other for work.
It is all still up for grabs</h2>
None of this is science fiction set decades out. The candidate agents are being built now. The talent-hunting tools exist already in early form. The shape of the market in 2030 is being decided by the choices people make in 2026.
So the question is the same whether you are building a career, building a team, or building the tools that will run this market. It is all still up for grabs, and the quality of the thinking you bring to it now is what will decide where you land. That is the same logic behind running a dual-stream strategy</a>: deliver on today while you build deliberately for the market that is coming.
If you are trying to work out what this means for your business or your team, I am always happy to think it through with you.

Want to talk through what the agentic job market means for how you hire or how you build your career? Let's talk.</a>
Related: Most of what you do at work will be automated. The interesting question is what won't</a> · The training ladder is broken</a> · The dual-stream strategy</a>

If your AI strategy is just ChatGPT, you don't have one

2026-05-31T00:00:00+00:00

Here is a quick test of your AI strategy. If the honest summary of it is "we are rolling out ChatGPT", or Copilot, or Gemini, or some chatbot built on one of them, then you do not have an AI strategy. You have a subscription.
That is not a criticism of the tools. They are genuinely useful. It is a criticism of mistaking them for the whole of AI, and mistaking access to them for an advantage.
Blindsided by LLMs</h2>
Something strange has happened over the last couple of years. Awareness of AI has gone through the roof, and understanding of it has barely moved</a>. Most leaders now quietly equate "AI" with large language models, the things that write text and hold a conversation. I call it being blindsided by LLMs: the one form of AI that is easy to see has crowded out all the others.
It matters because of a simple competitive fact. The frontier language models are available to everyone, through the same handful of APIs, at the same price. Your biggest competitor can buy exactly what you buy, on the same afternoon. So whatever edge you think you are getting by adopting an LLM, they are getting too. Adopting the thing everyone can adopt is not a strategy. It is keeping up.
LLMs are one tool in a large box</h2>
The deeper problem is that an LLM is often not even the right tool. Language models are one corner of a much larger field. Depending on the problem, the technique that actually moves your numbers might be demand forecasting, optimisation, anomaly detection, recommendation, computer vision, simulation, or a plain well-tuned predictive model that is cheaper, faster, more accurate, and more explainable than any chatbot. These are not exotic. They are mature, proven, and frequently a far better fit than asking a language model to do a job it was never built for.
When the only tool you reach for is the one in the headlines, you end up forcing every problem into the shape of a chat interface. Some problems fit. Many don't.
Where the advantage actually lives</h2>
If the model is commoditised, where is the edge? In the things that are yours and cannot be bought off a shelf. Your proprietary data. The specific problems in your business that are worth solving. And, above all, the willingness to redesign the work around the technology rather than bolting it on top. The model is the commodity. The advantage is everything you wrap around it.
So what do you actually do?</h2> Not the obvious thing, which is to pick a tool and roll it out. The wiser order is the reverse: start from the parts of your business where AI could genuinely change the economics, and only then match each one to the right technique</a>, which may or may not be an LLM. That is slower and less exciting than announcing a chatbot. It is also the difference between AI spend that shows up in the numbers and AI spend that doesn't</a>.
The companies that win the next few years will not be the ones that adopted AI first. Almost everyone will have adopted it. They will be the ones who understood that AI was never one thing, refused to be blindsided by the single form of it everyone was talking about, and did the unglamorous work of matching the right tool to the right problem.

If you want help working out where AI could actually move the needle in your business, and which kind of AI that even is, I am happy to talk it through. Let's talk.</a>
Related: The people making the biggest AI decisions understand it the least</a> · Why your AI spend isn't showing up in the numbers</a> · Stop counting AI use cases. Redesign three value streams instead</a>

From AI that talks to AI that works: the autonomous leap of 2026

2026-05-31T00:00:00+00:00

A few weeks ago, a developer reported something that should make every leader sit up. His AI assistant had quietly bought a phone number on Twilio, built itself speech capability, and started calling him to chat.
Nobody told it to. It decided that talking was a better way to reach him, and acted on it.
That assistant runs on OpenClaw, an open source project that barely existed before mid November 2025. Within weeks it became one of the fastest growing open source projects anywhere. Its author built it almost entirely agentically, with Claude Code doing the work.
This is the moment the shift becomes obvious. 2025 gave us AI that talks. 2026 is the year of AI that works.
From answering to acting</h2>
The difference is not subtle. A chatbot waits for your prompt and answers. An agent takes your goal and pursues it, for hours or days, while you sleep. It gets in touch when it needs a decision. It remembers everything you have ever told it: your preferences, your context, the facts of your life.
That is a categorical change, not an incremental one. It is also why the engineering underneath matters more than ever. When a system only answers, a mistake is a bad sentence. When a system acts, a mistake is a bad outcome in the world. I have written before about why you are not talking to an LLM, you are talking to a system</a>, and autonomy raises the stakes on every layer of that system.
I have spent the last year building in exactly this space. A personal assistant as a hobby project. A professional mentor application with Mentor360</a>, now being trialled by the Royal Navy, one of the Formula 1 teams, and other high-performance organisations. So when I say the ground has shifted, it is not a guess from the sidelines. It is what I am watching happen in the products I help build.
OpenClaw, and why it matters</h2>
OpenClaw is the clearest public sign of it. You install it on your own machine, a Raspberry Pi is enough, or in any cloud. You talk to it through your favourite messaging app. You hand it a task and it goes to work. The only real limits are your budget for model calls and your imagination.
What makes it striking is not any single feature. It is that a capable, general-purpose, autonomous agent is now something a hobbyist can run at home, for the cost of the model calls it makes. The gap between a research demo and a thing ordinary people use has collapsed.
The risks are real</h2>
It is not finished, and it is not safe yet. There are serious privacy and security questions nobody has fully answered, and I would not yet trust it with anything that truly matters. An agent that can act on your behalf can also act wrongly on your behalf, at speed, with your credentials.
This is the honest tension of the moment. The capability is genuinely exciting and the guardrails are genuinely immature. Both things are true at once, and treating either as the whole story gets you into trouble.
A harbinger, not the destination</h2>
OpenClaw is a harbinger, not the destination. Apple, Google, Anthropic, and OpenAI are all building commercial versions of the same idea. Within a year, an autonomous assistant in your pocket will feel as ordinary as a search bar does today, with the safety and polish the open source version is still missing.
AI is still early. We have seen a fraction of what it will do, and it is accelerating. Nobody can tell you exactly where it leads, or how fast. But the people who put it to work this year will pull steadily ahead of the people who waited to see what happened. The same pattern is already visible in how the best teams are actually shipping agents in production</a>.
So it is worth asking yourself honestly: are you doing enough to put this to work, in your business and in your life?

Weighing up where autonomous AI fits in your business and not sure where to start? Let's talk.</a>
Related: AI is about to split the job market in two</a> · Agentic AI in 2026: what actually works in production</a> · You're not talking to an LLM, you're talking to a system</a> · The irreducible human edge</a>

How big tech wins the talent war, and it isn't the money

2026-05-31T00:00:00+00:00

Over the last twelve weeks I did something slightly unusual. I interviewed for senior leadership roles at five big tech companies, and not only because I wanted the job. I wanted to understand, from the inside, how the best-regarded technology companies in the world build their cultures. Why they win the talent war so consistently, while smaller companies, often with better missions and more interesting problems, struggle to attract and keep the same people.
I accepted one of the roles. And the thing I went in looking for turned out to be more deliberate, and more important, than I expected.
It is not the money. The money helps, obviously. But the best people have an almost endless choice of where to work, and the thing that actually separates the companies they flock to is not the package. It is psychological safety: an absolute, non-negotiable floor of respect and emotional security that these companies treat as a hard operating requirement, not a nice-to-have.
Why the best people need it most</h2>
There is a hard reason for this, not a soft one. The most talented people are very often the most sensitive. The traits that make someone exceptional, intensity, deep focus, a low tolerance for things being wrong, frequently come bundled with a nervous system that reacts strongly to its environment. Many of the best engineers I have worked with were not comfortable in the average school playground, and they are certainly not looking to relive it at work.
The science is settled enough. People do their best work under a moderate, positive kind of pressure. Push beyond that and something physical happens: the brain starts diverting resources to its older, survival-focused parts, and the higher-level, creative, analytical machinery quietly powers down. A frightened brain cannot do its best thinking. So if you lead through fear, distrust, and pressure, which a surprising number of ordinary companies still do, you are literally switching off the capability you are paying for.
The cocoon</h2>
The best companies build a protective wall around their most valuable people. Partly because those people can be fragile, and partly because it lets them disappear into the work. That disappearing is the whole game. Deep, undisturbed focus is where flow lives, the state where output multiplies several times over, and flow only grows in the right conditions: high interest, low anxiety, no interruptions, no fear.
Flow is a fragile thing. It takes real effort to create and almost nothing to destroy.
And it is not just about heads-down focus. High performance needs open lines, people willing to float a half-formed idea without bracing for impact. Not every idea is good. But the moment someone shares one and is met with a flinch, a smirk, or a flicker of scorn, you have taught them something precise: never do that again. They will keep the next idea, possibly the good one, to themselves. The cheapest leadership tool in the world runs the other way: genuine, specific recognition</a> for the act of contributing, every time.
The best organisations understand that a brilliant idea can come from anyone, at any level. The weak ones operate on the quiet assumption that good ideas are the property of senior people, and they defend that assumption in ways that slowly poison everyone beneath them.
The part that surprised me</h2>
There is a real edge to this, and I felt it personally. The bar for respect is so high that it constrains how people speak. You learn to be genuinely careful, with jokes, with stories, with offhand references, because what reads as harmless to you might land badly on someone else.
I ran into this myself. I sailed through the engineering and most of the leadership interviews at one of these companies, and then stumbled on a single phrase. Asked for an example of resolving a crisis, I described a past situation as a bit of "high school drama". The interviewer read it as dismissive and insensitive. It cost me. I was surprised by the intensity of the reaction, and then, thinking about it, I understood it. If you are going to promise everyone a workplace free of casual cruelty, you have to hold the line everywhere, including with a candidate who used two careless words.
Soft, or strong?</h2>
It is fashionable in some circles to call this coddling. We have all heard the gospel of the high-pressure founder who gets results by making people afraid. So is psychological safety just weakness dressed up in HR language?
I think the opposite is true. These cultures are not weak. They are extraordinarily strong, because they let a far wider range of people, with different backgrounds and different ways of thinking, perform at their best at the same time. That is a much harder thing to build than a pressure cooker, and a much more powerful one.
What this means if you are not big tech</h2>
The good news is that psychological safety is not expensive. You cannot always match a tech giant on salary or equity. But you can match them, and often beat them, on the thing that actually retains your best people. It costs nothing to build a culture where ideas are welcomed, mistakes are examined rather than punished, and respect is genuinely non-negotiable from the top down.
Most companies don't, because it requires the leaders themselves to model it relentlessly, and that is harder than writing a cheque. But if you get it right, you can hold talent that a much larger company would happily pay double for. In a world where the old advantages of scale and capital are dissolving</a>, the protective culture you build around your best people may be one of the few moats you have left.

If you are trying to build that kind of culture, or wondering why your best people keep leaving for companies with worse problems and better environments, I am always happy to compare notes. Let's talk.</a>
Related: The best technology rarely wins. The best-led team does</a> · The most powerful yet overlooked tool in a leader's arsenal</a> · Traditional moats are dissolving</a> · Most of what you do at work will be automated. The interesting question is what won't</a>

The hidden conflict of interest in hiring a fractional CTO

2026-05-31T00:00:00+00:00

Fractional CTOs are everywhere now, and mostly that is a good thing. Senior technology leadership without the full-time cost is exactly what a lot of companies need. But there is a version of this arrangement that quietly works against you, and most founders never see it coming.
It is the fractional CTO who comes attached to an agency.
Here is the problem. When a software house or digital agency lends you one of their experts to act as your technology leader, that person has two employers: you, and the agency that signs their cheque. Their advice is supposed to serve your interests. But every recommendation to bring in more of the agency's developers, to extend the agency's contract, to pick the stack the agency happens to specialise in, also serves their real boss. It is hard to serve two masters. So they don't. The agency wins, and you pay for it.
The imbalance of knowledge, used against you</h2>
This works because of a gap you already feel if you are a non-technical founder. The person across the table knows more about the technology than you do, and a good salesperson knows exactly how to use that. Account managers are trained to upsell. The genuinely well-meaning engineers get kept at a safe distance from you.
And the agency that swears it is "technology agnostic", free to pick the best tool for your job, almost never is. Everyone specialises. They have teams built around specific languages and frameworks, and they are not going to retool at their own expense to suit you. So you get steered, gently and expertly, toward the solution that suits them.
The "CTO" might be a business analyst</h2>
There is a second trap, and it is more common than it should be. An agency will tell you that all its people are top-tier experts, then put forward an average business analyst or a mid-level engineer with a CTO title bolted on. I have seen this happen more than once. The reputation of the firm is doing the talking, not the actual experience of the person you are about to trust with the most strategically important decisions in your business.
The defence is simple. Interview the individual, not the logo. Judge the specific person on their own merits, their own track record, their own scars. The reputation of the firm tells you nothing about the competence of the one human being they have put in front of you.
What good actually looks like</h2>
The fix for both problems is the same. Find someone independent, who charges you directly, with no middleman and no colleagues to upsell. Someone personally accountable, who you can meet, evaluate, and build a relationship with. Someone whose only incentive is your outcome, because that is the only thing they are being paid for.
And there is one trait worth weighting above almost all others: curiosity. A real advisor leads with questions. They dig into your business, validate their assumptions, and tell you where their knowledge comes from. If someone fires back quick, confident answers to genuinely complex questions without doing the work first, treat it as a red flag, not a sign of brilliance. The best technical advice is slow before it is fast.
One more thing, and it is the one founders get wrong most often. Engage your independent advisor early, before you hire the development team, not after. The most expensive mistakes in a tech project are made in the first few decisions: the architecture, the platform, the hiring profile. Those are made before a single agency developer writes a line of code. By the time you have a team in place, the costly choices are already behind you.
None of this means an agency is the wrong answer, or that a fractional CTO is a gamble. A well-structured fractional engagement is one of the best-value decisions a growing company can make, and I have written separately about when it fits and when it doesn't</a>. It simply means you should know whose interests your technology leader actually serves. If the honest answer is "not only yours", you have not really hired a CTO. You have hired a salesperson with a better title.
If you want a second opinion from someone with no agency behind them and nothing to upsell, that is exactly what I do. Let's talk.</a>
Related: Fractional CTO. Is outsourced technology leadership right for you?</a> · Fractional CTO or AI consultancy? Don't hire the consultancy first</a> · What to do when your AI pilot fails</a> · Does your business need a CTO?</a>

The quality you can't see is the one that kills you

2026-05-31T00:00:00+00:00

A friend of mine lost two years of his life and several million pounds of his own money on software that worked perfectly. The features were brilliant, genuinely ahead of anything AutoTrader had at the time. Then the users arrived, the traffic grew faster than the system could scale, and it fell over. The business never recovered. He will tell you himself: the architecture was wrong, and the launch was rushed, with no real load testing.
Here is the uncomfortable truth that story illustrates. There are two kinds of software quality. The kind you can see, and the kind you can't.
The kind you can see is the one everyone talks about: does it work, does it look good, is it a pleasure to use. The kind you can't see is the one that decides whether your company survives: does it stay up under load, does it resist attack, can it be changed without falling apart, will it still cope when you have ten times the users. The second kind is invisible right up until the moment it isn't, and that moment usually arrives at the worst possible time. During scale-up. During a fundraise. During an exit.
Three companies that learned it the hard way</h2>
My friend's car-trading site is the first. Visionary features, no competitor close, and none of it mattered once the user base outgrew the architecture.
The second: a major university website that went offline for most of a day during clearing, the single day in the year when it receives the flood of new applications. Estimates of the lost revenue run between £8 and £21 million. The site worked fine every other day of the year. It just couldn't take the one day that mattered.
The third one is mine. At my previous company, GeoVS, we lost our first sale of a £300,000 system because the back end of our distributed sensor platform could not perform under real conditions. That one hurt. We learned, re-architected, and the same platform now runs at national scale in several countries, monitoring critical infrastructure worth hundreds of billions of dollars, and it is known for never going down. There is a sting in the tail. Years later, when we sold GeoVS, one of the reasons the buyer went ahead was a testimonial from that very first client, the one who had refused us. They said it was the first and only system they had ever used that never crashed. We won them back. But the early failure cost us ground we never fully recovered, and a better exit.
None of these failures were about features. Every one of them was about the quality nobody could see until it was too late.
Why it keeps happening</h2>
So why does it keep happening? Because software quality means different things to different people, as Gerald Weinberg put it. The business side owns the visible quality: the features, the experience, the thing the customer is sold. The engineers own the invisible quality: the load tests, the security, the architecture that has to hold. And the two halves too often don't talk. Each assumes the other has it covered. Neither does.
I once worked with an engineer who told me, with a straight face, that users expect bugs. He was the reason we lost a first sale. That attitude, the quiet belief that the invisible quality is someone else's problem, is more expensive than any feature you will ever cut.
The fix is not complicated, but it takes intent. Treat the invisible quality as a first-class business concern, not an engineering detail. Load test before launch, not after the outage. Make security and scalability someone's explicit responsibility, with a name attached. And get the two halves of the team in the same room early, because business requirements are better when they are technically honest, and architecture is better when it understands what the business is actually betting on.
Why this is suddenly more urgent</h2>
AI now writes a large share of the code in many companies, and it is very good at the quality you can see. It produces working features, clean-looking functions, plausible output, fast. What it is weakest at is exactly the quality you can't see: the architecture that holds under load, the security that assumes someone hostile is on the other end, the maintainability that a human will have to live with in two years.
The volume of code is going up, and the share of it that any human has truly examined is going down. That is why the percentage of AI-generated code is a vanity metric</a>: it counts the quality you can see and tells you nothing about the quality that kills you. The invisible quality has never been easier to neglect, or more dangerous to ignore.
Tom DeMarco offered the definition of quality I keep coming back to: a product's quality is a function of how much it changes the world for the better. A clumsy product nobody trusts, or one that falls over on the day that matters, never gets the chance. The visible quality earns you the user. The invisible quality is what lets you keep them.

If you are scaling, raising, or heading toward an exit and you are not sure how much invisible quality your product is carrying, that is exactly the thing worth checking before someone else checks it for you. Let's talk.</a>
Related: 75% of Google's new code is AI-generated. So what?</a> · What to do when your AI pilot fails</a> · How to unlock AI ROI: what the 20% do differently</a>

What to do when your AI pilot fails

2026-05-31T00:00:00+00:00

If your AI pilot has failed, the first thing to know is that you are firmly in the majority, and that most failed pilots are recoverable. By recent counts, 95% of generative AI pilots produce no measurable return (MIT, 2025), and 42% of UK firms scrapped most of their AI initiatives in 2025, up from 17% the year before (S&P Global). The failure is rarely the technology. It is almost always something fixable in how the project was scoped, governed, and built. Here is how to work out what went wrong, and how to get the value you were promised.
It almost certainly wasn't the AI</h2> When a pilot dies, the instinct is to blame the model. Wrong model, not smart enough, not ready yet. Almost always, that is not what happened. The predictable causes are the same handful every time: a use case chosen because it was exciting rather than valuable, data and retrieval quality that could not survive real inputs, no clear definition of success, and no plan for the unglamorous engineering between a demo and production. I have written separately about why AI projects fail and what the 20% that succeed do differently</a>. For now the important point is simpler: a failed pilot is usually a fixable pilot.
How to recover a failed AI pilot</h2>

Diagnose before you spend another pound. The most expensive mistake is to pour more money in the same direction before understanding why the first attempt failed. Start with an honest post-mortem of scope, data, metric, and engineering, not a new vendor.</li>
Separate the idea from the execution. A pilot can fail because the idea was never going to pay off, or because a good idea was built badly. These need opposite responses, so decide which one you are looking at before anything else.</li>
Find the real success metric. Many pilots fail because nobody agreed what success looked like in numbers. If you cannot say what the pilot was supposed to move on the P&L, that is the first thing to fix, not the model.</li>
Decide: salvage or restart. If the use case maps to genuine value and a clear metric, the execution can usually be rebuilt on the same foundation. If the use case never had a path to value, restart from the problem, not the prototype.</li>
Rebuild the unglamorous parts. Most of the value lives in the layers nobody demos</a>: retrieval, data quality, error handling, escalation, and the workflow redesign around the model. That is where the recovery effort should go.</li> </ol>
Who should run the recovery, and who shouldn't</h2>
Here is the part most people get wrong. The worst-placed people to recover your failed AI pilot are usually the ones who built it. Not because they are not capable, but because their incentives and their blind spots both point the wrong way. The firm that built the pilot has a commercial interest in selling you more of the same, and a natural reluctance to name the decisions that caused the failure, because they made them.
</th> The consultancy that built it</th> An independent fractional CTO</th></tr></thead>

Incentive</td> Sell more build hours</td> Get you to a working outcome</td></tr>
Blind spot</td> Owns the decisions that failed</td> No stake in the original build</td></tr>
Salvage-or-restart call</td> Biased toward "keep building"</td> Decided on the merits</td></tr>
Accountability</td> To their own pipeline</td> To your result</td></tr> </tbody></table>
This is the same conflict of interest that runs through agency-supplied technology leadership</a>. For a recovery, where the whole job is an unflinching diagnosis, independence is not a nice-to-have. It is the point.
What recovery actually looks like</h2>
None of this is exotic. The European insurance brokerage I worked with</a> reached 67% autonomous resolution on real customer cases, not because of a cleverer model than anyone else had, but because the unglamorous parts were done properly: retrieval engineered as a first-class problem, conservative escalation, a metric everyone agreed on, and the workflow rebuilt around the system rather than bolted on top. A recovered pilot looks the same. It is the demo plus all the work the demo skipped.
A dead pilot feels like a write-off, and the board will be tempted to treat it as one. Usually it is not. It is a first draft that taught you, at some expense, exactly which of the four things above went wrong. That is worth more than it feels like in the moment, as long as the diagnosis is honest and the recovery is run by someone whose only interest is your result.

If you have an AI pilot that stalled or failed and you want an independent read on whether to salvage it or start again, that is exactly the kind of diagnosis I do. Let's talk.</a>
Related: How to unlock AI ROI: what the 20% do differently</a> · The hidden conflict of interest in hiring a fractional CTO</a> · Stop counting AI use cases. Redesign three value streams instead</a>

The people making the biggest AI decisions understand it the least

2026-05-30T00:00:00+00:00

The people making the biggest AI decisions understand it the least. I watch it happen every week.
The concentric circles of AI understanding</h2>
Picture knowledge of where AI is actually heading as a set of concentric circles. At the centre sit the people running the frontier labs and the researchers shipping the models. They see the curve up close. Move one ring out and understanding drops sharply. By the time you reach the outer rings, the traditional-industry executives holding the budgets and the large consultancies advising them, real understanding is thin.
Here is the uncomfortable part. The money and the strategic decisions sit in those outer rings. The clarity sits at the centre. The gap is widest exactly where the stakes are highest.
Where I stand</h2>
I see this from a particular vantage point. I build with these tools daily. I co-founded AdBrain AI and shipped an agentic system at one of Europe's largest insurance brokerages that now resolves 67% of customer service cases without human intervention</a>. That work keeps me close enough to the frontier to feel where it is moving. Not inside any single lab, not captured by one company's narrative, but near enough to build with the latest models rather than read summaries about them.
From there, the distance between people who have watched a demo and people who have actually built something is wider than anyone in a boardroom admits.
The chain of advice</h2>
Think about the chain of advice that reaches most leadership teams. A traditional-industry executive trusts a consultancy. The consultancy briefs a partner. The partner reads an analyst report. The analyst watched a keynote. By the time a recommendation lands on the boardroom table, it can be two or three steps removed from anyone who has shipped a single thing with these tools. Each layer smooths the edges, removes the uncertainty, and quietly loses the truth that the people closest to the work would never have rounded off.
Most strategy I encounter is built this way. A quiet game of Chinese whispers, played across enough hand-offs that the original signal barely survives. It is one reason so much AI transformation turns into theatre</a>.
What genuine insight actually requires</h2>
So what does real insight look like? In my experience it needs four things together: real domain expertise, hands-on use of the frontier tools, a forecaster's discipline about probability and evidence, and the willingness to change your mind quickly when the facts move.
Miss any one and the picture distorts. Domain expertise without hands-on use gives you confident opinions about tools you have never touched. Hands-on use without discipline gives you hype. Discipline without the willingness to update gives you yesterday's forecast defended to the death.
Even the models cannot replace the human</h2>
There is a detail here that surprised me. In recent forecasting benchmarks, the strongest models now edge out expert human forecasters. You might think that settles it, that we should simply ask the model. It does not. The sharpest forecasts come from a capable human working with a powerful model. Neither alone is best. The human supplies the intent, the taste, the judgement about what actually matters. The model supplies the breadth and the speed.
The same is true of understanding AI itself. The people who see clearest observe the frontier up close, yet refuse to take any single lab's word as gospel.
What to do about it</h2>
I am not saying every executive needs to write code. I am saying the further a decision sits from anyone who has genuinely built with these tools, the more carefully you should question it. Ask where the advice came from. Ask who in the chain has actually shipped something. Ask how many hands it passed through before it reached you.
When you think about your own AI strategy, can you name a single person in that chain who has actually built with these tools, rather than watched someone else demo them? Trace it back. What you find is usually the real story.

If you want AI strategy from someone who builds with these tools rather than summarising them, get in touch</a>.
Related: Turning AI theatre into AI that moves the numbers</a> · The interesting question is what AI won't automate</a> · Why 80% of AI projects fail to deliver ROI</a>

You're not talking to an LLM. You're talking to a system

2026-05-23T00:00:00+00:00

You're not talking to an LLM. You're talking to nine systems in a trench coat, and the model is only one of them.
When someone types a question into ChatGPT or Claude, they picture one clever brain in a box. A single mind reading their words and thinking back at them.
That is not what is happening. You are talking to a system, and the model is one small part of it. I know this because building the rest of the parts is my day job: the retrieval, the guardrails, the routing, the document handling. The model is the bit I worry about least.
Let me walk you through the coat.
What decides whether your question even reaches the model</h2>
Two layers act before the model sees a single word. First, alignment guardrails: the system checks tone, safety, and factuality going in and coming back, and tries to catch confident nonsense before it reaches you. Second, routing. Some products quietly send simpler questions to a smaller, cheaper, weaker model to manage cost and latency. You never see the handover.
Caching sits alongside both. The same question asked twice should not cost twice, so the system reuses earlier work where it can.
The memory is a trick</h2>
This is the part that surprises people most. The model's weights do not change as you talk to it. It has no built-in memory of your last message, let alone last week. The continuity you feel is faked, and faked well, by separate tooling that stores your history, retrieves the relevant pieces, and injects them back into the conversation before the model ever sees them.
When a chat gets long, compaction takes over. The earlier parts are summarised and compressed so the whole thing still fits in the context window. You experience one smooth conversation. Underneath, it is being rewritten on the fly.
What happens when you upload a document</h2>
Upload a PDF and more machinery wakes up. OCR reads the text off the page. Chunking breaks it into pieces. Vector search, which matches meaning rather than keywords, finds the few paragraphs that actually answer your question. The model never reads your whole file. It reads a curated handful of fragments that the surrounding system decided were relevant. Getting that retrieval right, rather than the model, is what most production AI actually turns on</a>.
And the deliberate thinking you sometimes see, the model working through a problem step by step, is the system instructing it to show its reasoning rather than blurt the first answer that comes to mind.
Nine systems, one model</h2>
Guardrails, routing, caching, memory, compaction, OCR, chunking, vector search, step-by-step reasoning. Count them. Nine. The model is one of them.
Now the honest punchline, the part vendors rarely say plainly. With all of that scaffolding, the model's weights still do not change while you use it. Whatever it learns from your conversation happens later, in bulk, during training, if at all. The ideal we are all working towards is a model that genuinely learns from new data as it goes. That is not today. Today we fake learning with retrieval and careful plumbing, and most of the time that plumbing is what decides whether the product works.
The tenth passenger: when it stops answering and starts doing</h2>
Everything so far describes what happens when you ask for an answer. Increasingly you are not asking for an answer. You are asking for an action: book it, file it, reconcile it, draft the reply and send it. That adds a tenth passenger to the coat, and it is the one growing fastest. The agentic harness.
You have probably met these already, even if you never named them as such. Anthropic's Claude Code and Claude Cowork. OpenAI's Codex. Google's Antigravity and Gemini Spark. Amazon's Quick Suite. Every one of them is a harness wrapped around a model, not a model. The race between the big labs is no longer only about whose model is smartest. It is increasingly about whose harness lets that model get real work done safely.
Here the model is handed a set of tools, things it can actually call: a search, a database query, a code runner, an email API. It does not execute them itself. It proposes an action, the harness runs it, feeds the result back, and the loop repeats until the job is done or the agent decides it is stuck. The model is the part that chooses what to do next. The harness is everything that lets it do anything at all, and everything that stops it doing the wrong thing.
That harness is where production agents are won or lost. It holds the tool definitions, the permissions for what the agent is allowed to touch, the budget limits, the verification step that checks the agent did what it claimed rather than trusting it, and the escalation path for the cases it should not handle alone. The actual agent loop is often a few dozen lines. The engineering lives in the scaffolding around it. I have written about what works here in more detail</a>.
Strip it back and the harness does four jobs the model cannot do for itself.
It manages processes: starting agents, running several at once, spawning a focused subagent for a sub-task so the main agent's context stays clean, and stopping the ones that go wrong before they do damage.
It manages memory: not the model remembering, which it cannot, but the harness recording what the agent did and decided across steps and across runs, then feeding the relevant pieces back when they matter. The same retrieval trick from earlier, now in service of an agent rather than a conversation.
It manages workflows: the order steps run in, what must finish before the next begins, where a human signs off. The agent improvises within a structure the harness defines, rather than freelancing from a blank page.
And it manages skills: capabilities loaded on demand for the task in front of it, rather than carried all at once. The harness brings in the right skill at the right moment, which keeps the agent sharp instead of bloated.
Tools, processes, memory, workflows, skills, verification. The model supplies the judgement about what to do next. The harness supplies almost everything else.
So when a tool uses AI to do something rather than say something, the model is doing even less of the work, not more. The harness is doing the rest. And the same rule holds, harder: when an agent fails, the model is rarely the reason.
What this means for the decisions you make</h2>
Why does this matter if you are not the one building it?
Because executives keep buying the whole system and then arguing only about the brain inside it. They debate which foundation model is smartest while the things that actually decide whether their AI works, the retrieval, the guardrails, the routing, the document handling, sit unexamined. They are paying for a system and inspecting one component.
Better AI decisions start with one plain question: which layer am I actually paying for, and which layer is failing me? When an AI product disappoints, the model is rarely the problem. The retrieval is feeding it the wrong fragments. The chunking mangled the document. The router quietly downgraded you. The guardrails are too tight, or too loose. The 67% autonomous case resolution we reached at a European insurance brokerage</a> came from getting those layers right, not from a cleverer model.
The brain in the box is real, and it is remarkable. But it has never been alone in there. The next time a demo dazzles you, or a tool frustrates you, resist the urge to credit or blame the model. Ask what the rest of the coat is doing.

If you want to work out which layer of your AI stack is actually failing you, get in touch</a>.
Related: Agentic AI in 2026: what actually works in production</a> · What two hours with Anthropic's agent team taught me</a> · Why 80% of AI projects fail to deliver ROI</a>

Agent sprawl is the new shadow IT. Your business needs a control plane

2026-05-16T00:00:00+00:00

How many AI agents are running in your business right now?
If you can't answer that question with a number, you have a problem. And it's the same problem that cloud created in 2014 when every team started spinning up AWS accounts on a credit card, and the CFO discovered six months later that the company was running 400 services across nine regions with no inventory, no budgets, and no kill switch.
We are about to repeat that mistake at speed. The 2026 version is agent sprawl.
The new shadow IT</h2>
I wrote a few months ago about shadow AI</a>, the problem of employees using ChatGPT and Claude on personal accounts to process company data. That problem hasn't gone away. But there's now a second, more serious version of it: the agents your organisation has actually deployed.
In the last 30 days, Microsoft, Google, Salesforce and IBM all shipped what they're calling agent management platforms. Microsoft Agent 365 is positioned as a control plane to observe, govern, and secure agents, including discovery of "shadow AI," agent credentials, permissions, and registry sync with AWS Bedrock and Google Cloud. Google's Gemini Enterprise Agent Platform launched with Agent Identity, an Agent Gateway, Agent Observability, simulation, evaluation, and prompt-injection defences. Salesforce shipped Agent Fabric for trusted agent identity, model choice, deterministic handoffs, and agent scanning. IBM positioned watsonx Orchestrate as a central orchestration layer for agents, tools, and workflows with governance and auditability built in.
Four of the largest enterprise software companies in the world, all shipping the same product category in the same month. That's not a coincidence. That's the shape of the next problem.
The early signal that this is becoming procurement-grade is the rise of two open standards: Anthropic's Model Context Protocol (MCP) and the emerging Agent-to-Agent (A2A) work championed by Google. These are turning into the default way agents discover and call tools across vendors. Within twelve months I expect to see RFPs from regulated industries that list "MCP support" and "agent identity controls" the way they list SSO and SCIM today.
What an agent control plane actually does</h2>
When you deploy agents at scale, you face five questions that no spreadsheet or wiki can answer for long:
Who built this agent? Inventory. Owner. Purpose. Date deployed. Last reviewed.
What can it access? Data sources, customer records, internal documents, third-party APIs. Permissions need to be inherited from human identity, not assumed.
What can it do? Which tools it can call. Which actions are reversible and which are not. Which require human approval.
What budget can it spend? Token limits per task, per day, per month. Hard caps before the bill arrives, not after.
What did it do? A decision log. Which prompt, which tools, which outputs, which approvals. Reproducible, auditable, exportable.
These are the same five questions IAM answers for human identity, FinOps answers for cloud cost, and observability answers for production systems. The reason every major vendor is building this layer now is that agents collapse all three problems into one new stack.
An agent control plane is what IAM, FinOps, and APM became when they merged.
Lakhani, Spataro and Stave framed this shift in Harvard Business Review more directly than most vendors will: "agents should be treated as a managed workforce rather than a collection of software scripts." Once you accept that framing, the questions get easier. You already know how to onboard, evaluate, monitor, and offboard a workforce. The new task is doing it for software.
The reality check on urgency</h2>
The situation is less urgent than the vendor messaging suggests. Gartner's April Hype Cycle placed agentic AI at the Peak of Inflated Expectations and noted that only 17% of organisations had actually deployed AI agents in production. More than 60% expect to within two years, but expectation and reality are different animals.
The point is not that you need an agent control plane today. The point is that the window between "we don't have agents" and "we have agents we can't account for" is going to be about six months. That's how long it took most companies to move from "we have one AWS account" to "we have no idea how many AWS accounts we have." Agents will move faster because they're easier to spin up and harder to see.
Why this matters now</h2>
There's a specific moment where this becomes urgent, and most companies miss it.
It's not when you deploy your first agent. It's when your third department deploys an agent without telling the second one. Customer support has a triage agent. Legal has a contract review agent. Finance has a reconciliation agent. They were built by three different teams, with three different vendors, on three different model providers, with three different definitions of "approved data access." Nobody owns the cross-cutting view.
I have seen this play out twice already, on smaller scales. In one business, a customer success team had built a perfectly reasonable agent to summarise account notes before renewal calls. Around the same time, a separate operations team had built an agent that wrote into the same CRM records. Neither team knew about the other. When the renewal agent's summary started including content the operations agent had written automatically, the business spent a week working out whether the resulting renewal note had been generated, edited, or invented. The answer existed somewhere in the logs. Nobody owned the logs.
That moment usually arrives between deployment numbers four and eight. After that, retrofitting governance is roughly twice as expensive as building it in. I've watched the same cost curve in cloud, in containers, in microservices, and in data pipelines. It's identical every time.
What I'd do in your position</h2>
If you're the CTO, COO, or head of operations at a company that has deployed more than one agent, or is about to, I'd do four things in the next quarter:
Build the inventory first. Not the platform, the inventory. A simple register of every agent in production or in pilot: owner, purpose, data access, model, monthly cost. You will be surprised by what you find. Most leaders are.
Define your agent development lifecycle. Treat agents like production systems, because they are. Requirements, tool contracts, data contracts, evaluations, red-team tests, permission reviews, simulation, rollout, monitoring, rollback, incident management, audit. Most of these already exist for your software. You need to extend them, not invent them.
Pick the control plane after you understand the requirements. The vendor space is moving weekly. Microsoft, Google, Salesforce, IBM, and a dozen smaller players will all claim to solve this. The right answer depends on where your data already lives and which agents you already run. Don't buy the platform first and shape your operating model around the vendor.
Test the kill switch. Every agent in production needs an off button. Not a "we'll figure it out" off button. A documented, owner-on-call, actually-tested off button. Pick a Tuesday morning and run a drill: shut the agent down, observe what breaks downstream, time how long it takes to recover. This is the single fastest way to expose which agents are genuinely understood by their owners and which are running on hope.
The board-level reframe</h2>
For boards and PE-backed leadership teams, the simplest reframe is this: agents are software that takes actions on your behalf, using your data, spending your money, and creating audit trails you may not own. The governance you would demand for any other system that did all four of those things should apply here.
This is not a reason to slow down agent adoption. It's a reason to build the inventory and the lifecycle now, while you have three agents instead of thirty. The companies that lead on this in 2026 will look like the companies that built proper cloud governance in 2015. The ones that don't will look like the ones still cleaning up cloud waste a decade later.
If you'd like to talk through what an agent inventory or lifecycle would look like in your business, get in touch</a>. I've built governance frameworks alongside production AI systems at NHS Wales</a> and in regulated insurance</a>, where the audit bar is high and the cost of getting it wrong is higher.

Related: Who is accountable for AI on your board?</a> · Shadow AI is your next audit finding</a> · Agentic AI in 2026. What actually works</a> · The AI Transformation Sprint</a>

Headless is the new mobile-first. Agents are about to become your biggest user

2026-05-09T00:00:00+00:00

Here is a question worth asking your product team this week. What percentage of your software's use, twelve months from now, will involve a human looking at a screen?
If the honest answer is anything less than 80%, your product has the wrong shape.
In April, four companies that sit at very different parts of the software stack said the same thing. Box CEO Aaron Levie posted that as agents become the biggest users of software, software has to be available in headless form because agents will talk to APIs, not click through UIs. Zapier CEO Wade Foster told an Axios audience that agents are likely to become the predominant users of software. Salesforce shipped "Headless 360," with cofounder Parker Harris framing the provocation directly: why should a user need to log into Salesforce at all when an agent can act through APIs and tools? Stripe, Mastercard and OpenAI quietly built the rails for agents to make purchases on a user's behalf.
This is not a niche prediction. The next generation of users is software, not people, and the software you built for clicks is now being asked to serve callers.
What "the wrong shape" actually means</h2>
For the last fifteen years, most B2B products have been built around the same loop: a user logs in, navigates a UI, takes an action, sees a confirmation. Roadmaps optimised that loop. Designers shortened the click path. Product managers measured engagement, session length, retention.
Agents do not log in. They do not navigate. They do not see the confirmation toast. They call an endpoint, pass parameters, parse the response, and move on. Most products, including most of the SaaS your business pays for today, were not designed for that. The API exists for integrations, but it covers maybe 30% of what the UI can do. The auth model assumes a human at a keyboard. The error messages are written for users, not callers. The pricing model charges for seats that nobody is sitting in.
I learned how big this gap is the hard way. A few months ago I wired an agent into a well-known mid-market SaaS product on behalf of a client. The marketing pages promised a "complete API." The reality was that two of the four actions we needed were UI-only. The vendor's answer was to use browser automation. That is the 2026 equivalent of telling someone to fax their tax return. The product wasn't bad. It was simply built for a world where the user had hands.
Salesforce's Headless 360 announcement is the clearest signal of where this is going. More than 60 MCP tools and 30+ coding skills exposed for Claude Code, Cursor, Codex, Windsurf, and others. The promise is that anything you can do in the UI, you can do through an API, an MCP call, or a CLI command. Salesforce is the largest enterprise software company in the world. If they are doing this, every serious B2B platform will follow within eighteen months.
The three layers your product now needs</h2>
The shift is not "add an API." Most products already have one. The shift is that you now need to design for three different consumers of your product, and treat all three as first-class.
The human layer. The traditional UI. Still essential, still where decisions get made and judgment lives. But it is no longer the only interface, and probably not the dominant one for routine work.
The agent layer. A complete, agent-addressable surface. Every meaningful action in your product needs to be reachable through an API, MCP tool, or CLI command. Schemas need to be machine-readable. Errors need to be parseable. Permissions need to be inherited from the human the agent is acting for. This is where Salesforce, Microsoft, and a growing number of vertical SaaS players are investing right now.
The governance layer. This is the one most teams haven't started thinking about, and it's the most interesting. When an agent is about to act on a user's behalf, the user needs a preview of what it plans to do, a confirmation flow for irreversible actions, and a clear log of what happened. The governance layer is the human in the loop, surfaced as a product feature, not buried in admin settings.
Three layers. One product. Most teams are still building one.
The pricing question this forces</h2>
If the agent becomes a user, what do you charge? Per-seat pricing assumed a human consumed the licence. An agent might do the work of fifty seats while occupying zero. Microsoft has already started shifting Dynamics customers to a mix of seats plus consumption credits, with around 60% of Dynamics service customers now buying usage-based credits. Microsoft also moved GitHub Copilot to usage-based pricing, explicitly aligning what they charge with what the customer consumes.
This is not the death of seat-based pricing. It's the start of hybrid pricing, where seats cover platform access and consumption covers agent-driven work. The hard part, and where I'd be spending CFO time right now if I were on your board, is protecting gross margin when agent usage can spike unpredictably. SaaS economics assumed flat-rate consumption per seat. Agents break that assumption.
The practical answer is simple to state and hard to implement. If you don't have a unit of work in your product that you can measure and charge for (a resolution, a workflow completed, a document processed, a lead qualified), build one before your competitors do. Once your competitor is charging per outcome and you are charging per seat, the comparison gets very uncomfortable very quickly.
The mobile-first analogy is exact</h2>
In 2010, every software company had a website that worked beautifully on a 1280-pixel monitor and barely worked on a phone. Then mobile traffic crossed a threshold, and the companies that hadn't rebuilt for touch, latency, and a smaller viewport spent the next five years losing ground to ones that had. The phrase "mobile-first" became shorthand for "rebuild your product around how people actually use it."
We are about to repeat that, with agents. The companies that get there first will look the way responsive-design pioneers looked in 2013. The companies that wait will rebuild under duress with their customers already comparing them to a faster competitor.
The good news is that the work is more tractable than mobile was. You don't need to redesign for a new viewport. You need to expose what already exists, structure it for machine readers, and add a governance layer most users will value even when they're using your product directly.
What I'd do in your position</h2>
If you run a B2B product, I'd put four things on the next quarterly roadmap:
Audit your API coverage. Map every meaningful user action in your product. For each one, mark whether it is reachable through your API. The honest number is rarely above 40% for products older than five years. That gap is your roadmap.
Build an MCP surface. Don't rebuild your API, wrap it. MCP is the emerging standard for how agents discover and use tools, and the integration cost is low compared to the strategic optionality it buys you. Start with the five actions agents would most plausibly want to take in your product.
Design the preview and approval flows. What does it look like when an agent is about to act inside your product? Where does the user see it? How do they cancel? How do they review what happened? This is product design work, and it is currently being skipped by every team I look at.
Pick a unit of work to charge for. Resolutions, workflows completed, documents processed, leads qualified, transactions executed. Agents make per-seat pricing leak value. The companies that figure out the right unit early will protect margin. The ones that don't will find themselves negotiating discounts against unbounded usage.
The board reframe</h2>
For founders and operators reading this, the simplest reframe is: your competitive moat for the next decade depends on how many of your users are software. If the answer is "almost none," your product is being designed for a market that is shrinking relative to the one being built for agents. If the answer is "more than we expected," you are early to a shift that most of your competitors are still treating as marketing language.
Headless software is not a feature. It is a posture toward where computing is going. The shape of your product is the most strategic decision you'll make this year, and the window to make it is shorter than the time it took most of you to ship a mobile app.
If you'd like to talk through what an agent-addressable product surface would look like for your business, get in touch</a>. I've spent the last decade building production AI systems and the platforms underneath them, including the agentic insurance automation work</a> where the customer's agent had to call our system, not the other way around. The patterns travel.

Related: Agent sprawl is the new shadow IT</a> · Agentic AI in 2026. What actually works</a> · The orchestrator, not the 10x engineer</a>

Uber burned through its token budget by April. Your business will be next

2026-05-02T00:00:00+00:00

In an April interview with The Verge, Uber's CEO Dara Khosrowshahi admitted, almost as an aside, that the company's CTO had told him they had burned through their token budget by early April. The interview was about hiring, software-team structure, and how AI was reshaping the relationship between product managers, designers, and engineers. The token budget line was a throwaway. It shouldn't have been. It was the most important sentence in the conversation.
Uber is not a company that runs out of money in April by accident. They have one of the most sophisticated cloud finance functions in tech. If their AI spend caught them by surprise, yours will too.
Token spend is becoming a P&L conversation, and most organisations are still treating it like an experiments line.
The cloud FinOps curve, replayed at speed</h2>
I have watched this exact pattern before. In 2014, every CFO I worked with was discovering that "cloud is cheaper than on-prem" was only true for a few specific workloads. The bill kept growing. Engineering teams spun up environments and forgot about them. Data egress charges arrived without warning. Reserved instances were bought and never used. The discipline we now call FinOps emerged because the pain became too obvious to ignore.
That curve took the industry roughly a decade to flatten. Cloud Foundation, AWS Cost Explorer, GCP billing alerts, Spot.io, CloudHealth, the FinOps Foundation, dedicated FinOps engineers in every serious cloud-native business. Ten years of work to turn cloud spend from "scary line item" to "managed discipline."
Token spend will not get a decade. It's already moving faster, for three reasons.
Spend is far less predictable. A single coding agent on a long-running task can consume more tokens in an afternoon than a customer-support workflow uses in a month. A poorly tuned prompt can ten-x cost overnight. The variance between similar tasks is wild compared to the variance between similar EC2 instances.
Model choice changes economics by orders of magnitude. Routing a task to the wrong model can be 30x more expensive than routing it correctly. Most teams have no routing strategy. They picked one model in a proof-of-concept and never revisited the decision.
Caching, batching, and prompt design are not yet boardroom vocabulary. A team that knows how to use prompt caching, batch APIs, and disciplined prompt design will spend a fraction of what an undisciplined team spends for the same outcome. This is a skill that exists in maybe 5% of engineering organisations today.
Anthropic's own positioning of Claude Code for Enterprise tells you where the market is going. The product page emphasises contribution metrics, token usage, cost monitoring through OpenTelemetry, centrally managed permissions, file-access restrictions, and per-team observability. Those are not features for hobbyists. They are features for organisations that are about to learn what their AI spend really is.
Workflows are cheaper than agents</h2>
There is a specific insight from Zapier's Wade Foster that more leaders should hear. He has been saying for months that agents are less reliable and more expensive than deterministic workflows, so leaders should use workflows where reliability and cost matter, and reserve agents for ambiguity, recovery, and creation.
This is the most important practical FinOps lever your engineering organisation has, and almost nobody is using it.
Most teams default to "build an agent" when the actual problem is "automate a known sequence of steps." A deterministic workflow runs in milliseconds at near-zero variable cost. An agent runs in seconds, sometimes minutes, at meaningful per-task cost, with non-zero failure rates and the occasional spectacular blowup. The cost difference between these two approaches, applied across an enterprise, is the difference between AI being a margin builder and AI being the new shadow line item that ate the budget.
I have built both. On one recent engagement, the team had built an agent to triage incoming documents, classify them, and route them. Six months in, it was costing roughly fifty times what the same triage would have cost as a deterministic pipeline using a small classifier model and a few rules. The agent was more flexible, yes. The flexibility was being used about 4% of the time. The other 96% was a known sequence of steps being run through the most expensive possible machine.
The right architecture is almost always workflows where the path is known, agents where it isn't. Most teams are doing the opposite because agents are newer and more interesting to build.
What a CFO actually needs by Q3</h2>
If you are the CFO, COO, or finance lead of an organisation that runs more than a handful of AI use cases in production, there is a specific operating discipline you need before the end of this quarter. I'd put four things in place.
Per-team token budgets, with hard caps. Same model as cloud spend. Each team gets a monthly allowance, denominated in dollars or tokens, with alerts at 50%, 80%, and 100%. The cap is enforced at the API layer, not in a wiki. If a team needs more, they ask. This is the single highest-impact move you can make this year.
Unit economics per workflow. For every AI-driven workflow in production, you should know its cost per execution. Cost per resolved support ticket. Cost per generated report. Cost per closed code review. Without this number, you cannot make any honest decision about whether the AI workflow is profitable. With it, you can compare variants, justify investment, and spot regressions.
A model routing policy. Most organisations are still defaulting to the most capable model for every task. That is genuinely expensive. A simple extraction task can cost 30x more on a frontier model than on a small one fine-tuned for the job. A routing layer that sends simple tasks to smaller models, harder tasks to larger ones, and routine extractions to cached responses can cut spend by 50% to 80% with no perceptible quality loss. The engineering effort is small. The financial impact is enormous.
Observability that includes cost, not just performance. OpenTelemetry, Honeycomb, Datadog and most major observability platforms now expose AI cost telemetry. If your engineering teams can see latency and error rate but not cost-per-call, they cannot optimise the third dimension. Show them the bill.
The board reframe</h2>
For boards and investors reading this, the simplest question to ask the next executive who presents an AI strategy is: "What is your monthly token spend, and what controls do you have on it?" If the answer is "we're tracking it," the answer is no.
Token spend will follow the cloud spend curve, except the slope is steeper, the volatility is higher, and the lessons that took a decade to learn the first time are available for free in the second. There is no reason to repeat the mistake at a faster cadence. The companies that build AI FinOps discipline in 2026 will look like the companies that built cloud FinOps in 2018. The ones that don't will look like the ones still arguing over reserved instance utilisation in 2024.
If you'd like to talk through what an AI FinOps function would look like in your business, get in touch</a>. I've sat on both sides of this conversation. Engineering teams that built it well and finance teams that wished engineering had built it sooner.

Related: Why most AI spend doesn't show up in the numbers</a> · Agent sprawl is the new shadow IT</a> · How to unlock AI ROI: what the 20% do differently</a>

Stop counting AI use cases. Redesign three value streams instead

2026-04-25T00:00:00+00:00

I sat through an AI strategy review with a leadership team last month where the head of transformation opened the deck with a slide titled "AI Use Cases In Production." There were 47 of them. Customer service summarisation. Sales call coaching. Marketing copy generation. Code completion. Document classification. Meeting minutes. Onboarding assistants. The list filled the screen in 9-point font.
I asked one question. "What's the EBIT impact?"
The room went quiet, because the answer was: nobody had computed it. The use cases existed. The value didn't. And yet the value was right there to be unlocked, sitting in the same processes, waiting for someone to redesign the stream instead of decorating its steps.
This is the new shape of AI theatre. I called the previous shape performance art</a> three months ago. That piece was about pilots that never reach production. This one is about pilots that do reach production and still produce nothing on the P&L.
The trap has moved from pilot purgatory to use-case purgatory. Counting deployed assistants is the new measuring of pilot velocity.
Why use-case counting persists</h2>
I understand why this keeps happening. Use cases are easy to count. They are easy to put on a board slide. They give a head of transformation something concrete to point at when the CEO asks "what are we doing with AI?" Forty-seven is more impressive than four. Activity is easier to measure than outcome.
There's also a procurement reason. Most enterprise AI platforms are sold on use-case breadth. Vendors love to show a tile-grid of pre-built assistants because it makes the platform look comprehensive. The customer side answers in kind by deploying as many tiles as possible. Both sides are optimising for the wrong thing.
The result is what I keep seeing in mid-market and PE-backed businesses: a portfolio of small productivity improvements, none of which is large enough to move a business metric, all of which add to the AI budget. Twelve months in, the conversation with the CFO becomes uncomfortable. The honest answer is "I cannot draw a line from any of these to revenue, cost, or risk."
Lakhani, Spataro and Stave coined a useful phrase for this in a March 2026 Harvard Business Review piece. They called it being "pilot-rich but transformation-poor." That is exactly the shape of the problem. Hundreds of working pilots, none of which has changed how the business operates.
The Krishna reframe</h2>
At IBM Think 2026 earlier this month, Arvind Krishna put the alternative more directly than I have heard a major-vendor CEO put it: the enterprises pulling ahead are not deploying more AI, they are redesigning how the business operates. IBM positioned the AI operating model around agents, data, automation, and hybrid governance, and framed the shift as "from improving parts of the business to changing how the business operates."
That is not the same statement as "deploy more AI." It is the opposite statement. ServiceNow's Bill McDermott has been making the same point in different words. AI value comes from auditable execution across workflows, data, policy, CRM, HR, security, and IT, not from disconnected assistants sitting alongside human work.
The HBR authors put the same point in a single line that should be printed on the wall of every transformation office: when you drop AI into one step of a process you have not redesigned, "the bottleneck simply shifts." Their example is an agent that drafts a complex contract in seconds, only to have the contract sit in a manual legal review queue for two weeks. The pilot worked. The cycle time did not change. The business did not get faster.
The point is that AI's economic impact does not live in the assistant in the middle of a process. It lives in the redesign of the process itself.
What "value stream" actually means</h2>
A value stream is the end-to-end sequence of steps that delivers a specific outcome the business cares about. It usually crosses multiple teams, multiple systems, and multiple decision points. The interesting metric for a value stream is throughput, cycle time, error rate, cost per unit, or customer impact, not the number of tools used inside it.
Examples of value streams worth redesigning:
Customer support resolution. From inbound contact to closed ticket. Measured in time to first response, time to resolution, customer effort score, cost per resolution.
Sales lead to revenue. From inbound lead to closed deal. Measured in conversion rate at each stage, sales cycle time, cost of customer acquisition.
Month-end financial close. From period end to signed-off financial statements. Measured in days to close, manual adjustments, audit findings.
Underwriting or claims processing. From application to decision. Measured in straight-through processing rate, cycle time, loss ratio.
Engineering migration. From legacy system to modern stack. Measured in throughput, defect escape rate, cost per migrated component.
Each of these is a candidate for end-to-end redesign with AI in the middle, agents at decision points, workflows at routine steps, and human judgment at exceptions. The metric for success is not "we deployed an AI assistant in step 4." It is "this value stream now operates at half the cycle time and a third of the cost."
The Microsoft data the room missed</h2>
Microsoft's 5 May Work Trend Index reported a finding that should be on every transformation lead's desk. Organisational factors, including culture, manager support, and talent systems, accounted for more than twice the perceived AI impact of individual factors. The same Copilot deployment, in two organisations, produces wildly different outcomes depending on how the work itself is structured.
This is why use-case counting fails. You can deploy an excellent meeting summary assistant in two companies. In the first, where meetings are already overprescribed and follow-through is weak, the assistant generates more meeting noise. In the second, where meetings are tightly run and decisions are tracked, the assistant compresses cycle time. Same tool, opposite outcomes, because the surrounding operating model is different.
Use cases live in tools. Value lives in operating models. You cannot use-case your way to a redesign.
How to pick three value streams</h2>
If you are leading AI strategy at a mid-market or PE-backed business, I'd kill the use-case inventory and run a different exercise. Take it to your leadership team in the next month.
Map your top eight value streams. Not eighty. Eight. The ones that, if you compressed cycle time by 30% or reduced unit cost by 20%, would move the business in a way the board would notice.
Pick three. Use three criteria: measurable economic impact, achievable within 6 to 12 months, and a sponsor with real authority. The third criterion is the one most exercises skip. A value stream without an empowered owner becomes another deck.
Commit to redesign, not augmentation. The temptation is to bolt AI onto the existing process. Don't. Map the current process, identify which steps can be eliminated, which can be automated end-to-end, which need a human decision, and which can be combined. Then design the future state, with AI in the middle, and migrate.
Measure outcomes, not adoption. The metrics are cycle time, unit cost, throughput, quality, customer satisfaction. Not seats licensed. Not assistants deployed. Not prompts entered. Hold the leadership team to those metrics quarterly.
Tell the rest of the business to wait. This is the hardest part. Every other team will want their own AI use case. The answer for the next year is "we are concentrating effort on three streams, we will share what we learn." A focused redesign of three value streams will produce more EBIT impact than fifty deployed assistants. I have watched this in both directions.
The board reframe</h2>
For boards and investors reading this, the simplest test of an AI strategy is: name the three value streams you are redesigning, and the metrics you'll be measured against in 12 months. If the answer is a list of deployed tools, you don't have a strategy. You have a procurement plan with AI in the title.
The companies pulling ahead in 2026 are not the ones with the longest use-case inventory. They are the ones who picked three things and rebuilt them properly. The operating model is the moat. The use cases are the marketing.
If you'd like to talk through which value streams in your business would benefit most from end-to-end redesign, get in touch</a>. I've helped leadership teams pick the right three more than once, and it is almost always not the three they would have chosen alone.

Related: Turning AI theatre into AI that moves the numbers</a> · How to unlock AI ROI: what the 20% do differently</a> · The dual-stream strategy</a>

75% of Google's new code is AI-generated. So what?

2026-04-18T00:00:00+00:00

At Google Cloud Next 2026, Sundar Pichai announced that 75% of Google's new code is now AI-generated and approved by engineers, up from 50% last autumn. The number was repeated by every AI newsletter, every industry analyst, and a quarter of the LinkedIn posts I saw that week.
Here is the inconvenient question almost nobody asked. So what?
What does that number actually tell you about Google's engineering output? Does it ship more product? Does the product have fewer defects? Is the customer experience better? Did the engineering organisation get cheaper to operate, or more expensive? Is morale up or down? Are good engineers staying or leaving?
The 75% number does not answer any of those questions. It is a measurement of inputs, presented as if it were a measurement of outcomes. And it is about to become the most reported, least useful metric in enterprise engineering.
Why this metric is irresistible to executives</h2>
I understand the appeal. AI-generated code percentage is a single number that goes up over time, sounds impressive on an earnings call, and feels like progress. CFOs and boards have been waiting for someone to give them a quantified answer to "is the AI investment working?" Engineering leaders, sensing the pressure, are happy to provide one.
The trouble is that this number measures the activity, not the value. It is the engineering equivalent of measuring sales effectiveness by counting how many emails the team sent. There is a correlation, on average, between effort and outcome. There is not a useful one between AI-generated lines and shipped value.
I have already seen this metric inverted in real organisations. A team I worked with reported that 80% of their merged code was AI-generated, and used it to justify a larger AI tooling budget. When I looked at their actual delivery metrics, cycle time had increased. Defect escape rate had doubled. The team was generating more code, merging more PRs, and producing more bugs, all of which were now arriving faster. The percentage was up. The product was getting worse.
What's actually changing in the SDLC</h2>
The interesting shift over the last year is not how much code is being written. It is how engineering work itself is being reshaped. Coding agents are taking over routine implementation, but they are also reshaping requirements, design, code review, testing, migration, deployment, and incident response. The whole software development lifecycle is being rewired, not just the typing.
OpenAI's enterprise update said Codex hit 3 million weekly active users and that customers including GitHub, Nextdoor, Notion, and Wonderful are building multi-agent systems that execute engineering work end-to-end. Microsoft reported roughly 140,000 organisations using GitHub Copilot, with enterprise subscribers nearly tripling year on year. Anthropic positioned Claude Code for Enterprise as a coding agent that writes, debugs, refactors, creates tests, opens PRs, and works across terminal, IDE, Slack, and web, with enterprise controls including permissions, OpenTelemetry monitoring, token visibility, SSO, SCIM, and audit. Salesforce went further, exposing 60+ MCP tools and 30+ coding skills through Headless 360, claiming up to 40% cycle time reduction through their DevOps Center MCP.
If you read those announcements carefully, the language has shifted. Vendors are no longer selling "AI that writes code faster." They are selling auditable agents that execute engineering work with controls. The metric the vendors themselves are now optimising for is not "lines generated." It is "engineering work completed safely."
That is the metric the board should be asking for.
The five questions to bring to your next board meeting</h2>
If you sit on a board, run a PE-backed business, or chair an audit committee where engineering reports up, these are the five questions to ask your CTO about AI in engineering. They cost nothing to ask. They reveal a great deal.
What is your release frequency, and how has it changed? How often does code reach production? Daily, weekly, monthly? Has it accelerated since AI tools were rolled out, or stayed flat? The companies that get real value from AI in engineering ship more often, not just produce more code.
What is your defect escape rate? What percentage of bugs reach production before being caught? If this number is rising in step with AI-generated code, you are paying for velocity in customer pain. This is the number to watch most carefully.
What is the PR review latency? When code is written, how long does it sit waiting for a human to review and merge it? AI-generated code can pile up faster than reviewers can handle. The cycle time of code reaching production depends on review, not on writing.
What is the cost per accepted change? Add up the cost of AI tools, developer time, review time, testing, and incident remediation, then divide by the number of changes that successfully reach production. This is the most honest unit economics you can put on engineering AI. It should be going down. In poorly managed deployments, it goes up.
What is the mean time to recovery? When something breaks, how fast does the team detect it, diagnose it, and recover? AI tools can both help and hurt this. Help, by suggesting fixes faster. Hurt, by introducing changes the team did not write and does not fully understand.
These five questions are not exhaustive. They are the minimum set. None of them includes "what percentage of code is AI-generated," because that number does not appear in any of them.
The migration metric is the one to lead with</h2>
If I were a CTO going to a board with one number to demonstrate engineering value from AI, it would not be code-generation percentage. It would be migration throughput.
Legacy system migration is a real cost in most established businesses. It is also the workload where AI agents are showing the largest, most measurable gains. Google reported that a complex internal migration was completed six times faster with agents and engineers working together. Anthropic's Claude Code Enterprise materials emphasise migration as one of the highest-value workloads. I have seen the same in my own work. Migration is the workload where the new tools produce orders-of-magnitude improvement, not single-digit ones.
If your engineering organisation can clear a 2-year migration backlog in 4 months, that is a board-relevant outcome. The percentage of code written by AI in the process is a footnote.
What I'd tell your CTO</h2>
If I were sitting across the table from your CTO this quarter, my advice would be:
Stop reporting AI-generated code percentages upward. It will land well in the first board meeting and badly in the third, when someone realises the number is rising and the product is not getting noticeably better.
Pick one engineering value stream and rebuild it with AI in the middle. Migration is the obvious choice. Security remediation is another (Google reported 90%+ mitigation time reduction in some workflows). PR review is a third. Pick one, redesign it, measure throughput and quality.
Make the metrics changes visible across the organisation. Cycle time, defect escape rate, review latency, cost per accepted change, MTTR. Put them on a dashboard. Show them at every engineering review. The team will optimise for what gets measured. Right now, most teams are not measuring the right things.
Spend the saved engineering time on the work that humans still do best. Hard problem decomposition, system architecture, code review at the level of taste, mentoring, judgment under uncertainty. The engineers who become valuable in 2027 are the ones who orchestrate well. I wrote about this last month in orchestrator, not 10x engineer</a>.
The board reframe</h2>
For boards reading this, the simple test is: when your CTO talks about AI in engineering, do they lead with effort metrics or outcome metrics? If the lead number is "% of code AI-generated," you are getting an activity report. If the lead number is "release frequency up, defect rate down, migration throughput tripled, cost per accepted change halved," you are getting a value report.
The companies winning the engineering productivity race in 2026 are not the ones with the highest AI-generated code percentage. They are the ones whose boards refuse to accept that number as the answer.
If you'd like to talk through what your engineering AI metrics should look like, or how to redesign one engineering value stream around agents, get in touch</a>. I've spent the last decade building engineering organisations that ship, and the last three years building them with AI in the middle.

Related: Has AI made developers slower? The METR study, reframed</a> · The orchestrator, not the 10x engineer</a> · What two hours with Anthropic's agent team taught me about building AI</a>

Most of what you do at work will be automated. The interesting question is what won't

2026-04-11T00:00:00+00:00

If it can be automated, it must be automated.
I mean that literally. Not as aspiration, but as economic inevitability. Every task that a machine can do faster, cheaper, and more consistently than a human will eventually be handed to a machine. This has been true since the spinning jenny. AI just compresses the timeline from decades to months.
The question that most leaders are asking, "Will AI take our jobs?", is the wrong question. It's too binary and too abstract. The better question is specific and strategic: what can only humans do, and how do we get better at it?
That's where the real competitive advantage lives. Not in resisting automation, but in ruthlessly embracing it so that your people can focus on the things that actually require a human mind.
What AI does better. Accept it and move on</h2>
Let's be honest about this, because denial wastes time.
AI is better than humans at processing large volumes of structured information. It's better at pattern matching across datasets too large for any person to hold in their head. It's better at maintaining consistency across thousands of decisions. It's better at operating at scale without fatigue, mood, or distraction.
McKinsey estimates that 60-70% of current work activities could be automated with existing technology. Not future technology. What exists today. The insurance brokerage I worked with</a> achieved 67% autonomous case resolution. Not because the technology was extraordinary, but because most of those cases genuinely didn't require human judgement. They required pattern matching, data retrieval, and rule application. Machines do all three better than people.
Here's the finding that should challenge any comfortable assumptions about human-AI collaboration. Stanford HAI's 2025 AI Index reported that in a healthcare diagnostic trial, GPT-4 alone achieved 92% accuracy. Physicians alone scored 74%. And physicians assisted by GPT-4 scored 76%. Adding humans to AI made it worse. Not better. Worse. The humans second-guessed correct AI diagnoses and introduced errors that the AI alone would not have made.
This is deeply counterintuitive. It's also a useful corrective. The comfortable narrative that humans will always add value "in the loop" needs qualifying. For many tasks, they don't. The human edge is real, but it's narrower than most people want to believe.
Pretending otherwise isn't loyalty to your workforce. It's a failure of leadership. The organisations that try to protect people from automation end up protecting them into irrelevance, doing work that machines do better while competitors pull ahead.
The irreducible human capabilities</h2>
So what's left? More than you might think. And it's the work that actually matters.
The Harvard Business School study with 758 BCG consultants mapped what they call the "jagged frontier" of AI capability. Consultants using GPT-4 completed 12% more tasks, 25% faster, with 40% higher quality, but only for tasks within the AI's capability frontier. For tasks outside the frontier, consultants using AI were 19% less likely to produce correct solutions. They trusted the AI when they shouldn't have. The best performers were the ones who knew exactly where the frontier was, and handled the other side themselves.
Strategic intent. Knowing what's worth doing</h3>
AI can optimise any objective function you give it. What it cannot do is decide which objective function matters. It can tell you the most efficient path to a goal. It cannot tell you whether the goal is worth pursuing.
This is not a small distinction. The most expensive mistakes in business aren't execution failures. They're strategic ones. Building the wrong product perfectly. Optimising the wrong metric efficiently. Scaling the wrong business model flawlessly.
I've seen AI projects fail not because the technology didn't work, but because nobody asked whether the problem was worth solving. The 80% failure rate in AI projects</a> isn't primarily a technical problem. It's a strategic one. Someone has to own the intent. Someone has to say, "This is worth doing" or, more importantly, "This is not worth doing." That someone is human.
Taste, judgement, and opinion</h3>
Here's something that doesn't get discussed enough in the AI conversation. Taste matters.
Not aesthetic taste, though that too. Business taste. The intuition that comes from twenty years of experience in an industry. The ability to look at a proposal and know, before the data confirms it, that something is off. The judgement to say "this is technically correct but strategically wrong."
AI has no opinions. It has outputs calibrated to probability distributions. It will give you the statistically most likely answer, which is often the most mediocre one. The organisations deploying AI well</a> aren't the ones deferring to AI outputs. They're the ones whose leaders have strong enough judgement to know when the AI is right and when it's confidently wrong.
Block's CTO Dhanji Prasanna said it well: code quality has "nothing to do" with product success. YouTube triumphed despite "terrible" code. The decisions that matter are about what to build, not how to build it. That's taste. That's judgement. And no model currently possesses it.
I've built products where the data pointed one way and experience pointed another. Experience was right more often than most data scientists would like to admit. Not because data doesn't matter, but because data only tells you what happened. Judgement tells you what it means.
Lakhani, Spataro and Stave warned about this in HBR. A relentless focus on efficiency, they argue, "risks hollowing out the human capabilities, such as judgment and storytelling, that differentiate high-value work." The organisations that treat AI purely as a cost-reduction tool tend to lose the capacity to do the work AI cannot do.
Human-to-human relationships</h3>
No amount of AI sophistication replaces the trust that forms between people who have worked through difficult problems together. A client doesn't hire me because an algorithm recommended me. They hire me because a conversation revealed that I understood their situation in a way that felt different from the others.
This isn't sentiment. It's economics. B2B sales cycles, board decisions, partnership formations, key hires. The transactions that shape organisations happen between humans who trust each other. AI can prepare the analysis. It can surface the options. It can draft the presentation. But the moment where someone decides to commit resources, take a risk, or change direction, that moment is human.
The shift from individual contributor to orchestrator</a> makes this more important, not less. As AI handles more of the technical execution, the human skills of communication, persuasion, and relationship become a larger proportion of what determines success.
Ethical reasoning and contextual wisdom</h3>
AI systems optimise. That's what they do. They find the path of least resistance to whatever objective you've defined. They don't ask whether the objective is ethical. They don't consider second-order consequences on people who aren't represented in the training data. They don't feel uncomfortable when something is technically legal but plainly wrong.
Every organisation I've worked with has faced decisions where the right answer wasn't the most efficient one. Where serving a customer well meant absorbing a cost. Where doing the ethical thing meant leaving money on the table. These decisions require a kind of contextual wisdom that comes from lived experience, from having been in situations where the "optimal" choice turned out to be the wrong one.
The governance questions around shadow AI</a> are a good example. An AI system will happily process sensitive data if you let it. Knowing when it shouldn't, and why, requires human judgement about risk, reputation, and responsibility that no model currently possesses.
The strategic argument. Offload everything else</h2>
If these are the irreducible human capabilities, the strategic implication is clear: automate everything that isn't on this list.
Not gradually. Not cautiously. Aggressively.
Every hour your best people spend on work that a machine could do is an hour they're not spending on strategic thinking, relationship building, or the kind of difficult judgement calls that actually determine your organisation's trajectory. It's not just wasteful. It's competitively dangerous.
The dual-stream approach</a> I advocate is exactly this: run two tracks simultaneously. On one track, automate every process that can be automated. On the other, deliberately invest in developing the human capabilities that machines cannot replicate. The organisations that do both will outperform those that do either one alone.
This means restructuring roles, not eliminating them. It means telling your team: "We're going to take away the parts of your job that a machine does better, and we're going to expect you to become exceptional at the parts only you can do." That's a harder conversation than "AI is coming for your jobs," but it's a more honest and more productive one.
The "for now" problem</h2>
I want to be honest about something. The human edge is shrinking.
Five years ago, I would have included creative writing on the list of irreducible human capabilities. Today, AI produces competent prose that passes most quality bars. Three years ago, I would have included basic code architecture. Today, agentic AI systems</a> are making architectural decisions that are, in many cases, good enough.
The boundary between "human only" and "machine capable" moves in one direction. It moves towards the machine. Slowly in some domains, startlingly fast in others. Anyone who tells you that strategic thinking, relationship building, and ethical judgement are permanently safe from automation is making a prediction about a technology whose trajectory they cannot know.
Ben Goertzel, CEO of SingularityNET, claims AI will surpass human strategic thinking "in about two years." I think he's probably wrong on the timeline, but I take the direction seriously. The WEF Future of Jobs Report identifies creative thinking, resilience, and curiosity as the fastest-rising skills employers value. These are the human edge skills. And yet a quieter risk is emerging in the data. Critical thinking is atrophying in teams that lean too hard on AI outputs. Junior staff who don't first form their own view before consulting the model lose, over time, the muscle that makes them a useful check on it. We may be losing the very capabilities that make us irreplaceable, even as we still hold them.
I don't think they're safe forever. I think they're safe now, and they'll be safe for long enough to matter strategically. The organisations that double down on developing these capabilities in their people will have a decisive advantage for the next five to ten years. And five to ten years of competitive advantage is, in business terms, an eternity.
The right response to a shrinking edge is not to pretend it isn't shrinking. It's to maximise the advantage while it exists. Play the hand you have, not the hand you wish you had or the hand you fear you'll be dealt.
What this means for you</h2>
If you lead an organisation, three things follow from this argument.
First, stop protecting people from automation. Every task you shield from AI because "it's always been done by humans" is a task where you're choosing nostalgia over competitiveness. Free your people to do the work that only they can do.
Second, invest in the human skills that matter. Strategic thinking, judgement, relationship building, ethical reasoning. These aren't soft skills. They're the hardest skills. And they're the ones your organisation's future depends on. When AI handles scale and speed, the bottleneck becomes human judgement: the precision of the questions you ask, the depth with which you interpret model reasoning, and your ability to turn AI-generated ideas into better decisions. Lakhani, Spataro and Stave put it more bluntly in a recent Harvard Business Review piece: "the AI last mile is not blocked by technology. It is blocked by unresolved questions regarding operating models, governance, and human identity." Treat these skills with the same seriousness you treat technical capability.
Third, be honest about the timeline. The human edge is real, but it's not permanent. Build your strategy around it, but don't build your identity around it. Stay adaptive. The line will move again.
The most valuable people in any organisation have always been the ones who know what's worth doing, not just how to do it. AI hasn't changed that. If anything, it's made it more true than ever.
If you're working out where the human edge matters most in your organisation, get in touch</a>.
Related: You're not a 10x engineer. You're an orchestrator</a> · Most companies are adopting AI. Few are adopting it well</a> · Traditional moats are dissolving</a>

AI is not just for engineering. Every function in your business can use it today

2026-04-04T00:00:00+00:00

McKinsey's latest State of AI survey found that 88% of organisations now use AI in at least one business function. But only 6% qualify as "AI high performers" attributing more than 5% of EBIT to AI.
That gap, between using AI and benefiting from AI, is the real story. The technology is deployed everywhere. The value is concentrated in a few. And the reason is almost always the same: most companies treat AI as an engineering tool, not a business-wide operating system.
Every process in every business in every industry can be optimised with AI. I don't mean hypothetically. I mean right now, with tools that exist today, at a cost that makes the ROI obvious within weeks. Shopify CEO Tobi Lutke made the right call when he told his company that no one can request headcount without first proving AI cannot do the job. The burden of proof has flipped. It's no longer "why should we use AI?" It's "why aren't we?"
The engineering tunnel vision problem</h2>
Most companies that "do AI" are doing it in one place: software development. They've bought Copilot licences. Maybe they're experimenting with agentic coding tools. The engineering team is 6 months ahead of everyone else in the organisation.
Meanwhile, the finance team is still manually reconciling spreadsheets. Marketing is writing every piece of content from scratch. Customer support agents are copy-pasting the same responses they've been using for three years. Legal is reviewing contracts clause by clause.
Lakhani, Spataro and Stave described this same pattern in a March 2026 Harvard Business Review piece as "islands of productivity": tools that boost individual output but exist as isolated wins, difficult to convert into scaled, trustworthy enterprise systems. That phrase matches what I see almost everywhere. A high-performing engineering function. A back office that has barely changed in a decade.
This is a massive missed opportunity. The biggest AI gains I've seen are not in engineering. They're in operations, support, and back-office functions where the work is repetitive, the volume is high, and the cost of doing it manually is quietly enormous.
Function by function. What works today</h2>
Finance and accounting</h3>
AI is genuinely good at financial operations right now. Invoice processing, expense categorisation, anomaly detection in transactions, cash flow forecasting. These are not experimental use cases. They're production-ready.
IBM automated over 90% of their finance journal entries using watsonx Orchestrate. HPE uses intelligent agents to automate quarterly close, forecasting, and analysis. These aren't pilots. They're running in production at two of the largest technology companies in the world.
I've seen finance teams cut month-end close time by 40% using AI-assisted reconciliation. The tool doesn't replace the accountant. It does the tedious matching work and flags the exceptions that need human judgement. Fortune reports that CFOs are predicting AI will transform finance from retrospective reporting to real-time decision-making. The role is shifting from "what happened" to "what should we do."
What doesn't work yet: fully autonomous financial decision-making. AI can surface insights and flag anomalies, but anything involving judgement calls on material financial matters still needs a human. And it should.
Marketing and content</h3>
This is where the gap between what's possible and what most teams actually do is widest.
Most marketing teams using AI are generating first drafts of blog posts. That's fine, but it's about 10% of the value available. The real gains are in research, personalisation, and distribution. AI can analyse your entire content library and identify gaps. It can segment audiences and tailor messaging at a scale that would require a team of ten to do manually. It can A/B test subject lines, optimise send times, and identify which channels are converting for which segments.
HubSpot's 2025 State of Marketing report found that teams using AI across the full content lifecycle (research, creation, distribution, analysis) saw 3x the output with the same headcount. Not 3x the content. 3x the output measured by engagement and conversion.
What doesn't work yet: letting AI write your brand voice without heavy human editing. The tools produce competent copy. Competent is not enough. You still need a human who understands what makes your voice distinctive.
Sales</h3>
AI in sales is past the experimental phase. Lead scoring, call analysis, pipeline forecasting, proposal generation. These are all live use cases with proven ROI.
The most impactful application I've seen is AI-powered call analysis. Tools like Gong and Chorus analyse every sales conversation, identify what top performers do differently, and surface coaching opportunities for the rest of the team. One organisation I advised saw win rates increase 18% within a quarter after implementing structured call analysis with AI-generated coaching recommendations.
Proposal generation is another area where the ROI is immediate. A senior salesperson spending two hours crafting a custom proposal can get a strong first draft in fifteen minutes. That's not about replacing the salesperson. It's about freeing them to spend time on relationships and strategy instead of formatting documents.
What doesn't work yet: AI closing deals autonomously. Sales is fundamentally about trust between humans. AI makes salespeople more effective. It doesn't replace them.
Customer support</h3> This is where I have the most direct experience. The insurance brokerage case</a> I led achieved 67% autonomous case resolution with an agentic AI system. Not chatbot-style deflection. Genuine resolution: retrieving policy information, making coverage determinations, communicating outcomes to customers.
Klarna's experience is instructive. Their AI assistant handled 2.3 million conversations in its first month, equivalent to 700 full-time agents. The headlines were triumphant. Then quality problems forced them to reverse course and rehire humans. They ended up with a hybrid model that may actually be more effective than either pure approach. The lesson: AI can handle the volume, but you need humans for the edge cases that destroy customer trust when handled badly.
The key insight from my own work: customer support is the function where AI delivers the most measurable, immediate ROI in most organisations. The volume is high, the queries are repetitive, the cost per interaction is well understood, and the quality bar is definable. If you're only going to pick one function to start with, start here.
What doesn't work yet: handling emotionally complex or genuinely novel situations. The best systems know when to escalate. The worst ones try to handle everything and erode trust in the process.
Legal and contracts</h3>
Legal is the sleeper disruption story of 2026. Corporate AI adoption in legal more than doubled in a single year, from 23% to 52%, according to the ACC/Everlaw survey. 64% of in-house teams now expect less dependence on outside counsel. 61% are pushing for changes in how outside legal services are priced.
Tools like Luminance, Ironclad, and Thomson Reuters' CoCounsel can review standard commercial contracts in minutes, flagging non-standard clauses, missing provisions, and risk areas that a junior lawyer would take hours to identify. LexisNexis has deployed a four-agent system for legal research: orchestrator, legal research, web search, and customer document analysis.
I've seen legal teams reduce contract review time by 60-70% for standard agreements. The AI handles the first pass. The lawyer handles the judgement calls. This isn't about reducing legal headcount. It's about removing the bottleneck that legal review often creates in deal velocity.
What doesn't work yet: novel legal reasoning or complex regulatory interpretation. AI can tell you what a contract says. It can't yet reliably tell you what it means in the context of a specific business situation and regulatory environment.
Project management and reporting</h3>
This is the function where AI adoption is lowest and the opportunity is most underestimated.
AI can eliminate 80% of status reporting. It can pull data from Jira, Slack, GitHub, and your time-tracking tool, synthesise it into a coherent status update, flag risks based on velocity trends, and generate the weekly report that a project manager currently spends two hours compiling every Friday.
I've seen project leads reclaim an entire day per week by automating reporting and status synthesis. That's a day they can spend actually managing the project instead of describing it.
What doesn't work yet: AI project managers. Prioritisation, stakeholder management, and the ability to read a room when a project is going sideways. These remain distinctly human skills.
Internal communications</h3>
Meeting summarisation alone justifies AI investment for most organisations. If your company has more than 50 people, you're spending thousands of hours per year in meetings where half the attendees are there "just in case." AI meeting tools (Otter, Fireflies, Copilot in Teams) can record, transcribe, summarise, and extract action items. The people who didn't need to attend can read the summary in two minutes.
Beyond meetings: internal knowledge bases that actually answer questions, onboarding documentation that stays current, policy documents that can be queried rather than read. These are all production-ready use cases today.
The compounding effect</h2>
Here's what makes internal AI enablement a competitive advantage rather than just an efficiency play.
Each function you optimise with AI frees capacity. That capacity can be redirected to higher-value work, or it can allow you to grow operations without proportionally growing headcount. When you do this across five or six functions simultaneously, the effect compounds. You don't get 10% efficiency in each area. You get a fundamentally different cost structure.
The trap, as Lakhani, Spataro and Stave noted in Harvard Business Review, is that "saved time is often re-absorbed into low-value activities, like more internal meetings or unnecessary emails, rather than being structurally harvested." Capacity does not capture itself. Someone has to redesign the role, change the budget line, or shift the headcount allocation. Without that step, the AI investment shows up as a vendor bill and nothing else.
The roles most exposed are the reporting-heavy ones in the middle of the organisation: finance analysts whose primary output is monthly decks, compliance officers compiling regulatory submissions, supply chain planners building forecasts from spreadsheets, procurement managers drafting RFPs. The organisations moving fastest are not eliminating these roles wholesale. They are reallocating the people in them toward analytical, judgement-heavy, and creative work that AI cannot yet do well.
The organisations I work with that understand this are not just saving money. They're moving faster than competitors who are still running every function manually. And that gap widens every quarter.
The common mistakes</h2>
Even with the right intent, most organisations get internal AI enablement wrong in predictable ways.
Mistake one: starting everywhere at once. Pick one function. Get it working. Measure the results. Then expand. The 80% failure rate</a> applies to internal tools just as much as customer-facing ones.
Mistake two: no governance. When every department is buying its own AI tools, you get shadow AI</a> at scale. Sensitive data flowing to tools nobody approved. Duplicate spend. Inconsistent quality. Internal enablement needs a lightweight governance framework from day one.
Mistake three: expecting AI to fix broken processes. If your sales process is a mess, AI will make it a faster mess. The organisations that see real results redesign the workflow</a> before adding AI to it.
Mistake four: forgetting the humans. Every function-level AI deployment is a change management exercise. The finance team needs to trust the reconciliation tool. The legal team needs to believe the contract review is reliable. That trust is built through transparency, gradual rollout, and honest communication about what the tool does and doesn't do.
Where to start</h2>
If I were advising an organisation that hadn't yet done any cross-functional AI enablement, I'd tell them to pick the function with the highest volume of repetitive, well-defined work. For most companies, that's customer support or finance operations.
Run a focused pilot. Measure before and after. Be honest about what worked and what didn't. Then use that success (and those lessons) to build momentum for the next function.
The technology is ready. The tools are affordable. The ROI is measurable within a quarter, not a year. The only thing missing in most organisations is someone with enough authority and enough cross-functional understanding to see the full picture and connect the dots. That is not a technology problem. It is a leadership one</a>.

If you want to map where AI can create the most value inside your organisation, get in touch</a>.
Related: How to unlock AI ROI: what the 20% do differently</a> · Most companies are adopting AI. Few are adopting it well</a> · How I approach AI transformation</a>

Traditional moats are dissolving. Size and capital no longer protect you

2026-03-28T00:00:00+00:00

The most dangerous assumption in business right now is that being big makes you safe.
For decades, size was the ultimate competitive advantage. Deep pockets meant you could outspend competitors on R&D, hire the best talent, absorb regulatory costs, and outlast anyone who tried to disrupt you. Scale meant distribution. Distribution meant dominance. And dominance, once achieved, was very hard to undo.
That logic is breaking down. Fast.
The moat is leaking</h2>
Warren Buffett popularised the concept of economic moats: the structural advantages that protect a business from competition. Brand recognition. Proprietary data. Network effects. Regulatory capture. Economies of scale. These were the things that let incumbents sleep well at night.
AI is eroding every single one of them.
Brand recognition used to take decades and hundreds of millions in marketing spend to build. Today, a two-person team with a genuinely useful AI-powered product can reach millions of users in weeks through organic distribution. Perplexity went from zero to 100 million monthly queries in under two years. Not because they outspent Google. Because they built something that solved a problem better than the incumbent.
Proprietary data was once an unassailable advantage. You had the data, your competitors didn't, end of discussion. Now, foundation models trained on the open web give any startup access to reasoning capabilities that previously required a decade of data collection. The advantage has shifted from having data to knowing what to do with it. Those are very different capabilities.
Economies of scale meant that producing more was cheaper per unit, which meant incumbents could undercut any challenger. But when a team of five can build and deploy a product that previously required fifty, the cost curve inverts. The challenger isn't competing on your terms. They're operating on a fundamentally different cost structure.
Midjourney is the clearest example. Approximately 100 employees. $500 million in revenue. $10.5 billion valuation. No external funding. No sales team. No marketing department. Organic growth through Discord and social sharing. They built one of the most commercially successful AI products on the planet with a team smaller than most companies' marketing departments.
Sam Altman put it bluntly: "In my little group chat with my tech CEO friends there's this betting pool for the first year that there is a one-person billion-dollar company." That's not hyperbole. It's a direction of travel.
If you walk through the classic moat pillars one by one (switching costs, network effects, intangible assets, efficient scale, cost advantage) the only one that still clearly protects is the last. Physical cost advantage: factories, supply chains, mineral reserves, energy contracts. If your competitive advantage isn't bolted to the ground, AI is dissolving it.
The speed advantage is compounding</h2>
Here's what makes this different from previous waves of disruption.
Previous technology shifts, the internet, mobile, cloud, gave incumbents time to adapt. The transition from physical retail to e-commerce took fifteen years. The shift to mobile-first took a decade. Cloud migration is still happening twenty years after AWS launched.
AI is not giving anyone that kind of runway.
McKinsey's 2024 research found that organisations already using AI effectively are pulling ahead at an accelerating rate. The gap between AI leaders and laggards isn't closing. It's widening. Every quarter that an organisation delays meaningful AI deployment, the distance to the leaders grows, because the leaders are compounding their advantage. They're not just using AI. They're learning how to use AI better, building institutional knowledge that compounds over time.
I've seen this firsthand. One business I advised began embedding AI into its core operations roughly fifteen months ago. They are now operating on a different plane to a competitor with three times their headcount, who started six months ago and is still in pilot stage. The technology is no better today than it was for the early mover. The difference is fifteen months of compounded operational learning, model evaluations they've kept, prompts they've refined, workflows they've redesigned around AI from scratch. That institutional knowledge is the new moat. And you can't buy it. You can only build it.
Why incumbents struggle</h2>
If size no longer protects you, why don't large organisations just adopt AI faster?
Because the very things that made them dominant are now the things slowing them down.
Organisational complexity. A decision that takes a five-person startup an afternoon takes an enterprise six months. Procurement, legal review, security assessment, change management, stakeholder alignment, pilot programme, evaluation period, board approval, implementation. By the time the enterprise has approved the pilot, the startup has iterated through twelve versions of a production system.
Talent distribution. The people who are best at building with AI are disproportionately choosing to work at smaller companies or on their own. They want speed, autonomy, and direct impact. Enterprise bureaucracy is the opposite of what attracts them. Every founder I speak to who is hiring for production AI capability tells me the same thing: the best candidates are weighing offers from companies a tenth the size of the incumbent, and the smaller companies are winning more often than not. The talent is self-selecting away from the organisations that need it most.
Sunk cost mentality. Large organisations have invested hundreds of millions in existing systems, processes, and team structures. Embracing AI properly often means acknowledging that some of those investments are now liabilities, not assets. That's a hard conversation for any leadership team, and harder still for one that approved those investments. The result is the AI theatre I've written about before</a>: pilots and innovation labs that exist to demonstrate activity without disrupting anything that matters.
Risk aversion at scale. When you have a billion-pound revenue line to protect, every change feels risky. When you have nothing to lose and everything to gain, every change feels like opportunity. This asymmetry has always favoured challengers, but AI amplifies it enormously because the cost of building a credible competitor has dropped by an order of magnitude.
What this means in practice</h2>
This is not theoretical. It's playing out across industries right now.
In legal, the numbers are startling. Corporate AI adoption more than doubled in a single year, from 23% to 52%, according to the ACC/Everlaw survey. 64% of in-house legal teams now expect less dependence on outside counsel. 61% are pushing for changes in how outside legal services are priced. An entire industry built on billable hours and institutional knowledge is being restructured by tools that teams of ten built.
In software, the shift from traditional engineering to AI-augmented orchestration</a> means a small team with strong AI fluency can build what previously required departments. Andrej Karpathy, OpenAI co-founder, calls the new paradigm "agentic engineering": not writing code, but orchestrating agents who do. Features that took two to six weeks in 2024 now ship in a day, sometimes hours.
Since the start of 2026, ETFs for public software companies have fallen 30%. Salesforce, Adobe, Intuit, ServiceNow, all down 25-30% in weeks. a16z calls it the "SaaSpocalypse." The market is pricing in what the incumbents haven't yet accepted.
The pattern is the same everywhere. A small team that knows how to use AI well can now compete with organisations ten or fifty times their size. Not on everything. Not yet. But on specific, high-value capabilities that used to be the exclusive domain of incumbents.
And the window for incumbents to respond is narrowing.
The new moat</h2>
If traditional moats are dissolving, what replaces them?
Institutional AI fluency. The organisations that will dominate the next decade are the ones building deep, organisation-wide capability in working with AI. Not just buying tools. Not just running pilots. Actually changing how work gets done, how decisions get made, how products get built. This is the investment that most organisations are still avoiding</a>.
Speed of iteration. The ability to deploy, measure, learn, and improve faster than competitors. This favours organisations with flat structures, clear decision authority, and a culture that treats failed experiments as data rather than career risk.
Production AI capability. The gap between "we have an AI strategy" and "we have AI systems in production delivering measurable business outcomes" is where competitive advantage lives. Only about one in five organisations unlock real ROI from AI</a>. The 20% that succeed are building something their competitors cannot easily replicate, because it's built on operational knowledge, not just technology.
Data feedback loops. Not the static data advantage of old, where you simply had more data than the competition. The dynamic advantage of having production AI systems that generate data about what works, which feeds back into better systems, which generate more data. This is the compounding loop that makes early movers increasingly hard to catch.
The honest assessment</h2>
I'm not arguing that every large company is doomed or that every startup with an AI tool will win. Scale still matters for distribution, for regulatory compliance capacity, for customer trust in high-stakes domains.
But the balance has shifted. Dramatically. The assumption that being the biggest player in your market means you'll still be the biggest player in five years is no longer safe. Industry leaders have no guarantees of maintaining their position. The power is moving to those who know how to use AI, and who started learning earlier.
Lakhani, Spataro and Stave summarised the situation precisely in Harvard Business Review: "while execution is increasingly automated, what remains scarce is the leadership ability to imagine and commit to a different way of running the enterprise." That scarcity is the new moat. It is not capital. It is not headcount. It is the willingness, at the top of the organisation, to redesign.
If you're leading a large organisation, the question isn't whether you can afford to invest in AI transformation. It's whether you can afford the speed at which you're currently moving. Because somewhere, a team of five people who really understand this technology is building what comes next in your industry. And they're not waiting for your procurement process to finish.
If you want to talk through what this means for your competitive position, get in touch</a>.
Related: Turning AI theatre into AI that moves the numbers</a> · Most companies are adopting AI. Few are adopting it well</a> · How to unlock AI ROI: what the 20% do differently</a>

The dual-stream strategy. Protect your current business while building what replaces it

2026-03-20T00:00:00+00:00

Every successful business is running on borrowed time. That sounds dramatic, but the evidence is clear: the average lifespan of an S&P 500 company has dropped from 61 years in 1958 to under 18 years today. McKinsey projects that by 2027, 75% of the companies currently on that list will have been replaced.
The cause isn't bad management. It's the inability to build the next thing while the current thing still works.
The innovator's dilemma, but worse</h2>
Clayton Christensen named this problem decades ago. Successful companies optimise for their existing customers, their existing margins, their existing competitive advantages. They get so good at what they do that they can't see the thing that will make it irrelevant. By the time they do see it, someone else has built it.
AI makes this problem orders of magnitude more urgent. Previous technology shifts gave you a decade to adapt. AI gives you one to three years. The speed at which AI capabilities are compounding means the window between "this could affect our business" and "this has already disrupted our market" is collapsing.
I've worked with companies across sectors where this conversation is happening right now. The question always takes the same form: do we invest in new products that could eat into our own current advantage?
It's not really a dilemma.
Two streams, running in parallel</h2>
The smartest position for any profitable business right now is to work in two parallel streams.
Stream one: protect and optimise what you have. Keep running your current business. Serve your customers. Maintain your margins. This is the revenue that funds everything else, and abandoning it prematurely is as dangerous as ignoring what comes next. Apply AI to make your existing operations more efficient, your customer experience sharper, your costs lower. This is where most organisations start, and it's necessary.
Stream two: build the thing that replaces it. Start developing AI-native capabilities that could fundamentally change your product, your business model, or your market position. This is the uncomfortable stream, because it means investing in something that might cannibalise the very thing generating your revenue today.
Most companies only run stream one. They use AI to optimise what exists. They bolt tools onto existing processes</a> and call it transformation. They measure adoption rates and report to the board that AI is being used. But they never build the thing that would actually change the trajectory of the business.
That's not strategy. That's maintenance.
The distribution is shifting</h2>
Here's the part that makes boards uncomfortable. The balance between these two streams is not static. You should be putting more focus on stream two every quarter. Not because stream one is failing, but because the competitive landscape is accelerating.
A year ago, using AI to improve internal efficiency was a legitimate strategic priority. Today, it's table stakes. Every competitor is doing it. The differentiation now comes from AI-native products, AI-enabled business models, and capabilities that didn't exist before.
The numbers tell a brutal story. An NBER survey of 6,000 executives across the US, UK, Germany, and Australia found that over 80% detected no discernible productivity impact from AI despite near-universal adoption. Executives use AI only 1.5 hours per week on average. Robert Solow's 1987 paradox is repeating itself: "You can see the computer age everywhere but in the productivity statistics." The AI is there. The transformation is not.
Meanwhile, PwC's 2026 Global CEO Survey found that 45% of CEOs believe their company will not be viable in ten years if it continues on its current path. BCG classifies only 5% of companies as "future-built" for AI. 60% are laggards. The gap between those two groups is widening, not closing. Leaders expect twice the revenue increase and 40% greater cost reductions than laggards. And the gap compounds every quarter that the laggards delay.
The organisations I advise that are getting this right treat stream two with the same seriousness as stream one. Dedicated teams. Ring-fenced budget. Separate metrics. Not a side project in the innovation lab. Not a pilot that exists to generate a board slide. A genuine second line of business development with the mandate and resources to build something real.
The profit question</h2>
The objection I hear most often is about margins. "We're profitable. Why would we invest in something that might not work and could undermine our current revenue?"
I'll be direct. Even if stream two needs to consume all your profits, or requires additional investment, it is worth doing. Because this is truly existential.
Your future self, one to three years from now, will never forgive short-sighted thinking on this. The companies that are cautious with stream two investment today will find themselves trying to catch up in 18 months when a competitor, or a startup with no legacy to protect, has already built what they should have been building.
This isn't theoretical. I've seen it happen in real time. At one organisation I worked with, we built an agentic AI system that achieved 67% autonomous case resolution</a>. That system didn't optimise the existing workflow. It replaced significant parts of it. The company's competitors, who were still optimising their existing processes, are now trying to catch up. They won't.
The pattern is playing out right now with companies you can name.
Klarna went all-in on AI replacing customer service agents. Their AI assistant handled 2.3 million conversations in its first month, equivalent to 700 full-time employees. Then quality problems forced them to reverse course and rehire humans. The lesson wasn't that AI doesn't work. It was that the transition requires building the new while still running the old. Ripping out stream one before stream two is ready is as dangerous as never starting stream two at all.
Shopify took the opposite approach and got it right. Revenue growing 21%+ per year while headcount dropped from 11,600 to 8,100. CEO Tobi Lutke's memo made it explicit: no one can hire a human without first proving AI cannot do the job. They didn't stop running the business. They systematically replaced how the business runs.
Duolingo kept the same number of full-time employees and produced 4-5x more content by restructuring around AI. Same investment, radically different output.
The pattern is always the same: protect the current business at the expense of the next one, and someone else will build the next one for you.
How to run stream two without killing stream one</h2>
This is where the execution matters more than the strategy.
Start with a clear threat assessment. What does your business look like if an AI-native competitor enters your market with no legacy systems, no existing customer expectations, and no margin to protect? What would they build? That's what you need to build.
Ring-fence the investment. Stream two cannot compete with stream one for budget on a quarterly basis. If every investment decision runs through the same ROI model that governs your current business, stream two will always lose. New capabilities don't have the same return profile as established ones. They need protected funding with different success criteria.
Staff it with your best people. The temptation is to put the innovation team on stream two and keep your strongest operators on stream one. This is backwards. Stream two is harder, riskier, and more consequential. It needs your best technical and product minds, people who understand both the existing business and what AI can actually do in production.
Set a time horizon, not just a budget. Stream two needs 12 to 18 months to prove itself. If you're evaluating it on quarterly revenue contribution, you'll kill it before it has a chance to work. Define what success looks like at 6 months, 12 months, and 18 months. Make those milestones about capability and learning, not just revenue.
Accept the cannibalisation. If stream two succeeds, it will take revenue from stream one. That's the point. Better you cannibalise your own business than let someone else do it. Amazon understood this when they launched AWS, which competed directly with their own retail infrastructure costs. Apple understood it when the iPhone killed the iPod. The companies that survive are the ones willing to disrupt themselves.
The real risk is doing nothing</h2>
I talk to a lot of leaders who frame this as a risk decision. "What's the risk of investing in stream two?" The risk of investing is that you spend money on something that takes time to generate returns.
The risk of not investing is that your business becomes irrelevant.
Those are not symmetrical risks.
PwC's 2026 data is unambiguous: companies applying AI widely to products, services, and customer experiences achieved nearly 4 percentage points higher profit margins than those using AI only for internal efficiency. CEOs with strong AI foundations are 3x more likely to report meaningful financial returns. That's not a marginal advantage. That's the difference between leading and following.
The roughly 80% of AI projects that never unlock their ROI</a> almost all share one characteristic: they were optimisation projects, not transformation projects. They made the existing thing slightly better. They didn't build the next thing.
Start now</h2>
If you're running a profitable business and haven't started stream two, you're late. Not too late. But late enough that starting next quarter instead of this one is a decision you'll regret.
The good news is that stream two doesn't have to be enormous to begin with. A small team. A clear thesis about what an AI-native version of your business looks like. Permission to build something that might compete with your current product. And the understanding, at the board level, that this investment is not optional.
Your current business is funding your future one. Use it while it's still strong enough to do so.

If you want to talk through how this applies to your business, get in touch</a>.
Related: Turning AI theatre into AI that moves the numbers</a> · How to unlock AI ROI: what the 20% do differently</a> · Most companies are adopting AI. Few are adopting it well</a>

What two hours with Anthropic's agent team taught me about building AI

2026-03-16T00:00:00+00:00

Anthropic recently ran a full workshop on their Claude Agent SDK at the AI Engineer conference. Thariq Shihipar, who works on the SDK team, spent nearly two hours walking through how Anthropic builds agents internally.
I've built agentic systems in production across insurance, defence, and enterprise software. Some of what I heard confirmed patterns I already use. Some gave me new tools. All of it crystallised into five principles that I think define how production agents should be built right now.
The actual agent code is about 50 lines. The real engineering is everything around it.
Here are the five principles.
1. Your agent is the environment, not the code</h2> This was the workshop's most powerful reframing. The orchestration code is trivial. The real engineering is what you put in the working directory. The same lesson, that the engineering lives in the scaffolding rather than the model, runs through everything you are actually talking to when you use an AI</a>.
A typical agent project:
your-agent/ ├── agent.ts # ~50 lines of boilerplate ├── CLAUDE.md # Instructions, API descriptions, rules ├── scripts/ # Bash tools with --help ├── lib/ # TypeScript SDKs and types ├── data/ # Reference data ├── skills/ # On-demand context ├── memories/ # Persistent state (just files) └── examples/ # Example scripts for codegen </code></pre> Context is not just a prompt. It's the scripts the agent can discover. The TypeScript SDK you generated for your API. The CLAUDE.md file describing what's available. The skill directories the agent can navigate into when it needs specialised knowledge. Thariq used a good analogy. If someone locked you in a room and gave you tasks, would you want a stack of papers or a computer with Google? You'd want the computer. Give the agent the tools to find its own information, not the information itself.I've seen this principle in my own work. The insurance automation system</a> I designed resolves 67% of cases autonomously, and the agent code is a small fraction of the engineering effort. Most of the work went into the environment: data pipelines, decision rules, escalation logic, and verification layers. Once you make that shift, agent development becomes less about writing clever code and more about curating an excellent workspace. 2. A shell replaces a tool registry</h2> Instead of defining a search tool, a lint tool, an execute tool, and a test tool, each with its own schema and error handling, Anthropic's approach is to give the agent bash. The agent just uses grep</code>, npm run lint</code>, npm test</code>, and ffmpeg</code>. One generic tool replaces an entire registry. The reason this works is composability. Bash lets the agent pipe outputs together, save intermediate results to files, discover new capabilities by running --help</code>, and leverage the entire Unix ecosystem. You don't need to anticipate every action the agent might take. You give it a shell and it composes the tools that already exist. This is how Claude Code is built, and it's the most capable coding agent available today. The same architecture powers non-coding agents in finance, legal, healthcare, and customer service. The bash tool is what makes it generalise. The workshop laid out a clear decision framework for when to use each capability. Tools for irreversible actions where you want explicit confirmation. Bash for composable operations. Code generation for dynamic logic. The practical takeaway: if you're maintaining more than a handful of custom tool definitions, you're probably doing work the shell could do better. 3. Translate your data into the model's language</h2> This is the principle with the highest return on effort. Make your problem in-distribution. If you've only tried one search interface for your data, it's probably not enough. For a spreadsheet agent, you might try SQL queries, cell reference syntax, grep on CSV, or XML queries (XLS files are XML underneath). Different approaches work differently depending on the data shape. The most impactful thing you can do is translate your data into a format the model already knows well. Loading a CSV into SQLite and letting the agent write SQL queries is often dramatically more effective than any custom search tool. Generating TypeScript interfaces from your API schema gives the model type information it can reason about natively. This single step often produces more improvement than any amount of prompt engineering. It's also the easiest to test: try two formats, measure which produces better results, keep the winner. 4. Verify at every layer, not just the output</h2> Every agent follows three steps: gather context, take action, verify work. Planning sits optionally between the first and second steps. That sounds trivial. Getting it right is not. Verification is a discipline applied at every layer, not a final check. This aligns precisely with what I described in my earlier piece on agentic AI in production</a>. Errors compound in multi-step pipelines. Catching them early is dramatically cheaper than catching them at the end. Anthropic uses deterministic rules wherever possible: linting, compilation, schema validation, constraint checks. In Claude Code, if the agent tries to write a file it hasn't read, the harness throws an error and tells it to read first. Simple, deterministic, and extremely effective. A practical detail worth noting: the model reads error messages and iterates. If your error says "you tried to insert 50,000 rows in one operation, please chunk this into batches of 1,000 or fewer," the agent will follow that coaching. Design your error messages as instructions, not diagnostics. Sub-agents add a powerful verification layer. You spawn a sub-agent with a completely fresh context and frame the task combatively: "This analysis was written by a junior analyst. Find the errors." The fresh context means the verifier has no sympathetic relationship with the work. It's genuinely adversarial. The gap between self-verification and adversarial verification is significant. I plan to integrate this pattern into my own production deployments. Sub-agents also shine for parallel processing ("read and summarise sheet 1, sheet 2, sheet 3 simultaneously") and search offloading, where many queries run but only the final answer returns to the main agent. Both patterns keep the main context clean and focused. 5. Read every transcript. Then improve the environment</h2> The workshop was emphatic about one workflow: don't start with the SDK. Start with Claude Code. Set up a working directory with your APIs, data, and scripts. Write a CLAUDE.md. Chat with Claude Code and give it real tasks. Then read the transcripts. This is the single most important practice for improving agent design, and it's the one most people skip. After every session, read the full transcript. Where did the agent get stuck? Where did it take unnecessary detours? What context was it missing? Where did it use training knowledge instead of your data? Iterate on the environment based on what you learn. Improve the instructions. Add scripts. Create skills. Add hooks to catch behaviour you don't want. Then read the transcripts again. The iteration loop between reading transcripts and improving context is where most of the real engineering happens. Once results feel good, writing the agent.ts file and deploying to a sandbox is straightforward. A note on security</h2> Anthropic describes their security model as a "Swiss cheese defence." No single layer blocks everything. Together, the layers cover each other's gaps. Your job as an agent builder is the outer layer: sandboxing. One container per user. Network isolation. Filesystem isolation. Use providers like Cloudflare, Modal, E2B, or Daytona. The "lethal trifecta" to guard against: code execution, filesystem changes, and data exfiltration. Sandbox the network and you cut off exfiltration even if the other two are compromised. For database access, the principle is counterintuitive but sound: give the agent broad access, then add guardrails. Letting the agent write dynamic SQL and fix its own errors through iteration produces better results than restricting it to predefined queries. Reserve strict masking for genuinely sensitive data. Build for now. Rewrite in six months</h2> Thariq closed with something that resonated. Model capabilities change fast. Code that was necessary six months ago may be unnecessary today. Build for current capabilities. Ship now. Rewrite later. The companies moving fastest are the ones willing to throw away code and rebuild with current capabilities. As Thariq put it: "We can write code 10x faster. We should throw out code 10x faster." That's not instability. That's the natural rhythm of building on a platform that's improving faster than any in history. The best time to start is now, knowing you'll improve it later. If you want a structured way to move from prototype to production, my methodology page</a> describes how I approach these engagements, and the transformation sprint</a> is designed specifically for getting agentic systems into production. Building an agentic system and want to validate your architecture? Let's talk.</a> Related: Agentic AI in 2026: what actually works in production</a> · AI made developers 19% slower. Here's what they were doing wrong</a> · How to unlock AI ROI: what the 20% do differently</a> · Case study: agentic AI in insurance</a>
You're not a 10x engineer. You're an orchestrator, and that's harder 2026-03-12T00:00:00+00:00 Andrej Karpathy coined "vibe coding" in February 2025: "you fully give in to the vibes, embrace exponentials, and forget that the code even exists." It was a throwaway tweet. It became Collins Dictionary's Word of the Year. And a year later, Karpathy himself declared it passé. His replacement term is more interesting: agentic engineering. "The new default is that you are not writing the code directly 99% of the time. You are orchestrating agents who do and acting as oversight." That one sentence captures the biggest shift in software engineering in a generation. And most of the industry hasn't caught up with what it actually means. The old 10x myth</h2> The "10x engineer" was always a flawed concept. The idea that one developer could produce ten times the output of another was based on a misunderstanding of what software engineers actually do. Writing code was never the bottleneck. Understanding the problem, designing the system, and making the right trade-offs. That was always the hard part. But the myth persisted because, in the old paradigm, implementation speed was visible and valued. The engineer who could bang out a feature in a day while others took a week looked ten times more productive, even if the feature was poorly designed and would need rewriting in six months. AI has made that version of productivity meaningless. When any developer can direct an AI agent to produce code at machine speed, typing speed is no longer a differentiator. The skill that used to look like 10x, fast and fluent code production, has been commoditised overnight. What hasn't been commoditised is the thing that was always more important: judgement. What orchestration actually looks like</h2> Boris Cherny, the head of Claude Code at Anthropic, runs 5 local sessions and 5-10 remote sessions in parallel, each in its own git checkout. He shipped 22 pull requests in a day, then 27 the next, every line written by AI. He hasn't edited code by hand since November 2025. That sounds like effortless productivity. It isn't. What Cherny actually does is architectural direction, quality control, and context management at a pace that would overwhelm most engineers. Each session needs a well-scoped task. Each result needs review against the broader system. Roughly 10-20% of parallel sessions get abandoned because the agent went in an unexpected direction. The team maintains structured documentation that tells the agent what conventions to follow and what mistakes to avoid, and every time the agent makes a new kind of error, they update the documentation so it doesn't happen again. This isn't "vibe coding." This is engineering management at a different level of abstraction. The code is written by machines. The thinking (the decomposition, the verification, the architectural coherence) is entirely human. At StrongDM, three engineers built what Simon Willison called "the most ambitious form of AI-assisted software development I've seen yet." No human writes code. No human reviews code. The humans design specifications, curate test scenarios, and watch scores. They built digital replicas of Okta, Jira, Slack, and Google Docs to run thousands of automated test scenarios per hour. Three people. Zero human code. And the system works because those three people have the engineering judgement to design the right specifications and the right tests. Which is vastly harder than writing the code would have been. The dirty secret</h2> Tanmai Gopal, CEO of a billion-dollar-plus startup, said something that cuts through the hype: "70% of the effort required to make AI useful relies entirely on unwritten business context that exists only in human heads." This is the part that gets lost in the "AI writes all the code" narrative. The code is the easy part. It was always the easy part. The hard part is knowing what to build, why to build it, and how it fits into the system that already exists. An AI agent can write a feature. It cannot understand why the previous architect made certain trade-offs, what implicit assumptions the existing system relies on, which stakeholders care about which outcomes, or how a change in one subsystem will cascade through the business process it supports. That context, the messy, human, organisational context, is the orchestrator's primary raw material. And it's the thing that makes the role harder, not easier, than the old "just write the code" paradigm. The competence drain</h2> DHH, the creator of Ruby on Rails and one of the most respected voices in software development, described his experience with AI coding tools in strikingly physical terms: "I can literally feel competence draining out of my fingers." He loves using AI for drafts, API lookups, and second opinions. But he keeps AI code in a separate window. He doesn't let it drive. His analogy: "You're not going to get fit by watching fitness videos. You have to do the sit-ups." Dave Farley, author of the definitive book on continuous delivery, made the same point more directly: "AI is not going to replace software engineers. But it is going to expose the ones who never learned to think like engineers in the first place." There's a real tension here. The orchestrator role requires more engineering judgement than the implementer role, not less. You need to evaluate AI-generated code for correctness, security, performance, and maintainability. That means you need to understand code at a level that many developers never reached even when they were writing it themselves. The METR study</a> found that developers using AI were 19% slower, and believed they were 20% faster. That perception gap is what the competence drain looks like from the inside. You feel productive because the tool is doing things at machine speed. But your ability to critically evaluate what it produces is atrophying. And you don't notice until something breaks in production. What the orchestrator needs to be good at</h2> If the role is shifting from implementer to orchestrator, the skill profile shifts with it. Based on what I've seen work, both in my own practice and in the organisations I advise, here's what matters: Problem decomposition. The single most important skill. An AI agent can execute a well-scoped task. It cannot take a vague business requirement and figure out what "done" looks like. The orchestrator breaks ambiguous problems into clear, testable units of work, each one small enough for an agent to handle and specific enough to verify. Architectural judgement. AI generates code that works in isolation. The orchestrator ensures it works within the system: that the data model is consistent, the abstractions are right, the performance characteristics match the requirements, and the changes don't introduce subtle regressions elsewhere. This requires the kind of deep system understanding that only comes from experience. The national security platform</a> I worked on is a good example: when systems operate across 30+ countries at defence-grade reliability, there's no room for AI-generated code that "works in isolation" but breaks the wider architecture. Verification discipline. Gergely Orosz, one of the most followed voices in software engineering, identified this as the skill that's becoming more valuable as AI generates more code: the ability to read code critically and catch what's wrong. Not just syntax errors. Architectural flaws, security vulnerabilities, subtle logic errors that the agent will never flag. CodeRabbit's data shows AI produces 75% more logic errors and 8x more excessive I/O operations than humans. Someone has to catch those. Context maintenance. The orchestrator holds the business context, the system context, and the user context in their head simultaneously, and translates that context into instructions the agent can act on. This is what Tanmai Gopal's "70% unwritten business context" means in practice: the orchestrator is the bridge between what the organisation needs and what the machine can do. In the insurance automation project</a>, the agentic system works because of clear decision delegation: the agent handles cases autonomously but the humans defined the boundaries, the escalation triggers, and the verification rules. That's orchestration at the organisational level. Knowing when not to use AI. This might be the most underrated skill. Not every task benefits from AI delegation. Some problems require the kind of deep, focused thinking that gets worse when you're managing parallel agent sessions. The best orchestrators I've worked with are deliberate about when they direct agents and when they sit down and think. The identity problem</h2> There's something uncomfortable about this transition that doesn't get discussed enough. An anonymous junior engineer at a large San Francisco tech company told the SF Standard: "I'm basically a proxy to Claude Code. My manager tells me what to do, and I tell Claude to do it. The skill you spent years developing is now just commoditised to the general public. It makes you feel kind of empty." Michael Parker, VP of Engineering at TurinTech, put it differently: "I used to be a craftsman. Now I feel like a factory manager of Ikea. I'm just shipping low-quality chairs." These aren't edge cases. A lot of experienced developers are grappling with the same feeling. The thing they were good at, writing elegant, efficient, well-structured code, is no longer the thing that matters most. The new thing that matters, orchestrating AI agents, maintaining context, verifying output, doesn't feel like craftsmanship. It feels like project management. I think this is a temporary perception. Orchestration at its best is a craft, one that requires deeper understanding of systems, architecture, and engineering principles than implementation ever did. But it's a new craft, and the industry hasn't yet built the identity, the language, or the career ladders around it. The organisations that figure this out first, that build roles, progression paths, and recognition structures for the orchestrator, will attract and retain the best engineering talent. The ones that don't will lose their best people to the companies that do. What this means for engineering leaders</h2> If you lead an engineering team, the transition from implementer to orchestrator isn't optional. It's happening whether you manage it or not. The question is whether it happens deliberately, with clear expectations, appropriate training, and workflow design that sets people up to succeed, or whether it happens chaotically, with developers independently experimenting with AI tools, accumulating technical debt, and losing skills they'll need when the agent produces something wrong. I'd start with three things: Redefine what "senior" means. If your promotion criteria still centre on code quality and implementation speed, they're measuring the old game. Senior engineers in the agentic era are defined by judgement, system thinking, and the ability to direct AI effectively, not by how fast they can write a function. Build verification into the workflow. AI-generated code needs different review practices than human-written code. The failure modes are different: more duplication, more security vulnerabilities, more plausible-looking logic errors. Your code review process needs to account for this explicitly. Invest in the transition. Your best implementers won't automatically become your best orchestrators. Some will. Others will need support, training, and time. The ones who make the transition will be extraordinarily valuable. The investment is worth it. The title "software engineer" might survive. Or it might evolve into something else. What won't change is the need for people who can think clearly about complex systems, make good decisions under uncertainty, and translate business problems into technical solutions. That's always been the job. The tools just changed. If you're navigating this transition in your engineering organisation and want to think it through with someone who's been in the seat, get in touch</a>. Related: The training ladder is broken</a> · AI made developers 19% slower: here's what they were doing wrong</a> · Agentic AI in 2026: what actually works in production</a> · How I help engineering teams make this transition</a> AI made developers 19% slower. Here's what they were doing wrong 2026-03-08T00:00:00+00:00 The most rigorous study we have on AI coding productivity comes from METR, a non-profit AI research lab that ran a randomised controlled trial with 16 experienced open-source developers across 246 real-world tasks. The result: developers using AI tools completed tasks 19% slower than without them. That's a striking finding. But the truly alarming part isn't the slowdown. It's this: before the study, developers predicted AI would make them 24% faster. After experiencing the slowdown, they still believed AI had sped them up by 20%. That perception gap, being slower while feeling faster, is the most dangerous thing happening in software engineering right now. What METR actually measured</h2> The study deserves close reading, because the details matter more than the headline. These were experienced developers working on their own mature repositories, codebases they knew intimately. They were using mainstream AI coding tools: autocomplete, chat-based assistance, the kind of tooling that most organisations have already deployed. Domenic Denicola, maintainer of jsdom and one of the study participants, published a detailed account. A performance optimisation he estimated at 30 minutes took 4 hours and 7 minutes with AI. A test-writing task he estimated at 1 hour took 4 hours and 20 minutes. Agents got stuck in loops, spent 30+ minutes finding files, applied syntax incorrectly, and moved lines one at a time instead of reordering them. His verdict: AI made the tasks "more engaging," like a game, but not faster. And agents required "constant handholding and continuous awareness of the model's limitations." This is not a story about AI being useless. It's a story about developers using the wrong tools in the wrong way on the wrong tasks. The autocomplete trap</h2> Here's what most organisations have done: they've bought Copilot licences, rolled them out to the engineering team, and called it AI adoption. That's like giving someone a power drill and asking them to use it as a hammer. It's the wrong tool for the job. Or more precisely, it's the right tool being used in the wrong paradigm. Autocomplete-style AI, suggesting the next few lines as you type, is useful for boilerplate. But when you're working in a codebase you already know well, on tasks you already know how to do, adding an AI middleman to your muscle memory is overhead. You're slower because you're reading and evaluating suggestions for code you could have written faster yourself. The METR developers weren't bad engineers. They were excellent engineers using AI tools designed for a workflow that doesn't match how excellent engineers actually work. What "doing it right" looks like</h2> Meanwhile, in a parallel universe, Boris Cherny, the head of Claude Code at Anthropic, ships 10 to 30 pull requests per day. Every line written by AI. He hasn't edited code by hand since November 2025. Lee Edwards, an investor at Root Ventures, wrote hundreds of thousands of lines of code across six projects in two weeks using agentic AI tools. He described it as "a nuclear-powered six-axis mill. A single-person software factory." At StrongDM, three engineers built a system where no human writes code and no human reviews code. The humans design specifications, curate test scenarios, and watch scores. Simon Willison called it "the most ambitious form of AI-assisted software development I've seen yet." These aren't demo numbers. These are production systems. I've seen the same pattern in my own work: the agentic AI system I designed for a European insurance brokerage</a> resolves 67% of customer service cases without human intervention. Not a demo. A production system handling thousands of cases per month. The difference isn't talent. It's method. Autocomplete versus agentic</h2> The gap in the data makes no sense until you separate two fundamentally different approaches to AI-assisted development. Autocomplete AI (Copilot, inline suggestions): the developer writes code, the AI suggests completions. The developer remains in the driver's seat, making every decision, with the AI offering marginal assistance on each line. On familiar codebases with experienced developers, this adds friction more often than it removes it. DX's survey of 121,000 developers found that productivity gains from this approach have plateaued at roughly 10%, unchanged since Q2 2025. Agentic AI (Claude Code, Cursor agents, similar tools): the developer describes what needs to be built. The AI agent reads the codebase, writes the code, runs the tests, iterates on failures, and delivers a working result. The developer's role shifts from writing to directing and reviewing. This is where the 5x-10x productivity claims come from, and where the evidence supports them. The METR study measured the first approach. The production results from Cherny, Edwards, and StrongDM use the second. This distinction matters enormously, because most organisations haven't made the shift. They're still in the autocomplete paradigm: buying licences, measuring adoption rates, and wondering why the numbers haven't moved. The perception gap is the real problem</h2> Let me come back to that METR finding: developers were 19% slower but believed they were 20% faster. That's a 39-percentage-point perception gap. This pattern is everywhere. The DX survey found 92.6% of developers use AI tools at least monthly, but productivity gains are stuck at 10%. Fastly's survey found 95% of developers spend extra hours debugging AI output. Seniors spend up to 40% of their time fixing AI-generated code. CodeRabbit's analysis of 470 open-source repositories found that AI creates 1.7x more bugs, 75% more logic errors, and 2.74x more security vulnerabilities than human-written code. Meanwhile, Stack Overflow's 2025 developer survey shows trust in AI accuracy has fallen to 29%, down from 40%. And the top frustration, cited by 66% of developers: "AI solutions that are almost right, but not quite." If your team believes AI is making them faster but you can't see it in the output metrics, the METR perception gap is probably your explanation. They're not lying. They genuinely feel more productive. The tool is engaging and reduces the tedium of certain tasks. But the net effect, including debugging, rework, and the cognitive overhead of evaluating suggestions, is neutral or negative. You can't fix what you can't see. And if your developers sincerely believe the tool is helping when the data says it isn't, you have a measurement problem masquerading as a productivity problem. What I'd tell a CTO reading this</h2> I use agentic AI tools daily. I've seen what they can do in the hands of someone who understands both the tools and the engineering problems they're applied to. The productivity gains are real. Genuinely transformative in some workflows. But I've also seen the other side: organisations that rolled out AI coding tools, measured adoption instead of outcomes, and now have developers who are slower, less rigorous in code review, and accumulating technical debt at a rate that will cost them dearly in 18 months. The difference comes down to three things: First, use the right class of tool for the job. Autocomplete has its place for quick lookups, unfamiliar syntax, and API discovery. But for meaningful productivity gains, you need agentic tools that can take on whole tasks, not just suggest the next line. And your workflow needs to be rebuilt around delegation and review, not around typing faster. Second, measure outcomes, not adoption. I don't care what percentage of your team uses AI tools. I care about cycle time, defect rate, time-to-production, and business metrics. If those haven't improved, your AI adoption isn't working, regardless of what your developers report in satisfaction surveys. The discipline this requires is the same one I learned building defence-grade platforms</a>: measure what matters, not what's easy to count. Third, invest in AI fluency, not just AI access. The gap between the METR developers (19% slower) and Boris Cherny (27 PRs per day) is not about the AI models. It's about how you structure your work around them. That's a skill, and like any skill, it requires deliberate development, not just tool provisioning. The organisations that get this right will have a genuine competitive advantage. The ones that confuse AI adoption with AI effectiveness will have expensive tools and the same output. Or worse. If you're trying to figure out whether your AI tooling investment is actually delivering, let's talk</a>. Related: Turning AI theatre into AI that moves the numbers</a> · Why your AI spend isn't showing up in the numbers</a> · Agentic AI in 2026: what actually works in production</a> · Transformation sprint: fixing AI tooling and workflow</a> Most companies are adopting AI. Few are adopting it well 2026-03-04T00:00:00+00:00 Here are four numbers that should not coexist: 84% of developers now use AI coding tools</li> 29% trust the accuracy of what those tools produce</li> 10% is the average productivity gain, unchanged for a year</li> 55% of companies that laid off workers for AI now regret it</li> </ul> That's not an AI problem. That's an adoption problem. And it's the most expensive kind: the kind where you've already spent the money and aren't getting the return. It's also the most recoverable kind, because the fix doesn't need a bigger budget or a better model. It needs the return unlocked from spend you've already committed. The procurement fallacy</h2> Most organisations treat AI adoption as a procurement decision. Buy Copilot licences. Roll them out. Track adoption rates. Report to the board that 90% of engineers are using AI tools, a habit that usually traces back to decision-makers who have watched a demo rather than built anything</a>. This is the equivalent of buying gym memberships for the entire company and measuring success by how many people scanned their badges at the door. You're measuring presence, not results. MIT researchers found that 95% of enterprise generative AI deployments had no measurable impact on profit and loss. Not "small impact." No measurable impact. Forrester found that over half of companies that cut staff in the name of AI efficiency are now quietly rehiring, because it turns out that removing humans from processes that AI can't actually handle creates problems that are more expensive than the savings. The founders and small to mid-market teams I work with that are genuinely getting value from AI didn't start by buying tools. They started by asking a different question entirely. What "doing it badly" looks like</h2> The pattern is remarkably consistent. Stage 1: Tool deployment. The company buys AI coding tool licences. There's an announcement. Maybe a lunch-and-learn. Developers start using autocomplete suggestions. Stage 2: Adoption theatre. Usage numbers go up. The team reports feeling more productive. Internal surveys are positive. The board gets a slide showing 85% adoption. Stage 3: The invisible costs accumulate. Code review becomes cursory. Developers rubber-stamp AI suggestions they should scrutinise. Technical debt accumulates faster. CodeRabbit's analysis of 470 open-source repositories found AI-generated code contains 1.7x more bugs, 75% more logic errors, and 2.74x more security vulnerabilities. GitClear tracked a doubling of code churn (lines reverted or updated within two weeks) compared to the pre-AI baseline. Copy-pasted code increased 48%. Stage 4: The reckoning. Defect rates climb. Production incidents increase. The productivity gains that everyone felt never materialise in the actual delivery metrics. But by now, the organisation has restructured around the assumption that AI is working. Unwinding is painful. I've seen this play out at multiple organisations. The specific tools vary. The pattern doesn't. What "doing it well" looks like</h2> The companies getting genuine returns from AI share characteristics that have nothing to do with which model they're using or how much they're spending on compute. They changed the workflow, not just the tooling</h3> Deloitte's research shows that organisations taking a work-redesign approach, rethinking processes before selecting tools, are twice as likely to exceed ROI targets than those starting with the technology. This means something concrete. It means you don't give developers AI tools and tell them to keep working the same way. You redesign how work flows through the team. At Anthropic, the Claude Code team maintains structured documentation files that tell the AI agent what the codebase conventions are, what mistakes to avoid, and how to structure changes. That's not a tool feature. It's a workflow decision. And it improves output quality by 2-3x. At Shopify, Tobi Lutke's internal memo was explicit: "Reflexive AI usage is now a baseline expectation." But the meaningful part wasn't the mandate. It was the structural change. Teams must demonstrate why they cannot achieve what they need using AI before requesting additional headcount. That forces a genuine rethink of how work gets divided between humans and tools, rather than bolting AI onto the existing structure. They measure outcomes, not activity</h3> DX surveyed 121,000 developers across 450+ companies and found that the organisations seeing real gains aren't the ones with the highest adoption rates. They're the ones measuring business-level outcomes: cycle time, defect rate, time from commit to production, customer-facing incident frequency. Some companies in the survey saw twice as many customer-facing incidents after AI adoption. Others saw a 50% reduction. The difference wasn't the tools. It was whether the organisation had built quality gates that matched the new workflow. Laura Tacho, CTO at DX, put it precisely: "In struggling organisations, AI tends to highlight existing flaws rather than fix them." They invested in agentic workflows, not just autocomplete</h3> This is the biggest differentiator I see. The 19% slowdown that METR found in their study</a> was developers using autocomplete-style tools on familiar codebases. The 5-10x gains that companies like StrongDM, Courier, and Anthropic report come from agentic workflows, where AI agents take on entire tasks, not just suggest the next line of code. The shift from autocomplete to agentic isn't just a tool upgrade. It requires fundamentally different skills from the developer: the ability to decompose problems into well-scoped tasks, write clear specifications, evaluate output critically, and maintain architectural coherence across AI-generated code. That's a training investment, not a licence purchase. They kept humans in the loop, deliberately</h3> Duolingo made headlines with a policy that only permits hiring if work cannot be automated. It's a bold position, and I understand the logic. But the companies I've seen get the best results take a more nuanced approach: they define specifically which decisions AI makes autonomously, which require human review, and which remain entirely human. This isn't governance for governance's sake. It's engineering. The insurance brokerage I worked with</a> achieved 67% autonomous case resolution, but the 33% that required human handling was designed with as much care as the automated portion. The handoff included full context, the agent's reasoning, and the information it had retrieved. That's what made the whole system trustworthy enough to scale. The same principle held at NHS Wales</a>, where the governance structures weren't optional. They were the foundation for a transformation programme that identified £20M+ in savings opportunities. The Shopify paradox</h2> Shopify is doing something interesting that illustrates the tension well. On one hand, Lutke's memo says prove AI can't do it before we hire a human. On the other hand, Shopify is hiring 1,000 interns specifically for "AI-native thinking." That's not a contradiction. It's the right strategic move. They're reducing headcount for tasks AI genuinely handles well, while simultaneously investing in developing people who can work with AI effectively. They understand that the tool is only as good as the human directing it, and that developing that human capability requires deliberate investment. Most organisations are doing only the first half: cutting costs. Very few are doing the second half: building capability. And the second half is where the long-term competitive advantage lives. What I'd ask any engineering leader</h2> If you're running an engineering organisation and you've deployed AI tools, three questions will tell you whether you're adopting well or just adopting: Are you measuring outcomes or adoption? If your primary metric is "percentage of developers using AI tools," you're measuring the wrong thing. If you can point to specific improvements in cycle time, defect rate, or delivery throughput, and attribute them to AI, you're on the right track. Have you changed the workflow or just added a tool? If developers are working the same way they did before, with AI suggestions layered on top, you're in the autocomplete trap. The real gains come from redesigning how work is structured, delegated, and reviewed. Are you developing AI fluency or just providing AI access? The gap between developers who are slower with AI tools</a> and developers who are 10x more productive is not about the tools. It's about skill, method, and workflow design. That requires investment: in training, in mentorship, in giving people time to develop new ways of working. The good news is that the organisations doing this well are pulling ahead fast. The bad news is that most organisations haven't started. If you're not sure where your organisation falls, the AI readiness diagnostic</a> will give you a clear picture in 15 minutes. If you want to figure out where your AI investment is actually delivering and where it's theatre, get in touch</a>. Related: Turning AI theatre into AI that moves the numbers</a> · How to unlock AI ROI: what the 20% do differently</a> · How I approach AI transformation</a> The training ladder is broken. And nobody has a plan to fix it 2026-02-25T00:00:00+00:00 Entry-level developer hiring has dropped 67% since 2022. At the fifteen largest US tech companies, new graduate hiring has fallen by more than half since 2019. Fresh graduates now make up just 7% of big tech hires. At startups, the number has gone from 30% to under 6%. These aren't projections. These are the numbers right now. And almost nobody in a leadership position is talking about what happens next. The logic that got us here</h2> The reasoning is straightforward, and on the surface, hard to argue with. AI tools can now do a significant portion of what junior developers used to do. Bug fixes. Boilerplate code. Test writing. Documentation. Simple feature implementation. The tasks that used to take a new graduate three days now take an AI agent three minutes. So companies look at the numbers and make the obvious call: why hire a junior at £60-90K when an AI tool costs a fraction of that? Hire fewer, more experienced engineers. Give them agentic AI tools. Get more output from a smaller, senior team. I understand the logic. I've been in the room when this decision gets made. And in the short term, it works. Headcount drops. Output holds. The CFO is happy. The problem is that this logic has a time bomb buried in it. Where senior engineers come from</h2> This might seem obvious, but it needs saying: every senior engineer was once a junior engineer. The skills that make someone a valuable senior developer (architectural judgement, debugging intuition, the ability to read a codebase and understand not just what it does but why it was built that way, the instinct for where a system will break under load) none of these come from courses or certifications. They come from years of doing the work. The grunt work. The work we're now automating away. Harvard economists analysed 62 million LinkedIn profiles and 200 million job postings. Their finding was precise: at firms that adopted generative AI, junior headcount fell 7.7% within six quarters. Senior employment barely moved. The decline was steepest among graduates of mid-tier universities, not the elite schools (those graduates are too productive to replace) and not the lowest tier (too cheap to bother replacing). The middle got squeezed. Mark Russinovich, Azure's CTO and not exactly a junior voice in this conversation, published a paper in February with Scott Hanselman arguing that AI tools "give senior engineers an AI boost while imposing an AI drag on early-in-career developers." He said this is now a hot topic in every customer engagement Microsoft has. Every company sees it. Nobody has a plan. Matt Garman, the CEO of AWS, was more blunt. He called replacing junior developers with AI "one of the dumbest things I've ever heard." His reasoning: juniors are the least expensive employees you have, and they're the most engaged with AI tools. Cut them, and in ten years "you have no one that has learned anything." The training ladder problem</h2> Software engineering has always had an informal training ladder. You join as a junior. You fix bugs. You write tests. You struggle with a codebase someone else built. You make mistakes and learn from the code review. You pair with a senior who shows you why your elegant solution won't survive production traffic. Gradually, painfully, you develop judgement. That ladder is being dismantled. Not deliberately. Nobody set out to destroy it. But the economic incentives are all pointed the same way: automate the junior work, hire fewer juniors, give the savings back to the business. The problem is that the junior work was the training. It wasn't grunt work that happened to be done by beginners. It was the mechanism by which beginners became experts. Anthropic, the company that builds Claude, ran their own study on this. Junior engineers using AI scored 50% on comprehension tests. Those who coded manually scored 67%. The largest gap appeared in debugging, the exact skill that separates a competent senior from a dangerous one. Stack Overflow's monthly question volume has collapsed from 200,000 at peak to under 4,000 by the end of 2025. That's a 78% year-over-year decline. The knowledge ecosystem that trained a generation of developers, and that AI models themselves were trained on, is dying. The five-year cliff</h2> Octopus Deploy's AI Pulse Report projects a three-phase crisis: experimentation (2024-2025), junior hiring freeze (2025-2027), and senior talent crisis (2027-2030). I think that timeline is roughly right. The wage gap is already widening. US junior developers earn $75-95K while seniors command $193-263K. That gap will widen further as junior supply increases (more graduates, fewer positions) and senior demand intensifies (fewer juniors maturing into senior roles, more AI systems requiring senior oversight). The maths is simple. If you stop feeding the bottom of the pipeline, the top of the pipeline runs dry. Not immediately. Not this quarter. But the organisations making these cuts today will feel the consequences, and by the time they feel them, rebuilding the pipeline will take years, not months. What I'd actually do about it</h2> I don't think the answer is to ignore AI's capabilities and keep hiring juniors to do work that AI genuinely does better. That's nostalgic, not strategic. But I do think the answer requires more imagination than most organisations are applying. Here's what I'd recommend to any CTO or engineering leader thinking about this: Redefine what juniors do, don't eliminate the role. The junior developer role needs to evolve, not disappear. Instead of writing boilerplate, juniors should be reviewing AI-generated code, learning to spot the patterns of failure that AI produces (and it produces them reliably; CodeRabbit's data shows AI creates 1.7x more bugs and 2.74x more security vulnerabilities than humans). This is a different training ground, but it's still a training ground. Make mentorship a measured responsibility. Russinovich and Hanselman's paper proposes a "preceptor model," structured mentorship where senior engineers are explicitly assessed on developing junior talent. I'd go further: make it a promotion criterion. If you can't develop the people around you, you're not senior. You're just experienced. Invest in the AI-native training path. Shopify is hiring 1,000 interns specifically for what they call "AI-native thinking." That's a bet on a new kind of training ladder, one where the junior's job is to direct AI agents, evaluate their output, and develop the judgement to know when the output is wrong. It's a different skill set, but it still requires deliberate development. Budget for the future, not just the quarter. The short-term savings from cutting junior hires are real. The long-term cost of having no pipeline is also real, and much larger. The organisations that get this right will be the ones that treat junior development as an investment with a 3-5 year payback period, not a cost to be optimised away. The uncomfortable truth</h2> I've built engineering teams across four ventures</a> and in defence-grade environments at Improbable</a>. I've hired juniors who became the best engineers I've ever worked with. And I've watched what happens when organisations optimise purely for short-term efficiency at the expense of long-term capability. The uncomfortable truth is that the market is telling companies to do something that is locally rational and globally catastrophic. Cut the juniors. Save the money. Ship more with fewer people. And then, in five years, wonder why there are no senior engineers available, and why the ones who exist command salaries that make the original savings look like pocket change. The companies that will have the strongest engineering teams in 2030 are the ones making the unfashionable decision to invest in junior talent today. Not because it's charitable. Because it's strategic. If you're rethinking your engineering team structure and want to talk through the trade-offs, a fractional CTO engagement</a> is one way to get that thinking in the room. Or just get in touch</a>. Related: Does your business need a CTO?</a> · Fractional CTO: is outsourced technology leadership right for you?</a> · How to unlock AI ROI: what the 20% do differently</a> Why your AI spend isn't showing up in the numbers 2026-02-18T00:00:00+00:00 I've sat in enough boardrooms to recognise the moment. The CEO pulls up the quarterly numbers, someone asks about the AI initiative, and the room goes quiet. Not because AI isn't being used. It is. But the P&L hasn't moved. This is not an anecdote. It's the dominant pattern. It's also a solvable one. The spend isn't wasted because AI can't deliver; it's underperforming because the return was never engineered in. Unlock that, and the same investment starts showing up where it should. The data is damning</h2> PwC's 2026 Global CEO Survey, covering 4,454 CEOs, found that 56% say AI has delivered no significant benefits. Only one in eight report improvements to both cost and revenue. MIT's analysis of generative AI pilots is worse: 95% produce no measurable P&L impact. Not "disappointing results." No measurable impact at all. The NBER published a working paper in February 2026 surveying roughly 6,000 executives across the US, UK, Germany, and Australia. More than 70% of firms are actively using AI. Over 80% report no impact on employment or productivity over the last three years. Executives themselves average about 90 minutes a week using AI tools; a quarter report using them not at all. These are not fringe findings. This is the consensus view from every major research institution studying AI deployment in 2025–2026. Why the gap exists</h2> The instinct is to blame the technology. It's not the technology. Deloitte's enterprise survey found that organisations taking a work-redesign approach, rethinking processes before deploying tools, are twice as likely to exceed their ROI targets as those taking a technology-first approach. Prosci's research across 1,107 organisations is even more specific: 63% of AI failures trace to human factors, not technical ones. Cultural and organisational barriers account for 65% of failures. Technical issues? 22%. Most organisations are doing this backwards. They buy the tool, run a pilot, get a promising demo, declare success, and then wonder why the numbers don't move when they try to scale. The pilot works because someone babysat it. Production fails because nobody redesigned the workflow around it. Workday presented data at Davos suggesting that roughly 40% of "time saved" by AI goes straight into rework, correcting low-quality outputs that the system generated. That's not a productivity gain. That's a productivity shell game. What actually works</h2> I've built production AI systems that moved business metrics. Not in a lab, not in a pilot, in production at enterprise scale. At AdBrain, the agentic AI system I co-founded and built for a European insurance brokerage achieved 67% autonomous case resolution</a> and a 23% improvement in sales KPIs. These weren't projections. They were measured outcomes on real customer cases. The difference wasn't the model or the infrastructure. The difference was approach. We started with the process, not the technology. We mapped every decision point in the customer service workflow, identified which decisions could be delegated to an AI system with acceptable error rates, and built governance around the ones that couldn't. The technology was in service of the workflow redesign, not the other way round. This is the pattern I see again and again in the organisations that get results. The 5% that McKinsey identifies as achieving true AI transformation aren't using better models. They're deploying AI into redesigned processes with clear KPIs, governance frameworks, and kill criteria for initiatives that aren't working. The 90-day question</h2> If you've been investing in AI and the numbers haven't moved, the question isn't whether to invest more. It's whether you're deploying AI into the right processes, with the right workflow design, and with governance that scales. Most founders and small to mid-market teams I work with can answer that question in 90 days, with one production system delivering measurable results and a clear roadmap for what comes next. The AI readiness diagnostic</a> is a good place to start. It takes 15 minutes and gives you an honest baseline. The AI isn't the hard part. The hard part is being honest about what's working and what isn't, and having someone in the room who has done this before. If that sounds like a conversation worth having, get in touch</a>. No slides, no pitch. Just an honest assessment of where you are. Related: How to unlock AI ROI: what the 20% do differently</a> · Turning AI theatre into AI that moves the numbers</a> · Shadow AI is your next audit finding</a> Turning AI theatre into AI that moves the numbers 2026-02-11T00:00:00+00:00 I want to name something that everyone in the room knows but nobody says out loud. Most AI transformations are performance art. They exist to demonstrate that something is happening, not to deliver results. The innovation lab is staffed. The pilots are running. The quarterly board update has an AI slide with a roadmap and a timeline and a budget. And the P&L hasn't moved. This is not a controversial observation. BCG's own research admits that 60% of AI consulting engagements generate no material value. Only 5% achieve anything at scale. McKinsey puts the number of organisations achieving true AI transformation at one in twenty. Gartner predicts that 60% of AI initiatives will be abandoned through 2026. The industry has a name for this. They call it "pilot purgatory." I think that's too kind. Pilots are experiments that lead somewhere. What most organisations are doing is theatre. But here is the part that matters: this is the most fixable problem in enterprise AI. The gap between theatre and transformation isn't talent, budget, or better models. It's a handful of structural choices, and they are entirely learnable. The same numbers that look damning are really a map. They tell you exactly what the 5% do that everyone else doesn't. The rest of this piece is that map. What AI theatre looks like</h2> You can spot it from the language. "We're exploring." "We're evaluating vendors." "We have a pilot running with promising results." "We're building our AI strategy." These phrases have one thing in common: they describe activity, not outcomes. Nobody is measuring anything. Nobody has defined what success looks like. And nobody has the authority, or the incentive, to kill something that isn't working. The typical pattern runs like this: A consulting firm is engaged to "develop an AI strategy." They deliver a 60-page deck with a maturity assessment, a vendor landscape, and a phased roadmap. The organisation selects two or three use cases for pilots. The pilots are built by a small team with enthusiastic support from one sponsor. The demos look impressive. Then the pilot hits production-readiness requirements (security review, data governance, integration with existing systems, change management) and stalls. Six months later, the pilot is still "in progress." The team has moved on to the next pilot. The first one quietly dies. The board update still shows green. I've seen this pattern at organisations of every size, from funded startups to FTSE 250 companies. The technology is real. The results are not. Why it happens</h2> Three structural reasons. First, incentives are misaligned. The people evaluating AI tools are not the people whose P&L depends on the outcomes. When the innovation team's KPI is "number of pilots launched" rather than "revenue impact of deployed systems," you get exactly what you'd expect: lots of pilots, no production systems. Second, the process is backwards. Deloitte's research shows that organisations taking a work-redesign approach, rethinking processes before selecting tools, are twice as likely to exceed ROI targets than those starting with the technology. But redesigning processes is hard, political, and slow. Buying a tool and running a pilot is fast, visible, and feels like progress. Third, nobody has done it before. Most organisations don't have a senior leader who has built production AI systems. They have people who have evaluated them, recommended them, and managed pilots of them. The people making the call have usually watched a demo, not built one</a>. The gap between "this demos well" and "this runs in production at scale" is enormous, and it's a gap that only operating experience can bridge. What the alternative looks like</h2> The organisations that get real results from AI share a few characteristics. They start with the P&L, not the technology. Before selecting any tool or model, they identify a specific business process where AI can deliver measurable improvement, and they define what "measurable" means upfront. Not "efficiency gains." A number. A KPI. A target. They redesign the workflow. Prosci's research across 1,107 organisations found that 63% of AI failures trace to human factors, not technology. The organisations that succeed don't bolt AI onto existing processes. They redesign the process around what AI can and can't do, with clear decision delegation: what the system decides, what a human decides, and where the handoff happens. They deploy to production in weeks, not quarters. At AdBrain, we had an agentic AI system handling real customer cases within weeks of starting the build. Not because we cut corners. Because we scoped tightly. One process. One set of decisions. Full governance. Measured KPIs from day one. The result: 67% autonomous case resolution</a>, 23% sales lift. Production, not pilot. They kill what doesn't work. This is the hardest part. Most organisations don't have kill criteria for AI initiatives. If it's not working after 90 days, they add more resources or extend the timeline. The right move is to kill it, learn from it, and redirect the investment to something that can deliver. The 90-day test</h2> If you want to know whether your AI programme is performance art or real transformation, ask yourself three questions: Can you name one AI system in production that is measured by a business KPI? Not "deployed." Not "being used by the team." Measured. With a number. That someone reports on. Do you have kill criteria for your current AI initiatives? Is there a defined point at which you'd stop investing in a pilot that isn't delivering? Has anyone in your leadership team built a production AI system before? Not evaluated one. Not managed a pilot. Built one, deployed it, and measured the results. If the answer to any of those is no, you're closer to theatre than transformation. That's not a judgement. It's a diagnosis. And the good news is that the fix is faster than you think. One production system. One set of measured KPIs. One honest assessment of what's working and what isn't. That's the starting point. Everything else is decoration. If you'd like to have that conversation, I'm here</a>. No deck, no maturity assessment. Just an honest view of where you are and what would actually move the numbers. Related: Why your AI spend isn't showing up in the numbers</a> · Agentic AI in 2026: what actually works in production</a> · How I approach AI transformation</a> Shadow AI is your next audit finding 2026-02-04T00:00:00+00:00 Your employees are already using AI. The question is whether you know about it. Cyberhaven's research found that 38% of employees are sharing confidential company data through consumer AI tools: ChatGPT, Claude, Gemini, Copilot. Not through sanctioned enterprise deployments with data handling agreements. Through personal accounts, on personal devices, with no audit trail and no governance. The broader number is worse: 78% of employees are using AI tools their employer hasn't approved. They're summarising client documents, generating financial analysis, drafting legal correspondence, and processing sensitive data through systems their IT and compliance teams don't know exist. This is shadow AI. And it's about to become a very expensive problem. The regulatory clock is ticking</h2> The EU AI Act's major enforcement milestones begin August 2, 2026. That includes transparency obligations, high-risk system requirements under Annex III, and governance structures that most organisations haven't built yet. If you're operating in the EU or processing EU citizen data, which includes most UK businesses with European clients, you need to be ready. Not "aware." Ready. With documented governance frameworks, risk assessments for every AI system in use (including the ones your employees adopted without telling you), and human oversight structures that can withstand regulatory scrutiny. This isn't theoretical. IBM's Institute for Business Value reports that 82% of organisations say AI risks have accelerated their need for governance modernisation. They know the gap exists. Most haven't closed it. Why governance fails when it's treated as a blocker</h2> The instinct in most organisations is to respond to shadow AI with a ban. Lock down the tools, restrict access, send a memo. This doesn't work. The tools are too useful, the workarounds too easy, and the productivity gains too visible for people to stop using them just because a policy document said so. The organisations that get this right treat governance as an enabler, not a blocker. The goal isn't to stop people using AI. It's to channel that usage into managed, monitored, compliant systems that the organisation controls. Governance that makes AI adoption faster, not slower, by removing the ambiguity that forces employees to make their own decisions about what's acceptable. A proper governance framework does three things: First, it maps what's actually happening. A shadow AI audit identifies every tool in use, every data flow, every risk. You can't govern what you can't see. Most organisations are genuinely surprised by what they find. Second, it provides sanctioned alternatives. For every unapproved tool your employees are using, there should be an approved path that's at least as convenient. If the governance framework makes people's work harder, they'll route around it, and you're back to shadow AI. Third, it builds the compliance structure. Risk classifications, human oversight requirements, data handling protocols, incident response procedures. The EU AI Act doesn't require perfection. It requires a demonstrable, documented framework that shows you're managing AI risk systematically. This is the approach I took at NHS Wales</a>, where governance had to withstand national-level scrutiny. The same principles apply at any scale. The cost of waiting</h2> Informatica's 2026 survey of 600 data leaders found that three out of four say governance hasn't kept pace with AI adoption. Nearly 7 in 10 organisations have adopted generative AI, and almost half have moved into agentic AI. The tools are already deployed. The governance is months, or years, behind. The gap creates three categories of risk: Regulatory risk. EU AI Act non-compliance penalties scale to 7% of global annual turnover for the most serious violations. Even for mid-market companies, that's a material number. Data risk. Confidential client data, financial information, proprietary IP, all flowing through systems with no data processing agreements, no audit logs, and no retention controls. Operational risk. Decisions being made based on AI outputs that no one is verifying, using models that no one has validated for the use case, with error rates that no one is measuring. What I'd do in your position</h2> If I were sitting in your seat (CTO, COO, or board member of a company with 50+ employees) I'd do three things in the next 30 days: Run a shadow AI audit. Not a survey. A proper audit. Map the tools, the data flows, and the risks. Accept that you'll find things you didn't expect. Build a governance framework that enables, not restricts. Classify your AI use cases by risk level. Provide sanctioned tools for the high-value, high-frequency use cases. Build monitoring into the approved stack. Set a timeline for EU AI Act readiness. August 2026 isn't far. If you need to be compliant, work backwards from that date and identify every gap. If you'd like help with any of that, let's talk</a>. I've built governance frameworks alongside production AI systems, not as a separate workstream, but as part of the deployment. It's the only way it works. Related: Turning AI theatre into AI that moves the numbers</a> · How to unlock AI ROI: what the 20% do differently</a> · The AI Transformation Sprint</a> How to unlock AI ROI: what the 20% do differently 2026-01-28T00:00:00+00:00 A statistic that should focus the mind of anyone investing in AI: according to multiple industry surveys, roughly 80% of companies have deployed generative AI. And roughly 80% report no material impact on earnings. It's tempting to read that as "AI doesn't pay back." That's the wrong lesson. The returns are real and repeatable, but they have to be unlocked. The 80% aren't evidence that the technology fails; they're evidence that most organisations haven't yet learned how to deploy it. The real risk to your investment isn't outright failure. It's quiet underperformance: an initiative that returns a fraction of what it could, because the work around the tool never changed. This piece is about what the 20% do differently to unlock the return. Why is the easy explanation for AI failure wrong?</h2> The tempting interpretation is that the technology isn't there yet. That LLMs hallucinate too much. That the models aren't reliable enough. That we need better tools before AI can deliver business value. This is comfortable because it requires no action. Just wait. It's also wrong. The organisations delivering measurable ROI from AI are not waiting. They have fundamentally different approaches to how they build and deploy AI systems, and those approaches are not technology-dependent. They're architectural and organisational. What do the 20% of successful AI projects do differently?</h2> 1. They solve the data problem first</h3> Every serious AI deployment that delivers business outcomes starts with a data architecture question, not a model question. The question isn't "which LLM should we use?" It's "can we reliably retrieve the specific information this AI system needs to make good decisions?" In most organisations, the answer to that second question is no. Customer data is fragmented across CRM systems. Product data doesn't conform to a consistent schema. Historical decisions weren't recorded in a way that makes them usable as context. Case notes are in unstructured text with no metadata. Before any AI system can work reliably in production, someone has to make this data retrieval problem tractable. The organisations that skip this step and go straight to building on top of raw, fragmented data end up with AI systems that work inconsistently and unpredictably. Which is worse than no AI at all, because it erodes trust. The 20% treat data architecture as a prerequisite, not a detail. 2. They define the right problem to solve</h3> There's a pattern in AI project failures that goes like this: Organisation decides to "add AI"</li> Team picks a use case that seems tractable: a chatbot, a recommendation engine, a document summariser</li> The use case gets built and deployed</li> Nobody uses it, or it doesn't move any metric that matters</li> Conclusion: "AI doesn't work for us"</li> </ol> The failure happened at step 2. The use case wasn't connected to a problem that the business actually has, in a workflow that people actually use, with a metric that the business actually tracks. The 20% start from the business problem: what is the high-volume, high-friction, high-cost workflow that AI could change? Then they work backward to the AI architecture, not forward from "what's possible with LLMs." For the insurance brokerage I worked with</a> at AdBrain, the problem was specific and measurable: thousands of customer service cases per month, inconsistent handling, slow resolution, agents unable to scale. AI was the solution to that problem, not a technology experiment running parallel to the real business. 3. They invest in production engineering</h3> The gap between "the demo works" and "the system works in production" is where most AI projects disappear. Production AI requires: Retrieval that works at scale, not just in a controlled test environment with clean data</li> Graceful degradation. What happens when the model is uncertain, when the data is missing, when the case is outside the training distribution?</li> Observability. Can you see what the system is doing, why it made each decision, and where it's failing?</li> Human-in-the-loop design. When should the AI handle something autonomously, and when should it escalate? And when it escalates, does the human get the context they need?</li> Audit trails, especially in regulated industries, but increasingly in any consequential business process</li> </ul> The 20% treat production engineering as a first-class concern from the start. The 80% treat it as a problem to solve after the demo works. 4. They stage the rollout</h3> "Big bang" AI deployment almost never works. The 20% deploy incrementally: start with a small fraction of real traffic, measure outcomes against real business metrics, build confidence in the system before scaling. This isn't just risk management. It's how you build institutional trust in an automated system. The people whose jobs the system is affecting need to see it work. Leadership needs to see the metrics move. Compliance needs to see the audit trail. Staged rollout also allows you to catch failures early, in production conditions that your test environment will never fully replicate, without catastrophic consequences. 5. They treat AI governance as a competitive advantage</h3> With the EU AI Act in full effect and organisations increasingly asking hard questions about AI risk, the companies that have built mature AI governance frameworks are at a commercial advantage over those that haven't. This doesn't mean governance as bureaucracy. It means: Clear ownership of AI decisions (the CAIO role or equivalent)</li> Documented decision logic for automated systems</li> Regular accuracy and bias auditing</li> Clear escalation paths when systems fail</li> An approach to EU AI Act risk categorisation for the AI systems you're deploying</li> </ul> Only about 1 in 5 companies have this in place today. That's a gap, and a gap creates differentiation. How do you avoid being in the 80% of failed AI projects?</h2> If you're building or deploying AI, the questions above aren't abstract. They're the questions your enterprise customers' IT and legal teams will ask before signing a contract. They're the questions an acquirer's technical due diligence team will surface during an exit process. They're the questions investors will ask when they want to understand why your AI investment is defensible. Building with these considerations in mind from the start is not slower or more expensive than building without them. It's usually faster, because you don't have to rebuild the parts that break. If you want a quick sense of where your organisation stands on these patterns, try the AI readiness diagnostic</a>. If you want to pressure-test your AI approach against these patterns, get in touch</a>. Related: Your world-class engineering team is already in the building</a> · Agentic AI in 2026: what actually works in production</a> · Turning AI theatre into AI that moves the numbers</a> · Shadow AI is your next audit finding</a> Agentic AI in 2026: what actually works in production 2026-01-14T00:00:00+00:00 Every major technology conference in the last 18 months has featured a demo of an AI agent doing something impressive. Booking a flight. Writing and executing code. Managing a customer enquiry from start to finish. Most of those demos are not production systems. I've built agentic AI in production, at a European insurance brokerage</a> at enterprise scale, with 67% autonomous resolution rates on real customer service cases. I've also watched a significant number of agentic AI projects fail in ways that were entirely predictable. This is an honest account of what the difference looks like. What "agentic AI" actually means</h2> An AI agent, in the technical sense, is a system that can take actions, not just generate text. It can retrieve information, execute tools, make decisions across multiple steps, and produce outcomes in the world rather than just producing responses. The demo version of this: an agent that can look up flight prices, check calendar availability, book a seat, and confirm the booking in a single conversational interaction. The production version of this: an agent that can do the above 10,000 times per day, on inputs that don't match the training distribution, with graceful handling of edge cases, a full audit trail of every decision, and escalation logic that surfaces the cases the agent shouldn't handle autonomously. The gap between those two descriptions is where most agentic AI projects fail. Why most agents don't work in production</h2> Problem 1: Retrieval is the weakest link</h3> Agents are only as good as the information they can access. And in almost every real-world deployment, retrieving the right information, from the right source, in the right format, at the right time, is harder than building the agent logic. Vector databases are not magic. Embedding quality degrades with domain-specific content. Retrieval precision drops sharply when the knowledge base is large, inconsistent, or poorly structured. The agent that works beautifully on clean, curated documentation fails silently on the messy reality of actual enterprise data. The solution is to treat retrieval as an engineering problem of its own, with the same rigour as any other part of the system. Chunking strategies, embedding models, hybrid retrieval combining semantic and keyword search, metadata filtering, reranking. These are not implementation details; they are load-bearing engineering decisions. Retrieval is one of the layers I unpack in you're not talking to an LLM, you're talking to a system</a>. Problem 2: Error propagation in multi-step pipelines</h3> Single-step AI is relatively forgiving. If the model makes an error, you see it, you correct it, you move on. Multi-step agentic pipelines are not forgiving. Each step's output becomes the next step's input. Errors compound. A misclassification in step 1 propagates through the entire pipeline and produces a confident, coherent, wrong answer at the end. Production agents need explicit error detection at each step. They need to know when they're uncertain. They need to know when the input doesn't match the patterns they were built for. And they need escalation logic that fires reliably when these conditions occur. Not optimistically, but conservatively. Problem 3: The state management problem</h3> Conversational agents need to maintain context across a session. Orchestration agents need to manage state across multiple tool calls. Long-running agents need to persist state across interruptions and restarts. State management in agentic systems is genuinely hard. The naive approach, passing the entire conversation history as context on every API call, doesn't scale and degrades performance. The sophisticated approach (explicit state machines, persistent state stores, careful context window management) requires engineering that most early-stage AI projects don't budget for. Problem 4: Testing is much harder than for traditional software</h3> You can write unit tests for functions. You can write integration tests for APIs. Testing an AI agent that takes non-deterministic multi-step actions is a different problem. How do you test a system where the same input can produce different outputs? How do you build a test suite that catches regressions in natural language reasoning? How do you know your agent will handle the edge cases it hasn't seen during development? The answer involves a combination of golden-set evaluation (specific inputs with expected outputs), adversarial testing (deliberately trying to break the agent), and production monitoring (catching failures when they happen and feeding them back into the development process). None of this is impossible, but all of it requires deliberate engineering investment. Problem 5: Trust and adoption</h3> Even when the agent works technically, getting people to trust it, and therefore use it, is its own challenge. A customer service agent that resolves 67% of cases autonomously is only valuable if the remaining 33% that require human handling are escalated smoothly, with full context, to agents who trust the system enough to take the handoff efficiently. Building this trust requires transparency: the human needs to understand why the agent is escalating, what it's already determined, and what information it retrieved. Black-box escalation ("here's a case the AI couldn't handle, good luck") destroys the value of the automated component. What makes agentic AI actually work in production</h2> Based on the systems I've built, the patterns that distinguish production-ready agents from demo-ready agents are: Retrieval engineering as a first-class concern. Not an afterthought. Not a vector database with default settings. A carefully designed retrieval architecture with tested precision and recall at real-world data scale. Conservative escalation logic. Better to escalate unnecessarily than to resolve incorrectly. The agent should know what it doesn't know, and be honest about it. Explicit state management. Every step of the pipeline has observable state. Every decision is logged. Every error is caught and categorised. Staged rollout with real metrics. Start at 10% of production volume. Measure resolution quality, escalation rate, user satisfaction, and business outcomes. Scale when the numbers are good. Human-in-the-loop design that respects human time. The escalation handoff should give the human everything they need to pick up efficiently, not a blank canvas. Production monitoring that catches drift. AI system performance degrades over time as input distributions change. The system needs to monitor for this and surface it proactively. What this means if you're deploying agents</h2> If you're building agentic AI in 2026, the question "can our agent do X?" is the wrong starting point. The question is "can our agent do X reliably, in production, at the scale we need, with the error handling and auditability our customers require?" Most demos say yes to the first question. Very few production systems actually deliver on the second. The founders and small to mid-market teams I work with who get this right are the ones who treat the production engineering question as seriously as the model selection question. From day one, not after launch. Building an agentic AI product and want a second opinion on your architecture approach? Let's talk.</a> Related: How to unlock AI ROI: what the 20% do differently</a> · Why your AI spend isn't showing up in the numbers</a> · How I approach production AI deployment</a> The most important skill in business and life 2023-11-09T00:00:00+00:00 CEO confidence in revenue growth has hit a five-year low. PwC's 2026 survey of 4,454 chief executives across 95 countries found that only 30% are confident, down from 56% in 2022. Mentions of "uncertainty" appeared in 87% of public earnings statements in early 2025. Glassdoor reviews mentioning uncertainty are up 80% year-over-year. The five highest measurements of global economic policy uncertainty ever recorded have all come in the past five years. And this is before the full impact of AI reshapes entire industries. I've led technology teams through several of these inflection points, at NHS Wales</a>, where the wrong call affects millions of people, and at startups, where the wrong call means you run out of runway. The pattern I've noticed is that the skill separating the leaders who thrive from those who freeze is always the same: the ability to make good decisions when nobody knows what happens next. Why uncertainty breaks most leaders</h2> There's a neuroscience explanation for why uncertainty is so paralysing. When the brain encounters uncertain threats, the amygdala fires and cortisol rises. A systematic review of the research found that the resulting stress response significantly impairs decision-making on uncertainty-based tasks. Worse, and this is the part that should concern every leader, elevated cortisol impairs metacognition. You make worse decisions and you don't realise it. This creates a predictable failure pattern in organisations. The leader faces an uncertain situation, say, whether to invest heavily in AI or wait for the technology to mature. Stress rises. The brain's threat response activates. And instead of reasoning clearly, the leader defaults to one of two failure modes: analysis paralysis (delay the decision indefinitely, commission another report) or false certainty (pick a direction with excessive conviction, ignore disconfirming evidence). Both are catastrophic. And both are everywhere. What the evidence says actually works</h2> Jim Collins and Morten Hansen spent nine years studying companies that outperformed their industry index by 10x in chaotic, uncertain environments. Their findings upend the conventional wisdom about visionary leadership. 10X leaders were not more creative, more visionary, or more risk-seeking than comparison leaders. They were more disciplined, more empirical, and more paranoid. Three specific behaviours defined them: Empirical creativity: "fire bullets, then cannonballs." Before making big bets, 10X leaders ran small, low-cost experiments to calibrate their aim. They didn't rely on analysis or intuition alone. They tested. Then, when they had empirical evidence that something worked, they committed resources aggressively. The comparison companies did the opposite: they fired cannonballs first, making large bets based on untested assumptions. Fanatic discipline. 10X companies changed only 10-20% of their strategies over 20 years. Comparison companies changed 55-70%. Consistency, sticking with a validated approach even when the environment was chaotic, beat agility. This is counterintuitive. Most leadership advice says "be agile, pivot fast." The data says the opposite: find what works and hold the line. Productive paranoia. 10X leaders built financial buffers and contingency plans before crises hit, not during them. They assumed bad things would happen and prepared accordingly. They carried more cash, had more contingency plans, and were more attuned to threats than their peers. The most striking finding: luck was evenly distributed across both groups. What differed was what leaders did with it. The OODA loop and pattern recognition</h2> Colonel John Boyd developed the OODA loop (Observe, Orient, Decide, Act) from studying air combat. His insight was that the entity which cycles through this loop fastest doesn't just win. It creates confusion and disorientation in the opponent. But Boyd's most important contribution was identifying orientation as the bottleneck. Not observation, not decision, not action, but the mental model you bring to the situation. Your culture, experience, prior assumptions, and cognitive biases all shape how you interpret what you observe. And when your mental model is wrong, faster action just means you fail faster. Gary Klein's research on expert decision-makers confirms this. He studied firefighters, military officers, and surgeons making high-stakes decisions under time pressure. He found that experts don't compare options analytically. They use pattern recognition from experience to rapidly identify a workable course of action. The quality of their decisions depends on the quality of their mental models, which depend on the depth and breadth of their experience. I saw this firsthand when I served as expert witness in a Hong Kong High Court case</a> involving 39 casualties. The analysis that changed the outcome didn't come from better data. It came from a different way of looking at the same evidence. This is why the best decisions under uncertainty come from leaders who have built diverse mental models through operating experience, not from leaders who have the best analysis or the most data. What this means in the age of AI</h2> The current AI transition is the most significant source of uncertainty in business since the internet. And most leaders are handling it badly. EY's 2026 CEO Outlook found that 82% of CEOs are more optimistic about AI than a year ago, but 60% admit they've intentionally slowed implementation due to fear of errors. Half believe their job stability depends on successfully integrating AI. Gartner reports that 72% of CIOs are breaking even or losing money on AI investments. The pattern is familiar. Uncertainty triggers the stress response. Leaders oscillate between two extremes: rushing to adopt AI without understanding the risks (false certainty) or delaying meaningful action while commissioning strategy decks (analysis paralysis). Collins's research suggests a better approach, one I use with every organisation I work with: Fire bullets first. Don't bet the business on a comprehensive AI transformation. Pick one high-value process. Build a focused AI solution. Measure it against a real business metric. Learn from what works and what doesn't. Then, and only then, fire the cannonball. Be empirical, not ideological. The AI debate has become tribal: accelerationists versus sceptics, maximalists versus minimalists. None of that matters. What matters is whether the specific AI system you're building moves a specific number that your business cares about. If it doesn't, kill it.</a> If it does, scale it. Build the buffer. Productive paranoia in the AI context means keeping the skills and the people you'll need if the technology doesn't deliver what it promises. It means not cutting your junior engineering pipeline</a> to fund AI tools that might not work. It means maintaining optionality, the ability to change course without catastrophic cost. The Kodak lesson</h2> Kodak invented the digital camera in 1975. Their leadership buried it because they feared cannibalising their film business. Despite a succession of new CEOs and mounting evidence that digital photography was the future, the organisation couldn't adapt. The result: an 80% workforce decline, a collapsed stock price, and a bankruptcy filing after more than a century of market dominance. Nokia's engineers presented a full touchscreen phone prototype to management. The response: "that's not how phones work." The company lost roughly $100 billion in market value. Blockbuster's executives dismissed Netflix as a "very small niche business" and turned down a $50 million acquisition offer. Netflix is now worth over $100 billion. In every case, the failure wasn't a lack of information. It was a failure of orientation. Boyd's bottleneck. The mental models of the leaders in the room couldn't accommodate the change they were facing. So they didn't. The leaders navigating AI well today, and I include Satya Nadella's transformation of Microsoft from a $300 billion company to a $2.5 trillion one among the best examples, share a different orientation. They treat their mental models as provisional. They expect to be wrong about some things. They test, measure, and adjust. And they maintain the discipline to hold their nerve when the uncertainty is highest. Eisenhower put it best: "Plans are worthless, but planning is everything." The value isn't in the plan. It's in the thinking the plan forces you to do. And when reality diverges from the plan, as it always does, that thinking is what allows you to improvise effectively. That's the skill. Not predicting the future. Not having the best strategy. Not being the most decisive person in the room. Just the ability to think clearly when nobody knows what happens next, and to act on that thinking with discipline. It's the most important skill in business. And it's learnable. If you're making technology decisions under uncertainty and want a second perspective, a fractional CTO engagement</a> is one way to get it. Or simply get in touch</a>. Related: Turning AI theatre into AI that moves the numbers</a> · Your world-class engineering team is already in the building</a> · NHS Wales: transformation at national scale</a> · How I work</a> The most powerful yet overlooked tool in a leader's arsenal 2023-10-13T00:00:00+00:00 A Wharton study gave a university director one task: visit a group of fundraisers and say, sincerely, "I am very grateful for your hard work. We sincerely appreciate your contributions." That was it. No bonus. No promotion. No formal programme. Just a human being telling other human beings that their work mattered. The result: the thanked group made 50% more fundraising calls the following week. The control group (same job, same pay, same conditions, no visit) showed zero change. The researchers, Adam Grant and Francesca Gino, found the mechanism wasn't confidence. It was social worth. Being thanked made people feel valued as members of a community. And that feeling, belonging and mattering, drove behaviour more powerfully than any incentive scheme could. This is not a soft finding. It's one of the hardest results in organisational psychology. And most leaders ignore it. The numbers behind "thank you"</h2> Gallup and Workhuman ran a longitudinal study tracking 3,400 employees from 2022 to 2024. The headline finding: employees who received high-quality recognition were 45% less likely to have left two years later. That's not a marginal effect. That's nearly half of voluntary turnover, preventable. The same study found that employees who felt fulfilled by recognition were 4x as likely to be engaged and 65% less likely to be actively job-searching. For a 10,000-person company, Gallup estimates that a strong recognition culture saves up to $16.1 million in turnover costs annually. And yet only 22% of employees say they receive the right amount of recognition. That number hasn't moved since 2022. The data from other sources converges on the same point. O.C. Tanner's Global Culture Report found employees are 18x more likely to produce great work when recognition is integrated and personalised. Deloitte found that organisations with recognition programmes see 14% higher engagement, productivity, and performance than those without. A 15% improvement in engagement translates to a 2% increase in margins. 79% of employees who quit cite lack of appreciation as a major reason. 59% say they have never had a boss who truly appreciates them. These are not small numbers. These are systemic failures of leadership. What happens in the brain</h2> The neuroscience is straightforward. Recognition triggers dopamine, the reward signal that drives motivation and reinforces behaviour. It also triggers oxytocin, which builds trust and social bonding. And serotonin, associated with well-being and satisfaction. The dopamine effect creates a reinforcement loop: when someone is recognised for a behaviour, the neurochemical reward makes them more likely to repeat it. This isn't metaphorical. It's the same mechanism that makes habits form. Recognition literally rewires the brain's reward circuitry. An Indiana University study found that participants who practised gratitude showed lasting increases in neural sensitivity in the medial prefrontal cortex, months after the intervention. The brain doesn't just respond to recognition in the moment. It adapts structurally over time, becoming more attuned to positive signals. Gratitude, given and received, compounds. The story I can't forget</h2> Years ago I was working with an exceptional team of software engineers at a company that was, genuinely, considered a gold standard in culture and talent development. The team had just finished a multi-month crunch. They'd been fighting like lions to enable the business to win a massive multi-year, multi-billion pound contract. Weekends. Late nights. The kind of sustained intensity that burns people out even when the outcome is good. One engineer was the technical leader of the entire effort. He'd worked harder, and had done more to make the successful outcome happen, than anyone else on the team. When the win was announced, the company's senior leaders praised their own effort. Publicly and privately, they thanked themselves. The engineer who had made it happen, the person who'd given months of his life to the outcome, went unnoticed. What followed was predictable, if you know the research. He quietly quit. Not formally. He stayed in his seat. But the engagement evaporated. He became negative. The negativity spread. Productivity across the team visibly dropped. Within a few months, he left. Several colleagues followed. These were engineers with rare, specialised skills, the kind that take years to develop and months to replace. The cost to the company was enormous, and it compounded for over a year. At the exit interview he told me that the lack of appreciation was the turning point. He'd realised the leadership didn't care about their people. That the values and the speeches were, in his experience, hollow. All it would have taken was a "thank you." Gallup's data says employees who received recognition in the prior month saw their attrition risk decrease by 58%, their perception of growth opportunities increase by 108%, and their positive perception of leaders increase by 180%. One moment of genuine recognition. Those are the numbers. Why this matters more now than ever</h2> I want to make the connection to the current moment, because I think it's important. We are in the middle of the most significant transformation of knowledge work in a generation. AI is changing what engineers do, how teams are structured, and what skills matter. McKinsey found that 70% of large-scale transformations fail, and the primary reasons are employee resistance and poor change management. BCG puts it at 70% of AI implementation challenges being people problems, not technical ones. People who are anxious about their relevance, and a lot of engineers are anxious right now, don't need another all-hands presentation about the AI roadmap. They need to know that their contribution matters. That the years of expertise they've built aren't invisible to the people making decisions about the future. Nearly half of CEOs in one survey admitted their employees were resistant or openly hostile to AI-driven changes. The instinct is to respond with more communication, more training, more change management programmes. And those things matter. But the most powerful intervention is also the simplest: seeing the person, acknowledging their work, and saying thank you. Highly engaged employees experience significantly fewer negative effects of change-related stress. And engagement, as every study cited above confirms, is driven more by recognition than by any other single factor. Making it real</h2> If recognition is so effective and so cheap, why don't more leaders do it? HBR published research showing that more powerful people express less gratitude. As leaders gain authority, they become less attuned to the contributions of others. It's not malice. It's a cognitive shift. Power narrows attention toward goals and away from people. The very thing that makes someone an effective leader in some dimensions makes them worse at the human dimension that matters most. The fix is simple but requires intention. Be immediate. Recognition delayed is recognition diluted. The Grant/Gino study showed the effect in the same week. When someone does good work, say so then. Not at the next performance review. Not at the next all-hands. Now. Be specific. "Great job" is better than silence. But "the way you structured that data pipeline saved us two weeks of rework" is better than "great job." Specificity signals that you actually noticed the work, not just the outcome. Be genuine. People detect performative gratitude instantly. If you don't mean it, don't say it. But if you genuinely believe someone's work mattered, and if you're paying attention you'll find evidence of this every day, say so. The bar is not eloquence. The bar is sincerity. Make it structural, not optional. The organisations with the best retention don't rely on individual managers remembering to say thank you. They build recognition into the operating rhythm: weekly stand-ups, code reviews, project retrospectives. Google's gThanks programme lets any employee nominate a colleague for a small bonus. The mechanism matters less than the consistency. The engineering leader who builds a culture of genuine recognition will retain more of their best people, build more resilient teams, and navigate the AI transition with less friction than the one who doesn't. I've led teams at national scale in the public sector</a> and in defence environments where the pressure is relentless</a>. The teams that delivered best were the ones where recognition was part of the operating culture, not an afterthought. The data is unambiguous on this point. And it starts with two words. Related: The best technology rarely wins. The best-led team does</a> · The training ladder is broken</a> · Does your business need a CTO?</a> · Fractional CTO services</a> Fractional CTO. Is outsourced technology leadership right for you? 2022-09-28T00:00:00+00:00 The fractional CTO model exists because of a real gap. You need senior technical leadership for architecture decisions, investor credibility, hiring, and AI strategy, but a full-time CTO hire is either unaffordable, impractical, or premature at your stage. I've been on both sides of this. I've been the full-time CTO. I've been the fractional CTO stepping into organisations mid-crisis. And I've worked with companies that tried to do without one entirely. The last option is almost always the most expensive. When does a fractional CTO engagement work?</h2> A fractional CTO engagement works when the organisation has real technology decisions to make but doesn't yet need, or can't yet justify, a full-time executive hire. That typically looks like: Post-seed or Series A. You have 3-20 engineers and no technical co-founder. Architecture decisions are being made by the most senior developer, who may be excellent at engineering but hasn't done this at company level before.</li> Technical co-founder departure. The scenario every funded startup dreads. I stepped into exactly this situation at Mentor360, stabilised the team, and secured a Royal Navy contract during a period that could have derailed the company.</li> AI deployment. You're building AI into your product or operations and need someone who's done it in production, not someone who's read about it. The insurance automation case</a> is a good example of what this looks like in practice: agentic AI resolving 67% of cases autonomously, designed and deployed during a fractional engagement.</li> Fundraise or exit preparation. Investors and acquirers will ask hard technology questions. You need a credible technical voice in the room.</li> </ul> In these situations, a fractional CTO at 2 days per week gives you 80% of the strategic value of a full-time hire at a fraction of the cost, without the six-month recruitment process or the risk of a bad hire. What are the honest disadvantages of a fractional CTO?</h2> I'd be doing you a disservice if I didn't name these. Limited availability. A fractional CTO isn't in the building every day. The trade-off is that you're paying exclusively for the high-value strategic work (architecture decisions, hiring guidance, investor preparation) rather than a full-time salary that includes meetings, email, and organisational overhead. Whether that trade-off works depends on your stage and needs. Temporary by design. A fractional engagement isn't a permanent commitment. That's a feature for some organisations and a limitation for others. The best arrangements either evolve into something more permanent or end with a clear handover to a full-time hire. Less skin in the game. A fractional CTO doesn't have equity (I don't take it; it keeps incentives clean). That means the relationship is professional, not existential. For most engagements, this is healthy. But it's worth being honest about the dynamic. Quality varies enormously. This is the biggest risk. The fractional CTO market has grown fast, and not everyone offering the service has the experience to back it up. "CTO" on a LinkedIn profile doesn't mean someone has built production systems, managed engineering teams, or sat in an investor meeting with hard questions coming. Two things to look for: independence and operating experience. A fractional CTO provided by a development agency has a structural conflict of interest. Their agency benefits from recommending more development work. And a fractional CTO who has only advised but never built lacks the pattern recognition that comes from being in the seat when things go wrong. My background</a> includes four exits, CTO roles at NHS Wales and in defence technology, and production AI systems. That operating experience is what makes fractional work credible. How do you evaluate whether a fractional CTO is right for your business?</h2> Before engaging a fractional CTO, including me, ask yourself: Do you have real decisions to make? If you need architecture direction, hiring guidance, or investor preparation in the next 90 days, a fractional CTO earns their fee quickly. If you need someone to write code, hire a senior engineer. Is the timing right? A fractional CTO adds the most value at inflection points: post-raise, pre-exit, during a scaling push, or when AI deployment is on the roadmap. If you're in steady-state with a functioning team, lighter-touch advisory may be more appropriate. Can you define the scope? The best fractional engagements have clear boundaries: weekly cadence, defined responsibilities, specific deliverables at 90 days. Open-ended arrangements tend to drift. Is a fractional CTO right for you?</h2> Having senior technical leadership is not optional for technology-driven businesses. The arrangement (full-time, fractional, or advisory) depends on your stage, budget, and needs. If you're weighing the options, a conversation is a good starting point</a>. No commitment, just an honest assessment of what you actually need. Related: Does your business need a CTO?</a> · Fractional CTO service details and pricing</a> · How I work</a> · Case study: NHS Wales transformation</a> Does your business need a CTO? 2022-06-30T00:00:00+00:00 I've watched this pattern play out dozens of times. A founder or managing director knows their business depends on technology but isn't sure whether they need a CTO. They assume it's a hire they can defer, something for later, when the budget is bigger or the product is further along. Deferring the CTO decision is almost always a mistake. By the time founders realise it, the cost of operating without senior technical leadership has already compounded. What is the real cost of operating without a CTO?</h2> The obvious risk is bad architecture decisions. But the deeper problem is subtler: you don't know what you don't know. Without senior technical leadership, you can't evaluate whether your engineering team is building the right thing in the right way. You can't assess vendor claims. You can't tell whether your AI pilot is genuinely promising or a well-produced demo. You can't prepare for the technical questions investors or acquirers will ask. The kind of analytical rigour that changes outcomes</a> simply isn't present without someone whose job it is to provide it. I've seen companies lose months of engineering time, sometimes years, to decisions that a competent CTO would have caught in week one. Wrong cloud provider for the use case. Wrong data architecture for the product. Wrong hiring profile for the stage. Each of these compounds quietly until the bill comes due, usually at the worst possible moment: during a fundraise, an exit process, or a scaling push. What does a CTO actually do?</h2> The title means different things at different stages. But at its core, a CTO does six things: Sets technology strategy. Not in isolation. In lockstep with business strategy. Every serious business decision has a technology dimension. The CTO ensures those dimensions are visible before commitments are made. Defines what to build. Which products, which features, in what order. This isn't a technical exercise. It's a commercial one, informed by technical reality. The CTO translates business priorities into engineering priorities. Decides how to build it. Build or buy. Internal team or outsource. Which stack, which architecture, which deployment model. These decisions determine speed, cost, and scalability for years. Getting them wrong at Series Seed creates Series B problems. Executes the roadmap. Plans, builds or sources the team, manages the development process. Owns the delivery. Translates between business and engineering. In board meetings, investor calls, and cross-functional discussions, the CTO makes technology decisions legible to non-technical stakeholders. This is where fundraises succeed or stall. Investors need to trust that someone credible is making the technology calls. Leads the engineering team. Hires well, structures the team correctly for the stage, shields engineers from organisational noise so they can focus on deep work. The leadership mistakes at this stage are expensive. A bad senior hire can set you back six months. Why is a CTO's role strategic, not just technical?</h2> A great CTO isn't the best coder in the room. They're the person who sees what's coming: the technology shift that creates an opportunity, the architectural decision that will box you in, the vendor relationship that's about to become a liability. I've held this role at national scale, at NHS Wales, where the wrong technology call has consequences for millions of people, and at startups, where the wrong call means you run out of runway. I've also been a founder four times</a>, so I know the other side of the table too. The stakes vary. The discipline is the same. When does a business actually need a CTO?</h2> Whether you're a 5-person startup or a 200-person mid-market company, if technology is core to your business, you need CTO-calibre thinking in the room. The question is the arrangement. A permanent, full-time CTO is ideal, but it's expensive, takes months to hire well, and the cost of hiring the wrong one is severe. Various alternatives work: interim, fractional, or advisory arrangements all prove superior to having no senior technical leadership at all. If a permanent hire isn't feasible yet, a fractional CTO engagement</a> gives you the expertise at a fraction of the cost, with none of the hiring risk and all of the strategic value. Related: Fractional CTO: is outsourced technology leadership right for you?</a> · The best technology rarely wins. The best-led team does</a> · Four companies, four exits</a> · How I work as a Fractional CTO</a>

CTO Zen | Fractional CTO & AI Advisory - Insights. AI Strategy, Technology Leadership & Production AI

The best technology rarely wins. The best-led team does

Your world-class engineering team is already in the building

Agile is now the bottleneck

Who is accountable for AI on your board?

What proportionate governance looks like</h2> Not a forty-page policy. For a company your size, five things:</p>

How to build an AI strategy without a CTO

You don't need to build a brewery to drink a pint of beer

Your four options</h2> Build an internal team.</strong> Best when the technology is core, proprietary, regulated, or long-term. Most control, often cheaper over time, but slow to assemble and demanding to lead.</li>

After 20 years as a CTO, I learned the engineering was the easy part

Fractional CTO or AI consultancy? Don't hire the consultancy first

Why your tech recruiter isn't on your side

How to use a recruiter without getting fleeced</h2> Used well, an agency gives you one valuable thing: a flow of candidates you would not have found. Treat that as a supplement to your process, never a replacement for it.</p>

AI is about to split the job market in two

If your AI strategy is just ChatGPT, you don't have one

From AI that talks to AI that works: the autonomous leap of 2026

How big tech wins the talent war, and it isn't the money

The hidden conflict of interest in hiring a fractional CTO

The quality you can't see is the one that kills you

What to do when your AI pilot fails

The people making the biggest AI decisions understand it the least

You're not talking to an LLM. You're talking to a system

Agent sprawl is the new shadow IT. Your business needs a control plane

Headless is the new mobile-first. Agents are about to become your biggest user

Uber burned through its token budget by April. Your business will be next

Stop counting AI use cases. Redesign three value streams instead

75% of Google's new code is AI-generated. So what?

Most of what you do at work will be automated. The interesting question is what won't

AI is not just for engineering. Every function in your business can use it today