In the world of software development, technical prowess is crucial, but the ability to communicate effectively is the unacknowledged hero that propels projects and people forward. As a new entrant to this fast-paced career, piloting yourself through the intricacies of effective communication is essential for your success.
As a developer, you’re a member of a dynamic team consisting of fellow engineers, designers, product managers, stakeholders, and more. It’s critical for you to understand how you fit in, and to know how often and what to communicate. This understanding ensures seamless collaboration and contributes to the project’s success.
What You’ll Learn
In this article, you’ll learn:
- The essentials of effective communication in software development teams.
- How to articulate your needs to your manager and team.
- When and how to ask for help.
- Managing miscommunication and conflict.
Now that you’ve seen the significance of communication in software development, it’s time to delve into what it entails. What exactly is communication in this context?
What Is Communication?
Because communication seems so straightforward, it’s frequently overlooked as a crucial skill to hone. However, there’s a big difference between talking and communicating. Real communication isn’t just sending text messages or sitting in meetings with coworkers.
At its core, communication is about two parties transferring ideas to one another. Unless you’re telepathic, effectively transferring ideas involves constructing the context surrounding the idea and ensuring your partner comprehends by having them reflect back what they’ve understood.
Whether you’re communicating asynchronously through email, Slack, or Discord or having live interactions via in-person or video meetings, you’ll need two essential skills to communicate effectively: active listening and empathy.
Active listening is giving someone your full attention; not just hearing their words but really understanding what they’re saying. It’s like tuning in with your whole self, not just nodding along while you’re mentally somewhere else.
To actively listen, focus on the speaker, maintain eye contact, nod or provide verbal cues to show understanding, refrain from interrupting, and ask clarifying questions to ensure comprehension. Doing this will help you build a memory of the conversation and develop empathy towards the speaker.
Brené Brown, an expert on empathy, has given a number of talks and written books on how empathy can make you a better communicator and overall human. Take a look in the additional resources section for more on empathy.
Essential Rules for Communicating Remotely
As a mobile developer, you’ll likely collaborate on a daily basis with team members who are either working remotely or who are in-office in another location. That means you’ll need to cultivate some special skills for remote communication.
Communication Tools and Etiquette
Navigating the digital workspace means using communication tools thoughtfully and following etiquette guidelines to ensure smooth collaboration.
For example, conversations and decisions that happen in person need to be reflected to those not present. Hallway conversations are great and power a lot of important decisions — just don’t forget to document these decisions publicly and communicate them to other team members.
Be aware of camera angles, lighting, microphones, and audio levels when video conferencing. In video calls, you might not realize that people can’t hear you clearly — and other participants are often reluctant to speak up and say they can’t understand. This can cause crucial details to be lost.
Cultural Awareness
When you’re working with team members from around the world, cultural differences can affect how messages are conveyed and received. Don’t assume everyone communicates in the same way. For example, some people will prefer direct messaging, others more indirect. Check out the book Culture Map in the additional resources section for more about this.
Also, keep time zones in mind. Determine where your coworkers are and take that into account when scheduling meetings and setting expectations around when you’ll get a reply.
Now that you’ve covered how to communicate, it’s time to focus on what your communication should include.
Determining What You Need to Communicate
To be an effective communicator, you need to craft your messages so that they are clear, direct, and convey the right amount of context. You’ll also adjust your message depending on who you’re communicating with. You’ll start by considering your message resolution.
Message Resolution
When communicating, considering the resolution of your message helps you tailor your communication to the correct audience.
Low resolution means your audience has a general understanding of the context, and you’re providing a short, succinct message like a status update or a specific question relating to a project. Most messages in Slack end up being low resolution by default.
If your company uses Slack as a system of record for decisions, conversations may start low resolution, but end up leading into a higher resolution because of complexity or scope.
High resolution communication occurs when you’re communicating with an audience that has little context, or an unknown amount of context. Think of this when you need to write documentation for your project, leaving a code review for a person who you haven’t established trust with yet, or giving a presentation on a topic at an engineering tech talk.
Like any good story, you need to lead someone into the context with a bit of history and the paths taken and not taken so they understand where you are right now with an idea.
By determining the level of context you need to include, you ensure that your message strikes the right balance. This avoids over-explaining and wasting your audience’s time while also preventing confusion about the topic at hand.
Now that you have this idea down, you’ll focus your message more narrowly by considering the type of audience you’re targeting.
Communicating With Your Team
As a developer, a good portion of your job is to communicate with your team. That communication can be obvious, like a status update on assigned work or questions around how to approach a problem. Communication can also take the form of giving and receiving feedback (more on this later).
Some non-obvious forms of communication include comments on pull requests, feedback on design documents and engineering proposals, and formal software documentation.
What’s important to recognize is that every form of communication requires a different level of effort around context building and clarity of purpose.
If you’re not regularly communicating with your team, consider setting up regular weekly 30-minute 1:1s with everyone on your direct team. You may spend that time talking about your weekend and things not directly related to work, sometimes you might only talk about your project. The thing you’re doing here is establishing shared context and building trust with them.
Communicating with your Manager
Engineering managers handle numerous tasks every day such as project planning, budgeting, and career guidance. They typically allocate 30-60 minutes for one-on-one meetings (1:1s) with their team members on a regular basis, offering a place to discuss work updates, questions, and personal matters. Each manager may have a unique approach to conducting these meetings, but maintaining a shared document for agenda items and notes is recommended.
On a weekly basis, managers prioritize tracking work progress. Instead of using all 1:1s solely for status updates, employees can explore alternative methods for sharing progress, such as utilizing project management tools like Asana or JIRA. These updates benefit not only managers but also peers and adjacent teams, fostering transparency and collaboration. Additionally, sending quick status updates before 1:1s can serve as a helpful “pre-read” for managers.
Long-term success involves regular feedback exchanges between employees and managers. Constructive feedback demonstrates engagement and care for team success, highlighting areas for improvement alongside positive reinforcement. Effective communication with engineering managers often requires heightened attention and collaboration from coworkers, particularly in environments where managers focus on career development rather than project planning. This approach to communication may also be applicable when engaging with technical leads.
Asking for Help
You will need to balance out taking on a task yourself and working with others when you get stuck. You’ll use the stress of having to deliver to motivate you to find solutions and learn as you go. Stress is very much an accountability mechanism. There is a point, however, that the stress can turn counterproductive. It is completely okay to ask for help – and your manager will expect that of you. Before asking for help, write down what the problem is and what you’ve done and where you got stuck. A drafted pull request is a good place to do this. Showing that you’ve put a solid effort in can go a long way to communicating your intent to grow and learn and you respect the time others are giving you to help.
You’ve probably heard of the term “imposter syndrome” at some point in your career. If you haven’t, it generally means when someone believes their success isn’t deserved or hasn’t been legitimately achieved. This feeling can develop frequently when looking at other people’s successes, not seeing how their journey got them to that result, and feeling like you don’t belong in the same group. This can lead to procrastination and overworking oneself. At some point, you have to ask for help instead of assuming you need to do it yourself to be worthy.
There’s a word from Zen Buddhism that I love – Shoshin – which means beginner’s mind. A simple interpretation of this concept is when someone is an expert in something, it can blind you from finding ways to improve. Holding a beginner’s mind while looking at a problem may help you discover new ways to approach a solution. As a more junior software developer, you have the beginner’s mind by default. Asking someone for help when you’ve reached an impasse can have an unexpected outcome – the person providing the help could learn something themselves that they wouldn’t have seen without your inquiry. Ultimately, it refers to having an attitude of openness, eagerness, and lack of preconceptions when studying, even at an advanced level, just as a beginner would.
Failure to Communicate
At some point in your career, you will have to deal with problems around communicating. Maybe you’ve gotten harsh comments in a code review, feel you were misunderstood in a meeting, or are having trouble working with another team member. Giving and receiving feedback is critical to a successful career, and it is a skill that is rarely taught in school. While there are books dedicated to the subject of feedback, there are some simple steps you can follow when you need to give someone feedback.
The Situation-Behavior-Impact (SBI)™ Feedback Model is one good example of a framework to us. Describe the exact situation (I received a code review from you), the behavior (and I noticed that you left a large number of nit picks), and the impact (and it made me feel like I was being treated harshly compared to others on the team). This model can help people listen and reflect on the situation, enabling you to give feedback that is exact, clear and specific. This also can help to avoid assumptions or biases from sneaking in that could upset the other person. Feedback is a gift. It can be hard to hear and also to give, but ultimately, you will grow from it.
There are other frameworks that are similar to SBI that might feel more aligned with your personal preferences. The most important thing about giving feedback, regardless of what framework you use, is giving it in a timely manner. The longer you wait and ruminate on the feedback, the contextual relevance will fade away. A situation may not be as memorable for the person you’re giving feedback to and it’s important not to lose that for the feedback to be effective.
Key Takeaways
This article covers an incredibly wide amount of information and there are so many things to go deeper on. Some of the most important ideas you should take away are:
Communicating well is incredibly important to be a successful software developer. Just like coding, it takes practice and patience.
Not everyone communicates well, even people who have been in their careers for many years.
Your manager cares most about your growth, the progress on the work, and knowing how they can be a better manager.
Sometimes hard conversations are necessary – do not avoid them.
I challenge you to ask the hard questions, be proactive, and treat communication as an important skill you’ll hone as you advance through your career.
Additional Resources (Optional Section)
Here are a few resources that you can dig into for further reading about several subjects in this article. This list isn’t exhaustive by any means! Comment on this article if there’s another book, article, or blog post you particularly enjoy!
The Culture Map by Erin Meyer https://erinmeyer.com/books/the-culture-map/
Communicating Effectively as a Developer – Karl Sutt – Oct 28, 2022 – https://www.karlsutt.com/articles/communicating-effectively-as-a-developer/
How to Give Good Feedback – Saberr Blog – Sept 12, 2021 – https://blog.saberr.com/how-to-give-good-feedback
Junior Engineers: Your Job is to Learn – Alex Turek – Feb 8, 2023 – https://alexturek.com/2022-02-08-Junior-engineers-your-job-is-to-learn/
Asking for help 101 for trainee and junior developers – stack overfleur – Dec 16, 2020 – https://dev.to/autochocadora/asking-for-help-101-for-trainee-and-junior-developers-or-anyone-4d6c
Imposter Phenomenon – Martin R. Huecker – July 31, 2023 – https://www.ncbi.nlm.nih.gov/books/NBK585058/
Empathy – Brené Brown – https://brenebrown.com/videos/rsa-short-empathy/
Invitation to Join the Forum
Just a sentence mentioning the forum discussion and what the reader might want to discuss there.
About the Author
A few lines tying the author’s expertise into this article. Why were they the right ones to write this specific piece? Why should the reader listen to them on this subject?
