In the first article, I broke communication down into its various forms. In the second, I came up with guidelines for stakeholders to communicate effectively with the production team. In this third and final installment in the Software Developer’s Guide to Project Communication series, I'd like to talk from personal experience about how developers manage their email in hopes that it will be useful to both developers and other project stakeholders. Everyone uses email for work, but it plays a different role in the workflow for each different role within a project.
The following tips specifically address the sending of email to developers and are offered with humility from the perspective of a developer trying to maximize the value that I can provide to my client. The goal of sending email is to ensure communication occurs without inadvertently distracting particular members of the team who may not need to be involved in a conversation.
For developers, properly managing a robust pipeline of incoming email will allow you to organize your time better, avoid missing important information, and minimize distractions.
Know When "Reply-All" Is Appropriate
As a developer, I see conversational emails between multiple people as distracting and unnecessary unless I am directly involved in the conversation. Even then, I’d rather have a short phone call or meeting to discuss the topic synchronously. This approach, however, is not effective for other areas of the project. For sales and marketing teams, for example, email is a key part of their workflow. Project managers, I’ve found, lie somewhere in the middle, but lean more toward the reply-all side of the argument. As discussed in the previous article, programmers need to avoid distractions to maintain high levels of focus and productivity. In short, reply-all is acceptable as long as the sender limits who “all” represents to only those who need to take part in the discussion.
Here's an example of an ineffective use of the reply-all or CC feature:
"I have a question about the project. I’ll send this email to all the people on the development team to increase my chances of getting a quick response."
In theory, the more people who see the message, the more likely the sender is to get a response, right? Not always. The bystander effect is just as prominent in email as it is on the streets of New York City. Having more recipients cc'ed increases the chance that everyone will think that someone else will respond, and no one will take responsibility. The hopeful exception is that the project manager will step in. When I've played the role of project manager, striking a good balance between protecting my developers’ time while keeping stakeholders informed is perhaps the most critical service I can provide.
Summarize Long Conversations
Most email services have a setting that, when replying to an email, will include the previous message. While great in concept, some email threads become like Russian nesting dolls, even with just a few people involved in the conversation. If you find yourself desperately sifting through the backscroll trying to piece together the conversation, chances are the information is better disseminated in the project documentation such as a Confluence decision document.
One nice feature that many email services now implement is that they can group messages together by common recipients and subject lines, creating a conversation view. Rather than sifting through the nested conversations attached to the latest message, you can simply look for the original message then follow the chain of emails.
Enable conversation mode and cut out nested reply chains to make email conversations easier to follow.
ProTip: Some email clients now come with a feature that, when replying to a message, replaces the threaded discussion with the selected contents of the previous email. For example, select just the main message of the email you are reading and click the reply button to replace the entire threaded discussion at the bottom with just the text you selected.
When you are adding someone new to the conversation, the courteous thing to do is summarize it for them. I find it disrespectful when I'm cc'ed into a lengthy discussion (or even a Slack conversation for that matter) with a simple, “What do you think?” that requires me to sift out the context from a long, tangled thread.
Close Your Email Client (If You Can)
Email is often the pipeline between project managers and stakeholders, so this tip is more angled toward the production team, but don’t shrug it off completely, stakeholders. Keep this in mind when sending broad emails.
The pervasiveness of notifications in email has made it an integral part of the workflow. The trick is to remember where it falls in the communication urgency hierarchy; it’s low. Your relationship with email should look like this:
- Open mail client.
- Read mail.
- Save actionable items to a to-do list.
- Close mail client.
This should occur one or two times during the workday at most, and it should never be the first or last thing you do. The critical concept here is that you own your time and your inbox does not.
Email is full of requests for your time, and it’s easy to get sucked in “to-do list” mode. The thing is, email is not your to-do list, it’s someone else’s. Open email on your terms. Consequently, checking email right before you sign off is like pushing code to production on a Friday afternoon. Hopefully, everything is OK, but there's a chance your impending free time is about to be hijacked.
Save as much email triaging for the early afternoon. Much of the research done on brain activity shows that our brains are better equipped to handle logic problems in the morning when we are fresh off a good night’s sleep, and more creative topics in the afternoon. Have you ever tried debugging around 2:30 p.m. when the afternoon slump hits? This is an ideal time for email triage. Don’t let email distract you in the morning. Save that brain power for the deep tasks and deal with email after lunch. If something is so critical that it can't wait until tomorrow, the team should know to get a hold of you through another communication mode.
"Email is full of requests for your time, and it’s easy to get trapped in “to-do list” mode. The thing is, email is not your to-do list, it’s someone else’s."
If you can't get away with a once-per-day email habit, try some of these tricks to make it manageable.
Turn Off Unnecessary Notifications
Remember that email is on the "when-I-get-to-it" level of communication urgency. Thus you don't need to be notified every time a new message hits your inbox. This applies to all applications. Turn off all interrupting notifications on all apps (email included) on your phone, tablet, and the computer that are not direct, active communications. Allow the little red bubble on the icon to be the messenger, though even this takes a great deal of willpower. I know some people who go so far as to turn those off as well. The point is, check them on your own time. I've turned off all non-essential notifications and it has significantly decreased distractions and granted me back control of my own time. Best of all, I don't feel like I'm missing anything.
Avoid the Inbox
Normally, email clients will only alert you when new mail shows up in your inbox folder. Treat your inbox like a high society party with velvet ropes and a big dude named Bubba at the door to keep the riffraff out. Only the most important people are allowed inside. That is to say, don't let your inbox become a dumping ground for every message with your name attached to it. Most email services provide filters so you can sort your incoming mail into folders, tags, or even right into the trash can, avoiding the inbox completely. Here's a system that's been working great for me.
First, cut the crap.
Spam filtering has come a long way and is generally handled well at the server level, so let's tackle the second most heinous form of email, junk mail. Implement a filter that looks for the required subscription jargon in mailing list emails, then send all that junk mail to its own folder. (Then unsubscribe to the ones you don't find yourself reading most of the time.)
Use clever keyword filters to move junk mail to its own folder.
Next, no more project notifications.
Finding the important messages in a sea of project notifications is like digging through the cracks of your sofa hoping to find some loose change. I have yet to discover a suitable alternative to the digital tsunami that is project notifications. I'd turn them off completely, but some of them do alert me to important tasks. The first thing I do is set up filters to move the notifications into their own folders. Depending on your level of organization, you can dump them all into one folder, or, if you're hyper-organized like me, you can separate them into different folders.
This moves a plethora of messages out of the inbox into sorted, actionable lists you can deal with on your own time. Remember, out of the inbox means fewer interrupting application notifications.
Get service-generated notifications out of your inbox and organized for review.
Finally, prune the project messages.
On any given day I may receive a few important work emails that are not client or project specific, but I will inevitably end up in either the CC list or as one of many recipients on a series of project-related messages. These types of emails have unique characteristics I can use to filter them into their own folder as well, bypassing the inbox.
I like this trick for a couple of reasons. First, all my project conversations are in one place and I can deal with them all together; and second, when the project is over, I can archive the folder and prevent my mail client from downloading it, freeing up space on my hard drive.
For example, if you follow an active repository on GitHub, you probably receive notifications when there are changes to that repository. For me, 90 percent of these do not require my direct attention. Conversely, if I should not let it pass me by, it should have my name @mentioned in it somewhere. Here's the trick, and it's one of my favorites. I actually have two Gmail filters setup for GitHub notifications. The first filter moves them all to their own folder, skipping the inbox. The second checks the email body for my @username. If it doesn't find it then it marks the message as read. Now, in my GitHub notifications folder, I can look for unread notifications first, act on those, then go back and peruse or purge the others.
Email Notification Alternatives
To truly be at peace with your email, don't let it own your time. Turn it off. There are alternative services that can inform you of important, time-sensitive notifications, which could allow you to skip the project notification emails altogether.
Slack 'Em
Many services offer Slack integrations now, so notifications will appear directly in your Slack channel. Posting notifications into your #general or #project channel where regular conversation happens can become overwhelming to the point of downright annoying as the number of team members and integrated services grows. It can be helpful to create a separate channel just for these notifications. If you can, try to use the same username between Slack and those services so if your name is mentioned in the notification, Slack will highlight it and notify you. If this isn't a possibility, Slack also allows you to add custom highlight words in your settings.
When integrating services with Slack, add variations of your username as notification keywords.
RSS Notification Feeds
My most recent attempt to get project notifications out of email is to use RSS feeds. Most services offer RSS feeds for basic activity, but I haven't found any that provide the level of specificity that would make it useful. In an experiment with Jira and GitHub notifications, the most detailed information I could get through RSS was an issue number, making it difficult to tell what was done and whether or not it deserved my attention.
In Conclusion
Lullabot boasts some top-notch technical project managers who keep the communication lines in check and work with the clients early in the process to set the guidelines and expectations. As a developer, this makes navigating those communication channels easier, but other factors contribute to communication overload. More people and services involved in a project means more meeting requests, emails, Slack pings, and service notifications. Gone unchecked, this can destroy productivity, or even cause important deadlines and deliverables to be missed.
Whichever hat I may be wearing, be it a developer’s or occasionally a project manager’s, these tips and methods have allowed me to control my schedule, focus on the important pieces of my projects, and keep a good balance between my team and the client.
Hopefully, you found some useful tips as well, but not everybody's recipe is the same. What works for you? I'd love to hear about your tips.