Our most important learning from running AI programs with thousands of senior leaders is that AI transformation starts with the workflow. And the fastest way into a workflow is through the person who does that work every week.
That person knows where the information really comes from, which exceptions eat their afternoon, and what a good result looks like. Most of it is tacit knowledge they have never had to write down. Our job is to help them offload that knowledge into AI solutions that are tested in real work, from a simple assistant to an agent that carries part of the workflow forward on its own.
In our work, we see that the only real transformation happens when we transform one person's workflow at a time, with hands-on coaching.
Real Transformation Happens Through People, Workflow by Workflow
Giving employees licenses and telling them to experiment is not enough. A field experiment by Microsoft and Harvard Business School researchers across 66 firms and 7,137 knowledge workers shows the limit. The 80% of workers who used the AI assistant they were given spent two fewer hours a week on email, and the researchers did not detect any shift in the quantity or composition of their tasks.
Individuals saved time, and the work itself stayed the same. That is the pattern behind why AI is still not showing up in company results: most companies are still searching for where AI belongs in their work. As McKinsey's Kate Smaje put it, "every AI transformation at its heart is a people transformation."
So the first step is to uncover how people actually work, including the expertise, decisions and exceptions that rarely appear in process documentation.
Leaders tend to know a workflow by its outcome. The person running it knows the exceptions: which source is always a week out of date, which client needs a different format, and when a changed deadline counts as an update instead of a new task. That is exactly the judgment an AI system needs and cannot guess.
The philosopher Michael Polanyi named this in his 1966 book The Tacit Dimension. He called it tacit knowledge, and summed up the problem in eight words: "we can know more than we can tell." I see it all the time when leaders try to write instructions for their own work, because the parts that feel obvious are the easiest to leave out. No amount of prompt engineering fixes that on its own.
Francesco Marzoni, chief data and analytics officer at Ingka Group, put the business version plainly: "data is largely in people's heads." So the real work of transformation is offloading that tacit knowledge into something AI can use, which is what I have called context offloading.
I ran into this myself when I recorded my daily LinkedIn review as a Claude Skill. I narrated every filter, everything I skip and exactly what earns a reshare. When I read the Skill back, my narration had been looser than I thought, and I had to tighten the rules for what qualifies. If a routine I run every morning needed that correction, expect the same from your team's workflows.
The best-known study of AI at work points the same way. Erik Brynjolfsson, Danielle Li and Lindsey Raymond followed 5,172 customer support agents and found that an AI assistant raised issues resolved per hour by 15% on average, and by about 30% for less experienced and lower-skilled agents.
The assistant drew on the firm's own support conversations, and the authors suggest it may have spread the behaviors of the best agents to everyone else. (They call that analysis suggestive, and the expertise came from historical records instead of interviews, so there is more than one way to capture it.)
Make Employees the Co-Creators
Then, crucially, employees need to become the co-creators of their new AI-powered workflows and agents, so they can spend more of their time on higher-value work.
In my conversation with Debbie Lovich, Managing Director and Senior Partner at Boston Consulting Group, she explained why. A small team that builds a solution on the side and then rolls it out everywhere usually produces something that does not fit the day-to-day reality of the work, and people reject it. Teams that co-create the solution test it along the way, explain how the work really runs, and become its advocates with their colleagues. That is why co-creation does so much of the heavy lifting in AI change management: people adopt what they helped build.
Employees understand the exceptions, frustrations and informal practices that formal process maps miss. Debbie also sees co-creation as better upskilling than any course, because building real solutions for your own work is how people develop the skills they will need next. It builds AI fluency where it matters most, inside people's own work.
Practitioners are finding the same thing. At the Portland Trail Blazers, Chief Strategy and Innovation Officer Christa Stout runs "Lunch and Launch" sessions, where teams name what frustrates them about their jobs and then build AI solutions together, as Jeremy Utley describes.
Her colleague David Long, Vice President of Digital and Innovation, built the AI tools behind one of their clearest results. Work that took about 50 hours a week across three departments now takes one person three hours, and every comment gets a response within one to two days.
The same pattern shows up at the high end of professional work. Ropes & Gray built its AI deal-diligence system around how its own lawyers move through a data room and decide what matters, with lawyers and IT staff working directly alongside OpenAI's forward-deployed engineers.
The technology matters, but understanding the work comes first.
Learn From How Others Reorganized
Examples from other companies can be a helpful discovery mechanism too. In a field experiment across 515 high-growth startups, researchers from INSEAD and Harvard Business School showed some founders how other firms had reorganized their work around AI. Those startups discovered 44% more AI use cases and completed 12% more tasks than the control group.
The authors call the underlying challenge the mapping problem: discovering where and how AI creates value inside your own work.
Redesign the Work Itself
Involving employees is not enough if all we do is help them do their existing tasks faster. The bigger opportunity is to rethink the work itself. Which tasks can disappear? Which handoffs can be eliminated? What becomes possible when AI takes on entire parts of a workflow?
As Debbie also explains, much of our work was already broken before AI arrived. Her research found the average office worker spends about a day and a half each week on draining admin work, and the average manager about a full day. It is something we address in our lesson on the three mindset shifts for AI transformation.
The line we use in our programs is "do not put a rocket engine on a broken bicycle, unless you want bigger problems faster." If the inputs are scattered across individual inboxes, AI will only produce more output from a flawed process.
McKinsey reports that a cohort of 20 companies that fully rewired around AI averaged a 20% EBITDA uplift, with two-thirds focusing on three or fewer areas. Its State of AI research also found that reimagining workflows end to end was among the practices most strongly tied to value. We collect more research like this in our AI statistics guide.
Here are a few ways we propose to begin this work:
- Capture information at the source, with a form or a shared location, instead of chasing details across email and chat.
- Use a permitted recording or transcript so a follow-up draws on what was actually said.
- Remove steps and fix handoffs, especially where several people contribute pieces of the same report.
- Write the template or standard operating procedure first, including what a good output looks like.
- Reconsider the trigger, since part of the work may be able to run on a schedule.
Sometimes the biggest breakthrough in a program sits in these fixes, before any AI is involved. They also matter for a practical reason: AI cannot use information it cannot access, and permission to use the data and tools comes before any build.
Using AI is the starting point. The real opportunity is discovering how AI can change the work itself. It is also how companies start to become AI native organizations.
How to Choose and Map Your First Workflow
We start with one recurring piece of work with a clear start and finish. A single task like "summarize this meeting" is too small to change much. A role like "an AI project manager" is too broad to design.
A workflow sits in between: "take a partner meeting through to a reviewed follow-up and an updated action list." It has a trigger, inputs, several steps and a usable result, so you can see where AI helps and where a person needs to check or act.
We ask the person who runs it to answer five questions:
- What starts it? A concrete trigger, such as a meeting ending or a request arriving.
- What goes in? The notes, records, criteria or responses the work depends on.
- What happens? The steps from collecting the information through to review.
- What comes out? A specific deliverable or a completed action.
- Who checks it? The person accountable for judging the result before anyone uses it.
Map how the work happens today
Before designing anything new, we ask people to document how the work actually happens, including the manual steps, the handoffs and the waiting. Four distinctions do most of the work: work time (what you actively do), waiting time (where the work sits), information gaps (what you chase or reconstruct) and review points (where judgment is needed).
We also record how often the workflow runs and how long it takes. That becomes the baseline you will judge the result against later. Knowing your work at this level is what we call Workflow Literacy: you cannot delegate a process you have never made explicit.
Turning a Workflow Into an AI Assistant
You give AI one well-defined job inside the improved workflow, and you build that job on the knowledge of the person who does it.
To find the right step, we use GED-RT: work that is General, Error-friendly, Digital, Repetitive and Toil. Good candidates are steps like extracting, summarizing, comparing, reviewing or drafting, where someone can check the result and correct it.
Then we ask people to finish one sentence: "Given [these permitted inputs], AI will [one action] to produce [this first-pass output], which [this person] will check." In the partner-meeting example, AI extracts the commitments from the transcript and drafts the follow-up, and the account owner reviews both before anything goes out.
Redesign the work with OVER
For a whole role or a bigger workflow, we use the OVER framework to get from a vague initiative to something concrete enough to build:
- Outputs: list what you actually produce, such as decision memos, forecasts or customer updates.
- Verbs: break each output into five to twelve actions, such as collect, extract, structure, decide and communicate.
- Evaluate: label each action as AI-first, human-first or hybrid. If you can review it quickly and reverse a mistake cheaply, it can be AI-first. If it relies on tacit knowledge, political judgment or real accountability, it stays human-first.
- Route: match each action to the right kind of tool, from chat to embedded copilots to a custom assistant.
Offload the judgment nobody wrote down
This is where the person doing the work matters most. Take a simple step like comparing new meeting commitments with an existing action tracker. How do you know two commitments are the same task when they are worded differently?
An experienced person compares the substance of the task and its owner, and treats a changed deadline as an update. They do this automatically and would never think to explain it, which is exactly why an assistant without that rule creates duplicates.
So before anyone writes instructions, we have AI interview the person first. Our instructions-builder prompt asks up to four questions about how they make decisions, handle exceptions, avoid common mistakes and recognize a good result. Only then does it draft the instructions with our CODO prompting framework (Character, Objective, Do's and Don'ts, Output), marking anything uncertain as [TO CONFIRM].
AI should help people explain how the work should be done, and it should never invent how the work is done. The person then reviews the draft for assumptions they did not make.
Whether you interview people or record them doing the task, four habits decide how much of the knowledge survives the transfer:
- Explain why you do each step, as well as what you do. "I skip these because they are engagement bait" teaches far more than silent scrolling.
- Narrate your exclusions. In a filtering task, what you leave out defines the output as much as what you keep.
- Check that it generalizes. A recording shows one instance, so confirm the AI learned the underlying rule and did not copy an accidental detail.
- Test it on a fresh example before you schedule or share it, and look hardest at the judgment calls, since those are the parts most likely to be captured loosely.
From Assistants to Agents
An assistant helps you do the work, while an agent can carry bounded work forward for you. It gathers context, decides what to do next, acts, checks the result, and continues or stops, so nobody has to operate every step. A workflow deserves an agent when it suits AI and is also bounded, testable and feasible on your platform. The right first build is the smallest meaningful version, such as a post-meeting follow-up, well before anything like "manage our customer relationships."
Autonomy is then set per action, based on one question: what happens if this action is wrong? Reading approved information can run freely, posting or changing records should wait for approval, and conflicting or missing information should go back to a person. Because instructions describe what an agent should do while connected tools decide what it can do, the strongest boundary in a first version is often leaving a capability out. Our guide on what an AI agent really is, and when and how to build one walks through the full design, with examples in Copilot Studio and ChatGPT.
Does Starting With Individuals Actually Scale?
On its own, it does not, and it is worth being honest about that. Starting with the person doing the work is how you discover the workflow. Scaling it takes things only leadership can provide: connected handoffs across teams, access to the right data, governance, and a way to capture the value that gets created.
The Microsoft study above shows why. The changes it found were in work people control on their own, like email, while time spent in meetings did not change significantly. Work that depends on coordination between people usually needs someone with authority to redesign it.
There is a second risk: automating one person's habits. Two people running the same workflow often do it differently, and a solution built around one of them will break for the other. So we map the workflow with several representative users and the accountable owner, and we look for the version of the work the team should run.
Is hands-on coaching required?
We think it helps most with the hardest part, which is drawing out judgment, exceptions and context that people do not know they hold. The evidence does not yet show it is the only route, though.
AI-assisted interviews, tools that observe how work is done, and centrally led process redesign can all surface workflow knowledge. And not every piece of expertise can be put into words or delegated, which is one more reason the human stays in the lead.
Starting inside teams has support too. Atlassian's research, which we covered in an executive briefing, found that the first AI super user on a team makes the biggest difference to team performance, with diminishing returns after that. That is the logic behind AI champion programs: find those people, put them into real workflows, and let the practice spread.
Measuring Whether It Worked
Compare the result with the baseline you captured on day one: how often the workflow runs, how long it takes, and which part frustrated people most. Without that baseline, every result is an anecdote.
We also show an early build to the people who do the work, well before it is finished. They are the fastest way to find where it breaks, and their variants of the workflow are the best test cases you will get.
Three measures are worth tracking:
- Net time: time saved minus the time now spent reviewing and correcting the output.
- Quality: error rates, rework, and whether the reviewer trusts the result enough to use it. Our DRAFT Framework gives reviewers a structure for that judgment.
- Speed to the customer: how quickly the person at the end of the workflow gets what they need, like the Trail Blazers fans who now hear back within a day or two.
Hours saved will still miss part of the value, because good workflows also make new work possible. That is why we measure impact per hour, which counts both the time you get back and the things you can now do that were out of reach before. Decide up front where the reclaimed time should go with a clear North Star, or it disappears into more meetings and email.
A single workflow should show its answer within a quarter. Pick it, record the baseline, ship a bounded first version within a few weeks, and by the end of the quarter you should know whether it is better in real work, by how much, and which workflow it should connect to next.
Key Takeaways
- Transform through people, workflow by workflow. Licenses save individual time, and the work only changes when employees co-create how it flows.
- Offload what the person doing the work knows. Their tacit knowledge is what makes an AI solution usable, so interview them, have them demonstrate and narrate the task, and test what AI learned on a fresh example.
- Redesign the work itself. Ask which tasks and handoffs can disappear before you add AI, or AI will scale a broken process.
- Set autonomy per action. Ask what happens if each action is wrong, and give the agent only the tools its first version needs.
- Prove one workflow within a quarter. Record the baseline, test early builds with real users, and measure net time, quality and impact per hour.
