Mastering email overload
There's something about this article overall that strikes me as wrong, and I can't figure out exactly what it is.
One of the recommendations is to "Answer briefly", and that one definitely is not what I would advise. The problem I see here, which may be specific to my company's environment, is that an email becomes a physical record of your response, and a short answer leaves too much up to the recipient's interpretation.
Part of the issue lies with the sender's original email: are the points made very clearly, are the deliverables stated correctly, does the sender actually understand what they are asking for and the resources that it takes to deliver? I find that I very frequently have to "debug the question", where I have to take the sender's email (which may be a very short, seemingly low-key request) and try and find out exactly what they want and whether what they are requesting will actually fulfill that need. I need to take that into account when composing a response, and make sure that I am answering the real question, not the one posed.
For example, I received an email recently with a request from someone asking whether adding elements to the AD schema was relatively simple to do, given that we were now migrated to Windows 2003. The short answer to that is "yes", with a focus on "relatively", and another spotlight on the fact that it is technically simple, but... As it turns out, this was someone who was trying to given the task to find out whether a particular unified messaging solution (fax, voicemail in your inbox) was going to be an easy install.
The short answer, unfortunately, leaves out the fact that for various reasons (standards, security, overall architecture) we would never implement the messaging solution the sender was looking at. Unless I probed a little further to find that out, I would have been on the record stating that this was not a solution of which we disapproved... dysfunctional, yes, but the nature of this particular company. The next thing I would have heard would have been from the support group for this business unit stating that we (as managers of AD) were the roadblocks in a half-million dollar project for a solution that had already been purchased, since we were refusing to perform the simple act of changing the AD schema, which we have already stated was easy to do. Effed up? Yes. But trust me, it happens all the time.
This is why my responses to emails tend to be longer. I want to make sure that our approach, our philosophy and our requirements are well-stated. If I could do that in a separate document that we could just attach as part of every response, I would do so, but a document like that would never see the light of day from all the input it would have to receive from business units, managers, legal, HR, the VP of Project Encumbrance, the Executive Director of Delay, etc.
I also get a lot of email queries for new systems, services or features that have to be denied for a variety of reasons: whether it's a standards issue, a security concern, a supportability and resource issue, it just cannot be done in the current environment. I could easily just type a message saying "no," but then the requestor would not understand why the request was denied and just label me as an obstacle to be worked around, rather than someone who's trying to do what's best for the company.
Not that I'm saying I'm perfect either, but I like to think I try my best.
I think that my main concern with the article is an assumption that others are already following the recommendations: they will have stated intentions and requirements clearly, and so a short answer is appropriate. I rarely find that is the case. Yes, I understand that the article asks readers to lead by example, but some of the recommendations will lead to bigger problems in the short term before they start producing significant results.Link