Stop doing things ASAP

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:

1. When do we actually need this?
2. 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 actuallyASAP == 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?

The key to solving an ASAP situation is to transform it into a regular situation.

After you have set a deadline and went through the prioritization process with this task, you’re no longer dealing with an ASAP problem. You’re now solving a regular problem, without the additional stress and confusion. Just another JIRA issue to be fixed.

Whether you’re a developer or a PM, you’ll benefit from transforming ASAP tasks into regular tasks. You and your team will be less stressed and more focused. You’ll end up with a better product as a result.

I wanted to end this article with a joke: “There are no ASAP situations, except a fire”. But in fact, handling a fire is also a problem that deserves a well-defined deadline and a proper prioritization effort.

Remember that the next time you hear a fire alarm.

Thanks to Aleksandra Budyanskaya, Andrey Stolbovsky and Dmitry Adamian for help with this article.