Aristotle, Edison, and Monday Morning.

Idea in brief

• Most transformation programmes fail because they are led by technology. GenAI makes that failure mode more dangerous, not less.
• The right starting point is three parallel tracks — a CEO-owned strategic thesis, a bottom-up outcome redesign, and a capability engine — not a list of use cases.
• The roadmap lives where strategic materiality and execution feasibility overlap. Refresh it every three to six months.
• GenAI is an operator on top of the legacy stack. The humans in the loop become managers of operators, not faster typists.
• Adoption is not value. Measure the delta in the handful of KPIs that actually matter for the business.

I’ve been asked the same question three times in the last few weeks – by different counterparts, in completely different businesses. “How do you actually do this? When you walk into a new business that says ‘we want to do GenAI’, where do you begin?”

The honest answer starts with a sober statistic – roughly 70% of transformation programmes fail to deliver their stated value. They fail for a consistent reason: they are led by technology and tech functions. As technology does the how – not the what and the why – in most cases it does not challenge the core assumptions, the methods, the disciplines, or the way of doing things. And as a result, these programmes in most cases (assuming the tech works) would play around the edges, rather than moving the business needle in a meaningful way. In other words, real transformation requires the company to self-disrupt by doing the same thing fundamentally better.

GenAI makes this a higher-order problem. It does not just change the how; in many sectors it changes the what and the why. GenAI automates the intelligence layer, which means human work moves up to the judgement layer – and the design problem moves with it. Now the question is not only “how do we do this work better?” but “what work should we even be doing, given what GenAI can now do?” That sharpens the outcome question, because GenAI forces an outcome-based mental model. If three out of four legacy transformation programmes failed when the task was to redesign the how, the failure rate for transformation programs that require a fundamentally new operating model with GenAI will almost certainly be much higher.

One manifestation of this failure mode shows up as pilot purgatory: dozens of use cases, plenty of activity, little measurable change in unit economics, value chain position, or organisational shape.

The right starting point is therefore not a use case, and should certainly not be led by the tech function. It is a combination of two figures – Aristotle and Thomas Edison. The philosopher and the inventor. Top-down structural thinking, and bottom-up trial and error. Aristotle gives you the categories; Edison tells you what works when you actually plug it in. They are complementary, and the roadmap to GenAI lives where they overlap.

Operationally, that translates into three tracks running in parallel. First, a CEO-owned strategic thesis on how GenAI changes the economics, value chain, customer proposition, and right to exist of the business. Second, a bottom-up, outcome redesign that shows where GenAI is fit to work with the people, data, and constraints the business actually has. Third, a Monday-morning capability engine – literacy, tools, Skills, governance, measurement, and an operating model to support it. The roadmap lives where the first two overlap; the third is what makes it executable.

Let me explain.

Aristotle: the top-down view

Technology, even GenAI, exists within context. The difference is that GenAI also changes the context. Two variables, two equations.

This is not a stylistic flourish. It is the single most important conceptual point about GenAI. Cloud, mobile, and SaaS were strategic too, and each changed parts of the context they operated in – cost curves, distribution, delivery, customer expectations. But none of them automated the scarce cognitive layer of the enterprise. They were, in the end, enablers of an existing strategy. GenAI is different. It can change the market dynamics and the core assumptions of the strategy itself. It is not a derivative. In many cases, it forces the business back to first principles at the CEO level – because the question is no longer “how do we improve our model” but “what is our model when intelligence is automated, cheap, and widely accessible”.

The philosopher’s question is therefore: what does this business look like in the GenAI world? Not next quarter. Four, five, six years out. More specifically, in a world where a large share of cognitive work is automated, cheap, and widely accessible. The change management overlay, the technology stack, the organisational redesign – ignore these for a moment. The Aristotelian question is the prior one: what is this business’s right to exist when intelligence is automated and democratised?

What is this business’s right to exist when intelligence is automated and democratised?

A business has a right to exist – and the ability to charge a premium rather than become a commodity – for one of two reasons. Either it controls or significantly influences distribution. Or it has something genuinely unique about its product: a feature, a capability, or a cost position no one else can replicate cheaply. Distribution and product. Those are the two dimensions that survive every era. The Aristotelian question therefore decomposes into two sub-questions. In the GenAI world, who owns distribution? Does the business still control it, or does GenAI route around it? What about the product is unique enough to survive? Which features, which capabilities, which cost positions remain defensible when intelligence is automated and the cost of producing similar output collapses? Both questions need to be answered before any operational track begins.

