AI is making individuals dramatically faster. Organizations aren’t accelerating at the same rate.
An AI prototype can move incredibly fast.
One capable person can research a problem, analyze data, connect a few systems, build an agent, automate a workflow, test it, and put something useful in front of people in days. Sometimes hours.
That’s a real change in how work gets done. Work that once required several specialists and a series of handoffs can increasingly happen with one person.
But the faster that person gets, the more visible everything outside their control becomes.
The prototype is ready, but access isn’t. Two source systems disagree. Security needs to review the integration. Engineering owns the API. A business rule exists mostly because three people have learned how to interpret it. The agent can take an action, but nobody has decided whether it should.
This is where I think expectations around AI transformation are getting ahead of reality.
We’re increasing individual execution capacity much faster than we’re increasing an organization’s ability to absorb that work.
AI changes individual velocity first
I’ve experienced this directly. Some of the most useful AI systems I’ve built started with me sitting close enough to the work to understand the problem, connecting the information myself, and building the first version before there was a formal project around it.
AI removes a lot of the handoffs that used to slow that process down. I can go from understanding a problem to testing a working solution much faster than I could even a few years ago.
But there’s a boundary around that speed.
I can build the prototype. I can’t personally grant every permission, clean every source system, resolve every ownership question, approve every security decision, or make another team prioritize an integration.
The faster the work inside that boundary moves, the more obvious the dependencies outside it become.
That’s the gap between individual velocity and organizational velocity.
The business gets a vote
A good demo intentionally reduces complexity.
The information is reachable. The inputs make sense. The expected output is known. The happy path has been tested.
That’s what a prototype should do. It makes the possibility visible.
The real workflow contains everything the demo temporarily avoided.
One system is missing information. Permissions vary by role. A customer has an exception nobody documented. An API has a limit. Two people interpret the same business rule differently.
Then something weird happens on a Friday afternoon.
That’s where the business gets a vote.
The question is no longer whether the model can produce the right answer. It’s whether people can depend on the workflow when the inputs are incomplete, the rules are messy, and nobody is standing beside it telling it what to do.
Discovery doesn’t create complexity. It reveals it.
At one company where I led AI transformation discovery, we identified more than 100 go-to-market tasks and hundreds of subtasks spread across teams, systems, documents, and institutional knowledge.
Mapping the work didn’t make the organization more complicated. It showed us how complicated getting the work done already was.
What looked like one task might require finding an account’s history, checking product activity, comparing conflicting records, applying process guidance, asking another team for context, making a judgment call, updating a system, and notifying the next person.
A prototype can automate one part of that chain. Transformation has to understand enough of the chain to know what should actually change.
That’s why I don’t think the job of AI transformation is to find as many places as possible to use AI. The job is to find the highest-value ways to change how work gets done.
Sometimes that’s an agent. Sometimes deterministic automation is cheaper and more reliable. Sometimes the data isn’t ready. Sometimes the workflow needs to change first. Sometimes human judgment is creating more value than anyone realized.
Discovery has to be allowed to change the answer. Otherwise we’re starting with AI and working backward until we find somewhere to put it.
A prototype proves possibility. A pilot tests reality.
Once a prototype works, we’ve learned something useful: the technology can perform some meaningful part of the work.
The next question shouldn’t immediately be, “How quickly can we roll this out?”
I want to know what still has to be true for people to depend on it.
Use real inputs. Include normal exceptions. Put it in front of the people who actually understand the work and ask them where it’s wrong.
Measure the current process before changing it, then look beyond whether the AI produced a good answer. Did cycle time change? Which cases required an override? Where did the data fail? Did people trust the result? Could they recover when something went wrong?
And the pilot has to be allowed to prove the original idea wrong.
Maybe ordinary automation is better. Maybe the data isn’t ready. Maybe the workflow needs redesign before AI belongs anywhere near it.
I’d rather learn that during a pilot than spend months productionizing something because the demo looked impressive.
The workflow is the unit of transformation
If the goal is changing how work gets done, the work is much bigger than the agent.
You have to account for the systems, data, rules, people, decisions, exceptions, measurements, and ownership surrounding it.
Building is part of the job, and I increasingly think the person leading this work should be able to prototype a lot themselves. But they also need to understand how the work happens today, where it breaks, what should change, what level of autonomy makes sense, how success will be measured, and what happens when the system is wrong.
A system that drafts something for a person to review has a very different failure mode from one that makes a decision or takes an action without asking first. The technical capability might be similar. The operational requirements aren’t.
And none of this stops at launch. Business rules change. Employees change. Vendors change their systems. Customers continue finding creative ways to become exceptions.
Production is the ability to keep the workflow useful and reliable as those things change.
Transformation velocity is an organizational property
Executive sponsorship matters. The person leading the work needs a clear mandate, enough authority to operate across functions, and a shared understanding with leadership about what they’re there to do.
But I’ve learned that those things still aren’t enough.
The surrounding organization has to understand the role too.
AI transformation crosses boundaries almost by definition. It requires context from people who understand the work, access from people who own the systems, partnership from engineering and data teams, judgment from functional leaders, and participation from the ICs who know where the documented process stops matching reality.
Those people aren’t obstacles or dependencies to work around. They’re part of the transformation.
There has to be a shared understanding of why the role exists, what it’s responsible for, and what support it will require. If leadership sees the work as a company priority but the teams being asked to support it see it as optional, every project ends up negotiating that priority all over again.
The responsibility goes both ways. A transformation leader can’t walk into another team’s workflow assuming AI should change it. The people closest to the work usually know where the process is weird, which exceptions matter, what has already been tried, and what will break if you change the wrong thing.
If leadership wants transformation to move quickly, sponsorship has to extend beyond giving one person a mandate. The organization around that person needs the context, capacity, and incentive to participate in it.
Otherwise you can have executive sponsorship, a strong operator, and a clear strategy and still spend most of your time negotiating for the conditions required to execute it.
That’s not an individual performance problem. It’s an organizational alignment problem.
Use the right clock
Demo velocity measures how quickly we can prove something is possible.
Individual velocity measures how much of the path from problem to working solution one person can now cover themselves.
Transformation velocity measures how quickly the organization can turn that solution into work people can actually depend on.
AI is dramatically increasing the first two. The third doesn’t automatically follow.
As individuals become capable of moving much faster, we’re going to see the constraints around them more clearly. Eventually the question isn’t whether someone can build the thing. It’s whether the organization can absorb it.
A prototype moves quickly because we’ve intentionally narrowed the problem enough to learn something. Transformation has to put the complexity back in.
If we want that part to move faster too, we have to work on the system around the builder, not just the builder.