Engineering Team Communication: Using Mailing Lists Effectively

Most teams in business today rely on email.  Though imperfect it is ubiquitous for electronic communication.  It has proven the lowest-common denominator for communication between team members.

The question of how to organize email is often left to each team member.  I think this approach is lacking – it leaves folks with good organization skills at an advantage to keeping up with information.  As a team we should all be committed to keeping everyone in the loop.  A little effort up front can pay big dividends in team productivity.

Mailing lists allow team members to easily filter email and keep track of emails as appropriate to their role on the team.  In larger teams they also allow for managers in the team to manage the email lists appropriate for their team members.

From my experience (which is assisted by my last team at Microsoft – the former Max team) the following list of mailing lists should be created for a product team.  Assume each one is started with a short description of the product/team (for example: gizmo-dev is the developer mailing list).

-dev: developer mailing list.  Only developers on this list.
-test: test mailing list.  Only testers on this list.
-bus: business analyst, program manager mailing list.
-team (aggregate of -dev, -test, -bus): entire team, sometimes includes upper management
-commit (aggregates team): all checkin emails related to software development
-deploy (aggregate of team): deployment announcements for software deployments
-chat (aggregate of team): non-work related chatter – like new joke site, xkcd comic, etc
-oof (aggregate of team): out of facility announcements – like at the dentist for the next two hours, out for a week next week etc

First off, notice how more than half of the lists above just have the -team mailing list as its member.  This means you don’t have to manage all the lists individually, just the -dev, -test, and -bus ones.

Folks uninterested in the checkin emails can simply filter those out quickly into a folder that is kept unread, or archived.

The -oof list always is a controversial one.  There isn’t a good solution for knowing folks absences.  Blocking out your own calendar has the problem that people won’t notice unless they are scheduling something and you aren’t there.  The problem with sending invitations for your absence to the team is that most of the time the team doesn’t care and you are just adding more work for them to manage their calendars to make the time look “free” for them.  An Out-Of-Facility list is the simplest solution.  Email it when you will be away from work and then folks you are trying to find you will either know about it ahead of time or can check that list for up to the minute info.  And it has archival, filtering etc functionality.

If you work in a small team that has folks wearing multiple hats, no big deal, just add them to multiple lists.  The lists also serve a critical function of providing archival support in case someone leaves or is out for an extended period of time.  These lists also allow external teams to listen into conversations without having to know team members directly.

Image via CrunchBase

For direct communication each team should have an instant messaging solution as well.  If you are using a free service just make sure to check the Terms of Service – you don’t want to be spreading corporate secrets on the publicly searchable archives of a Google Talk conversation, for example.  I recommend setting up a Jabber server in the intranet of the organization and using it for communication.  Most likely it can integrate with the email server and prevent duplicate user generation.  In the end instant communication is great for real-time conversations without talking, but poor for documentation or business communication.  For that type of communication email is still the best option.

How does your team organize its communication?  Does it employ mailing lists?  What other tools help?  Let me know below or shoot me an email.