Take the software industry as a specific example. There is a long-running debate about whether software disappears in the GenAI era. The debate is interesting, but the right analogy is the carriage, the horse, and the car. When the car arrived, the carriage’s chassis and wheels survived in a different form. The horse did not. Software is the chassis – the structural substrate that carries the workload. GenAI is the engine. Where deterministic code is genuinely required – systems of record, regulated audit trails, integrations where agentic execution cannot meet the accuracy or auditability bar – the software remains. Everywhere else, the value proposition shifts upwards into the intelligence layer, where a disproportionate share of the business value will sit.

That kind of structural rewrite is what the philosopher’s view tries to surface. It produces a reasoned, microeconomic-level picture of what the business looks like in a GenAI-native world – and, by reverse engineering, what the cost structure, the value chain, the headcount profile, and the unit economics should look like when we get there.

There is a parallel rewrite on the demand side. In a world where every customer has frontier models in their pocket, customer expectations of what a company should deliver – speed of response, depth of self-serve, personalisation at scale, willingness to wait at all – are being reset too. The Aristotelian question therefore covers four interlocking pieces: cost structure in the GenAI world, customer expectations in the GenAI world, who owns distribution, and what remains unique about the product. For some businesses, the demand-side and distribution-side rewrites are faster and harder than the supply-side ones.

Two practical observations about this exercise.

The first is that it cannot happen without the CEO. Not the CTO. Not the CIO. Not the CDO. The CEO is the binary variable, because only the CEO carries the accountability for the right-to-exist question. The reason is structural: GenAI forces trade-offs across cost, risk, customer proposition, organisational design, and capital allocation simultaneously. No functional leader can make those trade-offs on behalf of the enterprise. Strategy at this register, delegated downward, becomes a slide deck.

The second is that the conversation needs people in the room who understand both model capability and industry economics. Most boards and ExCos do not understand the technology to the point of expressing a defensible personal opinion – and that is the problem they need to fix. They don’t need to understand the bits and bytes. However, they do need a strong conceptual grasp, ideally grounded in first-hand experience with the tools, sufficient to engage with the strategic conversation rather than outsource it. Advisors can supplement that capability – from inside the business, outside, or both – but they cannot replace it. Without that combination, the discussion collapses into either technology theatre or strategy theatre.

The output of the philosopher is a thesis. Not a roadmap. The roadmap requires Edison.

Edison: The Bottom-Up View

Aristotle: The Top-Down View

Technology, even GenAI, exists within context. The difference is that GenAI also changes the context. Two variables, two equations.

This is not a stylistic flourish. It is the single most important conceptual point about GenAI. Cloud, mobile, and SaaS were strategic too, and each changed parts of the context they operated in – cost curves, distribution, delivery, customer expectations. But none of them automated the scarce cognitive layer of the enterprise. They were, in the end, enablers of an existing strategy. GenAI is different. It can change the market dynamics and the core assumptions of the strategy itself. It is not a derivative. In many cases, it forces the business back to first principles at the CEO level – because the question is no longer “how do we improve our model” but “what is our model when intelligence is automated, cheap, and widely accessible”.

The philosopher’s question is therefore: what does this business look like in the GenAI world? Not next quarter. Four, five, six years out. More specifically, in a world where a large share of cognitive work is automated, cheap, and widely accessible. The change management overlay, the technology stack, the organisational redesign – ignore these for a moment. The Aristotelian question is the prior one: what is this business’s right to exist when intelligence is automated and democratised?

A business has a right to exist – and the ability to charge a premium rather than become a commodity – for one of two reasons. Either it controls or significantly influences distribution. Or it has something genuinely unique about its product: a feature, a capability, or a cost position others would struggle to replicate cheaply. Distribution and product. Those are the two dimensions that survive every era. The Aristotelian question therefore decomposes into two sub-questions. In the GenAI world, who owns distribution? Does the business still control it, or does GenAI route around it? What about the product is unique enough to survive? Which features, which capabilities, which cost positions remain defensible when intelligence is automated and the cost of producing similar output collapses? Both questions need to be answered before any operational track begins.

Take the software industry as a specific example. There is a long-running debate about whether software disappears in the GenAI era. The debate is interesting, but the right analogy is the carriage, the horse, and the car. When the car arrived, the carriage’s chassis and wheels survived in a different form. The horse did not. Software is the chassis – the structural substrate that carries the workload. GenAI is the engine. Where deterministic code is genuinely required – systems of record, regulated audit trails, accuracy levels agentic systems can’t meet economically – the software remains. Everywhere else, the value proposition shifts upwards into the intelligence layer, where a disproportionate share of the business value will sit.

