A Software Developer’s Guide to Project Communication: Part 1

The key to a successful project is good communication.  Honesty and directness about timelines and scopes of work go a long way to relieve pressure from the development team and avoid frustration from stakeholders, but what about the day-to-day information exchanged between developers, designers, and project managers? This is the grease that keeps the project running smoothly and should not be overlooked.

As teams vary in size, so do the roles and responsibilities of individual team members.  Smaller teams have fewer communication channels, so you may need to switch between your developer hat and project manager hat frequently.  On larger teams your hat rack may be quite sparse, but the number of communication channels, and thus the possibility of miscommunication, is far greater.

Regardless of the size of your team, information about the project must be communicated and documented effectively.  From very large teams to projects where it's just me, I've learned how damaging even minor miscommunication can be.  Conversely, you look like a hero when you get it right.  Stakeholders, project managers, and developers work in very different realms. In this article I'll discuss a few overarching principles that I've learned to help navigate the monsoon of information blustering through a project.  They will help you regain control of your time and create a more productive and successful project.

What is Communication?

Existentialism aside, what do we really mean when we talk about communication?  Communication is an exchange of information between parties.  The parties may be people, but they may also be project management tools.  From video conferences to GitHub notifications, these are all part of the project communication landscape and require different levels of attention.

Forms of Communication

Here are some of the most common methods of communication I've dealt with on projects:

• In-Person Meetings
• Voice conference
• Video conference
• Chat
• Text message
• Direct Email
• Email Notifications
• Project Management Tools
• RSS Feeds
• Twitter
• Mobile Notifications

All these types of communication serve a unique role. We wouldn't use them if they weren't helpful, but the question we really should be asking is, "are they necessary?"  Gone unchecked, many of these tools can overrun each other and tangle the workflow.

For example, Slack is a great tool for team members to quickly exchange information between each other, but numerous tools can also post updates into Slack.  A few may be helpful, but too many can dilute the conversation and the effectiveness of the tool.  So how do you find the balance between effective and over-communication?  We can start by categorizing these forms of communication into two groups: active and passive.

Active vs Passive Communication

I find it helpful to group all communication into two categories: active and passive.

Active communication is a two way street.  The sender is expecting a direct response.  Google hangouts, Slack discussions, and phone calls are all forms of active communication.  There is an immediate reciprocation between the parties involved.  You wouldn't invite someone to a conversation just to read them the backlog of tickets, would you?

Passive communication, on the other hand, does not require a direct reply.  This is not as easily definable as active communication.  Let's take a look at email as an example.

If Stakeholder Sarah emails you a question about the next deadline, that is active communication.  She is expecting a response from you in a timely manner.  When a Github notification shows up in your inbox informing you that your pull request has been merged, no follow up is required.  This is passive.  Now, if you receive an email from Jira Notifications because the client asked a question on one of your tickets, which category does that fall under?  It's a notification email, so you shouldn't respond to it directly, but the client is expecting an answer.  Ultimately it depends on the ground rules for communication you set for your project.

Setting Expectations

I tend to follow this order of urgency for response, from most urgent to least.  It's important to agree on a set of communication guidelines at the beginning of a project so everyone on the team follows the same expectations.

1. Live Communication
   
   If you ask me a question face-to-face, of course I will respond to you right away.
2. Chat
   
   Chances are that unless I've set my away message, I'm receiving chat messages in real time.  However, I might be neck-deep in some code or preoccupied in another conversation, so I will respond as soon as I can, but maybe not be right away. 
3. Mentions in Comments
   
   Comments in Jira tickets or GitHub pull requests will likely go unread even if they show up in my inbox unless I am specifically mentioned in them.  I get a lot.  The convention to use the @ symbol to mention another person links their account in the ticket and generates more specific notifications for that person.  It the difference between saying something needs to be done and asking someone to do something about it.
4. Email
   
   I use a couple of email addresses to keep my interests separate so I use an email client to aggregate them into one management space.  However, I find constant email notifications and alerts distracting, so I don't keep my email client open when I don't need to (more on this later).  If you email me, I will probably get back to you within the day, but don't rely on me standing by my inbox waiting to reply to you.  This rule is so important to us that we actually wrote it into the Lullabot Employee Handbook along with a few other tips.
5. Unmentioned Comments
   
   I will likely still get email notifications about activity on repositories, projects or tickets I'm watching or otherwise related to, but if you don't mention me in the comment, it will disappear into tornado of notifications and chances are I won't see it unless I'm reading the backscroll on the ticket.

These are just my rules, but they have worked well for me so far.

Understanding the communication landscape of your project is a necessary foundation.  Setting the proper expectations will prevent miscommunication and keep the project running smoothly.  So far we've identified some of the most common pitfalls and laid the groundwork for a fluid project.  In the next two articles of the series I'll provide advice for managers and stakeholders on how to communicate effectively with the development team and also offer some recommendations and tricks for handling the number one offender when it comes to communication overload: email.