For a long time we planned the way most teams do. A roadmap about three months out, two-week sprints under it, the next sprint's contents assembled a few days before it started. That setup earned its place, and it did real work for us: order, predictability, somewhere to put anything that takes longer than a day. Features don't arrive every morning, and something has to hold the queue.
Then the queue became the bottleneck. Someone from the business would come with a feature. The room would agree it was strong. And it could be started in one to two weeks. Nobody was blocking it — the calendar was holding it. Multiply that by every good idea and you get an engineering organization permanently answering the question the business asked two weeks ago.
I used to think that lag cost us time. It cost us attention, which is worse. By the time the work started, the person who brought the feature had moved on to their own next problem. They were still the stakeholder on paper. They were no longer thinking about it. So the work began from a ticket instead of from them, and the one person who knew what "good" meant here was somewhere else.
Now we do the opposite. When something is the most painful problem the business has right now, we pull a small group around it and take everything else off those people. That removal is the whole mechanism — not the team, not the goal, the removal. Other priorities get deprioritized out loud, to the team and to everyone else: this is the most important thing we are doing, and it needs to be done fast. Then business and engineering talk daily, inside the team, for as long as it runs. A merchant segment hitting a dead end on install was one of these; the alternative path was in production the next day. The next-day part is the least interesting thing about it.
None of this is new as a shape. Agile has expedite classes, and Kanban boards have had a fast lane for urgent work for as long as anyone has drawn one. The difference is the lane itself. We don't run the urgent thing alongside everything else, we clear everything else. A strike team that still owes three tickets in its old lane is a person with a new label.
What I didn't expect was where the gain actually came from. For about three years I tried to build daily contact between business and engineering, using every ritual you would guess: shared standups, embedded owners, review cadences. They decayed the same way every time, because the business side kept getting pulled back into its own work. What finally produced that contact wasn't a ritual. It was starting while the author of the idea was still thinking about it. Speed didn't deliver the communication as a bonus on top. Speed is the precondition for it. Attention has a half-life, and you either spend it in the first days or you don't get to spend it.
The second finding is less comfortable. The medium-term work these teams displaced often turned out to be unnecessary by the time it would have shipped. The business had already moved, usually because it had arrived with the very feature that displaced it. Which means the roadmap was largely a set of hypotheses that we were treating as commitments — and engineering leadership, me included, was the function defending that queue. That is a harder thing to say than "sprints were slow."
They also don't always disband. I used to think a strike team should dissolve the moment the gap closed, and that anything permanent was just a second roadmap with better branding. In practice some of them convert into standing teams, because the work turns out to be a line of business rather than a fire. What forms one is a spike in urgency, not a promise about how long it lives.
Then there is the cost, and it is not the one I expected to write down. The obvious version is that we traded the roadmap's visibility for speed: a roadmap sits in one place, and anyone can see what is coming without asking for it. Except I am not sure ours ever worked that way. We told ourselves it was the shared picture; in practice it was engineering's document that everyone else was welcome to open. Strike teams didn't destroy that picture. They revealed there wasn't one, and then made its absence expensive — because a team with everything else taken off it goes quiet by design, and from outside, heads-down and nothing-is-happening look identical. The work moves faster than it ever moved on the roadmap and it reads as silence. That is engineering leadership's problem and not the business's, and I don't have the answer to it yet.
Plan the work that compounds. Start everything else while the person who asked is still in the room.