When good communication becomes too much communication

Standard

Lost time

In software engineering communication plays a very big role. It could even be argued that software work is more about communication than it is about programming or design. The biggest reasons for software project failures lie in the communication between the team members than in any technical aspects.

Usually when talking about communication problems people tend to think about not having enough communication. Most of us would say that it’s bad if people don’t talk to each other, and suggest that the more we talk the better we work. But it’s not that straightforward. People can go overboard with communication, talking so much that their days are spent writing, reading and waiting for e-mail, talking on the phone, talking in person and so on. And in the end no productive work is done. When there is more talking than doing, it’s time to change something.

  1. Trust your co-workers: Your team mates are professionals, so you don’t need to make every decision together with them. You don’t even need to know about every decision they are making, and you definitely don’t need to know the rationale behind their every decision. If their code works, trust that it’s good and do your part.
  2. Trust yourself and be brave: Another common reason for too much communication is the fact that we are looking for others to back us up. But remember: You were chosen to your position because of your skills. You’re a professional, and your employer trusts you to know how to do your work. So should you. Just make sure you know what is expected from you and then just do your work.
  3. Ask and guess: In some cases you have to ask, but it takes time to get the answer. This happens to me a lot because many of my team mates are living on a different time zone (we have a 10 hour difference), so I don’t get an answer to my questions until the next morning. If I just sit and wait for the answer, I spend many days in some unproductive work. If you’re in a similar situation, I suggest that you send the question, then take a guess and continue based on your intuition. In most cases you guess right and receive a confirmation on the next day.
  4. Do unit tests: Documentation helps a lot, but documentation takes time to maintain. Test driven development provides a different tool to do testing and documentation at once: Write good unit tests that test every piece of functionality you’re writing, and suddenly you have documented your code. Unit tests also back up your guesses: when you try to work based on your hunch, the unit tests will tell you when you’re going wrong.
  5. Kill meetings: This is a common advice on the Internet, but sadly most companies still don’t get it. In a meeting in most of the cases at least half of the people present aren’t really needed for more than 10% of the duration of the meeting. So, if instead of calling the people in a meeting you talk to them individually, you’ll end up saving many people’s time, including yours.
  6. Prioritize: Only ask the important questions, because if you don’t you’ll be not only spending a lot of your own time writing e-mail, making phone calls or chatting with your coworkers, but also spending their time. Also, often people might answer to your easy questions first, so by prioritizing your questions you’ll make sure you get an answer to your most important question and not some less important ones.

Remember that time is the most valuable asset you have. If you want to finish your projects on time you don’t want to go spending your time on unnecessary discussion. So, optimize your communication, trust yourself and your team mates and be brave. Guessing isn’t always as bad as it might sound.