You’re not my manager, so I’m not going to ask how high when you tell me to jump

Date:May 22, 2007 / year-entry #180
Orig Link:
Comments:    44
Summary:This happens a lot. I'm minding my own business and then I start getting nag mail from somebody I've never heard of. It usually is marked "High Priority" and the content has lots of boldface and wording that makes it sound like the world is going to end tomorrow. (Pretend "elephant"† is some new buzzword.)...

This happens a lot. I'm minding my own business and then I start getting nag mail from somebody I've never heard of. It usually is marked "High Priority" and the content has lots of boldface and wording that makes it sound like the world is going to end tomorrow. (Pretend "elephant"† is some new buzzword.)


Your component has not completed its Elephant review. Elephant-readiness is a release criterion. You must visit http://elephantready/?id=16384 and fill out an Elephant compliance form by the end of the week.

When you go to the web site, it asks you to confirm a few pages of statements like this:

Component does not assume rhinos.
Component does not cover animals with a blanket (elephants are big).
Component supports a variable amount of peanuts.
Component does not require animal to have a horn.
Component does not reject animals with tusks.
All interfaces exposed by component can operate on elephants.

Okay, so I get this mail and my first reaction is "What's an elephant?"

I lied. That's not my first reaction. My first reaction is "Who the hell are you? Who died and made you my manager?"

Note to managers: Sending out random mail like this won't make you any friends. It turns out people don't like it when somebody creates work for them. Especially when it comes out of nowhere without warning. and double especially when they've never even heard of your feature. So far, you haven't given them any indication why they care aside from "You should care because I said so."

And you are who again?

Often when I look at these checklists, I can't even answer them. I mean, sure, I didn't write any code that assumes rhinos, but my component relies on other components, and I don't know whether those other components assume rhinos. Similarly, my code doesn't care about horns or tusks, but maybe one of the components I rely on does. I don't know.

As a result, I usually skip the questionnaire filled with questions I can't answer and just wait for the next round of urgent messages. That way, I can ignore the second round, too.

For you see, my manager decides what tasks I should be working on, not you. If you think my manager is doing a bad job of prioritizing those tasks, then feel free to have a little meeting with my manager and work out some sort of agreement. Until then, don't bug me. I have work to do.

For those new to this web site (and a reminder to those with poor memory):

†I disguise the name because (1) it's not important to the story, and because (2) the goal is not to ridicule but rather to illustrate a point. Attempts to guess what "elephant" is will be deleted. Don't make me delete further stories in this series like I did with "Stories about Bob."