That kind of structural rewrite is what the philosopher’s view tries to surface. It produces a reasoned, microeconomic-level picture of what the business looks like in a GenAI-native world – and, by reverse engineering, what the cost structure, the value chain, the headcount profile, and the unit economics should look like when we get there.

There is a parallel rewrite on the demand side. In a world where every customer has frontier models in their pocket, customer expectations of what a company should deliver – speed of response, depth of self-serve, personalisation at scale, willingness to wait at all – are being reset too. The Aristotelian question therefore covers four interlocking pieces: cost structure in the GenAI world, customer expectations in the GenAI world, who owns distribution, and what remains unique about the product. For some businesses, the demand-side and distribution-side rewrites are faster and harder than the supply-side ones.

Two practical observations about this exercise.

The first is that it cannot happen without the CEO and the CEO only. The CEO is the binary variable, because only the CEO carries the accountability for the right-to-exist question. The reason is structural: GenAI forces trade-offs across cost, risk, customer proposition, organisational design, and capital allocation simultaneously. No functional leader can make those trade-offs on behalf of the enterprise. Strategy at this register, delegated downward, becomes a slide deck.

The second is that the conversation needs people in the room who understand both model capability and industry economics. Most boards and ExCos do not understand the technology to the point of expressing a defensible opinion – and that is the problem they need to fix. They don’t need to understand the bits and bytes. However, they do need a strong conceptual grasp, ideally grounded in first-hand experience with the tools, sufficient to engage with the strategic conversation rather than outsource it. Advisors can supplement that capability – from inside the business, outside, or both – but they cannot replace it. Without that combination, the discussion collapses into either technology theatre or strategy theatre.

The output of the philosopher is a thesis. Not a roadmap. The roadmap requires Edison.

Edison: The Bottom-Up View

The Aristotelian view tells you what the end state should look like in a GenAI world. It does not tell you what to do on Monday morning. That gap is where most strategic GenAI conversations die – the board has heard the slide on industry transformation, agreed it’s important, and has no idea how to translate it into action, even if they managed to articulate the strategy correctly.

This is the inventor’s job. Trial and error. Learning by doing. Bottom-up, hands dirty.

In financial services and professional services – the sectors I work in most – it begins with a process audit. A clear, front-to-back understanding of current systems, people, processes, transaction volumes, handovers, bottlenecks, inefficiencies. A complete map, with a word of caution: in contrast to the BPM/RPA process audit we had been doing until two years ago, GenAI doesn’t automate the steps of an existing process; that’s the wrong abstraction. GenAI changes the design of work itself, and design follows outcomes. The process audit is useful only because it lets you see, accurately, what the current activity is trying to achieve – the outcomes and sub-outcomes that the existing processes serve. Once you know the outcomes, the existing process can be set aside, and the work redesigned from first principles.

That redesign – outcome-based design – is the central artefact of the inventor’s work. The artefact has a name: the outcome contract. One page per workflow, with eight fields: outcome statement; baseline and target metrics; data primitives; authority level; guardrails; human-in-the-loop design; evaluation against a measured human baseline; and kill-switch criteria. Each has its own subtleties, but the artefact’s force is that all eight live on one page.

One field is worth pulling out, because it is where most programmes default to over-supervision: human-in-the-loop design — which has four legitimate reasons: (1) a legal or regulatory requirement; (2) cost of error, where the consequences of getting it wrong outweigh the efficiency gain of full automation – including where the level of expertise involved is the binding factor; (3) liability, where the decision needs a named, accountable human separately from the error rate – a governance question, not an accuracy one; and (4) relationship value, where the human contact is itself part of what the customer is buying. Each implies a different governance and design pattern; conflating them is what produces the over-supervision that quietly kills the productivity case.

To make this concrete. In a credit workflow, the outcome contract is not “automate credit memo drafting”. It is “produce a decision-ready credit recommendation with cited source data, risk flags, covenant analysis, exception logic, and a human approval point before commitment”. The baseline is current analyst hours, error rate, rework rate, and time-to-decision. The target is the measurable delta against those numbers. Same eight fields; the difference is what you are designing toward.

