A 10 Second Guide to Smoother Projects: Urgent vs. Important

January 29, 2008


A little background information: I’ve decided to leave my job to launch a technology start-up company. (Talk about big news buried in an unsuspecting article, eh?)

As a result, I’ve spent most of this week transitioning my responsibilities to someone else. The handoff feels somewhat like a death-bed situation. Not because I think it won’t go well (I think it will go perfectly fine), but rather because I feel like I have a small window of time to think about and pass on the important advice I’d like to leave behind.

My position was Director of Software Development. This involved managing multiple teams responsible for new development and maintenance of a system with over one million lines of code. The single most important piece of knowledge I want to pass on to my successor is this:


Separate urgent items from important items.


Urgent items are those things that need to get done today or else the system will die. For example, if a client starts calling into the system with incorrectly formatted data, you urgently need to fix the situation, either by working with the client or adding code to accept the new format.

Important items are the longer term projects, for example: the new feature that increases profits by 10%, or the feature necessary for the big trade-show demo a month from now.

No matter how hard you try, there is no good way to prioritize one of these items against the other.

As a result, a team (or individual) can’t effectively work in both “urgent item” mode and “important item” mode at the same time.

Over the last few months, by far the most effective processes I’ve put into place is to assign all urgent items to a dedicated team. This enabled our group to handle almost any emergency thrown at us without having to re-adjust long term schedules. This saved a bunch of time that we used to waste jostling things about in order to accomodate the urgent item.

This also makes it very clear who will work on the item. When an emergency arose, I immediately sent it to the Firefighting team; nobody else has to be distracted. The Firefighting team might need to shuffle some priorities around, but they are used to that, because that’s the mode they work in all day.

I would imagine that as the group evolves, they will need to add a third type of team, resulting in:

The Research team works on technology gambles. The project may not work out, but if it does, then it will revolutionize the business. I would staff this team with senior people who are strong individual contributors who can investigate hazy ideas and make them reality.

« Back