Comments (44)
  1. whatever says:

    "my first reaction is "What’s an elephant?""

    It is a large grey mammal, but that’s not important right now.

  2. anonymous says:

    As Raymond wrote: Pretend "elephant" is some new buzzword!

    Of course, Raymond, you should always make sure that your software is buzzword-complaint. You’re saving the config file as a plain text file? Use XML instead! Then you can claim that you’re using modern XML technology.</irony>

  3. Michiel says:

    It’s quite a useful flag. Make an Inbox rule that moves it all to a subfolder ‘Important’. Then, ignore it. Of course, this only works if you have a higher rule for people that actually matter, e.g. your boss.

    On a similar note, always look at mail marked down. Usually that’s because people took time to realize you can’t have everything done today. So make sure to add a reminder to that mail for when you do have time.

  4. Sven Groot says:

    It is a large grey mammal, but that’s not important right now.

    Airplane FTW! :P

  5. sean says:

    Airplane FTW! :P

    Police Squad!

  6. SM says:

    When I reply to ‘high priority’ emails, I like to  include somewhere: "only spammers use the high priority flag."

  7. Larry Hosken says:

    <obscure ref="elephant:behavior">

    Yours is a good strategy. Whenever you hear "elephant" and "must" in the same sentence, that means you should stay the heck away.


  8. Cody says:

    I’m sorry, but "does not assume rhinos" has me in stitches.

  9. Stephen Jones says:

    Ignoring high priority emails is not always a good strategy.

    I sent one out with a high priority flag yesterday. The reason was that the one I sent out before had a couple of mistakes, and the new email collected them. The high priority flag was intended to get users to open the amended one first.

  10. Grant says:

    I once got an email flagged as low-priority.  I was so shocked I immediately dropped everything and helped the guy out on principal.

  11. AdamT says:

    As Stephen Jones mentioned – ignoring emails marked as high priority might not be a good idea – but it gets to the point where /everything/ is marked as high priority, and every ticket/bug/issue logged must be marked as ‘urgent’ – the term becomes meaningless.

    "Will my problem be first in the queue?"

    "Sure, it’ll be first, along with all the other problems that are first in the queue".

  12. ex-DonH says:

    When I get, say, a property tax notice in the mail, it usually comes in an envelope marked “Important: Official Business” and demands that I pay money by a fixed date, ignoring all my existing priorities.  Isn’t the Elephant campaign just another attempt to get developers to “pay their taxes”, a topic you’ve addressed before? (

    Once you’ve consented to the ability of others to levy taxes on you, do you really expect them to be polite when they exercise that ability?

    [I think you’re taking the analogy too literally. -Raymond]
  13. AndyC says:

    There’s an old English proverb – "Poor planning on your part does not constitute an emergency on mine."- which pretty much sums up how I deal with most emails labelled ‘urgent’

  14. Andrew Feldstein says:

    I do not even display the "High Priority" flag in my Outlook inbox.  Too many people around here set it on *every* email they send.

  15. njkayaker says:

    "Ignoring high priority emails is not always a good strategy.

    I sent one out with a high priority flag yesterday. The reason was that the one I sent out before had a couple of mistakes, and the new email collected them. The high priority flag was intended to get users to open the amended one first."

    A lame reason to use the "high priority" flag.

    Anyway, "everybody" "always" reads the oldest emails first!

  16. njkayaker says:

    Something is truly urgent only to the recipient or to your boss and, rarely, to "everybody" (eg, the file system is critically full, the building is burning) or some life-or-death thing.

    Almost nothing is urgent because it’s urgent to you or your precious "elephant" project.

  17. John G says:

    When everything is the highest priority, it is also the lowest priority.

  18. thereyago says:

    Low priority flags in my company mean "hey, I’ve attached a really funny link" and pretty much always get read within 10 minutes.

  19. Dean Harding says:

    I just reflexively checked all those checkboxes. Given that I know nothing about elephents, and all I’m interested in is making the person go away, can I just check all those checkboxes and call it a day?

  20. ulric says:

    this is going a tangent, but I’ve learned two things about the priority flags

    1) using the low priority flag as the same effect as using the high-priority one.  people read it immediately.  

    I’ve met more than one person who actually thought that using High Priorty made their mails ‘go faster’.  One claimed to have tested it with hotmail.

    Of course, using the red "!" flag actually…

    2) makes people angry and gets their blood pumping.

    I do use these flags.. but it’s usually the low-priority one that I use.  It means that the mail is funny and pointless.  And people naturally jump on it immediately.

  21. Dnomyar says:

    You seem to be missing an asterisk.


    “The dagger is used to indicate a footnote, in the same way an asterisk is. However, the dagger is only used as a second footnote when an asterisk is already used.”

    [I understand there are a lot of violations of formal writing style over on LiveJournal, too; you might want to let them know. -Raymond]
  22. Greg Beech says:

    Dnomyar – but then he would probably expose himself to having to qualify that * does not represent a pointer. At least the dagger symbol doesn’t represent anything in mainstream programming languages yet (well, until the C++/CLI guys come up with another few types of pointer anyway).

    As noted many, many times before. By nitpicking the nitpickers corner you aren’t being funny or original. Sorry.

  23. Curt Hagenlocher says:

    Totally off-topic, but 99% of the snail mail I get that’s marked "Important: Official Business" consists of offers to refinance my mortgage.

    Most of the email I get that’s marked "high priority" reflects the perceived self-importance of the sender and not of the content.

  24. JamesNT says:

    I completely agree with Mr. Chen on this one.  I have had many people, typically employees of those I contract with, send me an email demanding that I stop everything I am doing to fix some problem for them.  What they FAIL to realize is that any work I do for their employer constitutes billable hours (remember, I’m a contractor).  What I typically do is tell the person I am contracting for that he/she should explain to their employees that I am not a free resource and that they should go through their boss such that the need for the work can be evaluated and if deemed necessary, scheduled.  

    But that doesn’t stop the employees from mailing me anyway.

    And it certainly doesn’t stop that annoying-as-hell high priority flag.


  25. Alex says:

    Sure, you can’t implicitly trust that all pieces of code your code depends on do not assume rhinos, but if they all have to answer the same questions, the project lead can be sure that no code assumes rhinos.

  26. James says:

    Alex: not necessarily – depending on the nature of rhinos, a combination of apparently rhino-free components may exhibit rhino dependency between them. If it’s resource consumption, your code never using more than 3k of stack space and my code never using more than 3k of stack space doesn’t mean the combination will run safely with a 4k stack…

    Besides, the need for Elephant is clearly all Raymond’s fault in the first place for causing a run on ivory:

  27. Ahhh ‘Urgent’ such an oft abused word – I don’t know why it’s abused as much as it is. Right now I have about nine tasks all marked as urgent so my query is "which is more urgent than the others?".

    The word ‘urgent’ is like the boy who cried wolf, when everything is urgent nothing can be urgent.

  28. Hayden says:

    cf Dilbert:

    "Why can’t you concentrate your resources across the board?"


  29. Drak says:

    re: Greg

    <mindless fun>Actually in this case * would represent a pointer (of sorts) to the * in the nitpickers corner. </mindless fun>

  30. ulric says:

    I did not know that about daggers. I enjoyed that comment

  31. Harvey Pengwyn says:

    The dagger would have made a fine symbol for a huge pointer in the 16 bit segmented architecture, the relative length of the major axis to the minor symbolising its hugeness.

  32. You think the emails you get from your managers are bad?  

    You should see what I got recently:

  33. Colin says:

    Most high priority emails are irrelephant.

  34. Mikkin says:

    Oh, it’s an exclamation mark. I always thought it was an artless rendering of a red herring!

  35. Mark Anderson says:

    Not to sidetrack the discussion from email features, but…

    This actually is a huge problem with large software development organizations. Is this an argument for ‘matrix management’ in software projects? :-) I don’t think this is specific to Microsoft; it’s a property of any large organization at these scales. I agree the Elephant team doesn’t seem to be handling this very well, but it’s a hard problem.

    Typically a large project like windows gets broken down into teams along the major functional components of the system. But then there are cross functional things; elephants, snakes, sharks, etc. All the components need to support those cross functional things well for the system to work, and in many cases you need close to 100% compliance or the cross functional thing doesn’t get you much.

    The component team management tends to be resistant to you putting new requirements on them; it creates massive amount of push back. It often turns into a classic unfunded mandate problem; where’s the budget adds to fund the devs tasked with elephant compliance?

    If you are the elephant manager, you are in an awkward place; how do you get your job done? You could have a team of your own devs who can go through and do the work of insuring elephant compliance. But this has all sorts of issues; what if elephant compliance requires major changes, even a redesign? Then there’s the maintenance issues; does it stay elephant compliant as the feature team does its work?

    If you are lucky, there’s some way to automated verify elephant compliance, and you just track elephant compliance and jump on backsliders. Easier said than done.

    Otherwise, what else do you do? Do you send elephant awareness reps to each component team, and help them be elephant compliant? It isn’t enough to sit in at the design phase and say "Yep, this design is elephant compliant." Some of these things require attention at the micro level; a single line of code could cause systematic problems. (Pardon the lack of concrete examples, but I’m trying to respect Raymond’s desire to keep specifics out of it.)

    You end up doing things like writing the "Elephant compliance coding guidelines" and having elephant compliance training sessions. It usually takes a strong mandate from the top of the organization to get people to devote effort to it. Component team management has to buy in one way or another, and dedicate scarce resources to it. Getting these kind of cross function things right (or at least consistent) is a huge factor in the overall fit and finish of the system, and the user’s perception of quality. But if you are a manager of a narrow piece of system functionality, it can seem like a distraction from delivering your product.

    I won’t even talk about what happens when conflicting objectives like the Elephant team and the Mouse team collide :-)

    I’m a relatively recent hire at Microsoft, and I’ve gone from "those idiots, why can’t they make this thing work right" to "huh, it’s amazing that a system of this size and complexity works so well". Not that that eases the pain level for the users. I get asked as the family Microsoft rep, why can’t you guys get these simple things right? I think this is a place where the quote "everything is very simple in war, but the simplest thing is difficult" might apply.

    For internal folks, I work in the PPRC/CSE, a group that has produced a number of tools to assist with certain animal control issues.

  36. Bikedude says:

    Sorry, but that urgent mail looks like a spam. Copy its entire contents with complete headers and submit to

  37. nexusprime says:

    And who’s idea was it to come up with "read receipts", anyway?

    I generally never send these out of principle, unless its something that requires a response, and then I’ll send the receipt and not respond in any kind of timely fashion.

    In other words, I’m ignoring you, and I know (and am happy) that you know I am.

  38. This is why you need trained project coordinators and managers to stay on top and handle the organizational effort instead of spending thousands of cycles and millions of dollars on a ERM to flatten your organization.

    The more time developers have to spend cycles on this crap the more you exponentially decrease productivity.

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index