The outcome contract is what makes outcome-based design executable rather than aspirational. Once it exists, you can build a fully GenAI-native system around it, often bypassing the existing workflow, the existing tech stack, and large parts of the existing processes. Some of the legacy stack survives where deterministic code is genuinely required – systems of record, regulatory audit trails, counterparty integrations. The rest survives only as long as it does not become a constraint on the GenAI layer above it; over time, where deterministic code is not needed, it gives way to GenAI-native equivalents.

A separate point is worth flagging here, because it is where most programmes stumble. When the outcome contract calls for a redesign that bypasses the existing workflow, the implicit assumption is that the legacy stack and process are the constraint. They aren’t. The constraint is people. More specifically, the binding subset is the senior practitioners whose tacit judgement has to be codified into the new system. They are simultaneously the source of the redesign and, often, the role most absorbed by it. How they are managed through the transition – elevated and partnered with, not displaced by stealth – determines whether the codification happens at all. Roles get redesigned. A significant portion of FTEs may become redundant. The remaining team becomes a judgement-only function, not an execution one. The redesign can route around legacy systems; it cannot route around the human transition.

There is a slightly counter-intuitive point here. Among the available implementation models for GenAI, the outcome-based redesign that bypasses the existing stack is actually the lowest-friction model from a change-management perspective – because it does not force the existing team to relearn a new way of using the same systems. It builds a new system alongside, in parallel. The hard part is not operational change; it is the role transition for the people whose work the new system absorbs. Pretending otherwise is how transformations fail at the rollout stage.

Where the Roadmap Lives

The roadmap lives in the overlap.

The philosopher’s strategic thesis – industry-level, multi-year, structural – produces a long list of areas where GenAI ought to matter. The inventor’s evidence base – outcome maps, data primitives, evaluation benchmarks, guardrails – produces a list of areas where GenAI can move the business needle in practice.

Where the two lists overlap is where the roadmap belongs. The prioritisation test reduces to two axes – strategic materiality and execution feasibility. High on both goes on the roadmap. High strategic materiality but low feasibility is a capability-building investment, not a deployment. Low strategic materiality but high feasibility may be a useful local productivity play, but it should not dominate the transformation agenda. This exercise should be refreshed every 3-6 months, because both lists move – the Aristotelian thesis evolves as the technology evolves, and the empirical evidence evolves as the business builds capability and learns where the real bottlenecks are.

The 3-6 month cadence is also why the work needs an owner. Strategy refreshes that nobody is accountable for don’t happen.

Monday Morning

In parallel with the philosopher and the inventor, there is a practical track that has to start on day one. Not because it produces the strategic answer, but because nothing else works without it. Without Monday Morning, the philosopher’s thesis is a slide deck and the inventor’s outcome maps are an academic exercise.

The single biggest constraint to fix at the start, and the one that is almost universally underestimated, is literacy. Bluntly: most boards, ExCos, and operating teams do not understand GenAI well enough to have a serious conversation about it. The literacy gap is shocking, given how advanced GenAI already is. It is also the binding constraint on every conversation that follows. You cannot have a serious strategic discussion about industry transformation if the participants do not know what a frontier model can do, what a Skill is, what an agent is, or what an outcome contract looks like in their own function.

The solution is not training decks. The solution is hands on the tools.

Roll out Claude or ChatGPT to everyone (not Copilot), in whichever enterprise version passes the security and procurement gates. Train people on prompting. Train them on building Skills – by which I mean reusable, governed packages of instructions, context, examples, tools, and evaluation criteria that let a person or an agent perform a defined knowledge task or process repeatedly. Train them on Projects (multi-document workspaces with shared context) and artefacts (structured, persistent outputs that can be edited, shared, and reused). The vendor-specific names will change. The constructs will not.

This rollout is also an extension of the Edison track. Learning by doing is empirical work, and the patterns that emerge from broad-based use surface tactical opportunities the formal outcome audit may not see. Some of those tactical opportunities are strategically modest but operationally significant – particularly because GenAI’s heavy-lifting capability now solves problems that were previously infeasible to address on cost, time, or expertise grounds. Tactical does not mean trivial.

A warning, though. When GenAI is applied tactically without system thinking, it is easy to drive massive efficiency at one node and push the inefficiency downstream. Front office gets dramatically faster, and the bottleneck moves to the middle office. The discipline of looking at the end-to-end impact – not just the local one – has to apply even to tactical deployments.

In parallel, build a central support function for the more advanced cases – complex Skills, multi-document Projects, and, with managed agents, properly engineered agentic flows – and stand up a Skills pipeline in each business function: a managed process for identifying, developing, testing, evaluating, approving, deploying, sharing, and continuously improving Skills, with clear ownership at each stage.

