For some time now I’ve been thinking about communication tools used by small teams. In part that is because I work in a small team. There are 7 of us now in the OSS Watch team, though that is slightly misleading since only two of us work for OSS Watch full-time. Everyone else is either half-time or less. Moreover, no two of us share an office. And those conditions
- distributed participation
- partial participation
are typical of most open source projects. So the nut I’m trying to crack is one that lots of others have been busy cracking for some time.
Here are a few of the things I have learned so far about communication in a small team.
There is nothing new under the sun.
You may think you need to re-invent the wheel, but in fact the best solution to your communications challenge is probably being used by someone in the next room (or the next project). Go ask them what they use and try that first.
Everything is new to you at least once.
You may not need to re-invent the wheel in order to ride a bicycle, but you are still likely to fall off a few times. Don’t pretend there is some magic short-cut to successful communications. New tools take time to get used to. And each new member of your team will have to go through the same (difficult?) learning process.
Talking with people is hard; talking to people is easy.
Communication is about talking with one another, that is talking and listening. The tools you use will not compensate for your limitations as a communicator. So you are going to need practice. Lots of practice. But you may not have a water cooler at which to go stand around and practice. So you need to think of other mechanisms.
I don’t think I can adequately emphasize just how important this is.
In a fully distributed team (where you really don’t have the chance to meet face to face on a regular basis) there need to be multiple channels and levels of communication. It doesn’t matter whether you push this off to an irc channel (though that too could be your principal communication tool). What matters is that there are opportunities for members of the team to put some flesh on their digital bones.
Time is elastic, it snaps back when you stretch it.
Since you can’t expect the undivided attention of your partial participants at all times, you need to structure communications in such a way that they can participate fully as and when their time permits. What does this mean in practice? Don’t treat email as though it is a synchronous communications tool, even if it effectively is for you. Let other people get involved in a discussion rather than dominating it simply because you are always on.
Keep it fun.
Life isn’t just a grind. So why make it one?
Keep trying new things.
There are always new tools to play with, new ways of organizing meetings, new opportunities to facilitate communication.
Here are the tools that my team uses at the moment. They may have changed even by the time you read this because I’m always looking for that next opportunity.
- team emails
lots of emails that go to and from the whole team – and when I write lots I mean lots
(okay, I confess, I’m a bit of a dinosaur and this is my preferred route to team communication) - email list
dedicated mailing list for specific topics; be aware that some members of your team may not distinguish the specialized team mailing list from their ordinary team emails (yes, that’s me still on the upward slope of the learning curve) - irc channel
some people just love to use irc; great, so now we take advantage of that with a dedicated #oss-watch channel at irc.freenode.net; this serves at least two purposes (as everything should) – it provides an outlet for team chatter that only hits those members of the team that are actually working on OSS Watch stuff at the time, but it is also publicly available thus providing a further interface to the team for our stakeholder community (or at least the ones who like using irc) - team blog
recently we started a team blog to let us explore issues with each other (as well as the wider world) in public; it was time, I think, to let others see that we don’t always agree even amongst ourselves – but we do value the way in which we negotiate across those disagreements toward some common understanding - internal team wiki
a safe place for our initial thoughts, debates (yes, we usually thrash an issue from all sides), explanations of how to do things – very useful for new members of the team (or old ones with faulty memories), team meeting minutes and curiosities - team meetings
not everything needs to or should be done digitally, if you can mange it; our team meets once a week for an hour; since we use so many other communications tools, these meetings serve a different function – they remind us that this team is made up of real people - monthly team day
I won’t embarrass anyone by telling you what we actually call these, but they are not meetings as such, rather they are days when we pool our collective time in order to work together on something such as reviewing our published documents, exploring a new open source development tool, arguing the pros and cons of some topical issue, etc.; each one is different and yes, food is involved
I haven’t learned all there is to know about communication in a small team. But I am trying.