I spotted this interesting post by Dennis Stevenson titled "Why would you abandon e-mail for Streaming tools?", which was a reaction to an article by Stowe Boyd "The Business Case For Streams versus Email". Both are worth a read, and got me thinking about how we communicate and how our messages are received (or not received) by our team. The debate here is stream (public post on shared workspace, ie. twitter/yammer like communication) vs email.
It's funny because like what Stowe Boyd mentions in his piece, this is just the next debate over company communications. In the 70's and 80's there was the debate about email, and in the 90's web-based email. I'm sure there was once a big debate about how and when to best use the fax machine, and then it was the greatest thing ever, and these days I just wish I could burn the thing.
Dennis Stevenson compares email to a hammer:
"pounding everything as if it were a nail. It's a useful tool, but not suited to every situation. Flow or Streams are a different tool, say a pair of pliers. If you've never used a pair of pliers and always used a hammer, you may not have a particularly good understanding of all the things you can do with pliers. This may call for experimentation and some trial/error. That's ok."
I would think that those who prefer to stick to email would say that when you send an email you'll be assured that the recipient will see it and read it. You can select exactly who will receive it. This might not be the case when posting something to the stream.
But that's not necessarily true. That message might never get to where it needs to be because:
- The email could get blocked or stalled by the occasional full mailbox, spam rule, down server
- The recipient could have email rules setup to file away specific messages into folders, this sounds great and very organized but if the filing is happening before the email is being read than it's possible that email might get missed
- The recipient might accidentally delete the message while batch deleting the junk mail from the night before (hasn't everyone had one of those "Who just sent me an email? I just deleted by accident!" experiences, where you send a note out to everyone you can think of asking who just sent you an email?). This is less of a problem these days now that mail can more easily be retrieved from the trash, but it could still happen.
- The recipient might just choose not to read the email from you (in this case there are some other 'personnel' problems that should probably be tackled first).
So for any of these reasons the message is lost, deleted forever or buried in a pile of other messages, never to be read. When it’s something important it’s always good to follow up via some other form of communication (phone, instant message, tap on the shoulder, dart-gun, etc.) but it’s better when the message gets to where it needs to go in the first place. Even when it does get there, it’s not always ideal to have it sitting in one person’s inbox, more on this below.
When a message is posted to the ‘stream’ (via Twitter hashtag, Yammer, or Yammer-style communication tool embedded within the LiquidPlanner online project management system) there are ways to direct the message to a specific person or group of people, and it’s also just out there open for the public. Is the message sitting in someone’s inbox? Well, it can be if there are email alerts setup for messages and in some cases those hesitant to change can even use their email to participate in the discussion on the stream. Unless it’s strictly confidential information (and in this case even email might not be the best option) I think having the message on a shared system, in the stream, is much better solution long term. What it really takes is a cultural shift, having a team that treats the stream like they used to (hopefully) treat their email - keeping the application or browser window open, referring to the stream first when they are looking for something (rather than checking email, wiki, or other notes). Posting information on a shared system means that information will never get lost with one person, or in one person’s email folders. This will help with remote teams, or if someone is unavailable or leaves the organization. Posting to the stream means that critical details are always publicly accessible if an ass needs to be covered at some later point in the project. Although there is a problem that with some tools the messages might not be retrievable after a certain period of time (mentioned in the 2nd comment on the Boyd post). Because of this Twitter might not be the best tool for project communications.
One of the features I like best about the LiquidPlanner online project management tool is that the chatter can be easily organized by project task, sub-folder, or on the root of the project or client. There is no issue of older comments being deleted and the details specific to a task will always be stored where it can be easily found, with that task.
Communication is a critical element of project success, and as the team grows the number of possible communication channels multiplies ( N x ( N-1 ) / 2, where N is the number of stakeholders). I believe that using the stream is the easiest and most efficient way to cover all of those communication channels and ensure that the important details are available anytime and for anyone.