This is the most important capability to build first. A well-built Skill captures the expertise of an experienced practitioner and makes it reusable, governable, and improvable – the unit by which institutional knowledge gets democratised inside the organisation. Skills also offer the highest impact for the lowest cost, time, and technical-skill prerequisite: a non-technical team member can build one that operates across the entire Microsoft 365 estate or on top of an LLM web client. In financial services and professional services, in our experience, properly skilled team members can more than double their productivity and effective capacity almost immediately on spreadsheet-, presentation- and research-heavy work, without a stack rebuild. Once Skills exist, agentic automation becomes a composition exercise rather than clean-sheet engineering.

One reconciliation worth stating, because it can read as in tension with the Edison track. “Skills first” here is a capability statement, not a substitute for outcome-based redesign. Tactical Skills accelerate today’s work; outcome-contract-driven Skills, when they come, reshape it. Both are useful. They answer different questions, and the strategic delta sits in the second. The discipline to enforce, even while the tactical layer is paying for itself, is to keep promoting the highest-impact patterns up into outcome contracts – not to let the tactical layer become a permanent ceiling on the redesign.

The operating model around this matters as much as the tools. The pattern that works is hub-and-spoke: a central platform team owns governance, evaluation and observability infrastructure (logs, traces, escalation rates, override rates, drift monitoring), security, vendor relationships, and a small number of horizontal Skills used across the firm; spoke teams in each business function own their domain Skills and ship them through a defined release process. Without that operating model, the pipeline becomes a queue with no SLAs, and the central team becomes the bottleneck it was meant to remove.

A point about governance worth stating directly. Risk, compliance, and security must be in the room from day one – not blocking, but embedded, ideally leading. They must enable, not gate-keep. Governance is not an excuse not to do, or not to move at pace. The detailed framing – risk-tiered release management, and what it means when governance becomes the binding constraint – sits in the final section.

In parallel to the Skills pipeline, an articulation of the end-state stack is what ties Monday morning back to the Aristotelian thesis. At minimum, this needs a view on data access, data ontology, identity and permissions, model access and routing, orchestration, evaluation and observability, human approval points, system-of-record integration, and user-facing applications. The stack should be designed for the business value and the business outcomes, not the other way around.

The Operator and the Manager

Two further points are worth pulling out, because they connect to each other in a way that is easy to miss.

The first is conceptual. What GenAI does is automate the intelligence layer on top of an existing technology stack. That is the right mental model. Underneath there is still the enterprise system, the Microsoft 365 estate, the data warehouse, the line-of-business application. On top of that, sitting as a new layer, is GenAI – a plug-in, a Skill, a workspace, an agent, and eventually GenAI-native solutions. The intelligence layer doesn’t replace the stack underneath. It operates it.

That word matters. GenAI is increasingly an operator: it does the work that previously required a person at the keyboard. For the next several years, the picture is operator on top of legacy; in the longer term, much of the underlying stack gives way to GenAI-native systems.

The second point follows from the first. If GenAI is an operator, then the humans involved are no longer doing the work – they are managing the operator.

Manager in the operating sense – directing the task, monitoring performance, intervening on exceptions, improving the system. Not manager in the HR sense.

That is a fundamentally different cognitive task. It is not “use this tool to be faster at my job”. It is “design, deploy, monitor, and improve a system that performs the work, and intervene with judgement when it can’t”. The shape of the work changes entirely.

This makes the rollout of frontier tools a useful organisational diagnostic. It is a real-time, low-cost test of who already thinks like a manager and who is using the model as a faster typewriter.

The pattern is consistent. The split varies by sector and culture, but the shape holds. Three rough cohorts:

• The builders – the people who immediately get it. They start by automating the tactical, repeatable parts of their own work, then move up to the high-cognitive heavy lifting in their function. They treat the model as something to be directed, trained, evaluated, and improved. These are the leaders of the GenAI transformation – and a leading indicator of where the next generation of transformation leadership will come from.
• The adopters – the middle. They may not be builders, but they trust the systems, they trust the technology, and they are comfortable applying judgement on top of GenAI output. They will use the tools effectively when the use case is clear and embedded in their routines. They are not the leaders of the transformation, but they are absolutely not the obstacle.
• The resisters – will not adopt without external pressure, and even then will treat the tools as a faster typewriter rather than as an operator to be managed.

