Emails are so easy to use and so often used that we never think about them again. This article will introduce 3 dangers inherent to emails: immediacy, room for interpretation, crucial information storage.
We will present solutions to reducing these risks: delaying all sent emails, a safe email protocol agreement, thread management. This article is the part #2 of a series. The previous article in this series is available there: Keys to avoiding conflicts in an offshore software development project – Part 1.
Do you remember that email you sent fast because you were upset, angry or simply in a big rush? You know? …the one that came back in your mailbox with a big nightmare attached to it!… Well, it happened to us all and is likely to happen again. It would be nice to avoid the next one, though.
In a cross-cultural configuration like in an offshore software development project, the risks are much higher: a word badly interpreted, a tone misread, a joke not universally funny, etc. The problem is even worse as most of us are not even aware of the risk. We all believe that humans are humans and that we basically exchange the same way by emails. No, humans are not all identical and they certainly do not read emails with the same eye as yours. Interpretation is everything; we will see that in the next article of this series.
And what about that other email containing the new agreed deadline? It was …when you were talking about how to recruit a Graphic Designer. This quote must be somewhere, correct? Unfortunate that the last 3 search you made did not show what you were looking for!
When teams are remote from each other they make a great use of emails. That is natural as it is fast, reliable and as we have seen in part #1 of this series: asynchronous. The experience shows that one difficulty is to keep track of the threads and conversations exchanged. Emails contain various level of information, but it is very common to contain crucial information about the project, even if you do not want it. This goes from a precision on a requirement to a re-definition of a dead line or information about who is in charge of what. All in all, you may very well have a great software tool for your project management; it is very likely that your email will be a mine of information anyway, even against your will.
The objectives are:
- Reduce the risks of sending an email we will regret almost as soon as it is sent
- Reduce the risks of misinterpretation of emails
- Reduce the risks of loosing track of conversation, especially in the context of offshore software development, where people use more the email than they see each other
Let’s see how to achieve these 3 goals.
#1 How to never send again the email you will regret!
This will sound surprising but what we are now about to suggest is to do later what you could be doing now! In fact, have your mailer do later what it could be doing now. In short: put a delay in all the emails you send!
How does this work?
If your mailer allows it, automation is definitely the best option, but it can be done manually. Basically, you consider that every email is a time bomb. As such it can be defuse, but you need a couple of minutes to do so. Therefore you setup your outgoing email to always wait a few minutes before actually sending the message. I personally delay each email by 3 minutes. Outlook 2010 allows you to do that with a simple rule.
When you press the send button, your brain starts thinking about the consequences of your act. Then, you may realize how foolish or pointless your email was. And great news: you have time to change the course of events! You go back to your outbox, re-open the silly mail and modify or delete at will. You are not doomed anymore!
Why all emails?
Some might wonder why we need to do that for all emails since most of them are innocent anyway. The answer is double:
- You know that the email is innocent only because your brain tells you so after clicking the send button
- Do you really think that all emails cannot wait another 3 minutes?
What about real urgent emails?
What you can do for the real urgent answers is the following: add a code inside your email to tell the mailer that this one is an exception. I personally use the code [u] for “urgent”. You can place it anywhere and as small as you wish. The mailer will read it and act immediately. Problem sorted: the urgency is the exception, just like in real life.
#2 Reduce risks of misinterpretation: Safe Email Protocol Agreement
This problem is a tricky one because it is for part inherent to the written nature of the email. Saying that, an email is also a tool and is used in a very special way within a software development project. Unlike a bigger document like Requirements or a Vision, emails are often shorter with one or at most a handful of points in them. They are mostly formatted informally.
Here is a protocol that can save you from the agro of a misinterpreted email:
- When you receive an email, always assume that the sender has the best intentions. Our natural reaction is by default the opposite. Human beings are great at being critical and it takes energy to be constructive. In this case, always start on the right foot: the sender wants you good!
- Agree with the people you regularly correspond with that it is acceptable and even desirable to ask for explanation when something is unclear in an email. Then, when you read your emails, hunt for areas of possible misinterpretation. Ambiguities come a lot from adjectives or adverbs (but not only): “fast”, “reliable”, “soon”, etc.
- If possible, have regular voice conversations with the your correspondents. A regular chat is a strong way to create a common background on a topic. So, a chat on the project, for instance once a week is desirable.
- When the opportunity occurs, meet face to face. It is not always possible on an offshore software development project, but if it is possible then do it. Meeting with someone gives you a lot of clues about this person. You will “read” the others and your brain will keep that information and integrate that when you will write to and read from this person.
- Always answer your emails, even to say that you will answer later. Doing so, you show that you care for the other and you will put this person at ease with a possible delay. Encourage people to send you reminders for when you are late to answer. Make clear that a reminder is perfectly acceptable and consider them as such.
#3 Reduce risk to loose information tracks
Because emails are quite informal, people tend to just add anything that comes to mind into every email they are about to send. If this is convenient on the spot, it is a total nightmare later on. You can easily end-up asking someone to send you something you know you already have. And when you get yourself that type of message, you always wonder what on earth the other is doing with the info you send. Do they care? So, if you do not want to upset your correspondent anymore you’d rather put in place the following technique. A great discipline to have is to always create and maintain topic-threads with crystal clear titles. Here are the rules of the game:
- Every single email must have a proper title! Avoid at all cost the awful “News” or “Update” or “Need”. I have been using the following format for years and I am extremely glad I did: [Major Topic] Subtopic. For instance:
- [ACME company] request for quote
- [Project XYZ] Task 28
- [Web site] Need for a new Contact Form
- [Staff] Recruitment of a PM
- When you are writing about a topic, especially when you are answering, avoid at all cost to blend a totally different topic inside. For instance, if you are writing about the profile of your next Project manager, there is no need to add a few words on the new Contact Form page. Save it for the other thread.
- When a topic start to get wider, split it in 2. Create a new thread that will live its own life. For instance, inside the PM recruitment thread appears a topic about the agencies used inside the company. At some point, split for a new [Recruitment Strategy] Selection of the agencies.
- When an email is key to a thread or a project, mark it as such. Create a tag like #key email, or #milestone. You will later be able to find these emails faster in the jungle of emails.
Of course, you probably have a few tricks of your own. The points above are very easy to setup. They do not require any new tool or any training. They do not add any burden on your work. They are great time savers though!
At the beginning, our experience shows that people are reluctant to apply these rules. But they do not deserve any complain in terms of time burden. I know for a fact that they just save time and add to the quality of your project.
Although emails are part of our daily life, they can present some traps of their own, especially with the context of an Offshore Software Development Project. By following simple rules like delaying, safe email protocol agreement and Thread Management, one can make email much more friendly and reduce the risks inherent to their use.
Next Topic: Integrating the Culture in the Project Equation
An offshore software development project, by nature requires different countries, i.e. different cultures to collaborate. This requires some setup to work smoothly. This is what we will be covering in our next article.
Liemur provides Software Development Services within UK and with its nearshore branch in Budapest.
If you like this article, what about tweeting it or recommending it?
Sylvain’s personal blog can be found here: blog.sylvainliege.com