Your communication skills largely determine your impact within the company. We mostly spend the early phase of our careers on learning “what to say” — we grow in our technical expertise and domain knowledge(todo: link) so we can make the right trade-offs and come up with the best solution.
After that phase, “how to say" becomes important, because once you arrive at a conclusion, the next step is to share your reasoning and potentially influence the outcome of a discussion.
“How to say” deeply depends on “who you are talking to”. Knowing the person you are talking to is key to saying things in a way that the other person can easily understand and get on the same page with you.
Knowing what you want to say is one thing. Knowing how to say it and the person you are talking to is the next level.
This post covers:
- 1. why the more you know, the more important it is to communicate effectively;
- 2. the challenge and frustration of having the most domain knowledge;
- 3. my failed experience in effective communication;
- 4. a checklist for getting to know the person you are talking to.
Why the more you know, the more important it is to communicate effectively.
The more extra domain knowledge you have, compared to the rest of the team, the more critical it is for you to effectively communicate your reasoning with your team. Since you might be the only person who knows the information required to make the right decision, your ability to share that information could be crucial to the success of the project.
The challenge and frustration of having the most domain knowledge.
If you are the person in the room with the most domain knowledge, you will inevitably feel responsible to help the team to arrive at the right approach. But it’s often a challenging task to clearly articulate your reasoning—you might be in the domain for so long that you have developed certain intuition that’s hard to explain. There might be things you know for sure that won’t work. But retrieving and showing your logic can be hard. You need to identify and show the missing pieces that you know of but your teammates do not know of. Identifying the missing pieces is hard because everything might have become second nature to you that it’s hard to put them into words. This is especially hard in heated discussions where you don’t have much time to think.
I want to acknowledge the challenge and the frustration you might feel. On one hand, you feel the heavy responsibility. On the other hand, you face the challenge of sharing your logics with everyone on the team. That the bigger that knowledge gap and the more people involved, the more challenging it is to share your knowledge effectively.
If you ever feel the frustration, rest assured that it’s just part of the process. It’s because the communication task you face is hard. Don’t feel the pressure of having to explain everything all at once. It’s okay to tell your teammates you need more time to organize your thoughts and retrieve that missing pieces to connect the dots. If what you need to say is important, then it’s worth for the team to slow down a bit to get the context you have.
My failed experience in effective communication
This is a topic I have been struggling at work recently: I was highly focused on “/what to say/” and didn’t pay enough attention to know the person I was talking to. As a result, my communication wasn’t effective: both the other party and I spent lots of time repeating ourselves. It’s only after I got to know the other party better that I started to understand their concerns and address them directly.
Looking back, if I had spent some time to learn about the person I was talking to, my communication could have been more effective. Hence, I came up with this checklist of questions for knowing your audience.
A checklist for getting to know the person you are talking to
How much context does this person have?
You can gauge that by the amount of time they spend working on the domain.
What does this person care about?
People care about different things. Some people care more about getting things done first. Some people care about building a system for the long run. Some people care about avoiding duplication and DRYing (Do not Repeat Yourself ) things. Knowing what each person on the team cares about makes it a lot easier to understand their preferences. That will help you understand the trade-offs they have in mind.
What is this person’s background?
What’s the person’s past experience? What’s the scale and kind of problems he/she used to solve? What’s his/her old way of doing things? What did he/she get bitten by?
Understanding the person’s background helps you understand where he/she is coming from. The better you understand that, the easier for you to address his/her concerns.
Is the person the decision maker? Who else do you need to talk to?
Does the person feel comfortable making decisions? If the person is new to the domain, they might not feel comfortable making decisions. If that’s the case, you might want to think about who are the people this person might consultant with and consider if you should get on the same page with those people as well.
Last but not least, hearing the person out.
Communication is a two-way street. At the end of the day, everyone wants to feel heard. If they don’t feel heard, they will focus more on saying what they want to say than hearing what you have to say. Hear people out and make sure they feel heard first. You want to actually understand where people are coming from and what their proposals are optimized for. If you pay attention to what people have to say, when it’s your turn, people will also focus more on your message rather than trying to keep track of the things they haven’t had the chance to say. You should make people feel that they are participating in a discussion, instead of being lectured.
If you will be in a group discussion, it’s worth answering these questions for each individual separately as everyone is different. That’s why the more people involve, that more challenging the communication is.
PS: I’m no expert in this matter and have a lot to learn. I would love to hear about your experience and thoughts!
My career plan for the year is to grow into a tech lead. I’m excited about all the learnings ahead and would love to share this journey with you in a brutally honest fashion. I will be sharing my weekly learning on the blog.
In the next few months, I will focus on growing in the following areas. You can expect to see posts related to them:
- focusing on the big picture of the project instead of near-term implementation details;
- balancing my efforts between leading projects and coding;
- work-life balance for long-term productivity;
- the human side of software development: making sure everyone riding with me enjoys the ride and feels fulfilled and inspired.