Before AI Can Help Your Team, You Need to See Their Work
Most AI deployments start with what the technology can do — before anyone has looked at what the work actually is.
When leaders ask me where to start with AI transformation, they usually mean: which tools, which use cases, which teams first. Those are reasonable questions. But they're the second questions.
The first question — the one most organizations skip entirely — is this: what does your team's work actually look like at the task level?
Not the job description. Not the workflow diagram. The real daily work — what people are doing between meetings, the tasks they carry home, the things that keep getting bumped because something else always feels more urgent.
Starting there — before the tools, before the training, before the use case library — is the most direct path into transformation that actually changes how people work.
It's also the shift the research made. When economists first tried to estimate how AI would land on work, they scored whole occupations, and the picture came out either alarming or useless. The useful work only started when they broke jobs into their individual tasks.
In the study that set the standard, researchers found that about 80 percent of US workers have at least 10 percent of their tasks exposed to large language models — meaning the task could be done significantly faster at the same quality — and roughly one in five workers could see that for at least half of what they do.
What struck me most was the next number. On the raw model alone, the researchers estimated that around 15 percent of all work tasks could be sped up that way.
But once you account for the software and tools built on top of the model, that share jumps to somewhere between 47 and 56 percent — close to half of all tasks.
The AI model by itself is not the transformation. What gets built on top of it, fitted to the actual work, is where the real leverage lives.
It's worth noticing when this was measured. The study came out in early 2023, near the very beginning of this technology's arc, and the models have advanced enormously since. If these estimates are off today, they are almost certainly low.
And none of those numbers mean anything until you do the thing the researchers did: break the work into tasks and look at it one task at a time.
I Have Done This Before
The first time I did this work, it wasn't called AI transformation. It was called digital transformation, and the tools were nothing like what we have now.
Years ago at VMware, I built a five-year digital transformation roadmap. Before I could build any of it, I did something that felt almost too simple to count as strategy: I sat with people while they worked, and I wrote down what they were doing.
Not what their job description said, not what the process map claimed — what they actually did, task by task, hour by hour. That was how we found the openings, the places where something repetitive and rules-based could become digital and give people their time back for the work that needed a human.
People were nervous then too. They wondered whether the technology would make their skills matter less. It's the same question I hear now, just wearing different clothes.
And the answer turned out to be the opposite of what they feared: the people who got time back got to do more of the work only they could do.
What's changed is what we're looking for. Back then, we were looking for "if this, then that" — the deterministic, repeatable steps a system could follow without judgment. That was what could be automated, and not much else.
AI moved that line. Now we're looking for repeatable judgment — the places where someone makes the same kind of call over and over, where their expertise has a pattern even if no one has ever written it down.
That's a far larger territory, and a far less visible one. Which is exactly why you still have to look.
Use Cases Are a Starting Point, Not a Strategy
Most AI adoption in organizations starts with examples — and that's not a bad thing. Someone demos AI answering emails. Someone shares a prompt that generates a project summary in thirty seconds.
A use case circulates in a team meeting, people try it, and some of them discover that AI is less intimidating than they thought. That's real value. Use cases lower the barrier and give people a first foothold.
The limitation shows up in the next step. When someone tries to apply another person's use case to their own work and it doesn't produce the same results, doubt sets in — and doubt is expensive.
People who came in hoping to save time, think at a higher level, or make a real dent in their workload walk away wondering if AI is actually worth the effort.
A field experiment with several hundred consultants at Harvard and BCG showed exactly why this happens. On the tasks that sat inside what AI does well, the consultants got dramatically better. But on tasks that fell just outside its range — and the boundary is jagged, not a clean line — the ones using AI did meaningfully worse than the ones working without it, by around 19 percentage points.
The tool didn't change. Whether it helped depended entirely on whether the task happened to fall inside its frontier, and that frontier sits in a different place for every kind of work.
That experiment ran in 2023 and was revised in 2026, and the frontier it mapped has not stood still since — it moves every time the models improve. Which is the deeper reason a borrowed use case ages so quickly: the boundary it was built around has already shifted.
The reason underneath this is that knowledge work is genuinely variable, person to person, task to task. The way one person preps for a board presentation, manages a stakeholder relationship, or synthesizes a set of research findings is different from anyone else doing the same job title at the same company.
One of the largest studies of generative AI at work makes the point in numbers: customer support agents using an AI assistant resolved about 14 percent more issues per hour on average, but the newer workers improved by 34 percent while the most experienced barely changed at all.
Same tool, same role, completely different results depending on who was holding it and their existing knowledge base.
Someone else's use case can show you what's possible — but it can't show you where AI fits in your work. That requires actually looking at your work.
The muscle AI transformation requires isn't familiarity with tools. It's the ability to see your own workflow clearly enough to know where AI belongs in it.
That skill has to be developed — and the journal is how you develop it.
Two Levels of the Same Work
There are two places this looking has to happen, and they're easy to confuse.
The first is the organizational level — the interconnected, documented processes that run across a team or a department. Mapping those well, going deep on one real workflow rather than skimming all of them, is its own discipline.
It's the work I wrote about in What Discovery Actually Requires: the stated process and the lived process are almost never the same thing, and you find the difference by going deep on one workflow, not by collecting a library of use cases.
This piece is about the other level — the individual one. Organizational workflows have a defined shape that can be mapped and redesigned. Personal workflows are different.
They're how each knowledge worker actually gets their work done: the patterns they've developed, the judgment calls they make without naming them, the way they move through a week. These are variable, non-routine, and almost never written down — and they're where a huge share of the individual AI opportunity lives.
Paul Daugherty and James Wilson call the space where humans and machines produce the biggest gains the missing middle, and it doesn't live in a process diagram. It lives in the daily work of individual people.
They're not written down for a reason older than AI. The philosopher Michael Polanyi put it as plainly as it can be put: we know more than we can tell.
The most valuable things a skilled person does are often the ones they can't fully explain — the experienced nurse who senses something is wrong before the chart shows it, the manager who knows which conversation to have first.
The documented process and the real one differ not because anyone is hiding anything, but because the real one lives in the doing, not the describing.
Here's the part I want to be careful about: these two levels are not in competition, and neither one replaces the other. A lot of the value organizations are getting from AI right now came from the bottom — from individuals.
In Microsoft's global survey, 75 percent of knowledge workers were already using AI at work, and 78 percent were bringing their own tools to do it, often with no training or strategy around them. That's real momentum.
But on its own it produces hundreds of people solving the same problems in isolation, with no shared learning and no way to protect what they're building.
And organizational strategy built without ever looking at how individuals actually work produces tools that are technically right and contextually wrong. You need both.
The Assignment
Before any AI transformation work begins with a team, I ask everyone to keep a detailed work journal for two weeks. It tracks two things.
The first is tasks — and the energy behind each one.
Not a rating system, but a real account. What did you work on? Did it give you energy or take it — was it the kind of work that puts you in a state of focus, or the kind that depletes you as you go?
This isn't about what's important or high-status. It's about what's actually happening inside the work.
Here's an example from my own workflow. I used to read AI articles, record voice memos with my reactions, paste both into a Google Doc, download it to my desktop, and repeat that cycle enough times to eventually write a Substack article.
I liked reading the articles — the visual experience of seeing a headline, deciding if a piece mattered. That part I genuinely enjoyed.
Everything after it — the copy-paste, the file management, the drafts stacking up with no clear way to rank them — drained me every time.
I thought the whole routine was "reading articles." Once I mapped it at the task level, I could see exactly where the friction was — and that became the blueprint for what I built with AI.
The second is the work that's not getting done.
This column is the one people underestimate. Every knowledge worker has a list of things that matter — the strategic thinking, the relationship building, the creative work, the long-horizon planning — that keeps getting bumped by whatever is urgent.
This isn't about what anyone has fallen behind on. It's about what they're trying to protect space for. That pile is data — it's telling you what's being sacrificed so the friction can continue.
Two weeks is not arbitrary. Knowledge work varies enough from week to week that a shorter window gives you a snapshot rather than a pattern. You need to see the full range before the real picture emerges.
What the Data Is Actually Telling You
The energy signal is not a rule. Not everything that energizes someone should stay human, and not everything draining should be handed to AI. The journal is not a sorting mechanism. It is a way of making the invisible visible.
The real-world data backs that up: when Anthropic studied millions of actual conversations with its AI, mapped against a database of around 20,000 specific work tasks, the most common pattern wasn't automation — it was augmentation, people working alongside the tool rather than handing the task over entirely.
The journal isn't deciding what to give away. It's showing you the true shape of the work.
And it has to be a journal, not a memory, because we are surprisingly bad at seeing our own work clearly. Ask someone what they did last week and you'll get the three or four things that stood out.
Have them write it down as it happens, and a different picture emerges: how many genuinely different tasks they moved through, how little of the week actually went to the work they'd name as their real job.
I wouldn't have known what drained me in my own routine without having looked. That is the whole reason the journal works: it shows you what reflection alone will not.
When someone has documented two weeks of actual work — the tasks, the texture, the things they never got to — they can walk into the discovery conversation and say something specific. Not "I feel overwhelmed" or "I think AI could help with email."
They can say: here is the shape of my week. Here is where the friction is. Here is what I am trying to reach that I have not been able to.
That is a different starting place entirely.
What Leaders Do With This
Your job is not to analyze the journal data for your team. It is to create the conditions where gathering it is worth their time.
That means being direct about what this is for. The journal is not a performance assessment. It is not a way of identifying who is or isn't productive.
It is the pre-work that makes transformation actually fit the people doing the work — rather than asking people to fit a transformation designed without them.
Tell your team what they discover will shape what you build — not the other way around.
Then ask three questions:
What about this process could be better for everyone involved?
What task in the last two weeks do you wish you hadn't had to do yourself?
What's the work you keep meaning to get to that keeps not happening?
Those questions, before anyone opens a tool or attends a training, are where the real transformation starts.
The fear your team is carrying about AI — whether their judgment will still matter, whether they'll be able to keep up, whether they're already the person who got left behind — doesn't go away when you hand them a capability.
It starts to shift when they experience that what they know about their own work is being taken seriously as the starting point. The journal is one way to demonstrate that.
Someone Still Has to Do This Work
Most jobs, as the research keeps showing, are full of AI-touchable tasks. But knowing which ones, and whether AI actually helps with them, and how to fit it to one person's real work — that isn't something a tool does for you. It takes expertise.
There's an expensive way to get that expertise, and it's the one most people reach for first: bring in consultants to study the work and re-engineer it.
I can't tell you how many companies are actually doing that — but I can tell you what it would cost, because the work is variable enough that someone has to look at it one role at a time, and that runs into the millions per department fast.
And here's what rarely makes the pitch: when all of it is done, you still need people. People to run it, to judge it, to catch where it's wrong, to keep adapting it as the work keeps changing.
AI doesn't remove the need for human judgment. It raises the value of it.
There's a better version, and it's the whole reason I have people keep the journal themselves. The ability to look at your own work and find where AI fits isn't a one-time deliverable someone hands you.
It's a capability your people can build and keep — one that pays off again next quarter and next year, as the tools change again.
A company that teaches its staff to do this themselves isn't just saving the fee. It's building a workforce that can keep doing it. The journal is the first rep.
The Leaders Who Get This Right
This is not primarily a data exercise. It is a decision about where transformation starts.
Most organizations start with tools and work backward, trying to fit people to the capability. The pre-work journal inverts that.
It starts with the people — with what their work actually looks like, with what they're losing in the current design. The tools come later, shaped by what you found.
That requires a leader who is willing to know what's really going on. Not the polished version, not the capability deck version, but the real texture of how your team works and what it costs them.
The leaders who get AI transformation right won't be the ones who moved fastest. They'll be the ones who stopped long enough to actually look.
Sources
Microsoft and LinkedIn, 2024 Work Trend Index
Michael Polanyi, The Tacit Dimension (1966)
Human + Machine (Updated and Expanded) by Paul R. Daugherty and H. James Wilson
Intentional Design: "What Discovery Actually Requires"