“You don't understand, Chris. From idea to prototype takes us 24 months. 18 if we're lucky.”
I sat across from the lead software architect of a Fortune 100 company. It was 2003. I was showing him our code generation solution, expecting him to get excited about speed.
But his face told a different story. He wasn't thinking about speed at all.
He was thinking about what happens when 24 months becomes 24 days. Or 24 hours.
I didn't understand then. It took me weeks of walking through the implications with him before I finally saw what he already knew.
What 24 Months Actually Contains
Here's what I assumed: the timeline was long because coding is hard. Complex systems take time to build. Faster tools should mean faster delivery.
But that's not what 24 months contained.
Think about it. In a Fortune 100 company, idea-to-prototype isn't mostly coding. It's meetings. Approvals. Budget negotiations. Architecture reviews. Stakeholder alignment. Political maneuvering. Change orders. More meetings.
The coding was maybe 10% of that timeline. Which means the coding was never the actual bottleneck.
So if coding wasn't the bottleneck, why did everything take so long?
Because the timeline itself was the point.
Where Power Actually Accumulates
Here's what I learned walking through those weeks with the architect: different people hold power in the processes that turn ideas into products. And that power accumulates around bottlenecks.
When idea-to-prototype takes 24 months, power sits with specific people:
The gatekeepers who control access to engineering resources. They decide who waits and who moves forward. Everyone needs their approval. They have leverage over every initiative.
The budget owners who pace investments across fiscal years. A 24-month build means multi-year budget cycles. They control which ideas survive long enough to ship.
The senior architects who own the roadmap. Limited capacity means hard prioritization. They decide what gets built and what dies in the backlog.
The process managers who coordinate handoffs between teams. Complex timelines require complex coordination. Nothing moves without them.
These roles exist because the timeline is long. But here's what the architect understood that I didn't: they also exist to keep the timeline long.
Not through malice. Through incentive.
Why the Timeline Stays Long
Joe laid it out for me like this:
Long timelines create coordination roles. People fill those roles. They build expertise and relationships around coordination. Their careers depend on coordination remaining necessary.
So what happens if the timeline collapses?
Their leverage disappears. Which means they have every reason, consciously or not, to preserve the system that gives them power.
This is why technology changes don't automatically change organizations. The resistance isn't about the technology. It's about the power structure the technology threatens.
I thought we were talking about code generation. We were talking about organizational physics.
What Happens at 24 Hours
Now fast forward to today.
Coding agents can take an idea and produce a working prototype in an hour. Sometimes less. Code reviews that took days happen in minutes. Bugs that blocked releases for a week get fixed before lunch.
So who loses power?
The gatekeepers lose leverage. Why wait in a queue for engineering resources when you can generate a prototype without asking permission? The approval function becomes optional. People stop asking.
The budget pacing disappears. Why spread an initiative across three fiscal years when the build phase takes a weekend? The fiscal calendar stops being a constraint. Budget owners control less.
The roadmap owners face a different question. When capacity was scarce, they decided what to build. But when prototypes are cheap, the question shifts from “what can we build?” to “what's worth building?” Their expertise in capacity allocation matters less. Judgment about value matters more.
The process managers coordinate less. When handoffs shrink, so does coordination overhead. Their role contracts. But here's the thing, some of them fight this by creating new process requirements. New approval gates. New review layers.
I've watched it happen. Organizations trying to preserve the old power structures even as the underlying constraints disappear.
It doesn't work. But they try anyway.
The Risk Calculus Changes
Here's what I've been thinking about lately, the part that goes beyond what I learned in 2003.
When coding takes no time, the risk proposition itself changes.
A prototype that would have consumed a quarter of engineering capacity now costs an afternoon. You can test ten ideas instead of debating which single idea deserves the investment. The cost of being wrong drops dramatically.
But this only works if you embrace the shift.
I've watched organizations respond two different ways:
Some create new approval layers to slow things down. They add review gates. They require sign-offs that didn't exist before. They're trying to maintain the coordination structure that gave certain roles their power. They move at the old speed even with new tools. They get outpaced by competitors who don't.
Others let experimentation happen at the speed the tools allow. They accept that judgment about what's worth building matters more than control over what can be built. They run more experiments. They learn faster. They pull ahead.
The tools don't determine which path you take. The power dynamics do.
Back to the Architect
I called Joseph a few years ago. He'd retired by then. I asked if he remembered that conversation.
He laughed. “You kept trying to sell me on speed,” he said. “I was trying to tell you that speed was the threat, not the feature.”
I finally understood what he meant.
He wasn't worried about whether his company could code faster. He was worried about what happened to the organization when it could. Who would lose their leverage. Who would fight to keep it. How long that fight would slow everything down.
“The companies that figure it out,” he told me, “won't just build faster. They'll build different things. With different people in charge of the decisions.”
He was right. That's exactly what's happening now.
The Question for You
If you're an enterprise product leader, you sit at the intersection of these power dynamics every day. You navigate stakeholder politics. You negotiate for resources. You manage roadmaps.
A lot of that navigation depends on timelines being long.
So here's the question: when coding takes no time, where does your power come from?
If your value is tied to coordinating a slow process, you're at risk. The coordination function is exactly what contracts when timelines collapse.
But if your value is tied to judgment, to knowing what's worth building and why, that becomes the scarce resource. Not engineering capacity. Not process management. Judgment about what actually matters.
The organizations that figure this out first won't just build faster.
They'll build different things. With different people in charge of the decisions.
That's the shift. And it's already happening.