How I Set Priorities When Everything Is Urgent

Urgency is how a request arrives. Priority is what a schedule can actually hold. A team that treats every urgent claim as a priority is not accelerating anything. It is quietly letting volume decide the roadmap, and it misses the real emergency when that emergency finally shows up. I have sat in that queue, and I have watched genuine incidents deprioritized behind three well-dressed escalations.

The cleanest test I know is asking whose clock is running. A genuine emergency has a clock that belongs to nobody: a certificate expiring on a fixed date, an audit window that opens whether we are ready or not, a vulnerability being exploited right now, a payment flow degrading in front of customers. Manufactured urgency has a clock that belongs to a person: a meeting on Thursday, a promise someone made upstream, an expectation nobody checked with us. The second kind of clock can usually be negotiated. The first cannot.

So the first thing I do with a new urgent item is ask out loud: what happens if this waits until Thursday. Not why is this urgent, which invites people to perform urgency, but what happens if we wait, which demands a consequence. Consequences are sortable. If the honest answer is that someone will be annoyed, we are having a priority negotiation, not an emergency. Annoyance is real and worth managing, but it calls for a different tool.

When three stakeholders tell me their item is the most critical thing this week, I run the same four questions in the open, with the requester on the call. The structure is not bureaucracy. Genuine emergencies and loud demands look identical from the inside, and the questions separate them in minutes instead of meetings.

Every new urgent item goes through the same sequence: verify the clock, size the blast radius, check dependencies, check capacity, then pick a verdict. Most items land in schedule it, and that is healthy. If everything lands in drop everything, the problem is not the workload. It is that nobody is verifying.

Deciding is the easy half. Delivering the decision is where the relationship is won or lost. Most managers invest heavily in choosing priorities and almost nothing in telling the people who lose, then wonder why trust erodes around every re-prioritization.

A message that survives being forwarded reads like this: I know the date is fixed and why it matters. We are protecting the migration because the deprecation deadline is contractual. Taking this on now pushes the migration past the freeze window, which puts every customer at outage risk. What I can offer by Friday is a scoped interim fix, and the full version lands first next sprint. If you see the trade differently, this decision belongs to your leader, and I will gladly put both options in front of them together.

A not now with a date and a reason is a form of respect. A vague we will look into it spends other people’s planning time while committing me to nothing, and that is the version that actually damages trust.

Mid-sprint, a Tuesday. My most senior engineer surfaced during a routine audit that a set of TLS certificates in front of a large share of our production estate was nine days from expiry, and the automated renewal had been silently failing for weeks. If they lapsed, essentially every customer-facing system would fail at once.

The same morning, a sales VP came to me visibly stressed: a very large prospect had an on-site visit in four days, his team had promised a custom demo environment, and he needed it hardened from our standard sandbox by Thursday. Both requests were real. Both had revenue attached. Both felt absolutely urgent to the messenger.

Here is what made it hard. The demo environment was not trivial: it was several days of work for the same two senior engineers whose heads held the certificate automation. There was no version of that week where both happened at full quality. And the certificate deadline was not mine to move. It was set by cryptography.

I made the call: renewal first, including the root cause fix, and the demo would ship as a stripped-down sandbox, less customized but functional, delivered by Friday morning. Then came the conversation I did not enjoy. I did not soft-open. I told him the renewal had been failing silently, that a lapse would take down not just his demo but the product his demo was selling, and I offered the trade explicitly: we can build the full custom environment, but it means pulling the two people fixing the certificates, and if we are wrong about nine days, there is no demo and no product on Thursday either.

He was not happy. He said the sandbox would not land the same way, and he was right. We spent twenty minutes on whether the certificate work could be split, which remains my favorite request from people who do not have to do the splitting. What settled it was not my confidence. I had written down exactly which systems would be dark on day ten, and his demo environment was on the list.

The certificates were renewed with three days to spare, the automation bug got a permanent fix, and the demo ran on the sandbox. The deal did not die: the prospect signed months later, and I doubt anyone in that room remembers whether the demo environment was custom. The VP does remember that the platform did not have a catastrophic outage that quarter.

There is a failure mode on the far side of all this: a team that accepts every urgent request does not become responsive. It becomes slow, running five projects at a fifth of its velocity each and finishing none of them. Worse, every capitulation trains the next escalation. Say yes often enough and you have taught the organization that volume works.

Scarcity of capacity is not a personal failing. It is the default condition of any competent organization, because the people worth working with are always oversubscribed. The engineering manager’s real job is to be the place where urgency gets tested against evidence: where risk, impact, dependencies, and capacity are named out loud, and where the answer to this is urgent can be prove it without anyone flinching.

The frameworks above decay into wallpaper unless they rest on a few habits I keep repeating to every manager I coach.