Communication and Your Team

I talk about in my earlier onboarding post, that you need to let new hires in on all the methods of communication your team users: IM, shared drives or web sites, email aliases, meetings, etc.

See, teams are comprised of humans; humans do not respond consistently from human to human. Their backgrounds, the immediacy of a potentially bad roast beef sandwich, a stronger proclivity to visual learning...all kinds of stuff affect an individual human and their ability to be consistent in behavior with other humans. Some employees complain that they aren't even technically human until they've had their first cup of coffee in the day.

Somehow, the groupings of humans that comprise your team need to form some consistency in terms of communication that span all the differences and either mitigate those differences or utilize them. For example, for folks not actually fit for human consumption until after their first cup of coffee, either scheduling group meetings later in the morning, providing coffee at early meetings, or checking in with said non-human and putting a cuppa Joe in their hands (or delegate and have some other helpful soul work with you on this).

But aside from personal preference and humor in general, people on the team need to talk to each other and to you. They need to know what options are available besides shouting "Hey You" or dropping by your cube. They need to know whom they can talk to, for example, if their issue is with you personally, or if they need privacy to discuss and issue, or if it's just a matter of trying to find someone on the team who happens to know about the sepcifics of a certain kind of source control.

Often, a team is formed in one of two ways: 1) someone gets nominated to be a manager for a team already in existence or one that has members that are already chosen and may be adding more or 2) from scratch--no members but the manager have been hired and the manager has to fill out the team.

If you're starting from scratch, you can start with just making up the communication. Once you start getting more than two people on a team, however, you need to take into account preferred methods of working and communication as well as the good of the whole team, and derive ways to communicate and keep track of communications. This can be complicated, further, if your team is not co-located. In this case just yelling to someone else is really not an option (though you can certainly try it until other people in the office complain).

This means that, starting from scratch or inheriting a team or partial team, you'll probably do similar steps. These are my suggestions:

1) You must have an immediate method of communication
2) You must have a method of tracking/storing decisions and artifacts
3) 1&2, while possibly not the most favorite methods ever engaged by your entire team, should be accepted and agreed upon by the team (or they won't use them)
4) In addition to ways to communicate and store communication, you need group-agreed upon norms about communication...things like "not talking over each other" or "how to settle a dispute."

How you achieve this list is best determined by talking to your team. Most people, for example, are fine with email for instant communication, but some prefer instant messaging or walking over to other people/picking up the phone. You don't have to have one exclusive method for (1) above, but you should have only one for method for (2). This means that, whatever you and the team decide upon for instant communication, there's also a method for storing that communication and being able to search it and utilize it later.

I'm relatively loose about (2)--if there was a perfect storage and recovery system for team communications and artifacts, I'd be using it. Or have invented it and be on that tropical island I like to talk about. It depends on your team and people outside your team, as well; if you want to use, for example Sharepoint to store this information, and your company doesn't have it, that has to be worked out. If you want to use an internal share, and you're working with large files, you're not just affecting your own team.

As for (3) getting agreement from the team doesn't just mean having a meeting, telling them, and then asking if there are any questions or objections. If you have a vocal person, you might get an objection; otherwise, if they don't like it, they just won't use it. You need to talk to them about what they've used before at other places, what works for them, etc. For example, some software will allow you to check in documents and artifacts by emailing an alias; this might be a bit easier for some than copying and pasting to a shared drive.

Finally, developing norms (4)--I've talked a lot about it in earlier posts, so I'll hit the highlights here: if it's not normal to write down decisions, they won't get recorded. If it's normal to talk over each other so that not everyone is heard, you'll lose valuable experience you specifically hired for, and you'll get frustrated people who are less productive. You need the team to act as a team--not a group of people to whom you give orders--and they will create and police these norms themselves.