The importance of adapting the message to the listener
Have you ever struggled in a meeting because the conversation deviated from the original purpose? Maybe your message was not meant for your target person in that meeting
The way you talk, the visual artifacts you use, and your body language should be adapted to your target audience. Otherwise, one of the many issues you might face is that the conversation will lose focus on meaningful conversations.
In today’s issue, I want to share with you one of my failures in communication and how I overcame it.
If you’ve been following me for a while, you’ve already heard a lot about this. I’m not just repeating myself; I’m providing more resources to help you improve the key skill (communication) every Software Engineer needs, especially in the age of Agentic AI.
Three mistakes:
Reuse the same diagram.
Focusing on feelings instead of data.
What to do when the conversation is about bananas?
☝🏼 By the way, this is a concrete example from real life.
Reuse the same diagram
I think this was my main mistake by far.
I had a meeting with the Product team to explain our approach to the roadmap’s requirements and use cases. To support the discussion, I used the same system diagram I use with my fellow engineers, people who have deep technical knowledge and don’t get lost in the moving pieces.
Consequently, the Product team felt the need to clarify every single component in the diagram. This was a natural reaction; they wanted to contribute to the solution and needed to understand what they were looking at. However, we ended up getting bogged down in the details and missed the main objective of the meeting.
👉🏼 To pivot from my mistake, it would be better to use visuals tailored to your audience and keep only what is relevant to the discussion. Otherwise, we risk creating noise, like debating AWS SNS data formats, instead of staying focused on the meeting’s goal.
Focusing on feelings instead of data
Another mistake I used to make was the usage of feelings and memories during the meeting, instead of numbers. This happened to me as well in the example I’m using today.
I went to the meeting with the right preparation. Because of that, I had to start using my brain to make it speak in a way that my audience could understand what I wanted to transmit; This is the basis of communication indeed, and it’s good, but not enough, because you can commit mistakes or forget things properly, and your audience can find a flaw in your speech.
Forget about what you remember in the past. Show data, show numbers! Prepare your meeting to showcase numeric information, with dates, rates, or whatever applies to your use case.
👉🏼 It’s better when you use information that your audience can read and understand by themselves.
What to do when the conversation is about bananas?
This could happen, and it happened.
I found myself having to explain to the Product team why we were using a specific data format for the messages passing through AWS SNS. I can tell you that’s not what I wanted to talk about. At that point in the meeting, it felt like it was too late to try to steer the conversation back to the original topic.
👉🏼 My recommendation at this point is to try to end the meeting, wrap up, and call for another meeting (yeah, I know).
You have to make your audience understand that you need to go through all the points discussed to adapt your solution.
For that, you will invest the time until the new meeting to adapt your visuals and your speech, based on the points discussed above, and remove from the table parts that match with:
Bring noise to the conversations.
Make the system complex to understand.
Not useful for the goal of the meeting.
In order to know if something matches those 3 points, I ask myself: Will my audience ask for “this” that is not relevant to my goal? If yes, drop it.
From here, you will create layered diagrams and speeches, each of which is focused on a different audience you will meet to achieve your goal.
At this stage, you ask the following:
Marcos, what do I mean by layered resources?
I mean that, from the raw and complete information about the topic to discuss, create visuals and speeches for each of the personas/audiences you are targeting.
📖 For example
For your dev teammates, create visuals and text descriptions that make it pretty clear how your system works, so they do not get surprised when they find “that missing Lambda function there”.
In the case of your Engineer Manager, maybe you have to scale up +1 level of abstraction. Maybe she/he does not need to know all the possible Kafka topics or microservices in place, but a diagram where is displayed the technologies used, the changes to be done, and the risks.
Thinking about your Product Manager, definitely, she/he does not need to know if we are using AWS Lambdas or SNS or whatever. Use plain boxes without naming technologies and arrows to join the pieces and showcase the flow.
Keep in mind the visual I gave you in the section “Reuse the same diagram“.
👉🏼 You should go from super-low level to higher layers of abstraction, each of them meant for every kind of persona.
Let’s finish for today.
✨ Takeaways
Always take the time to prepare for your meetings by tailoring them to the specific audience.
It’s easy to let this slip through the cracks, especially when you’re caught up in a high-speed environment and focused on your daily routine. If it happens to you, don’t sweat it. Just schedule another sync to buy yourself some time, go over the main points again, and pivot your presentation to match their level.
In concrete terms, keep this in mind:
Do not use the same visuals or the same speech to explain a concept to different roles.
Use layered resources for the different kinds of audiences.
Hope you enjoyed today's email. I would love to hear from you about what are your experiences communicating. Drop me a message, I read them all!