Recently I've given an internal presentation about so-called over-communication.
What's that? It's a methodology (spirit, philosophy, doctrine...) that tries to help you with one of the ancient problems in IT - lack of communication. (Hold on, is it a problem, really? - you may think right now. The answer is - I don't know. From what I observed, it depends on multiple factors: team, project, methodology. But my personal experience is that there is always too little communication. Some people in RST-IT agreed on this statement, some strongly disagreed. I ain't even mad, I'm just jealous.
To recognize if it's a problem in your situation, just answer the following question. How often you don't know things that you should know? For instance, when it comes to the backlog, how often you don't know:
- what task to do?
- how urgent is the task?
- if the task is good to go, no blockers etc.,
- if you understand the task correctly,
- how to do the task?
- if everyone is aware of the potential technical debt,
- if it's clear for the whole team how you do it,
- who can help you with your task; who knows the technology and is available,
- if nobody disagrees on your solution,
- if your solution isn't dangerous,
- if you have all needed accesses to external services,
I'm not claiming that each of those should be explicitly stated for every single task. I just believe that there are situations when you don't know some of those, but you should.
- You start coding the frontend, suddenly it turns out that API is not implemented yet. Folks will deliver it in 2 days. You pick another task, switch context, waste time.
- You finish the 4-hours task and proudly share the news with your teammates on daily standup next morning. Sadly, it turns out that this could have been done with a one-liner in Python. And there's a gem for that, how could you not know that?!
- You complain in the kitchen that the-new-JS-framework is horrible, why it takes 3 days to even Hello World?! Thank God the person from another room heard your calling. He's an expert willing to help.
- You delivered the working API endpoint. Well, except the ID here should have been the UserId, not OrderId. We didn't tell you, sorry. Could you, like, fix it within 3 minutes, please?
- You take the next task from the backlog. It took you the whole day, yet yeah, you did it! But you know, someone forgot to mention that this one goes for the next iteration. Bugs are more important. Revert please, client hasn't paid for that yet.
Sounds familiar? If not, how about things not strictly related to the development process, but would be also nice to know:
- Your teammates' days off and remote hours
- Company standards - do they exist? Where can you find them? How often are they changed? Can you disagree with them? How?
- Can I have more monitors?
- Is the client happy about us?
- Who's this new guy in the office?
- Are we ran out of coffee? (seriously, I can live without knowing all of the above, but this one should be like a huge neon sign above my desk :))
If you can't relate - lucky you. But I still think many people (including myself) would like to know more. Not to mention that everyone is different, so I just can't imagine what other people lack the most.
Software development is a social routine. You not only code, but also document the code, write tests even if something works ;), share the knowledge - because other people are or will be involved.
Here comes the over-communication
What's that exactly? Well, it's kind of self-explanatory. It's encouraging people to communicate more. But not only that - it also provides some guides on how to do this in an efficient and convenient way.
push > pull
What I mean here is that you should try to answer questions before they are asked. Instead of relying on "pulling" information from others, others should "push" potentially important messages. Which may seem unnatural and spam-prone at first glance, but here are some tips and tricks on how to work around this:
- granularity of messaging channels should be relatively big (eg. many Slack channels),
- everyone can decide which channels to "subscribe",
- people should increase their personal tolerance for "spam". If this doesn't help, they can always leave or mute the channel, or temporarily just close the annoying app and focus.
Pushing information also means that some of it will be just of no use to anyone. That's OK, I think it's worth it.
write > talk
Writing is just more effective and reliable, for a few reasons:
- Pro-async - easier to reach currently AFK people
- Pro-broadcast - easier to reach more people at a time
- Pro-introvert - less pressure for immediate answer
- Less ephemeral - you can refer to a message later
repeating is OK
Repetition may involve:
More communication channels
Here in RST-IT we use:
- Google Calendar
- Google Docs
We also have Retro, regular fortnightly meetings. Finally, everyone is reachable in person in the office or has a phone, so there's a lot of potential ways to communicate something.
People often use only one "channel" to communicate a message. In the spirit of over-communicating however, it's completely OK to use more than one channel, eg:
- You send a very important email AND after that, you ping the recipient on HipChat (Hey, just sent you an email, take a look in your spare time, this is important)
- You push the commit to the Bitbucket, but you know it's a blocker. You suspect other people would want to know ASAP that it's done, so you send a quick message on the project's channel.
- You create an event in the calendar and share it with someone. It's related to a topic that you discussed 2 weeks ago. They may not remember or be confused about it. You'd better tell them via private message what's the meeting about.
- You created a document regarding company's recommendations for using Docker. That's fine, everyone can find it in a shared folder if they ever wanted to. But almost effortlessly you broadcast a message in a Developers channel, explaining in 2 phrases what's the document about and that this is a draft, so everyone's free to suggest changes.
Generally, it all may lead to a situation when HipChat is a central place where you can learn everything about everyone, while other tools are used less often. And that's OK, as long as people can join and leave the channels freely.
People forget things, so it's OK to remind them more than once. Especially when the deadline is soon. Simple as that.
Pro tip: don't use private messages. Unless it's truly private. Usually, it isn'tю For example, if it's about a project you're working on - why not send the same message, but to everyone involved?
Keep in mind that other people work in their own loops and can have different levels of understanding when it comes to what you're going to write about. You should always try to provide more than just a few words, just to make communication more convenient, also for quick updates.
Feel free to provide TL;DR for your materials, opinion, text formatting (
code, bold for vital parts). A link is always useful, you probably already have it in your browser, and your recipients may need much more time to find it.
Not only people could send messages, leverage integration. Messages from bots may be very useful, for example on project channel after each commit.
Over-communication means pushing a lot of written messages. That's the general rule, the signpost. The implementation depends on your personal situation, again - team, project, methodology, tools...
What to communicate about?
The most honest answer is: I don't know. Well, that's the essence of over-communication: you rarely know who and what about to ask, so please, everyone, tell me everything important. OK, not everything (I would say it's impossible rather than not useful), but usually more is better. The more extreme situation, the more attention you should pay to make sure everyone knows.
If you want some examples anyway, here are some messages that I recently missed and would find useful:
- (after you read a message sent to you) OK.
- (after someone asked you to do something) I'm taking it right away / I will do this later.
- I'm off tomorrow.
- This is important / it's a blocker.
- I'm available, willing to help someone.
- I have troubles with the-new-JS-Framework.
- We just finished the meeting. We decided to implement something-new. More information on Retro.
- Found a link about something-interesting
- Since Monday, someone is going to work in our office, only for a week. Don't touch his things.
- I found a bug, added an issue to Jira.
- I found a typo in our blog post, can someone fix it?.
Please keep in mind that I don't claim that over-communication is a silver bullet. It fits my personal preferences, I don't like not knowing things, although I'm probably not the best over-communicator. It may answer problems that you don't even have. But if you do, why not give it a go?