Why you should avoid your over-communication strategy 🥴
Effective communication > Over-communication for the sake of it
“There’s not such a thing as over-communication.” I have heard it multiple times, and I might be wrong here, but over-communication sometimes feels tiring. If you send the “same message” in different channels or use other words, you can end up wrongly communicating, as receptors might need extra work parsing the core message.
That’s why synthesizing and centralizing information will always be more effective than over-communicating with the hope that people will now understand what the message is.
Where it all starts, meetings…
I’ve been in meetings multiple times where the topic is “Define our product roadmap,” where various issues are discussed. There are brainstorming exercises, workshops, and tools that help understand the product goals backing up a business.
But when those meetings end, there’s always a gap between what was done in the forum and what people understood! Surprisingly, there’s a mismatch between what an engineer understood and what the CEO/Product manager intended to say.
And if it wasn’t bad already, sometimes people do not reach out when they don’t understand some parts, so there might be a chance that some ideas are implemented into the end product where they were not supposed to be.
Where is the source of truth between Slack, Notion, or the tickets?
After those meetings end, people are going to post messages after sessions, asking what the final resolution of a specific topic was. One can tell the source of truth is going to be a Slack Message, but another one will link to a Notion doc, but the message is newer! And don’t let me get started when you see a Linear ticket with a different description than the latest slack message the product manager sent!
How can we address this?
First, communication is a very complex problem; there’s no silver bullet to put everyone in the same channel just because we as humans interpret information based on our previous experiences and points of view. However, I believe there’s a technique to achieve more effective when communicating: to convey the most critical information and deliver it in the correct format. And no, meetings should not be the default.
Techniques
Do not start a meeting; send a Loom.
If you have something you want to share with your team that you think it’s essential to give a review, instead of starting with a meeting, you can start with a Loom video.
Loom is a tool that lets you record your screen and video so that you can run an explanation of whatever you want. After you stop recording, you will get a link you can share within Slack or any other tool so that people can view the video and give comments.
This is an underrated mechanism of communication. I had seen it shine in the most complex scenarios, i.e., when an architect was sharing the reasoning behind migrating from a shard-database provider into our cloud, he would send a loom with challenging content. Still, in the end, I thought that was the right call; let me explain the benefits of that specific example:
The architect had multiple shots of how he wanted to share the best possible explanation of the why and how
The viewers could pause at any point and look for the concepts or technologies the architect mentioned without sacrificing other parts of the explanation.
Some viewers did watch the video in 2X (yeah, there are people like that)
Any doubts or questions would land in a Slack Thread of the message where the video was posted. Everything was centralized in there.
But, the best of all benefits is we could watch at any time and re-watch it as much as we wanted.
This is a much better way to convey and share information with multiple people. At the end of the video, people would have many questions and suggestions for the content, and, you know what? We had a meeting later on, but with A LOT of clarity on what we wanted to focus on. It turned out as one of the most influential meetings I’ve ever had, everything ran smoothly, with a clear agenda (the Slack Thread questions), and the result was a well-formatted document. We will dive into that.
Start with problems, not with solutions.
There have been times when meetings occur, where people start talking about, “Let’s use Kafka to have a message broker that would allow us to replicate the same message to different services, so we can be as real-time as possible and decouple domains from each other.”
Well… yeah, Kafka is a fantastic technology, no doubt of it, but the real question should be (and it’s one of the most underrated questions I’ve noticed in my career):
💡 What is the problem we want to solve?
Having a clear problem statement counts as solving 50% of the problem. An apparent problem becomes multiple clear hypotheses to solve it, and various beliefs become multiple really-clear solutions.
Early in my career, I was surrounded by people who worked at a small startup, Fresh out (acquired by Envato). The team there had a culture of documenting and planning their work using a hybrid of the scientific method and agile; they called it the X-Workflow.
Senior engineers would bounce my Pull Requests or tickets because I didn’t clear my problem statement. And you know what? They were right; I was coding just for the sake of it, just for the excitement it represents when you are creating something from scratch that you know people will start using.
How do you know if you are trying to solve the right problem? That’s all contextual, business-dependent, and a skill you need to master. And I can tell I’m not even close 🙂
Use threads 🧵
Keeping your questions organized is good, and your answers are even better. Knowing your public is incredible.
I’ve recently found out you can use Linear as a replacement for Twist or Threads :) You can create a Discussions project in linear, write a discussion with excellent markdown capabilities, and subscribe to people you want to get involved with.
If you don’t use Twist or Threads, keeping a healthy threads culture in Slack might be good, but I believe products such as those add value when coming back to why some decisions were made.
Learn to convey elegant diagrams
I think there’s nothing as pleasant to me as seeing a diagram that can explain the small pieces of a more extensive system. Even if it’s just boxes and arrows (a lot of my favorite charts are just like that), it can help explain the “how-to” of feature development, or the “how-to” of how we communicate internally in a team, or anything. Good diagrams stick in the brain and help to understand a vision in any direction.
Just have smaller teams.
The fewer people there are in projects, the fewer communication lines are in place. I learned this from a conference team Newman (author of Building Microservices) gave in the Wizeline office back in 2017. Even one person added to a team of 4 can exponentially increase the communication lines, meaning more chances of miscommunication. The leaner teams are, the better they can communicate.
Conclusion
These are some of the tools I have used in the past, and I hope they help you on your road as a founding engineer or a startup person 🚀 do let us know if there’s anything else you recommend to improve communication!