Price the Wait, Not Just the Work

“Show me the math first.”

That was the answer I got when I proposed skipping a project, and it was the right answer. The plan had been to move one workload out of the cloud and onto on-site hardware. I wanted to put it off, so we modeled what waiting would actually cost.

“We’re just kicking the can down the road.” I’ve heard that line in a lot of planning meetings, and it’s almost always meant as an accusation. Deferring work sounds like avoiding it, and finishing sounds like discipline.

I’d push back on that. Sometimes kicking the can is the smartest move in the room, as long as you know what you’re paying for it.

Think about what you actually knew when a project started. You made a bet based on the world as it looked that day. Then the work began, months went by, and the world moved. New tools showed up. Requirements shifted. Sometimes you learn something along the way that makes the original project look a lot less necessary than it did. That’s normal. What shouldn’t be normal is ignoring it because you’re already halfway there.

That’s the sunk cost trap, and everybody knows the term. The time and money you’ve already spent are gone either way, so the only question that matters is what the next dollar buys. And yet teams finish things all the time for no better reason than that they’re half done. Stopping feels like admitting the first half was wasted. Usually it wasn’t. It’s the second half that might be.

What helps me is thinking of it as an option. Deferring a build is buying an option. You pay a small, known carrying cost, like keeping an old system running a few more months, and in exchange you keep the decision open while you learn more. Anybody who’s traded options knows the shape: you pay a premium for the right, but not the obligation, to act later. On a trading desk that’s called managing risk.

The case where this matters most is a migration, and that’s exactly what mine was. It had been planned for a while, and everybody agreed it was the right move. Two things changed. The cloud bill turned out lower than we’d feared. “The cost wasn’t as high as we thought it would be” was how I said it. And a newer in-house approach, still being proven, showed up that might make the thing we were moving unnecessary. Not definitely. Might. Most teams keep going anyway, because the plan is the plan and stopping feels like flinching. I think that’s usually the wrong call, and the way to see it is to price both sides honestly.

Start with the cost of waiting. If you leave the old system where it is, you keep paying to run it. That number is usually known to the dollar: hosting, licenses, a little maintenance time. For plenty of systems it’s a few thousand dollars a month. It’s annoying, and it shows up on a bill every month, and bills are easy to complain about. But it’s small, it’s predictable, and you can stop paying it whenever you decide to.

Now the cost of doing the migration. The obvious part is engineering hours. The part people forget is whose hours they are. A migration eats your best people, because the people who understand the old system well enough to move it safely are usually the ones you trust most. While they’re moving it, they aren’t building the new approach, and the new approach is the thing that’s going to tell you whether you needed the migration at all.

So you spend your strongest team on work the next architecture might cancel, and by doing it you starve the work that would have told you whether to cancel it. You place the bet before the information arrives, and then you make sure the information arrives late.

Flip it around. Pay the run-rate for a few more months and put the team on the new approach. That was my pitch. Skipping the move freed the engineers who would have done it to work on new products instead. “We can always revisit doing this work later.” One of two things happens. The new approach works, and the migration you didn’t do turns out to be work you never needed, so a modest monthly bill bought you months of engineering time, a better system, and no new thing to maintain forever after. Or the new approach falls apart, and you do the migration anyway, a little later, with better information and a team that knows why it’s doing it.

The key word in all of this is priced. A deferral with no price on it is just procrastination with a nicer name. So write it down. What does waiting cost per month? What are we learning in the meantime? What result would kill the work, what result would restart it, and when are we going to look again? If you can answer those, you’ve bought an option. If you can’t, you really are kicking the can.

I tried to be straight about that part too. Waiting isn’t cancelling. “We will still have to go to the edge someday, most likely.” I could be wrong about the new approach, and if I am, we’ll be doing the move later than we would have. In our case the later review agreed to keep the workload in the cloud on a discounted plan and look at it again down the road, which is about what a priced deferral should look like. That’s also the honest answer to the worry I hear most, which is that a paused project never restarts. It’s a real risk, and a date and a trigger are how you manage it.

The other objection is that the old system is risky to leave alone. Sometimes that’s true, and then the math changes. If the thing is falling over, or it’s a security problem, you aren’t paying a few thousand a month anymore. You’re paying in incidents, and those get priced too.

There’s a cultural piece here as well. Most organizations reward finishing over judgment. The engineer who ships the big project gets the shout-out at the all-hands. The one who said “let’s wait two months, I don’t think we’ll need this” gets nothing, even if they saved a year of work, because nobody throws a party for the thing that didn’t get built. If you lead a team, that one’s on you. Celebrate the good deferrals as loudly as the good launches.

None of this is an argument for never finishing anything. Most work should get done. But “we already started” is a feeling, and a lousy guide. The real test is whether you’d start this project today, knowing what you know now, and what your best people would build instead. If the honest answer is no, I’d stop.