Communication: A Key Skill in Your Tech Stack
Summary ⇒ Communication is your most critical soft skill. Without it, you risk solving the wrong problems or having your hard work go unnoticed and misunderstood. Here I share the key principles I learned to avoid these mistakes, with actionable advice and examples to help you become the person everyone wants on their team.
For years, I thought that my value as a developer was directly tied to my technical skills and output. I thought that writing clean, efficient code was the beginning and end of my job. I was naive, to say the less, and that perspective changed completely when I became an expat working in a foreign language. Suddenly, my coding and problem-solving skills weren’t enough. If I couldn’t clearly explain my ideas, understand my team’s needs, or articulate a problem, my technical contributions were limited at best and misguided at worst.
This is how I learned that no matter how elegant and great your solutions are, their value is limited by your ability to understand the needs of the project and to communicate your work to others.
Three Core Principles for Clear Communication
Over time, I’ve learned to focus on three things to guide most of my interactions, whether a chat message, a meeting, or a code review (If you are taking only one thing from this post, this should be it)
-
Speak Their Language: Before you write or speak, consider who you are speaking to and what they care about. Frame your message so it resonates with them.
-
Ensure Alignment: Misunderstandings are the source of most project delays and frustrations. Make it a habit of constantly check that you are all on the same page, recap what you understood, what the goals are, which approach is desired and whether your understating is right.
-
Write with Foresight: try to always write in a way that anticipates usual questions. It will take some extra time but by adding context or screenshots you can save time for others and help them see exactly what you meant.
Adapting Your Message
Many developers use the same communication style with everyone. But the way you talk to a fellow engineer should be different from how you talk to your manager or a product owner. The care about different things and have different backgrounds, so your goal is to deliver information in a way the can put it in context.
Communicating Up to Leadership
When you speak to managers, directors, or clients, they usually think of business objectives, timelines, and budgets. A highly technical explanation of a problem will be just noise, so translate the technical details into business impact.
-
Focus on “Why” and not just “How”: Explain the business reason for a decision. For example, instead of detailing the complexities of a database migration, explain that it will reduce costs, load time and improve user retention.
-
Speak in terms of time and money. Technical debt isn’t a vague concept, but as a risk that will cost a delay of two weeks if not addressed it is clearer to see.
-
Be concise and direct: don’t bombard anyone with too much information, provide a clear summary upfront and offer to go into more detail if needed.
Communicating Across to Your Peers
With your fellow developers, clarity and precision are paramount. Aim to eliminate ambiguity, reduce wasted effort, and be collaborative. Make it easy for others to work with you.
-
Write clear documentation and tickets: provides all the necessary context, acceptance criteria, or technical notes needed to get started and to understand what it going on. Answer their questions before they even have to ask them.
-
Be explicit in your pull requests: Your PR description should explain what the change is, why it was made, and how to test it. Don’t make people guess.
-
Recap conversations: After a technical discussion, summarize the decisions and action items in writing. This ensures everyone is aligned and creates a record of the plan.
Putting It Into Practice: Some Common Scenarios
Giving and Receiving Feedback
Feedback is essential for growth, but if poorly delivered it can even be counterproductive. The key is to be specific, objective, and solution oriented.
Instead of: “This code is a mess and really hard to read.”
Try: “This function is doing a few different things. We could improve readability by separating the data fetching logic from the UI rendering logic. What do you think about creating a separate service for the API call?”
Explaining Technical Concepts to Non-Technical Stakeholders
Analogies go a long way to connect complex ideas to concepts that everyone can understand.
For example, when explaining the need for refactoring:
“Think of our code like a kitchen-sync. Right now, it works, even with old dishes and pots taking part of the space. This can keep going, but unless we start washing some of these, it will get full and we will run out of utensils to use. A refactor is like taking the time to wash the dishes and pans, it won’t give us new things, but it will free-up the ones we have to use them again.”
Mentoring and Knowledge Sharing
If you are a senior developer, your can to multiply your impact by guiding others. So when you are mentoring or pair programming try to:
-
Be present: Give the person your full attention. Listen to their questions completely before formulating an answer.
-
Adjust your approach: tailor your explanation to the person’s experience level, past experience or interests.
-
Guide, don’t dictate: don’t give the solution, share the desired outcome and explain how you would go about it as an example. Let them find their own way to the goal, and develop problem-solving skills and confidence along the way.
Final Thoughts & Actionable Advice
Like it or not, people prefer to work with colleagues they can communicate with effectively. Solid technical and good communication skills will almost always win over a technical genius who is impossible to collaborate with.
Improving your communication is an active process. It requires intention and practice, just as learning a new programming language. Therefore, here are a few immediate steps you can take:
-
Recap the Next Meeting: At the end of your next meeting summarizes the key decisions and action items out loud.
-
Ask for Feedback on Your Writing: Ask a trusted peer if your document or description was clear and whether they had questions while reading it.
-
Translate a Recent Technical Task: Practice explaining its business value and connect your work to the bigger picture. Imagine you are speaking to your non-technical manager.
Thumbnail by Jeremy on Unsplash