Colin Hamilton's Blog

The Urgency Bias

I have two kinds of problems: the urgent and the important. The urgent are not important, and the important are never urgent.1

This is a quote from President Eisenhower, and it's formed a foundation for how I think about prioritization.

I had seen this quote a number of times online in the context of prioritization, usually discussing a system called The Eisenhower Matrix. But discussions I saw of the original quote didn’t leave me satisfied, because they don’t clarify what it means for something to be “important” vs “urgent” — and that’s the whole crux of the matter.

Indeed, if you’ve never heard the quote before, it can be a bit confusing, because “important” and “urgent” are very similar words in English; most thesauruses would list them as synonyms. The quote itself doesn’t expand on the difference — it is, after all, just supposed to be short and punchy and memorable. The meaning behind the words is left for the reader to figure out.

These are the definitions Merriam-Webster offers:

The definition for “important” is a bit vague on how to measure worth, though otherwise reasonable. But the definition for “urgent” is even less satisfying, due to the use of the passive voice. Who is calling for immediate attention? I believe this ambiguity is a central source of mis-prioritization.

Learning how to prioritize tasks is foundational to successfully execute just about any project, but in particular it’s a skill that separates good software developers from the great. Properly identifying importance and urgency is the basis of this skill.

Definitions

A bit dissatisfied with the vagueness of the dictionary definitions, I took a mathematician’s approach, and created my own definitions. As I’ve worked on better categorizing problems and tasks, I’ve found that there are actually three properties to account for:

Based on those three factors, I have three corresponding categories of tasks:

Note that I split “urgent” tasks into two categories. This addresses the ambiguity of the dictionary definition, by clarifying what makes a task worthy of “immediate attention.” You can either make that determination based on the pressures of others, or you can base it on an objective measure. Distinguishing these two case means discerning truth from perception. While some things do truly need to happen quickly, many more things that are not truly urgent are nonetheless treated as such by others. Just because someone else is treating something as urgent, doesn’t mean it actually is.

That, I think, is the crux of the Eisenhower quote. Looking at it again, it makes the most sense to me if his use of the word “urgent” refers to what I’ve called “perceived as urgent.” The lesson of the quote, then, can be rephrased in a way that’s less poetic but more specific, and resonates with my own experiences: the things that matter in the long run are rarely things that others will push you to do; and conversely, the things that people pressure you to do quickly rarely actually matter in the long run.

Examples in software

I do believe that these ideas can apply to any sort of project, but my own experience is mostly with software, so let’s look at some examples from each category in software. Keep in mind that I defined urgency in a particular way: truly urgent tasks must be done to prevent catastrophic harm. So to determine if a task is truly urgent, we can simply ask: what would happen if I delay this task, or even just don't do it at all? Would the harm be catastrophic?

Important Tasks

As I argued in my post on Keeping Software Soft, what matters in the long run for a software project is the ability to continually add changes and fix bugs. Therefore, the tasks that matter most in the long run are those that enhance this ability. This includes testing, monitoring, code documentation, refactors, and reductions of code and system complexity. While important, these are rarely truly urgent, as delaying them won’t cause immediate harm. They’re likewise rarely perceived as urgent.

Truly Urgent Tasks

The most obvious example of a truly urgent task would be a critical bug, like one that has crashed the server and made the product unusable. Every minute that the server stays down, users get frustrated with your product and lose faith in it. With no server, you have no product. Fixing that is pretty clearly urgent.

Other urgent tasks can arise from legal or contractual obligations. For example, last year, Apple introduced a requirement that apps must allow users to delete their accounts from within the app. Failure to add that feature by the deadline would have risked getting the app pulled from the App Store. If our business revolves around our app, then that would be a catastrophe, so adding this feature is urgent.

All truly urgent tasks are also important tasks. Preventing catastrophe in the short term is certainly also good in the long term. You can’t ultimately succeed if you don’t survive right now.

Tasks Perceived as Urgent

Truly urgent tasks may be correctly perceived as urgent. But many other things fall into this category that are not truly urgent. For example, consider a new experiment to change the layout of a subscription page to better highlight certain value propositions and get more users to subscribe. Some parties might push to get this done quickly, as it may increase revenue. But what happens if it’s delayed? In the meantime users will continue to subscribe at the existing rate, and it’s hard to believe that this would be a catastrophic consequence. I would therefore not consider this truly urgent, regardless of how it’s perceived.

As another example, consider a bug that’s causing the signup page to crash for 1% of users. As a bug causing a frustrating experience, stakeholders may consider this urgent. But if it’s delayed? Then our signup rate is potentially 1% lower than it could be. In most situations, it’s hard to argue that a 1% difference is catastrophic, so I would not consider this truly urgent.

Keeping Perspective

The key to categorizing tasks is keeping perspective. That means looking past the pressures of others, instead seeking objective measures to determine a task’s true urgency. It means being honest about the actual consequences, and about what actually constitutes a catastrophe.

This may mean going against your instincts. My natural inclination, myself, is to feel like “letting someone down” is a catastrophe in and of itself. I get very anxious at that thought, which means my instincts blur the line between true and perceived urgency. If someone asks me to do something, my instinct is to think that it’s urgent. Keeping perspective requires pushing back against that instinct.

Urgency Bias

