AI is at the forefront of every board's agenda. No one wants to be the organisation left behind, and the potential upside is real. But the mandate reaching technology, product and engineering leaders is often generalised: create an AI strategy, or reduce headcount to force innovation through AI. The intent is sound. The framing is not.

A broad instruction to "just use AI" without defining the problem puts leaders in an awkward position. It treats AI as an objective rather than a means, and it quietly assumes the value will materialise once the technology is switched on. It rarely does. The leaders who are getting the most from AI are the ones who have resisted the pressure to adopt it for its own sake and have instead started from a much harder question: where does value actually flow through this organisation, and where does it get stuck?

AI can absolutely be used as a tool. Point it at repetitive analysis, rapid prototyping, or the redesign of a clunky process and you will see genuine productivity gains. Teams in the room described testing and learning at a pace they had not experienced before. But used purely as a tool, bolted onto existing ways of working, the value is capped.

The shift happens when you stop asking "where can we use AI?" and start asking "how does work flow through our organisation, and how does AI change that flow?" Viewed through that lens, AI stops being a feature and becomes a reason to rethink processes, hand-offs, roles and responsibilities. Those changes are broad. They reach well beyond the engineering function and demand collaboration across the whole business. This is precisely why a mandate aimed only at the technology org tends to underdeliver: the biggest gains sit in the seams between functions, not inside any one of them.

Several threads from the session illustrate the point.

The most cited risk was not a technical failure but a human one, which the group called cognitive surrender: the tendency to accept AI output without applying critical thought. One leader described a process documented entirely by AI, without ever speaking to the people who actually operated it. The result was generic and unusable. The lesson is not that AI failed; it is that value was never in the document. It was in the human context the exercise skipped.

Reshaping the organisation was another recurring theme. Some leaders are building "Heads of-weighted" teams, hiring senior, hands-on practitioners who can direct AI to do the heavy lifting, rather than layering on oversight roles. Others are pushing engineering capability directly into business units, with central tech shifting its focus to security, data protection and cost efficiency rather than dictating which problems to solve. Both moves make the same underlying bet: that AI's value is unlocked by changing who does what and where decisions are made, not simply by giving the existing structure a new tool.

Product is experiencing the same shift. When AI closes the execution gap and building becomes cheap, the harder question surfaces immediately: are we building the right thing at all? The long discovery phase is giving way to rapid prototyping and iteration in front of real users. The product managers thriving in this environment are those with strong critical thinking, curiosity and judgement, rather than those who manage long delivery timelines. Again, the technology forces a question about value that the organisation has to answer with more than engineering.

Even the cost of AI is being turned to advantage. Several leaders described using the price of tokens as deliberate, positive friction, a "token tax" that forces teams to be intentional about what they build and scale. It is a neat example of the mindset that separates the leaders getting value from those merely adopting: constraints used to sharpen focus on the problems that matter.

If your instinct is to mandate AI, mandate the outcome, not the tool. Ask your teams to show where value is stuck and how a redesigned flow of work would release it. Expect the answer to involve changes to process and structure that reach beyond engineering, and resource the collaboration those changes require. Treat headcount decisions as a consequence of that redesign, not a lever you pull first to force it.

None of this dampens the enthusiasm in the room, and that is worth ending on. After long, established careers, many of the leaders spoke of a genuine reinvigoration in tackling these problems. The opportunity is real. It is just larger, and more organisational, than "just use AI" would suggest.