I'm seeing the same pattern across companies right now. A dev team estimates a feature at 30 days. They ship it in 3. That should be a win. It isn't.
Three days in, the team came back and said it was done. The feature was ready. The launch wasn't. Sales hadn't been briefed. Marketing was drafting the announcement for a date three weeks out. Customer success had no documentation. The fastest delivery the company had ever seen turned into an awkward three-week wait: finished software sitting in a branch while the rest of the organization caught up.
Nobody did anything wrong. Every team followed the process. That's exactly the problem: the process was built for a world that no longer exists.
What Changed: Execution Detached from Estimates
With Claude Code, Codex, and the current generation of coding agents, execution time has detached from estimate. The 30-day number wasn't a bad estimate. It was a perfectly reasonable estimate for the old way of working. Then the team pointed a handful of agents at the problem, reviewed the output, iterated, and a 30-day roadmap item landed by Friday.
This isn't a one-off, and it isn't limited to startups. I see the same thing in enterprise teams. Once a team learns to work with agents properly (clear specs, tight review loops, solid test coverage), the relationship between 'how big does this feel' and 'how long will it take' simply breaks. Estimating intuitions calibrated over twenty years of software development become fiction within a quarter.
And here's the part most leadership teams haven't internalized yet: this isn't a productivity tweak you can absorb with the existing operating model. Every planning ritual, every quarterly roadmap, every headcount conversation in your company quietly assumes that development capacity is scarce and expensive. That assumption just expired.
What the Speed Exposes
The interesting thing isn't the speed. It's what the speed exposes. For decades, software organizations were built on one assumption: dev capacity is the constraint. Roadmaps existed to ration it. Prioritization meetings existed to fight over it. Product managers existed, in large part, to shield it and feed it carefully scoped tickets.
Once that constraint breaks, everything that depended on it starts to wobble. The quarterly roadmap becomes a holding pen for ideas that could ship this week. The prioritization meeting argues about sequencing work that could all be done in parallel. The carefully written ticket takes longer to write than to implement.
The constraint doesn't disappear. It moves. In the theory of constraints, the moment you elevate one bottleneck, the next one becomes visible. In most software companies I work with, the next bottleneck is decision-making: knowing what to build, for whom, and what happens after it ships. That's not an engineering question. That's a leadership question.
The dev team isn't the bottleneck anymore. Leadership is.
The Four Shifts Every Organization Needs to Make
Do you have a ranked, well-specified pipeline of problems your team could pick up tomorrow morning and ship by Friday? If not, they'll idle or build whatever's nearest at hand. Velocity without direction is just noise. Here are the four shifts I see working in practice:
Make PMs the Engine of Discovery, Not the Scopers of Tickets
If your product managers spend the week tightening acceptance criteria, you're wasting them on work the dev team now does in an hour with an agent. Their job shifts upstream: customer conversations, ranked problem lists, rough prototypes that test demand before a single sprint is committed. A PM who brings three validated problems to Monday's planning is worth more than one who brings thirty perfectly groomed tickets.
Decouple Build from Launch
The three-week gap between 'done' and 'launched' in my opening story is a process artifact, not a law of nature. Stage features continuously behind flags, and run launches on a separate go-to-market rhythm that sales, marketing, and customer success actually control. Engineering ships when the code is ready; the business launches when the market is ready. The two should never block each other again.
Roll Agents Out Beyond Dev
If only engineering gets agents, you're widening the gap on purpose. Sales briefings, marketing copy, support documentation, ops runbooks: all of it can move at agent speed too. The companies handling this well treat agent adoption as a company-wide capability, not an engineering perk. The goal is one clock for the whole organization, not a fast lane next to a traffic jam.
Move Leadership Conversations Upstream
'Do we have capacity?' is a dying question. The conversations that matter now are: Is this the right problem? Who is it for? What do we do the moment it ships? Capacity is no longer scarce. Clarity is. Leadership meetings should spend their minutes on direction and sequencing, because execution will no longer hide a fuzzy strategy for six months. It will expose it by Friday.
Is Your Organization the Bottleneck?
A quick self-assessment. Answer honestly: every 'no' marks a place where finished software will sit and wait:
Do you have a ranked, well-specified pipeline of problems your dev team could start tomorrow morning and ship by Friday?
Can a finished feature reach customers without waiting for a marketing date, a sales briefing, or a documentation sprint?
Are your non-engineering teams (sales, marketing, customer success, ops) actively working with AI agents today?
Do your leadership meetings spend more time on which problems to solve than on whether there's capacity to solve them?
When a team ships dramatically faster than estimated, does your organization treat it as a win, or does it scramble?
Four or five yeses: you're ahead of almost everyone. Two or fewer: the bottleneck in your software organization isn't in the codebase. It's in the org chart.
What to Do Next Quarter
You don't fix this with a memo. But you can fix most of it in a quarter if you sequence it deliberately. Here's the order I recommend to the executive teams I work with:
Weeks 1–2: Measure the Real Gap
Take your last five shipped features and map two timelines: code-complete to customer-launch, and idea to code-start. Most leadership teams discover that engineering time is already the smallest slice. You can't rally the company around a bottleneck you haven't made visible.
Weeks 3–6: Build the Ranked Problem Pipeline
Move your PMs into discovery mode: ten customer conversations each, one ranked list of problems with a clear owner and a 'who is this for' on every line. The bar is simple: could a dev team pick the top item tomorrow at 9am and know exactly what winning looks like?
Weeks 5–8: Decouple Build from Launch Mechanically
Feature flags, a continuous staging rhythm, and a standing go-to-market cadence owned by the business. This is mostly plumbing plus a few ownership decisions, and it permanently removes the 'done but not launched' purgatory.
Weeks 7–12: Take Agents to the Rest of the Company
Pick one workflow each in sales, marketing, and customer success, and pair those teams with someone who has already shipped with agents in engineering. The point isn't the tooling. It's making agent speed normal everywhere, so no single function sets the company's clock.
How we work · Work · Insights