# The room that froze

> Seven engineering leaders arrived with plans. One person arrived with the thing built. Why the change AI makes possible has to start with the organization,...

Updated: 2026-09-06 · Author: Alan Wizemann

Not long ago I did a short piece of work for a company with an engineering organization of about a hundred people, and what happened in the first meeting of the build week is the reason this practice exists.

They were struggling with what everyone is struggling with: how to adopt the new ways of working that AI makes possible, when not every engineer is strong and the organization around them was built for a slower world. I proposed something simple – two weeks of discovery, then one week of building, and every day at ten o'clock we would meet and talk about what we were doing. They said, "Oh, like a standup," and I said yes, exactly like a standup.

Everyone knew from the Friday before what the week would look like. Seven engineering leaders came into that first meeting, and one by one they reported: we looked at what we could do and how we could build it, we did some requirements gathering, we have a plan. I had arranged to go last, and when they got to me I said that I had built it, and that it was in their inbox.

The silence in that room is the reason this practice exists. They were not annoyed; they were shocked, and then, quickly, they understood. The thing they had spent two weeks planning had been done in less time than the planning took, by one person, and it was not a trick. And then they understood something harder, which was that to work this way everything about how they were organized would have to change – not adjusted, but changed completely (from the way projects were created, to the way people were held accountable, to the way the engineering organization related to the rest of the company).

They froze, not because they disagreed, but because the change was too large and it had to start with the organization, not with the technology. Nobody in the room had the authority to do that, and nobody above the room had been asked. I have thought about that silence more than about any other moment in a long career of transformations, because it was the first time I watched a group of capable leaders understand the whole of it at once and then discover they had nowhere to take it.

## Five transformations, and then this one

Five times I have taken a business where technology was a department – a cost center that took orders – and rebuilt it into product teams: small, durable groups that owned a piece of the technology end to end, measured on outcomes rather than on delivery of a list. It worked, those companies got faster, and the people who built things got closer to the people who used them, and I would do all five again.

But the business was always on the other side of a line. Take the clearest example, the CRM. Sales used it every day and support used it every day, a product team owned it and built it, working in an agile way and shipping constantly, and yet every improvement moved through the same ritual: stakeholder interviews, requirements gathering, prioritization, a place on the roadmap, a quarter or two of waiting. The product team was excellent and the stakeholders were reasonable, and the ritual was necessary, because the team could only build so much and someone had to decide what.

## What changed since the last playbook

That ritual is what has disappeared. Anything you can describe clearly can now be built, by almost anyone, in days – not prototyped, built. I know principal engineers, people who can build anything, who have not looked at a line of code in a year because they no longer need to; they describe, they judge, they ship. I have watched a non-engineer build over a weekend what a room of engineers was still debating on Monday, and I have watched people who never coded in their lives build a better experience than the engineers would have, because they built it from the seat of the person who would use it.

The work and the speed are no longer the issue, so the reason for the line between the stakeholder and the builder is gone. In the accelerated organization the sales leader and the people who build the CRM are one team. There is no requirements document, because the person who has the requirement can describe it in the morning and see it working by the afternoon, and the question "what do you want next quarter?" becomes "what do you want to try today?"

Everything I now do with companies follows from that one collapse. The product model I spent a career installing was the right shape, it was just confined to technology. Now it applies to the whole company, because AI makes every function a builder, and the organization – not the technology, and not the talent – is the thing that has to be designed for it.

---
Canonical: https://alanwizemann.com/accelerated-organization/story