Communication skills matter a lot in software development. We rarely work alone and the foundation of good teamwork is good communication. Feedback, sharing ideas and sharing knowledge are all based on solid communication skills. To be a successful software engineer in a team you need to express your thoughts in a clear way that’s easy to follow for others.
You need empathy so you can understand how to approach other people. Consciously using communication styles will help you later in your career.
Your communication skills are also very likely to be tested when you’re interviewing – for more on that, I recommend the relevant parts of my post on acing your technical interview.
Let’s see the nuances of all this broken down by each level. Keep in mind that companies will have different definitions for these levels and that these are ranges in reality. I’ll try to be as generic as I can without sacrificing relevance.
Every engineer
The ability to express your thoughts clearly is a must on every level. You will work in a team, and communicating with others is a significant part of your regular job. While you’ll mostly talk to other engineers, assuming a sizeable common vocabulary, you still need to be conscious about how easy your train of thought is to follow.
Empathy is also not optional. Empathy in communication means you can understand what emotions and state of mind others have in certain situations and consider those when communicating. One trivial example is merely waiting for a better time with your question about how the database schema migration goes when you see that the other person is in a very frustrating bug hunt elsewhere in the system. Another is adjusting your message when you’re giving feedback on a pull request, and you understand that the person making the changes is emotionally attached to their solution.
Active listening goes hand in hand with empathy – it keeps you engaged with your conversation partner positively. It is the process of listening attentively while someone else speaks, paraphrasing and reflecting on what is said, and withholding judgment and advice.
Some everyday situations in which your communication skills is essential to your success:
- Effective dialogues on pull request reviews
- Writing good documentation with the target audience and their (lack of) context in mind.
- Giving feedback to others
Mid-level engineers
In addition to the above, more tenured software engineers will need to rely even more on communication to extend their scope of impact.
You will own complete user stories, sometimes even projects, and you’ll be responsible for coming up with plans in collaboration with the rest of the team, your Product Manager, and your Engineering Manager.
You will break down these projects into actionable steps and agree on them with your peers. You’ll need to add descriptions and acceptance criteria to these tasks so anyone can pick them up without much additional context.
Communication here starts shifting as you begin moving into technological and project leadership. Inclusive communication becomes the next milestone – that will be one new key factor in deciding whether you’re successful in your role or not. Whether you can lead a project with truly involving and empowering others will affect the project’s success and team culture and mood, too.
Senior engineers
For senior software engineers communicating on the next level becomes crucial to build out and maintain their network and influence over the organization. Stakeholders are of all kinds on this level, sometimes including CEOs and VPs.
On this level, you are expected to be successful in being the tech lead of a team that involves aligning engineers with your technological vision, being the primary point of contact for other teams, and being a strategic peer for your Product Manager and your Engineering Manager.
You will be forming tech visions, and you’ll need to communicate about those effectively.
To be successful, senior engineers need a wide network of peers across the organization – other senior engineers, managers, and people from different departments, such as customer success, sales, and marketing.
Staff engineers usually talk to VPs (Vice President of X) and sometimes C-level executives too.
Different kinds of stakeholders and peers require different approaches to getting your message through and understanding what’s important for them. Empathy alone is not enough anymore: you need to utilize various communication styles, too. A discussion about a topic needs technical depth when you’re talking to your engineering peers, and your VP will need a birds-eye-view of the same issue in the 30 minutes they can dedicate to listening to your proposal. Non-technical peers require different approaches with a different “language” and taxonomy. This article is a good summary of how situational awareness and communication relate to each other.
(Will Larson has a fantastic site for staff engineers (and their managers) which is a gold mine of useful articles: staffeng.com)
In a study, Peakon found that communication was the second thing most employees would like to change – right after salary.