Today, I learned something valuable from a simple technical issue.
We were troubleshooting a failed FTPS connection between our SSIS job and an external server. At first, I focused entirely on the technical details. I analyzed IP addresses, host names, client addresses, network policies, and firewall rules. Every new piece of information seemed important, and I felt compelled to explain everything I had discovered.
When I finally drafted an email, I realized it was more like an investigation report than a request for action.
My goal had unconsciously become explaining why the problem happened.
But that wasn’t what the recipient needed.
The other party didn’t need my reasoning process. They didn’t need to know how I distinguished a host IP from a client IP, or how I traced the issue through SSIS, WinSCP, and firewall policies. They only needed one piece of information:
“Please whitelist our public IP address: 207.102.134.77.”
That was the only action they could take.
At that moment, I realized something much broader than this single email.
Communication is a limited resource.
Every email costs someone time to read. Every unnecessary sentence consumes attention. Every extra explanation competes with the one message that truly matters.
As engineers, we often believe that if we explain our reasoning, people will better understand our conclusions. Sometimes that’s true. During incident investigations, design reviews, or root cause analyses, detailed explanations are essential.
But most day-to-day communication serves a different purpose.
Its purpose is not to explain everything we know.
Its purpose is to enable the next action.
I also noticed something interesting about myself. This wasn’t the first time I had done this. I already knew that concise communication was important, yet I still found myself writing long explanations. I realized that I wasn’t lacking knowledge—I was following a habit. As someone who enjoys solving problems, I naturally think in terms of causes, relationships, and detailed analysis. My instinct is to tell the whole story.
However, effective communication requires a different mindset.
Instead of asking,
“What do I want to explain?”
I should first ask,
“What does the other person need in order to take the next step?”
That single question changes everything.
I also began to notice this pattern in other people. Sometimes long explanations genuinely come from a desire to help. Sometimes they come from uncertainty or fear of leaving something out. And sometimes they are used to hide responsibility. Although they sound similar, their intentions are completely different.
Perhaps the most important lesson is that simplicity is not about leaving information out. It is about respecting the limited attention of the person on the other side.
A good diagram replaces pages of documentation.
A good API exposes only what its users need.
A good email tells people exactly what they need to do.
The goal of communication is not to transfer everything in my mind.
It is to create the greatest understanding with the fewest necessary words.
That is a skill I want to continue practicing—not only in emails, but in meetings, presentations, software design, and even in everyday conversations.