Your Lack of Planning is Not My Emergency

Recently a colleague shared a rule he uses when dealing with urgent requests:

Your lack of planning is not my emergency

My gut instinct was to disagree with it, but I couldn’t articulate it properly at the time. Now I see how it’s a regressive solution, which always makes me think there has to be a better way, and I wanted to explain my reasoning.

The history of it comes from working in IT where often capabilities need to be updated in a hurry, but the task has a dependency on another team, your team, who does not own that change. Your team now has a bunch of pressure exerted on it because another team encountered something that they hadn’t planned for.

The rule is a way to quickly diffuse any expectation that because another team made a mistake, that your team is responsible for fixing it. This is because these events are toxic in nature causing extra pressure to your own deliveries.You could also reasonably assume if your team helped out, the team who owned the event won’t learn anything and will know to go direct to you in future. A single urgent request in isolation is fine, but happening regularly can be crippling to a team.

Although if this kind of task ends up requiring an urgent response from your team, to dismiss it outright you will be making assumptions. The following is a breakdown of those assumptions.

Lack of Planning#

How often in IT are rapid changes caused by a lack of planning? I’m betting in most cases the source of the tasks are incidents, or security patches. If you dismiss the request, you will be seen as unwilling to help out at a time of need, and as someone who may be unwilling to participate in similar future requests.

I would expect this also means you reduce your chances of being consulted in future, or those who are making changes don’t know to inform you of them because you are not considered on the normal path to release.

Emergency Exit#

The other assumption to check is, how much of an emergency is it? Most of the project managers I’ve worked with would often say “Can you do this by tomorrow?” and when you trace back to the engineering team they’re happy with it being the next day, or May, or whenever. You may have decided not to participate based on faulty data.

Often the delivery date has been made up based on guess-work and have no meaning. I always like to check the deadlines. They rarely hold true.

The User Factor#

Another consideration is that users are often the cause of these rush jobs. Set aside that telling them ’no’ is a path to shadow IT, but it might be an indicator that your process isn’t fast enough for the demands for the business. If you have users who need software installed today and your SLA is 5 days, then maybe your SLAs are at fault.

Happy to Help#

You should always be willing to improve the operational effectiveness of your business. To do that you have to participate. That is the cost of being an effective team. Perhaps a single team is often the source of the problems, so where are their problems stemming from? Are they performing an incident post-mortem? Or learning any lessons? Is there something you can do with them to prevent their issues re-arising? Perhaps this is the true problem.

Finally, if you haven’t planned extra capacity in to your work, then have you actually planned your own work properly?