I used to hate doing things “ASAP”. Whenever our team did something ASAP, we ended up with bad code, stressed out developers and a buggy product. But in the last couple of years I think I figured out ASAP’s little secret and no longer feel anxious about it. And I can’t remember the last time I did something ASAP.

Thing is, whenever you hear the word “ASAP”, it’s an euphemism for “I don’t know when this needs to be done and I’m too stressed to find out”. It means that there is too much emotion present in the situation to handle it properly.

For example, imagine you’re a developer coding your latest feature when a manager interrupts you: “We just received an error report from the client’s representative. We need to fix this ASAP”.

In an ASAP situation it’s easy to give into the stress and immediately jump into panicky problem-solving. This is why “ASAP” is harmful: you’re presented with a hard problem and a highly emotional situation.

The key is to remove the emotion — and it’s actually not that hard. You just have to ask these 2 questions:

When do we actually need this? Are we OK with the costs?

1. When do we actually need this?

First of all, can we point to a specific point in time by which this problem must be fixed? To figure that out, look at the specific problem you’re trying to fix.

Maybe the error was reported by the client’s manager in charge of the project, and we need to fix it by the next meeting, which is in two weeks. Then actually ASAP == two weeks . Or maybe there’s been a new company policy installed that requires all client-reported bugs to be fixed in 3 days. Then ASAP == 3 days . Or maybe there’s an investor demo coming up the next day, and the problem blocks that demo. ASAP == 12 hours , good luck, hope you get paid for overtime.

Every task has a deadline. Especially urgent tasks — otherwise they wouldn’t be urgent. Once you set the deadline, it’s time to figure out the costs.

2. Are we OK with the costs?

“ASAP” often means doing things out of the usual production cycle. This means that cost of the work goes up. It’s harder to develop, test and deploy things in an “ASAP” fashion.

You’re also probably in the middle of a sprint. Because you’ll be doing this new urgent work, you won’t be able to deliver some of the planned features. You can already see the manager wincing!

Estimate and discuss the costs with your team. Then, ask: Is it actually worth fixing this problem in turbo mode? Is it worth postponing all the other tasks? Could it be that, when weighed against the increased costs, it’s better to instead postpone this seemingly urgent task and suffer the consequences of not doing it ASAP?