How to communicate efficiently as software engineers

Reading Time: 5 minutes

Conversation is the basis of collaboration. And yet, communication for software engineers is often such an overlooked soft skill. As software engineers we understand that different programming languages serve different purposes to describe to machines what we want to build. At the same time, different audiences and contexts call for different natural language subsets.

I have observed many times inefficient communication happen between the people building the software and the ones consuming it in some form or another.

Most of the times the source of the inefficiency comes from the inability to understand what each other are looking for: for example engineers explaining the technical challenges they are facing while a customer service representative might only looking for a delivery date.

Different audiences call for different languages

When talking to other people we most likely use a specific subset of our dictionary to explain our thoughts, to make our message clear and to maximise the chances that our interlocutor understands what we are saying.

The dictionary we use when we speak to our fellow engineers is quite specific and optimised to get technical concepts over. There is probably a huge amount of technical details that we give for granted and that come from, to name a few, the inherent technical expertise we believe our colleagues have, the specific technical context we are building within, recent conversations, the agreed technological direction of our organization and so on.

From time to time, though, we are required to interact with stakeholders from different departments or external to the company altogether. In this case the conversation will need to move to a non-technical level.

Does my audience even care?

Building software products that are actually useful requires software engineers to spend time with collaborators, users and colleagues, share perspectives and exchange feedback.

Collaboration happening with different functions will require different problems to be discussed. To each its own preferred language.

A product manager will be interested in your complexity assessment, but will not care about what Node module you are going to end up depending on to deliver the functionality.

Getting deep into the details of the implementation you already have in mind will also bring the conversation down to a level that is not helpful yet and with this audience. I have discussed this issue in the past when I talked about the business outcome language.

Similarly, if you are explaining to a customer service representative why the software is behaving the way it is, going into the details of your current architecture will hardly help.

As technologists we often miss the opportunity to communicate efficiently because we tend to pollute the conversation with unhelpful technical details. It is most likely due to our forma mentis and the fact that we spend the majority of our time at the technical level.

If we are explaining why we’re not hitting the originally forecasted date to a team of sales reps, what’s the point in telling them that you need to migrate your current webpack version to the latest one but breaking changes are slowing you down? This level of detail is not helpful nor actionable for them. What is the new delivery date you have confidence in? This is all it matters in this conversation.

When what you’re saying does not make sense to your audience you are contributing to making the communication inefficient. I’ve seen unnecessary technical details pollute the conversation, making it even harder for messages to get across. At times, an answer filled with irrelevant technical details results in the interlocutor shutting down completely, unsatisfied with the answer, and unwilling to ask again.

But how can you make the communication more efficient?

Know who you are communicating with

In my opinion, the first step towards efficient communication is having clear who your audience is. What is their day job, what do they care about? How does what you do impact them? What are they currently struggling with and how is your work going to make their life easier? What can they do about what you are saying?

If you keep these questions in mind when interacting with the your audience it’s going to be easier to refrain from including details or digress into irrelevant explanations.

I know I framed this issue as a dichotomy between technical and non-technical audiences so far, but clear communication might also be lacking within the same department.

Bonus: you might think you know your audience

Even your CTO might be interested in a level of detail that is different from what you normally share with the rest of your team.

Say you are having troubles upgrading to a newer version of a library because it’s introducing backwards incompatible changes. You might feel it would be easy to get down to the technical level to explain why your team is late (again?). After all you are talking to a C T O. They must get it.

I’m sure they do get it but that’s not what they are interested in. If your team is facing unforeseen challenges all is interesting to them is what your team is going to do to overcome them. Have you worked on an alternative plan? Do you have confidence on a different date you are going to be able to deliver the change?

Take the time to prepare for an efficient conversation

Communicating outside the comfort zone of the technical level might require a bit of preparation.

Take the time to prepare. If there is a meeting coming up where you are going to share about the progress of your team focus on what outcome the people in the meeting are going to look for.

Try to understand if you will have an answer for them. Sometimes we default to a technical explanation when we haven’t prepared a more useful and focused answer.

Reflecting on this ahead of the meeting also gives you a better chance to find the answer. As a leader, do not feel you must know the answer. Your job is actually to lead your team to find the answer rather than finding one on your own.

Practice makes perfect. Take the time to think about who your audience is and start practising what you are going to say. Reflect as to whether what you are saying is valuable for your audience or not and if not try again. Try to focus on the details that matter to your audience.

Focus on what’s actionable

Another important aspect for efficient cross-functional communication, in my experience, is how actionable what you are saying is.

For example, it’s not unusual for software teams to have to communicate a date is slipping (I won’t get into the debate on deadlines here, but if you are interested I got into it in this other post): how are you communicating this?

My recommendation is to focus on what’s actionable: are you communicating this to the customer success department? Well, then maybe they don’t care as to why the date is slipping but rather on how they are going to manage this communication with the customer. Therefore, focus on giving a new time frame your team has confidence in.

Focusing on what’s actionable is also a good forcing function to come prepared to the conversation. Don’t just communicate you are late, make the effort to adjust the original estimation and give more actionable information to your audience.

Reflect on how you communicate: are you conveying the information that the audience is looking for? Are you making it easy for them to extract the important bits or are you including distracting details?

Closing thoughts

Communication is an often overlooked aspect of the work of software engineers but, in my opinion, it’s the most important one to achieve efficient and high performing organisations. As individuals, working on perfecting our communication skills is a great investment to maximise the effectiveness of the teams we are part of.

Efficient communication enables teams to iterate more quickly, raise issues soon and course-correct fast because information flows swiftly if the people are deliberately taking care of the right level of detail in the conversation.

Take time to invest in this skill by preparing the conversation ahead, be mindful of your audience and deliberate about the information you are going to share.

The post How to communicate efficiently as software engineers appeared first on Alessandro Diaferia.