Before electricity, every factory was built around a single steam engine. A long shaft carried its power along the ceiling, and belts dropped down to each machine, so every machine had to sit as close to the engine as it could.
When electric motors arrived, most factories simply swapped out the engine and left the floor as it was. For decades, productivity barely moved.
The gains came when manufacturers stopped treating electricity as a better engine and rebuilt the floor around the work, giving each machine its own motor and laying the floor out in the order the work moved.
The redesign enabled the development of the moving assembly line. When Ford adopted it in 1913, the production time for a Model T decreased from over 12 hours to approximately 1.5 hours.
Most companies have done the same with AI: new power, old layout.
We know, because we did it ourselves for a year, until a client ultimatum forced us to rebuild.
We spent a year adding AI to the old way of working
Our first approach to AI looked like everyone else’s. Every person on the team had the AI assistant of their choice. We kept running the playbook that had made us successful and used AI to speed up pieces of it.
It helped, a little. Nothing about how we delivered work changed.
What changed it was a client. One of our private equity clients had been experimenting with AI on their own, and they came back with a blunt message: the old way of working was over. We had been building modern data environments for a handful of their portfolio companies. They wanted it done across 18 companies, nearly half the portfolio, and they wanted it completed in a few months.
Under our old process, the math didn’t work. It had taken us a little over a year, and serious resources, to deliver three portfolio companies. At that pace, 18 companies would take years.
Their question was straightforward:
How can you do this in two or three months?
Why the best teams resist the change
Our engineers were good at this work, and they had been doing it successfully for years. Their reaction was the one Clay Christensen saw in successful companies facing disruption. In our team’s words: We’ve been doing this for a long time. We know what we’re doing. Why would we take on something untested, with a completely different risk profile?
That’s a reasonable response, and it’s also how good teams get disrupted. Most organizations change only when something forces them to, like a client threatening to leave or a competitor moving in. The leaders who move first are the ones who see that pressure coming.
Part of the resistance comes from how AI gets introduced. Add it to an old workflow and the risks are obvious while the gains stay small, so skeptics have a point. To change the result, you have to change the design of the work.
Microsoft reached the same conclusion in its account of its own AI transformation, published in September. It calls the idea “lean before agents”: redesign the workflow first, then deploy the agents.
Our version came in five steps, taken in order.
1. Start with the outcome, not the tool
Most companies start by asking, “How can AI help us?” That question leads straight back to the old workflow, with a new motor bolted on.
Start instead with what the business needs to get done, for itself and for its customers. Once that’s clear, ask whether AI can help and how.
Our client’s goal was specific. They wanted the scattered, offline data of 18 portfolio companies, nearly half the portfolio, pulled into one cloud warehouse that leadership could treat as a single source of truth. And they wanted it done in about two months, before the end of the year.
A year earlier, our team would have called that a trip to the moon, a multi-year, multimillion-dollar program.
Try the same test on your own organization. Pick an outcome your leadership cares about, like every business unit reporting from one set of numbers within a quarter, or doubling revenue per salesperson without adding headcount. If your team accepts the goal without arguing, it probably isn’t ambitious enough to force a redesign.
2. Redesign the entire workflow, not the tasks
An outcome that ambitious can’t be reached by speeding up the old steps. Faster tasks inside the old workflow just give you a faster version of the same thing.
So we started from a blank page. If we let AI do what it does best, what problems does that create? Then we engineered for those problems.
The scariest problem came first. To be AI-first, you have to let AI write directly into the client’s data warehouse, which is unnerving after widely reported cases of AI agents deleting production data. So the redesign put governance at its center:
- The AI does its work in walled-off environments where it can’t touch the live system.
- Nothing moves toward the live system without a person signing off.
- Every change gets reviewed, the same as it would on any serious engineering team.
AI does the volume. People control what ships.
For your own teams, the question is the same one we asked. If your forecasting or revenue operations process were built today from a blank page, with these tools, what would it look like? And what would have to be true for you to trust its output?
3. Put the people at the center
A redesign on paper changes nothing. People have to build it, and that’s where many AI programs stall.
Nothing happens unless people do it, and nothing happens reliably unless someone is accountable for it.
We didn’t make real progress until our senior engineers were at the center of the work, building the new system rather than having it done to them.
The message to them was direct: You have a new toolkit. It’s a new world. What are you going to do about it?
That question can sound like a threat, especially to a team that has been successful doing things the old way. The worry underneath is simple: if AI can do my work, what happens to me?
How people answer depends on mindset. A team with a growth mindset sees a new toolkit as an opportunity, and a team with a fixed mindset sees a threat. Putting our engineers in the builder’s seat moved them toward the first.
Three weeks after we started rebuilding, it worked.
We tested it internally first, on an existing client, with no client risk, and saw a 20x improvement in speed at the same or better quality. One of our most senior data engineers, who had been skeptical from the start, came back and said, in effect:
Okay, now I see it. I’m a believer.
You have to experience it. It’s like the first time you drive at 70 mph on the highway (or 90, if you’re here in Colorado) after a lifetime of walking. No slide deck produces that moment for your team. Building the thing themselves does.
4. Expand what people can do, not just automate what they did
Once people have felt that speed, the next question is what to do with it.
Automation is real value, and it deserves its full due. A project that used to take three people three months now takes one or two people a few weeks.
But if automation is the whole story, the people who used to do the work are left with an uncomfortable question: the thing I was accountable for has been automated, so what am I for?
The bigger prize is what the same people can now take on.
Our team didn’t just do the same three portfolio companies faster. We took the new approach back to the client as a new three-company pilot, to prove it to them and to ourselves. We’re now on a path to 18 companies in two months, work that was a moonshot a year ago. The question on the team shifted from what’s left for me? to what else can we do, and what new value can we bring to the client?
That shift is the difference between a cheaper version of your old business and a new more valuable one.
5. Make the team smarter, not dependent
More speed and more scope raise the stakes on the last step. A team moving 20x faster can also make mistakes 20x faster.
There are two ways to use these tools.
You can say do this for me, take whatever comes back, and paste it in. Or you can engage with it: iterate, push back, look at the problem from several angles, and probe for holes.
The first path is cognitive offloading, and early on, we saw interns hand us a lot of slop that way. It can pass for a while, but the skills behind it don’t develop, and over time they erode. The second path keeps critical thinking in use, so it gets sharper.
Managing this looks the way good management always has. Push ownership onto people: You own your work product, and I’ll judge it. Then borrow the oldest pattern in professional services, prepare and review, where one person prepares and another reviews. It’s how our team holds quality at these new speeds.
Your next moonshot is closer than it looks
Electricity didn’t pay off when factories installed motors. It paid off when they rebuilt the floor around the work.
AI followed the same pattern for us. A year of adding tools to the old playbook bought small gains. When we started over from the outcome, put our people in charge of building the new system, and kept humans in control of what ships, work that would have taken years became a plan for the quarter.
The order matters: outcome before tool, workflow before task, people before platform.
This is the thinking behind our Trusted AI framework: let AI move as fast as it can, while people stay accountable for every output.
Do that, and the goal that once sounded like a trip to the moon becomes a project plan with dates on it, run by the people who doubted it.
We’re having more of these conversations every month.
If you’re running new power on an old workflow, feel free to reach out. Happy to compare notes.
