If everything is top priority, then nothing is top priority

Last time, I mentioned that eventually everything is top priority. A similar topic is what I'm calling priority inflation, which takes more than one form.

Today's priority inflation is the introduction of new "top priority" items. (Chris Becker has some thoughts on this topic as well.)

"XYZ is very important to our project. Please make it your top priority." A few weeks later, "ABC is very important to our project. It should take priority over all other issues." When this happens, I like to ask, "Is this even more important than XYZ?" I've done it so much that my management has changed the way it introduces new top priorities: Instead of just saying "Please make ABC your top priority," they list out all the existing top priorities... in priority order.

ABC is very important to our project. There are just a handful of ABC issues remaining, and we would like to close them out by the end of the month. If you have an ABC issue, please make it your top priority. To summarize:

  1. ABC issues.
  2. XYZ issues.
  3. DEF issues.

I like this approach because it forces management to understand and acknowledge where their priorities are. If you're going to ship a product, you have to make hard choices, and one of them is deciding where your priorities are.

If everything is top priority, then nothing is top priority.

Update: Sometimes, the answer to "Is this even more important than XYZ?" was "No, XYZ is still more important than ABC." So it's not a gimme that if somebody says that ABC is top priority, it replaces what used to be the top priority. That's why it's important to keep track.

Comments (34)
  1. Robert'); DROP TABLE Students;-- says:

    So if I understand your post correctly, you’re proud because you’ve forced your bosses to implement their own version of nitpicker’s corner.

    Jolly good show old chap!

  2. John says:

    You know, that’s kind of a catchy slogan:

    Windows Longhorn – If everything is top priority, then nothing is top priority.

  3. Rachael says:

    I completely agree.

    We have priorities 1 to 5, but 4 and 5 are never used. If I give things 4, they get upgraded to 3. So things which should be 5 are 3, things which should be 4 are 2, and everything which should be 1s, 2s and 3s gets squished into 1, so you can’t tell which of all the glut of 1s are actually more important.

  4. Joe says:

    Dude, the last few posts are sounding more and more bitter all the time.  I’ve gone through that a couple of times in my career, and it usually signals it’s time for a job change (or a really long vacation).  I’m just saying…

  5. Waage says:

    In soviet russia, priority tops you!

  6. Pierre B. says:

    I think this whole subject is a programmer / scientific / engineer state of mind, which is of taking thing literally.

    When someone says that something is top priority, it just means that. If something else was top before, it’s no longer top. I man when the media announces that player ABC is now the #1 tennis player, do every tennis enthusisat goes "Oh, and what about XYZ, huh? He was #1, so which it is?" No.

    It’s funny, because in programming we have the same concepts embodied, for example, in MRU lists and we make no fuss about understanding that when a new item becomes the most-recent, all previous most recent move a notch down.

    So, move along, nothing to see…

  7. Adrian says:

    We’re in the planning stages of our next release.  On my work list there are only two Priority 1 items.  Of course, there are seven "Priority 0" items.  There are also two Priority 2 items, but those are so far down the list, they’ll likely be cut.

  8. tsrblke says:

    @ Robert,

    I wouldn’t call this a "nitpicker’s corner"  I’ve seen management in all sorts of ranges (everything from Fast Food Manager when I was a Teenager, to large company managers) fail to properly prioritize things.  when you’re not doing the bulk of the work (or any work in some cases except designating) it’s easy to see everything as a Top Priority.  Someone whose in the trenches has to come and say "No really, what’s the top priority, because this is a conflicting nature."

    Raymond’s just looking at the big picture (or the Long term if you prefer).  I wish more management did it this way.  Heck I’ve got so many top priorities now, I’m totally lost (thankfully, in my field of science I can run a lot of things in tandem and I don’t mean spending half my day on one issue then have on another, I mean actually having two things working at the same time, but I’d imagine that’s a special case.)

  9. Godzila says:

    Raymond doesn’t come off as bitter to me at all. Some folks just are not the ‘let’s all have a team meeting to hug and sing campfire songs’ type people.

    Listen I don’t mean to go off on a rant here, but observing and commenting on one’s reality doesn’t make one a negative or bitter person. Nor does it signal a ‘time for a job change’, that’s just running away from the problem.

    If anything Raymond’s observations are exactly what is needed to -better- the situation. By pointing stuff like this out, it may actually (long shot) be corrected!

    Or should we all just sit in the room with the elephant in the corner and pass the rose colored glasses around the table?

  10. CDarklock says:

    I think this largely depends on how you define priority. When you define "top priority" as "line item number 1", this is a valid criticism, but when "top priority" is "the first N line items"… you can legitimately have N top priorities. If that’s not enough, you can always increase the value of N.

    I think the problem for most developers is that they can only work on one thing at a time, so they view "top priority" as "what should I do RIGHT NOW". When there are multiple top priorities, you have to make a decision, and they frequently don’t have enough information to make that decision painlessly by themselves.

    The painless way to make decisions is to understand that all difficult decisions are a lack of information. You need more information; if you can’t get it, or it is too difficult/time-consuming/expensive to get, you should discard the clearly-incorrect options and choose arbitrarily from those which remain. So when there are twelve top priorities, and you don’t know which of three items in that list you should do RIGHT NOW (assuming the other nine are things you can’t or shouldn’t do for obvious reasons), just pick one. It will be less wrong than doing nothing.

  11. Mark (The other Mark) says:

    Not to mention that, when switching between items, it’s fairly easy to "lose" time. If, for example, you’ve received a project on some interestingly documented peice of code and are trying to understand it, then have to take several days to work on another item, you may lose some of the time already invested.

    Possibly complicating it even further, while you are of on priority AAA+++, someone may have checked in source code that invalidates changes you’ve started, but not finished on priority AAA++.

    Yes, good note-taking and good source control can help with those specific examples, they are meant as off the cuff examples of a general case. In some cases, the time lost might be minutes, in others, perhaps hours.

    On a related front, for a look at "Priority Inflation", it might be interesting to check the Message Traffic Priorities the US used during WWII. Overuse of high priority codes led to the constant invention of new, higher priority codes.

  12. Wes says:

    I suppose you could call this phenomenon the Syndrome Syndrome. Or maybe not.

    "When everyone’s super…no one will be." — Syndrome, THE INCREDIBLES

  13. (a completly different) mark says:

    I used to use a similar trick with an absent minded boss at a previous job.

    When he would come in with some new project or task, i ask so what do you want me to stop working on.

    @Mark (the other Mark): i have ran into that exact scenario of loosing time due to switching projects, i found that the ‘extra’ time lost is proportional to the time taken for the new more important project.

  14. Angus says:

    My development group has discussed this extensively. We (mostly) agree that the only way to make sense of it is to ignore priority numbers, but have a total ordering of all of our requests, and have it published and editable (e.g., on a wiki). Unfortunately, we haven’t got management to but into that notion yet.

  15. You'll never take me alive. says:

    So one alternative to having a priority estimate is to have a gain estimate.  Someone submitting work has to associate a dollar figure they expect the work to gain the company.

    The problem than becomes one of resource optimization resulting in better resulting output.  And its harder to inflate and easier to challenge business return estimates.

  16. peterchen says:

    "So if I understand your post correctly, you’re proud because you’ve forced your bosses to implement their own version of nitpicker’s corner."

    No, he forced his managers to actually manage.

    Which sometimes, unfortunately, is an achievement to be proud of.

  17. Nick says:

    Heh.  The best example I can think of this is experienced when calling customer or technical support for a product.

    "Thank you for calling Foobar Inc where all of our customers are our top priority!"

    Your call will be answered in the order it was received."

  18. Greg D says:

    Is there anybody who’s been working as a professional developer for more than 12 months that hasn’t run into this?

    I know that I clarify my “top priority” every time I’m given a new top priority, and it’s absolutely not always the case that the new top priority beats the old one.  Especially when there are three different managers giving me my top priority tasks.

  19. Erik F says:

    This sounds like your boss has mastered the PROJECT_TOPMOST flag for the SetProjectPriorityPos() function.  They must have taken the advanced course (most managers still have yet to grasp the difference between this and PROJECT_TOP.  Maybe they should be required to read http://blogs.msdn.com/oldnewthing/archive/2005/11/21/495246.aspx.)

  20. Stephen says:

    The top problem with having multiple high-priority items is that humans have a huge context-switching latency — on the order of 15-30 minutes.  Every time your boss changes your priorities (which, to me, happens several times per day), everything you’re working on gets later — which of course results in a new round of priority shuffling by management.

    Some folks try to cope with multiple "top" priorities by time-sharing, but that runs into the same problem, except that it’s self-imposed.  You will finish faster if you finish #1A and then work on #1B than if you try to do them both at the same time, incurring all those context switching penalties.

    I’ve used the same "is this more important than the last top priority item you gave me?" trick, but many managers (i.e. those without an engineering or math background) will simply respond that both of the items are top priority and any explanation that two things can’t be #1 go right over their heads.  After all, two teams can be tied for a given ranking, right?

  21. manicmarc says:

    A client of ours insisted on a new category for support requests. In addition to low, medium and high, they wanted "urgent" above high. Of course low never gets used.

    It’s like McDonalds not selling small portions. They start at medium and then have Large and Super Size.

  22. Keith Patrick says:

    I’ve been a somewhat similar scenario that involved different managers (most of whom I do not report to) coming directly to me to make something my top priority. Gets really messy when my actual manager makes something else my priority, leading another manager to go to *his* manager to pull rank and get pet priority B bumped above. It ultimately becomes a game of "which manager has more clout?"

    (I could spend a full hour ranting and raving about this topic, easily)

  23. Cheong says:

    When your company’s management doesn’t follow "the chain of command" (commands must be passed only through the immediate upper level staff), you can easily have multiple "top priorities".

    And often the actual priority is not related to the nature of the bug / work, but the importance of the authority person so add the task.

    When I was working at certain "ex-company", sometimes I rejected orders from my immediate supervisor because my worklist is already full of items directly assigned by my manager. :P

  24. Milo says:

    It all boils down to corporate culture. There are urgent tasks, important tasks, and nice-to-haves. But most managers cannot distinguish one from the other and sometimes no matter how much explanation you make they just don’t get it. You can’t blame if the company doesn’t have sound and good project management philosophy, training,etc. They might not have the budget to implement CMMI level 5, nor the process engineering department, quality audit department, etc.

    In my case, I decided to work in a company that has all the things above and value project management and software development lifecycle at a high degree. Of course, there will still be projects that suck, but overall, the good management backbone makes everything easy.

    I remember 8 years ago when I was still in college, I would research of the most desirable and best place companies to work for, and I did everything possible to work in the top 50 in the list.

  25. Julian says:

    I am very impressed that your management was able to take the hint and start managing priorities (and you, for getting the hint across successfully.)

    I had a manager who would give me new "top priority" tasks every day – tasks that would take more than a day to complete, with the result that nothing could ever get finished.

    I threatened to write a script that deleted any email from him containing the text "top priority", "most urgent", or "drop what you are doing for this", but I only had limited success in changing his behaviour.

  26. Miles Archer says:

    Yep. Good job on this. I think I just annoy my management with this kind of thing. When it comes right down to it, just about everyone wants 10 pounds of stuff in a 5 pound bag.

  27. Ray Trent says:

    You’re also (perhaps intentionally, and perhaps wisely) missing the subtext message by limiting the problem domain too much.

    What they are *really* saying is:

    "Here are some things which are *not* top priority:

    1) Sleep.

    2) You having a life.

    3) Surfing the web.

    4) Answering emails."

    Though, sadly, apparently *not*:

    "5) Meetings."

  28. John says:

    At a previous company we used to have priorities in traffic light colours: Red top priority then descending from Amber to Green. This worked well as conceptually red means danger, as in get this one fixed first! Unfortunately everything was being entered in red, management decided we needed even higher priorities so we got grey and black!

  29. Kip says:

    In my company’s bug tracking, we have priority 1-4.  But 2, 3, 4 are basically treated exactly the same (neglected). So the majority of bugs are priority 1.  But then that must have gotten confusing, so we created several flags that can be appended to sev1 bugs:  mustfix, mandatory, and HMA.  Mandatory and mustfix sound like the same thing, but for whatever reason mandatory is more serious.  HMA is "high management attention", which basically means a customer is threatening to close their contract, so your boss’s boss knows about this issue and requires status updates at least twice a day.

  30. IMil says:

    A whole day passed without a Dilbert reference?

    Let me fix it:


  31. Matt Doar says:

    This reminds me of something I wrote in a book a few years ago.

    Severity Inflation

    "In most companies and projects, limited resources mean that as the ship date for a release approaches, only bugs with Severity 1 and 2 get fixed; the others are closed or deferred. Over time this practice leads to severity inflation. Someone entering a bug knows that this bug won’t stop the product, but she remembers that none of her Severity 3 bugs got fixed last time and she really wants this one fixed, so she makes it a Severity 2. In the extreme, by a process of induction, all bugs become Severity 1 bugs and the purpose of the

    field is lost."

    Whether it’s called Severity or Priority or anything else, it’s always got an invisible word in front of it – who’s priority it is.

    E.g. Engineering Priority, Customer Priority, CFO priority.


    ("Practical Development Environments", O’Reilly, 2005)

  32. (a completly different) Mark says:

    @stephen: those ‘context-switch’ penalties can be reduced when it is self imposed; you can plan when you don the switch. Similar to what one does at the end of the day, you find a good stopping point, which will minimize the time loss when you start up again the next day.

  33. I think an important thing about being agile a great developer is to make sure your backlog is correctly

Comments are closed.