The Art of Communicating Well in Software Engineering: How to Remove Friction, Confusion, and Complexity

When we think about good communication, we often jump to the same two points; How clearly am I speaking? And, How clearly am I writing? But communication is about far more than just those two aspects. Although important, they fail to address some more critical aspects of effective communication. So what does good communication mean?

Good communication is made up of multiple concepts and parts. It is about;

• Removing friction to understanding
• Removing confusion
• Simplifying complicated topics for easy digestion
• Being proactive in communication
• Using the correct means of communication
• Listening/reading
• Speaking and writing clearly

In software engineering, there can be a lot of moving parts and often times team members are located in different parts of the country if not the world. It's therefore important to have systems and tools in place that facilitate good communication between team members, and this goes beyond email and chat facilities like Slack or Teams.

Good communication is something that needs to be embodied into your company culture, and the earlier you set this standard of behaviour the better. The good news though, is that, unlike some things, this can be remedied.

There are a few key things you can do to improve communication within your team:

1. Encourage and practice active listening (and reading) - this means really hearing and understanding what the other person is saying. It requires being present and not letting your mind wander. This is probably one of the biggest things in good communication, you'd be amazed to see the improvements made when people start actively listening. It's undoubtedly one of the hardest ones to master as well.
2. Make sure everyone is on the same page - this covers the removing confusion part. Regardless of whether the communication was verbal, written, or other. When the discussion approaches what appears to be a conclusion, take that appearance with caution and review the discussion, key points and any outcomes. There is nothing worse than 3 people taking away from a discussion 3 different visions whilst believing they're all in agreement.
3. Address the right audience in the right way - I'm sure it has happened to you; you have been in a meeting where someone has spent half of it explaining something that only needed 5 minutes. And the opposite, where someone has glanced over a topic in 5 minutes and assumed you know all the details. Both leave you feeling confused or annoyed. And both cause you to lose attention and stop actively listening. So before you dive into the technical details of a project or choose to glance over deep implementation details, assess your target audience and ask yourself this question; What is the least information needed to convey the point and achieve shared understanding?
4. Use the right tool for the job - We have probably all said, "that meeting could have been an email". It's true; if you want to ensure that your communication is well received and understood, consider the medium in which it is delivered. How urgent is this? If it's very urgent, it should probably be a video/voice call, and if it's not urgent, it might be better as an email, a document, or a message in Slack/Teams. How detailed/complex is it? If it's very detailed/complex, maybe it should be a document first; give people a few days to read it, then follow up with a meeting or a channel/thread in Slack/Teams. How transient is this information? If this information is not going to change, a document would probably be best. Still, a voice/video recording could be a great adjoining way to communicate to allow for other learning styles. People often default to the meeting without considering its actual value. Before you arrange that meeting, send that email, or blast that group chat, think about what it is you're trying to achieve, and pick the solution, or solutions, that are going to support your aims whilst respecting your colleagues' time.

You can also foster and improve the communication culture in your software engineering org by utilising other more engineering-specific concepts. For example, Extreme Programming principles like Pair and Mob programming can take your team communication from "Okay" to "Outstanding". You can read more about that in my article, "Using extreme programming to build a strong, scalable team culture".

cccccbctejteSo there you have it, a quick and dirty guide to improving the Art of communicating well in Software Engineering.