A few years ago I kept a spreadsheet of everything my team shipped in a quarter, and then I ran a quiet little experiment. Next to each item I wrote two letters: U if it felt urgent at the time, and I if, six months later, it had actually mattered. The results were embarrassing. Something like 70 percent of what we treated as urgent turned out to be forgettable, and half of the things that genuinely mattered had no deadline attached at all. Nobody was banging on the table for them.
That gap is the whole game in engineering leadership. Urgent screams. Important sits quietly in the corner. And if you run your team purely on volume, the screaming always wins.
The matrix everyone quotes and nobody uses
You already know the Eisenhower matrix. Urgent and important, urgent and not important, important and not urgent, neither. It gets drawn on a whiteboard in every management offsite. The problem is that the quadrant is trivial to understand and almost impossible to live inside, because in the moment nothing arrives helpfully pre-labeled. A production alert at 2am feels identical whether it is a genuine outage or a flaky health check. A director pinging you on Slack feels urgent because a director is doing the pinging, not because the underlying thing has any real clock on it.
So I stopped treating the matrix as a sorting tool and started treating it as a language. The useful move is not "which box does this go in." It is being able to say out loud, in a standup, "this is urgent but it is not important, so we are going to do the cheap version and move on." Naming the quadrant gives the team permission to under-invest in things that are loud but low-value. That permission is the actual deliverable.
Urgency is often just someone else's anxiety with a timestamp
Here is the uncomfortable truth I have landed on after enough years of this: most urgency is manufactured, and it is manufactured by people who are anxious rather than by the situation itself. A sales rep promises a feature on a call to close a deal, and suddenly it is a fire. A VP reads an article about a competitor and now integration X is a top priority by Friday. None of these have a real deadline. They have an emotional one.
I am not being cynical about my colleagues. Anxiety is a legitimate business signal, sometimes. But it is a signal about a person's state of mind, not about the cost of delay. The single most useful question I ask when something lands as urgent is boring and slightly annoying to the asker: "What actually happens if we do this in three weeks instead of this week?" Maybe once in four times the answer is a real, concrete consequence with a dollar figure or a compliance date behind it. The other three times the honest answer is "nothing, I just wanted it handled." That is worth knowing before you interrupt an engineer mid-flow.
The context-switch tax nobody puts on the invoice
This matters more for engineers than for, say, a marketing team, because our work carries enormous switching costs. Pulling a senior engineer off a two-week refactor to chase a one-hour "urgent" fix does not cost you one hour. It costs you the hour, plus the twenty minutes to reload the refactor into their head, plus the subtle bug they introduce because they never fully got their context back. I have watched a clean piece of work turn into a three-day mess because it got interrupted four times by things that could all have waited until Thursday.
When I try to explain this to non-engineering stakeholders, the framing that finally lands is money. Deep work is the highest-margin thing your engineers produce, and interruptions are a tax on it that never shows up on any invoice. So I treat protecting focus as a financial decision, not a comfort one. A few concrete things I have found actually move the needle:
- A named on-call rotation so exactly one person absorbs the day's interruptions and everyone else stays heads-down.
- A rule that no ticket jumps the queue without a stated reason for delay cost, written down, not just asserted in chat.
- Batching. Non-emergency requests get triaged once in the morning and once after lunch, not the instant they arrive.
- A visible "we are not doing this now" list, so killed urgency does not quietly resurrect itself next week.
The important work has no advocate, so you have to be it
Think about what falls into important-but-not-urgent on an engineering team. Upgrading off a database version that goes end-of-life in fourteen months. Writing the integration tests for the payments path that has never once broken, so far. Documenting the tribal knowledge that lives entirely in one contractor's head. Paying down the auth service that everyone is a little afraid to touch. None of it has a customer waiting. None of it has a Slack thread full of angry emoji. And that is precisely why it rots.
I have come to believe that the core job of an engineering leader is to be the standing advocate for the work that has no natural advocate. Nobody else in the building is going to walk into a planning meeting and fight for the database upgrade. The sales team won't. The customers won't, until the day it falls over. If you don't reserve capacity for it on purpose, the urgent will eat all of it, every quarter, forever. I have never once seen important-not-urgent work happen "when things calm down," because things do not calm down.
The day the quiet thing gets loud
Let me tell you about a service I inherited at a payments company. It was a currency-conversion job that ran nightly, written by someone who had left two years earlier, with no tests and a hardcoded list of exchange-rate sources. Everyone knew it was fragile. It had been on the "we should really fix that" list for at least a year. Classic important, not urgent. It never got prioritized because it never broke.
Then one of the upstream rate providers changed their API response format without warning, on a Sunday, and the job silently wrote wrong numbers into settlement records for about nine hours before anyone noticed. Suddenly the quiet little service was the single most urgent thing in the entire company, and it stayed that way for a brutal week of reconciliation, apologetic customer calls, and a very uncomfortable conversation with a regulator. The fix, done calmly a year earlier, would have been maybe three days of work.
Important work does not stay quiet forever. It waits, patiently, until the least convenient possible moment, and then it converts itself into the most expensive kind of urgent there is.
The trap on the other side: fake important
Now, I do not want to pretend the answer is simply "protect engineers from all urgency and let them do noble long-term work." There is a failure mode on the other side, and I have been guilty of it myself. It is dressing up the work you find intellectually pleasant as strategically important. Rewriting a perfectly functional service in a trendier framework. Building a beautiful internal platform for a scaling problem you are three years away from having. Gold-plating an abstraction because it is satisfying, not because anyone needs it.
This is fake important, and it is dangerous precisely because it wears the costume of the good stuff. It has no deadline, it feels architecturally virtuous, and it lets you feel like a serious long-term thinker while you avoid the messier, less glamorous work that would actually move the business. The test I hold it up against is simple and a little deflating: can I draw a straight line from this to revenue, risk, or a real cost we are carrying today? If the line requires three hops and a hypothetical, it is probably a hobby, and I should treat it as one.
How I actually budget a quarter
Rules of thumb are more honest than frameworks here, so here is mine. I try to keep roughly half of a team's capacity aimed at the important-and-planned roadmap, about a quarter reserved and genuinely unallocated for the urgent things that will inevitably arrive, and the remaining quarter deliberately spent on important-not-urgent maintenance and resilience work. Those numbers are not sacred. But writing them down turns an argument about a single ticket into an argument about the whole budget, which is a much healthier argument to have.
The reserved-for-urgent slice is the part people push back on. Leaving a quarter of your team's time unplanned feels wasteful when you are staring at a backlog. But if you plan to 100 percent of capacity, then every single unexpected fire has to displace planned work, and you spend the whole quarter feeling behind and reactive. I would rather plan to 75 and hit it than plan to 100 and constantly break my own promises. Predictability is a feature, both for the team's morale and for everyone who depends on our dates.
Teaching the team to make the call without you
The thing I most want, and the hardest to get, is a team that can make these calls without me in the room. Early on I was the bottleneck for every "is this actually urgent" decision, which felt important and was in fact a failure. If every judgment routes through the leader, the leader becomes the single point of failure and the team never develops the muscle. So now I try to hand over the questions rather than the answers.
Concretely, when an engineer brings me a supposed fire, I resist just giving a verdict. I ask them what the cost of delay is, who is actually asking and why, and what the cheap version would look like. After a few months of that, they start asking themselves before they get to me, and the whole team gets faster and calmer. A blunt heuristic I hand out and stand behind:
If you cannot name a specific bad thing that happens on a specific date if we wait, it is not urgent. It might still be important. Those are different problems and they get different treatment.
Conclusion
The instinct I am most trying to unlearn in myself, and in the people I lead, is the quiet satisfaction of clearing an inbox. Closing twelve urgent tickets feels productive in a way that spending a day making one fragile service boring and safe simply does not. But the inbox is not the business. The business is the sum of the important things you protected while the urgent things were shouting, and it is also the sum of the fires you did not have because you paid the boring premium early.
So if you take one thing from all this, make it a habit rather than a framework: every so often, run my little spreadsheet. Look back at what you fought for six months ago and mark it U or I with the benefit of hindsight. It will sting a little. Then let that sting recalibrate what you allow to feel like an emergency next week. The urgent will always find you. The important is counting on you to find it first.