You Understand the Work. Now What?

At Within AI, customers usually come to me with a clear ask: map our processes, build the documentation. It's the right instinct — you can't transform work you can't see. Some of the most sophisticated companies in the world show up just wanting to know how their work happens today, and often it isn't even for an AI transformation — some other need is driving it. But once the conversation starts, it's like the world goes from black and white to color. Their challenge was never the ability to build with AI. It's knowing where to drive the change to make the right impact.

When I tell them the map is going to take a couple of weeks, with insights showing up in days, it blows their minds — because everyone in the room knows the traditional version. Black belts flying from site to site, running time studies, interviewing a fraction of the people, and always about the happy path. Then everyone flies to one location, the project team presents the value stream at the front of the room, and out come the pads of yellow sticky notes to find the Kaizen bursts. Honestly, I still get triggered by a pad of yellow sticky notes. I spent years of my life in those workshops — and worse, leading them. The result is a map that mixes different grains of data, already months old and incomplete the day it reaches leadership. And then the executive team spends the next 12–18 months making decisions off that original map — decisions about how large sums of money get spent and how their teams will work.

My boss and I keep coming back to the same picture for this: Wheel of Fortune. Leadership is investing to turn over as many letters as possible before they commit to solving the puzzle, and the old way buys you a handful of letters and a guess. The deeper you understand the relationships in the work, the more letters turn over. Connect how the process and the tools actually relate — that's a letter. Surface the hidden factories of work inside a process — you just bought a vowel.

That's why my favorite part of the job is lifting the conversation higher. When the map — the process, the teams, the tools, the risks, the bottlenecks, the hidden escalations that happen between the tools — arrives in weeks instead of quarters, mapping stops being the project. It becomes the starting line, and the real question arrives fast: what outcomes do you want to drive? (Moving from documents to context is a story for another day.)

So the map of how work really happens is sitting in front of you, and now we get to talk about transforming how the work happens. For every piece of work you can see clearly, there are exactly three moves available. Stop it. Automate it. Redesign it.

Stop doing the work. Some work costs more than the outcomes it delivers. A CAO told me this week that her record-to-report team spends ten hours every month closing and reconciling a single problem-child account worth about $1,000. Or the spend approval everyone rubber-stamps: the policy behind it was approved long ago, but nobody updated the procurement tool, so every request still sits in a queue waiting for a yes that's already been decided. Discovery makes this work visible, and the honest response is not to make it faster. This is the move leaders flinch at because it sounds like a headcount exercise. It isn't. When that work stops, people get their attention back for the work that actually needs their judgment — and that work is more rewarding to do.

Automate it. Some work is genuinely valuable, has to be done, and is repetitive enough that no human should spend attention on it. Comparing spreadsheets during the month-end close. Pulling line items out of invoice PDFs and keying them into the AP system. Automations are like Legos: they stack, and you don't need the grand end-to-end vision to place the first brick. Automation buys back hours. It doesn't change how the organization works.

Redesign the work. This is where the real returns live. Redesign means deciding, deliberately, how humans and agents work together in a process — which steps an agent owns, which a person owns, what "done" means for each, and who is accountable when the agent gets it wrong. I call these operating contracts between humans and agents. It's the hardest move, because it demands understanding the work at the atomic level — the escalation points, the exceptions, the work that lives between the tools. And it only works when you start from the outcomes the organization actually cares about.

The strategy isn't picking one move. It's sorting every piece of work you can now see into the right bucket — and having the nerve to use the first bucket at all.

And this isn't a framework I built for other people. My own team at Within runs on it: agents execute most of the work, people supervise for direction, judgment, and quality, and nobody lost a job. The hours went to customers.

Over the next three weeks I'll take each move in depth — how to spot the work that should stop, what makes a task ready to automate today, and how to actually write an operating contract between a human and an agent. This is part one of four. Subscribe and the rest will find you.