The same logic is why the Skills pipeline is the right primary investment. A Skill is the manager’s leverage on the operator. The best-built Skills are not automating typing or formatting or document retrieval – those are useful, but they are tactical. The best Skills automate cognitive heavy lifting – the parts of the work that previously required expertise, pattern-finding, and even judgement, and that are now performed by a Skill that the manager has designed, evaluated, and improved. That is where the value compounds.

So the rollout of the tools does two things at once. It builds capability across the organisation. And it surfaces, faster than any HR process can, the people who should be leading the next chapter.

Measurement: Adoption Is Not Value

There is one place where, across functions, transformation programs fail. They fail to articulate the baseline. That is exactly why baseline and target metrics sit inside the outcome contract – measurement is born into the design, not bolted on later as a reporting layer.

This discipline is true of any technology programme, but it is even more true of GenAI, because the temptation to declare success based on adoption metrics – number of users, number of Skills, number of agent invocations – is enormous. Adoption is not value. Adoption is leading-indicator hygiene.

What matters is the delta in the handful of KPIs that actually manifest the business outcome of each function the technology touches. Sales productivity. Cycle time. Cost-to-serve. Quality of decision. Error rate. Capacity per FTE. Not all the metrics – just the ones that genuinely matter for that part of the business to understand how it performs. State the current baseline based on hard data. State what GenAI is expected to move them to. Measure the delta. That is the so-what.

A small but important nuance. The classical business case framing – “if we deploy this, what’s the ROI?” – does not really apply to GenAI at the strategic level. In knowledge-intensive sectors, the structural rewrite of the industry happens whether the company participates or not. Hence, the importance of Aristotle’s North Star above, and the optionality GenAI capabilities give should the J-curve scenario materialise even faster than expected. So the strategic question is not “is the ROI positive?” but “are we ahead of, or behind, the curve?” Strategic spend follows the answer.

This strategic-level framing does not, however, excuse the absence of business cases at use-case level. Every individual deployment still needs a baseline, a target, an error cost, a change management cost, and an ongoing run cost. Without that, the Skills pipeline is just expensive enthusiasm.

A nuance on cost. The most advanced GenAI adopters do start to manage the ongoing cost of GenAI seriously – moving to locally hosted open-source models, using smaller models, optimising the stack and the orchestration. For most businesses, that is a rich man’s problem. Under current model pricing and licence economics, the productivity impact is so disproportionate to the run-cost that ongoing optimisation is not the binding constraint, and is unlikely to become one in the early phases.

A second nuance on people. When GenAI is deployed alongside an existing software system and an existing team, articulate the FTE consequence both ways. If the team is reduced, what’s the saving? If the team stays, what does the freed capacity get redirected to, in measurable terms? Either is acceptable. Neither being articulated is not. And both need to be tracked over time – the assumption that freed capacity will be absorbed by additional business volume often does not survive contact with reality.

Risk and Release Classes

The risks are real and worth naming: hallucination, prompt injection, IP and data leakage, regulatory breach – including AI-specific regulation, data protection, operational resilience, model risk, and sector-specific obligations in financial services – model drift, vendor outage, agentic systems with too much authority. None of these prevent adoption. All of them have to be governed.

The wrong answer is a single risk committee that reviews everything. The right answer is risk-tiered release management, with each tier carrying its own evaluation, auditability, oversight, data control, and kill-switch requirements.

A final point that needs to be direct. In financial services and professional services, risk and compliance are too often used as the best available excuse not to change anything – often more conservative than the regulators themselves, who in many cases are materially more progressive than internal compliance teams realise. With GenAI, that posture becomes existential. There is no version of any business that will not deploy GenAI in the coming years. The job of risk and compliance is to make safe deployment fast, not to make slow deployment safer. If governance has become the reason GenAI is not moving at pace, that is the single most important red flag for the CEO to address – because the failure mode is not a regulatory breach, it is being structurally outcompeted by businesses whose risk function understood that “do nothing” was the riskiest option of all.

Where to Begin

So – back to the original question. Where do you begin? Not with a use-case catalogue. Begin with a CEO-owned thesis on how GenAI changes the business: distribution, product, cost structure, customer expectations, right to exist. In parallel, build outcome contracts that show where the technology can move real economics with the people and data the business actually has. And from day one, the Monday-morning work: give everyone the AI tools and training, set up a Skills pipeline to build and share reusable workflows, agree what’s safe to deploy and how, and measure real business impact from a known starting point.

Aristotle gives the direction. Edison proves what works. Monday morning makes it executable. The roadmap lives where the first two overlap; the third is what makes the rest more than a slide deck.