Even top executives consistently make this mistake when sending e-mail.
10 years ago when I was developing software, my manager sent me an e-mail:
What is the status of bug #23508 Client crashes on call park notification?
I had been making great progress on the issue, so I was thrilled to answer him right away.
I've been investigating the crash and I think I know why it occurs. The problem is that user01 gets a notification to park his call against user02. The network layer tells the UI to confirm the call park with the user via a message box. However, immediately after we receive the first notification, we get a second notification which requires the park to be completed at the UI layer.
Fixing this would mean buffering events until the UI completes its task (function ParkedCall::registerListener). It might be as simple as adding a new "buferredEvents" list in class NetworkParkHandler.
We can't reproduce the issue ourselves, so it's hard to actually confirm that our fix attempt will work since we do not know what caused the server to behave like. Do you have a contact on server side that I could test this with? Hopefully, this fix attempt will not carry a signficant risk of regression on the call park functionality.
Overall, I do not think we would be able to provide a fix by the deadline this Friday. I think that this is a very rare scenario so the chances of it affecting a customer are quite slim.
Then I waited. No response. Finally, a call from Jim. "I'm not sure I understand" he said. "What exactly is the status?"
Suddenly I realized I had just wasted a serious chunk of time writing an e-mail that no one cared about, and confused my manager along the way.
10 years later, I am running a business unit, working with executives, senior team members and million dollar clients, and yet even at that level I see the same e-mail communication mistake happening over and over again. People wasting other people's time. Miscommunications due to e-mail.
So please, whether you are a junior software developer or a senior sales executive, take note!
What Information Do They Really Want?
In my example, I was all too eager to dump all the information I could possibly think of into an e-mail response. The more detailed the better, I thought. Later on I found out from my manager that he didn't get past the first paragraph.
When you are asked for an update from a customer, a progress report from your manager, or the all-too-familiar ask about "status", ask yourself "What information exactly are they really looking for?"
Know your audience. The higher up the corporate ladder you go the less likely the audience will want to decipher technical jargon and other forms of detail amidst the hundreds of other e-mails they are already getting each day. But it's not just executives - junior people are not interested in your life story either!
Often, the information they really want will be one or several of the following:
Your job is to figure out what information is needed and deliver this information in the most succinct way possible.
Seek to understand before you give your answer. Once on the phone, I asked my manager what exactly he was looking for in a status report. He told me every Monday he fills out a spreadsheet with forecast dates of each fix. In this case, the information he was really looking for was a date.
Formulate Your Bottom Line
People are busy. They multitask on different projects and receive calls and e-mails throughout the day. If you send them an e-mail the size of a novel, chances are they will not read past the first sentence.
If you want to get your message across, it's important to formulate a bottom line, and then put it first in your e-mail. In fact, in many cases that's the ONLY thing you need to put in your e-mail. Although organized paragraphs with bold headers and italicized keywords are essential when you need to convey a lot of information, most e-mails don't even need to go there. In most cases, you should strive to get to the point in 3 lines or less.
The next Monday morning, I knew my manager was looking for a forecast date. "The fix should be ready in 2 weeks, as long as I get someone on the server side to test it with."
There. I can rest easy knowing my manager will have read my 1 line response. Not to mention I've just saved some valuable typing time!
If the recipient of my mail needs additional information, he will ask for it and I will provide it in another bottom line response.
Highlight Action Items
In my original brain dump e-mail with Jim, I had an action item in there. Can you spot it? It's hiding in the 3rd paragraph - "Do you have a contact on server side that I could test this with?" Jim certainly didn't see it, and even if he had, he probably wouldn't have understood who the action was for and when it was due by.
One of the main purposes of writing an e-mail is to ask for help, directly or indirectly. When multiple people are involved in the task, it is easy to be confused on who is responsible for what action.
Consider the following:
Hi Mark and Tina,
Can one of you test that the new functionality is working on our server?
If Mark or Tina are really nice, one of them will take the initiative to test the scenario and report the results back to you. However, if they are very busy, Mark may wait for Tina to respond, and vice versa, leading to a slow response or no response at all.
If you are asking for help, remember 3 key ingredients:
A better version of the e-mail might look like this:
Can you test the new functionality on our server or give me the name of someone who can? If there is still a problem, please send me detailed server logs. I need a response from you by tomorrow.
Apply the 3-Line Rule
Once you have your bottom line and action items ready, read it over. Does your e-mail exceed 3 lines? If so, you might consider using a different medium to get your message across.
Phone? Meeting? Intranet post? The best medium to choose depends on your goal, and sometimes, using more than one medium will yield the best results.
To ensure an urgent task is dealt with right away, maybe you need to pick up the phone for a quick discussion or meet in person with your team to go over a new process. An e-mail might sit in the recipient's inbox until after the deadline.
What about explaining a new process to your team? You should probably go over the process during a separate meeting, as well as publish the process in an intranet post for reference later on.
Remember, the medium you choose determines the impact of your message on the recipients. Choose wisely to ensure your message is clear and your goal is met efficiently.