Four moves that turn AI ambition into operating capacity.

I built this method over a decade of running global functions inside Coursera, Microsoft, Oracle, NetApp, and Chegg, and then advising leaders across tech and tech-services through the current wave of AI redesigns. The pattern was consistent. The organisations that struggled were not short on tools or budget. They were short on a sequence. They were deploying AI on top of workflows that had never been examined, inside org charts that had never been redrawn, against capabilities that had never been defined. The result was activity without leverage.

What is different about this methodology is the order. Judgment before automation. Capability before workflow. Workflow before tool. Data flow last, because it only compounds once the first three are in place. The four moves are sequenced deliberately, and they hold across functions, industries, and company sizes. The numbers will vary. The pattern doesn't.

I start every engagement here, and it is the move most leaders want to skip. The instinct is to begin with the tools, or the workflows, or the headcount line. I refuse. Until the capabilities a function owes the business are named and ranked, every downstream decision is guesswork.

The principle underneath is that you are governing the work before you are governing the AI. A capability is not a job title and it is not a workflow. It is an outcome the function exists to produce. In the capability economy, the unit of value is no longer the knowledge a person holds. It is the capability a person can compose, codify, and orchestrate. That shift is the reason this move comes first. If you cannot compose the capability, you cannot codify it. If you cannot codify it, you cannot orchestrate it across humans and systems. And if you cannot orchestrate it, no tool you buy will give you leverage.

The failure mode is well-rehearsed. A function brings in an AI platform, runs a pilot, gets a productivity bump on a narrow task, and then cannot explain to the board why the function's output has not changed. It has not changed because the capability was never redefined. The team is doing the same work, slightly faster.

Here is what the move looks like when it lands. I worked with a qualitative research lead whose role on paper was "running customer surveys." We rewrote the capability. Her function was not to run surveys. It was to architect how the organisation hears its customers, at the cadence the business actually needs to make decisions. Once the capability was named that way, the workflow redesign wrote itself. The tools came last, and they were the right tools, because we knew what they were serving.

Once the capabilities are named, I walk the workflows. End to end. The discipline here is honesty. Most workflow maps inside large organisations are a sanitised version of how the work is supposed to happen, not how it actually happens. I do not work from those. I work from the version the people doing the work will tell you about over coffee, with the workarounds, the silent rework, the duplicate approvals, the spreadsheets nobody officially owns.

Then every step gets classified.

The phrase I hold the room to is classified, not cut. This is where my work parts company with headcount-reduction consulting. The point of the classification is not to find the autonomous bucket and shrink the org around it. The point is to redesign the function so that human attention lands on the human-essential steps, augmented capacity lands on the augmented ones, and the autonomous work runs without taxing anyone's calendar. Headcount may move. It is not the target. The target is leverage.

The clearest version of this I have run was a CRO redesign that arrived on my desk as a spreadsheet of FTE reductions. The CEO wanted a number. We did not give him a number first. We rebuilt the revenue workflow end to end and classified every step Autonomous / Augmented / Human-essential. The output to the board was not a cost line. It was a three-part narrative: the customer outcomes the redesigned function would now deliver, the org redesign that made those outcomes possible, and the financial leverage that fell out of the redesign as a consequence. The cost-out number was in there. It was the third thing the board heard, not the first. The redesign was approved in one meeting.

Judgment is the most expensive resource in the organisation. I treat it that way. The third move is where I decide, with the leader, where human judgment is placed in the redesigned function and where it is consciously withheld. Placement is a design choice. Default placement, where judgment sits wherever it has historically sat, is the most common failure mode I see in AI redesigns.

The question I ask in every Move 03 session is the same. Where does a human decision change the outcome enough to justify the cost of the human deciding it? Where it does, the human is the decisive actor and the system serves them. Where it does not, the system runs and the human is informed.

This move is also where The Lead comes into focus. The leader's job in an AI-native function is not to approve more. It is to decide better, and to be present in the moments where the system cannot. AI does not replace leadership. It increases the consequences of weak leadership. Every decision a leader makes now propagates through a system that runs faster and wider than it used to. Sharpening judgment is no longer a development goal. It is an operating requirement.

The Three-Layer ROI is a Judgment artefact, not a Finance artefact. It is the structure I hand the leader so that the most senior conversation in the company lands on the layer where the redesign actually creates value, rather than the layer the board is most rehearsed in discussing.

Most organisations still treat data as a function. A team owns it, a platform stores it, a dashboard surfaces it. In an AI-native function, data is not a function. It is shared infrastructure. It flows across the workflow, it carries the corrections the humans make, and it compounds. Every time someone overrides the system's suggestion, edits the draft, reclassifies the case, or refines the segmentation, that correction is logged and routed back into the system that produced the suggestion in the first place.

This is the compounding move. It is the difference between a function that is one redesign smarter than it was last quarter, and a function that gets smarter every week because its people are working. You do not need a separate program for it. You need the discipline that no correction is thrown away, and that the path from correction to system is short enough that the people doing the work can feel the loop closing.

Without it, the redesign is a snapshot, not a trajectory. With it, the function you redesigned in Q1 is materially sharper by Q4, not because anyone ran another transformation, but because the work itself was the training data.