Tony Dolan, my VP at DTCC, came and found me after a launch that had nearly broken the team, and what he said was, more or less: why didn't you tell me? We could have easily got this or that. If you needed an engineer, I'd have found them. You needed ten thousand more dollars — easy. That would have been easy.
I remember standing there doing the arithmetic on how much of the previous eleven weeks had been unnecessary, and arriving at a number I didn't want to say back to him.
He wasn't managing me — he meant it, and he could have done it. The problem was that I'd never handed him a decision. I'd handed him a delivery, on time, at a cost he couldn't see, and he had no way to act on a constraint that only existed in my head and in my team's evenings.
That one's on me, and I've watched a lot of good product leaders make the identical mistake since.
You can't out-sprint a capability loss
When capability drops, the instinct is to protect the promise and work the difference, and it feels like the professional move. It's also arithmetically impossible past a certain point, and everybody in the room knows roughly where that point sits except, apparently, the person who committed to the date.
So what actually happens? You don't miss the date. You do something considerably worse, which is that you hit it and pay for it somewhere invisible — in testing you skipped, in documentation nobody wrote, in a concierge process one person now runs by hand every Tuesday, in the goodwill of two engineers who'd already told you this was unrealistic and were overruled. That goodwill doesn't come back when the quarter closes, and nobody books it as a cost.
Hitting a date you should have moved isn't delivery. It's a loan against the next quarter.
Re-cutting the promise is a delivery skill, and it isn't an admission of anything. But almost nobody teaches it, so it gets improvised badly under pressure, which is how it ends up feeling like a confession.
Three piles, and the order you tell people
Here's the mechanic: when capability changes, every commitment goes into one of three piles, and you say which pile it landed in out loud.
Stands. This ships as promised, on the original date, and you're prepared to defend that in front of the team who has to build it. Be stingy here, because the credibility of the whole exercise comes from this pile being short. If everything stands, nothing was re-cut and your team will work that out before you finish the sentence.
Moves. This ships with a new date, and that new date is a real one rather than a hopeful one. A moved date that moves twice is worse than the original miss, because the second move is the one that tells everyone your dates are weather rather than commitments.
Dies. This isn't happening, and here is where it's recorded so that somebody can find it in six months and understand why.
Most leaders can manage Stands and Moves without much trouble. The pile that gets skipped is Dies, and skipping it is what turns a re-cut into a re-shuffle — the work doesn't leave, it just relocates to a backlog where it quietly keeps consuming attention and hope.
Then there's the order of telling, which matters more than the piles do. Who hears it first?
The team who builds it hears first, before anything is final, while they can still correct you and while their objection can still change the outcome. The stakeholder who wanted it hears second, from you, in an actual conversation rather than a status update they read on their phone. The wider org hears third, in writing, with the three piles named and dated. Get this order wrong — and the classic error is telling the stakeholder first because you're nervous about that conversation — and your team learns they're the last to know about their own work.
The company that got faster by having less
The best delivery turnaround I've been part of started from a genuinely grim place. The company repriced products on Amazon, and it had just been through a layoff. Morale was roughly where you'd expect it to be. They'd been shipping about one release a quarter even before the cut, with more people than they had now, and everything moved like molasses.
We didn't add anyone to the team. We cut the loop shorter, made the tradeoffs explicit before commitment rather than after, and put a hard trigger on cost, so a release that was going to blow up the bill stopped before it shipped rather than after.
They ended up shipping six to seven times faster, with the same people and the same budget. Fewer promises, kept properly.
What changed wasn't capacity — what changed was that the cost of a yes became visible at the moment of the yes, rather than three sprints later when it arrived as an outage or a bill. That's the whole trick, and it's why re-cutting is a delivery discipline rather than a communications one.
If you ever wondered why prices change on Amazon the way they do, buy me a drink sometime and I'll walk you through it, because that's a whole other essay.
The point is that the speed came from subtraction and from making costs visible at decision time, rather than from effort. There was no version of that team working harder that got to 6x. There was only a version that stopped carrying things it had never decided to carry.
What to do this week
Take your committed roadmap and sort it into the three piles. On paper, alone, before you talk to anybody, and give yourself no more than twenty minutes on it.
Then count the Dies pile. Is it empty? In that case you haven't re-cut anything — you've rescheduled, and your team will read it as exactly that, because they've seen the difference before.
Then write down who you'd tell first, and be honest about it. If your instinct was the stakeholder rather than the builders, that instinct is the thing to fix before the meeting rather than after it.