This is the second in my series of blog posts about how we unknowingly often let our IT determine how we communicate, and what to do about it.Teams need to communicate at three different speeds: Tomes, Task Tracking and Information Ping-pong. When we don't have the right IT support to for all three, things go wrong.
In this post, I'll talk about team communication by Tomes.
Tomes are documents that answer "Who are we? What do we do? How did we get here? Why are we doing this?"
These are often important things to say, but they aren't particularly urgent. They might or might not be read by people inside the team. Quite often they are read by people outside of the team, but often weeks or months after they were written.
Examples include:
- Project decisions
- Strategic plans
- Frequently asked questions
- Status reports for long, ongoing projects
- Minutes of meetings
- Discussions about any of the above
These are often tedious to write, and the task is often given to the person with the most free time using whatever tools are at hand. Generally, this means either email or MS-Word documents. There are serious flaws with both of these. Writing emails just contributes to the email overload problem. Writing a Word document and putting into a fileshare (or on to Sharepoint) leads to more meetings because it won't get read. Emailing a Word document around (which is probably the most common approach) manages to be the worst of both worlds.
I've made an attempt at distilling the 5 requirements for a tool to support Tomes. If you can think of more, let me know.
NAME MENTIONING If someone is mentioned in a Tome they need to be notified automatically. This keeps everyone on the same page (virtually). A common miscommunication I've seen is where everyone was expecting a response or involvement from someone outside of the team -- but the individual was never aware that they were supposed to be doing anything. Automatic notification mitigates this.
TASK ASSIGNMENT AND DUE If a task is mentioned in a Tome, it should be easy to assign it to someone and to give it a due-by date. The task should automatically appear on that person's to-do list. Otherwise, it is too easy for the task to get lost.
LIVE TASK STATUS When someone marks off a task as completed from their to-do list, this should be reflected automatically in the Tome. If a task has a lifecycle (e.g. it has to be reviewed by another team before it can be marked off as "Done"), then the live status of the task should appear.
This saves time in meetings working out whether something has been done or not. One of the most frustrating meetings I can remember (and I've had a few) is was a pointless nothing-to-report meeting: everyone admitted in the meeting that they hadn't had time to do anything and that there was nothing to report. This could have been trivially seen by the project manager who convened the meeting if he had been able to see the lack of progress on the task list of the minutes of the previous meeting.
IN-PAGE COMMENTS Comments about the Tome should appear with the tome. It should be easy to discuss and have a conversation about any part of the Tome.
CHANGE TRACKING AND WATCHING It should be easy to change the Tome. If it is changed, then it should be easy to see what changed even though the Tome displays the latest version by default. It should be possible to register an interest in changes to the Tome and get notified when this happens.
These seem obvious, and seems like a reasonably complete list.
- Email can do #1 (you can CC someone outside your team). If you are using Outlook you can drag the email into your todo list (and Gmail can do something roughly equivalent), so that satisfies #2. But #3 and #5 are impossible, and #4 by email is a recipe for giving everyone a full inbox that just gets dumped.
- Word documents in a portal or fileshare do #1 very poorly; #2 is even worse. #3 is impossible, but does OK on #4 or #5.
- Slightly more innovative companies will use Google Docs. The collaborators list can act as #1, and it does as well on #4 and #5 as a Word document does. #2 and #3 are sort-of possible if the tasks are put into a Google Sheets document instead, but it is rather fragile, complex to set up and means that there are multiple documents for the one event or topic.
- Startups often use Confluence. It nails all 5 requirements very well.
So what usually happens?
In large, traditional organisations, I see teams with Word documents being emailed around by a project manager, a deluge of emails (CC'ed to everyone the project manager sent the project tracking document to) and then meetings at least once a week so that everyone can work out whether or not they were supposed to have done something, and why that probably wasn't a high priority anyway.
Smaller organisations manage better, although the ones that try to do this with Google Docs tend to be very chaotic, and have someone always complaining about how they really haven't got their procedures and processes sorted out yet.
We think this mess is normal, but it's just driven by the software we use to intermediate our communications.
The next post in the series will hopefully be next Tuesday.
I'm hoping to put this (and many other thoughts) together in a book (current working title: "Bimodal, Trimodal, Devops and Tossing it over the Fence: a better practices guide to supporting software") -- sign up for updates about the book here: http://eepurl.com/bMYBC5
If you like this series -- and care about making organisations run better with better tools -- you'll probably find my automated estimator of effort and duration very interesting.
Greg Baker (gregb@ifost.org.au) is a consultant, author, developer and start-up advisor. His recent projects include a plug-in for Jira Service Desk which lets helpdesk staff tell their users how long a task will take and a wet-weather information system for school sports.