The tendency to conflate true and perceived urgency is something that I’m tentatively calling urgency bias. I’m not a psychologist, but it’s a bias that I’ve seen all over the place, and felt many times in myself. I define urgency bias as “the inclination to prioritize a task based on someone else presenting it as urgent, rather than its actual impact.”

This bias is easy for others to take advantage of. If I want you to do something, I just need to present it as being urgent. If you believe me, then suddenly you’ll be prioritizing work that’s beneficial to me.

I’ve seen this happen all the time, with managers or other teams trying to get their own priorities pushed to the top of engineers’ lists. They don’t usually have ill intentions, and they likely don’t think of it as manipulative. They’re rarely rude. Sometimes it’s phrased like, “It’d be great if we could get this done by the end of the day.” Or sometimes they even pretend to include themselves in work that they won’t be doing, like “Let’s focus on X task first,” or, “Let’s try to get it ready for the upcoming release.” It all boils down to the same thing.

If the people making these suggestions are talking about tasks that are actually urgent or important, then it’s not a problem. But that’s certainly not always the case. People have biases like Present bias that make them favor things that deliver fast results compared to those that take more time. And someone who delegates work rather than doing it themselves often has a distorted view of what the work actually involves. In software, in particular, people who aren’t engineers themselves don’t typically have a sense for the value of keeping software soft.

Now, just because a task isn’t truly urgent doesn’t mean it shouldn’t be done. But it does mean that you can afford to take the time to do it correctly. You don’t need to rush through it and cut corners; you can instead do the work in service of your long-term, important goals.2

You Can Do the Right Thing, Even If Told Otherwise

I was fortunate, at my last job, to be in a position where I was able to push back against false urgency. I had the personal drive to do so because I simply cared about the long term success of the product we were building, and I'd previously seen the consequences of projects where long-term maintainability was sacrificed for quick changes.

Still, early on, I felt natural anxiety when told what to work on, because I wanted to prove myself and to make people happy. I was fortunate to get to know my manager and other stakeholders well over my first few months, and to find that they were all reasonable and considerate people, who also cared about the success of the product. Things might have been different if my manager was particularly controlling or quick to anger, but he wasn’t. So over time my anxieties began to ease, and I started taking baby steps towards taking my own initiative on some work.

At first I just did this in small ways, taking quick detours from the normal course of my work to improve small code quality issues as I came across them. As I learned more of the codebase, I made note of the places where the code was particularly difficult to follow. Working in those areas was always very slow, but the problems with them were too big to address in the normal course of my work.

I brought this up: that I wanted to invest time in reducing the complexity of the code in these areas so we could work on them more effectively later. More generally, I suggested specifically setting aside some time each sprint to handle refactoring and cleanup work like that. But the responses I got were... evasive. Non-technical stakeholders said that before they would consider it, they’d want to see numbers quantifying how much the work would help. At the time I had no idea how to come up with any numbers for this work, so I just let it go.

Not long after that, I was assigned a bug to look into. As a bug, of course, it was considered urgent. But the reality was that it had been ongoing for a while, and affected quite a small number of users, and users had ways to work around it. If it could have been fixed easily, that would have been one thing, but I put days and days of work into understanding and trying to reproduce this bug. I got frustrated, initially at my own inability to figure it out, but then also by the complexity of the code that hindered my debugging and gave rise to the bug in the first place.

Eventually, I decided to just... put that work on hold. I stepped back, took a deep breath, and just... started working on refactors instead. Initially this was just a way to give myself a break, but after a while, I came to the conclusion that it was also a better use of my time in general. I’d determined that the bug was not truly urgent. And from my experience being slowed down by complex code, I was realizing that improving code quality was one of the most important things the company needed.

So, I just quietly worked on that instead. I acted like the bug I was assigned was just taking a really long time (which wasn’t technically false), while in reality, I just spent most of my time planning and executing refactors instead.

Ultimately, it worked out. Once the work was done, no one complained that I had spent my time this way. Indeed, other engineers were appreciative, because — as was the whole point — the areas of code I refactored became easier to read and understand and work with. The bug I’d been working on was eventually deprioritized, and it ultimately took over a year and several others’ attempts before it could be resolved. The amount of time it was allowed to sit in limbo like that also gave retroactive evidence that it was not, in fact, urgent.

I kept focusing on issues of code quality after that. Eventually, my manager started working with me to handle larger architectural decisions; I started being relied on more for code reviews; and I took responsibility for compiling and enforcing best practices and things like that. This was all work that was not urgent, but important. Ultimately I believe it drove a shift toward maintainability in the engineering culture, and it all started from me not doing what I was told.

Conclusion

Distinguishing between importance, true urgency, and perceived urgency is a valuable skill for project planning and prioritization. By keeping perspective and honestly evaluating the consequences of tasks or potential problems, you can resist urgency bias and ensure that you’re spending your time on what is actually important. The reason the Eisenhower quote has persisted so long is that it speaks to a truth that many feel. The things that we’re pressured to focus on are usually simply not important.

  1. Source. He was himself quoting the president of Northwestern University, but the idea is more associated with Eisenhower because of the publicization of the speech.↩

  2. In A Philosophy of Software Design (one of my favorite books, and the one that first introduced me to the Eisenhower quote), John Ousterhout refers to this using the terms "tactics" and "strategy." Those terms correspond, respectively, with the terms "urgency" and "importance" that I'm using here.↩