Heavily based (with permission) on Amitay’s great article
The more technical an engineer or manager is, the worse they are at explaining their thoughts and opinions, and the more frustrating it is for them (and for everyone else).
But let’s start at the beginning.
What’s this thing we call “Red”? In a way, there is no such thing. “Red” is a simplified representation of a range of visible wavelengths.
We compress infinite complexity into finite language.
When your engineer says “I’m frustrated”, they are actually compressing a complex range of emotions into a single word, making it communicable.
When we transfer information from one person to another - feelings, thoughts, technical concepts - some of it is always lost. When I say “I’m happy,” I lose the subtleties of my experience for the sake of being understood, hoping the listener fills in the gaps with their own interpretation once they decompress the message.
Same with an abstract concept like ‘technical debt’. For each engineer, it means different things, based on their own experience. What you try to transmit during that important architectural meeting might be completely different than what the other side receives.
You can think about it in circles: the center represents core experience (raw information). Within it, the information is rich and multidimensional. As you move outward from the center, the message becomes distilled and simplified, making it less accurate, but easier to transmit:
But why do we do that?
1. Cost
Describing the raw data of every experience or technical concept would take an enormous, possibly infinite amount of time.
At higher resolution (closer to the center of the circle), more information is available, but the cost of sharing increases due to the volume of data. At a certain point it becomes inefficient - the benefit of extra information no longer justifies the cost of transmitting it.
But what if I’m willing to pay the price? If I have all the time in the world?
2. Confusion
More information is not always better. At first, that’s true - understanding rises as you add context and detail.
But there’s a sweet spot where the idea fully “lands.” The recipient gets it.
In some cases, like the ‘R’ above, the understanding will keep rising. But in others, beyond that point, adding more information doesn’t just fail to help - it actually reduces understanding. Extra details blur the core message and introduce noise and confusion.
Draw me a sheep
In those cases, the curve doesn’t rise forever. It rises, peaks, and then drops once you cross the threshold where clarity starts turning into overload:
As engineering managers, there are 2 skills we need to master:
1. Compression
This is my weaker one. Being able to take the ‘inner circle’ of your experience/feeling/thought and compressing it into the right few sentences. Articulate yourself so the other side fully gets you, while in parallel:
Minimizing the cost (needing a few minutes instead of 1 hour meeting)
Avoiding confusion (understanding what exactly the other side thinks)
There are different ways to achieve this skill - some do it with great storytelling, but others achieve the same result with dry explanations full of facts. No matter which way you choose, you have to be at least a 7/10 in this skill as a manager.
You use it everywhere:
When giving feedback (what do you mean by ‘more ownership?’)
When pushing for your agenda (why ‘supporting scale’ is important?)
When mentoring an engineer
When you improve at it, you start to notice when you reach that tipping point, or what else you need to say to bring the other side to that ‘aha, now I understand’ moment.
Getting there takes a lot of practice. A good way to start is to ask the other side to explain back what they understood from your message.
Wes Kao has a couple of great articles on the topics, I’d start with how to be concise and Technical leaders make these 4 common storytelling mistakes.
2. Decompression
Being able to receive information effectively - get as close as possible to the ‘inner circle’ that the other side tried to transmit. Make the other side feel heard, and walk out of conversations feeling that both sides understood each other.
This requires shutting up and listening. Not jumping in to provide your opinion, or share your own experience in a similar situation.
This one is very underrated - as many managers think they are good at it, but are actually terrible. I feel the more sure you are that you fully understood the other side, the more likely you are to be wrong.
How it looks like in the day-to-day
I first encountered this problem as a newly-promoted first-time Engineering Manager. My own manager was the most tech-inclined engineering director I’ve seen. He didn’t care about customers at all - only about building technically excellent products. I’m on the opposite side - I care much more about our customers than the tech debt we create.
On paper, it could have been great balance, but we just couldn’t find the right words to use. He hated my approach, and gave me the worst performance review I ever got.
In hindsight, I can assume he was burned by too many rushed projects and wrong decisions.
Since then, I continue to encounter this gap almost every week. Just this last one, I’ve been working on a new project with 2 super talented principle engineers. And still, they struggle to explain their vision in a way that’ll bring everyone on board. We are slowly getting there, after 10+ hours of meetings and a lot of mental effort and exhaustion from all sides.
It both of those cases, all sides could have tried harder to imagine themselves in the other side’s shoes.
I’m not very communicative. In my personal life, I prefer reading a book to meeting people. This mental model of ‘compressing’ and ‘decompressing’ information helps me think about communication in a slightly different way, more suited to how my brain works. I feel I improved just by holding this concept in mind.
I hope it’ll help you too!
Discover weekly
Slow down to speed up by James Stanier.
Claude Cowork Might Be the Most Consequential Piece of Software You're Not Using by Eric Porres.
Avoiding a Culture of Emergencies by Stay SaaSy.
