Why good communication is so important
Professionally acting teams are successful because their communication works. Examples of this are familiar to all of us: rope teams in mountain sports, soccer teams, space crews. It can be the crew in the cockpit of an airplane, the captain with his crew on the bridge of a cruise ship, the staff in a restaurant or rock band and stage crew on a tour. Everywhere, communication plays a key role in a successful outcome and the successful meshing of different disciplines and roles.
As software engineers, we should always be aware of the fact that we can play a significant role in the success or failure of a project and a company not only through technical skills, but also through our ability to communicate. Knowledge about an effective communication skills for software engineers is an integral part of successful strategies and projects, while missing or withheld information can hardly be compensated by even the largest budget.
Whoever communicates, communicates information. Those who communicate information are perceived as competent – provided that the information is logically comprehensible and easy to understand. Our personal assessment of other people’s existing knowledge is often diametrically opposed to reality, and we clearly overestimate what information is known outside our own context. As a result, we communicate too little, too inaccurately, or too quietly.
Much of the information in this article is not only relevant for the communication of software engineers, but has a certain generality. Nevertheless, in some places I focus especially on the engineers and on their role in a successfully operating company.
Communication as link within the team
A well-coordinated team is generally characterized by very good communication skills among each other. A typical example is the operating room team in a hospital, consisting of a wide variety of roles such as surgeons, anesthesiologists, assistants and other key staff. In addition to routine collaboration, clear, unambiguous communication between these individuals is an extremely important piece of the puzzle in achieving the goal of a successful surgery.
Although the direct impact in an interdisciplinary engineering team is usually fortunately not as critical as in an operation, we can still learn a lot from communication skills from such industries. A team with the best people is only as good as their ability to communicate with each other. This becomes even more important the larger a team gets and the more teams exist in a business. It is not for nothing that the “two pizza team” is often mentioned as the ideal size, i.e. a team with a maximum of six to eight people. In this size a fluent cooperation is well possible, the decision paths are short and the communication between the individual persons can be easily ensured.
Even in this still very manageable size, good communication is not a foregone conclusion. The typical, more or less institutionalized opportunities for information exchange are usually daily standups, retros, one-on-ones or pair programming sessions. In addition, in such a small team there are frequent, spontaneous conversations between individual team members, so that there is a constant flow of information.
Communication within one’s own team is the safe space, i.e. the area in which most employees feel comfortable and do not have to leave their comfort zone to communicate. It is an ideal space for practice, which should definitely be used, because already outside the team communication becomes more complicated and at the same time even more important.
Business critical communication between tech and business
As a software engineer or technical leader, you usually work at the interface between people and machines, between company structures and an often complex software architecture. The typical image of an iceberg comes to mind: a small part is visible to everyone, but the largest part remains hidden under water to most eyes. Making this invisible part, the technology stack, comprehensible to all employees is a difficult but essential task and is largely responsible for the success of the business models based on it.
This fact places high demands on employees from the technology area, the potential impact of which must not be underestimated. Incomplete, misunderstood or even incorrect information between tech and business can lead to faulty business strategies and thus to extremely critical consequences in the medium to long term. A multidimensional communication between software engineers, product managers, designers, QA engineers, marketing, sales and management should therefore be the goal to weave a dense web of information flows and create a common understanding of the status quo, dependencies and goals.
Part of our job as software engineers is to communicate complex technical issues without jargon and irrelevant details in a transparent and easy-to-understand way for all employees of the different interdisciplinary teams. This can happen in townhall meetings, in demo showcases or in the daily standups of a product team. It can be written or verbal communication and the content can consist of new features, bugs or information about the status quo of individual teams or projects. What they all have in common is the high relevance of the information for an interdisciplinary organization that relies on extensive mutual understanding among all roles and people involved.
Can we Software Engineers communicate?
Most software engineers are not necessarily known as gifted speakers. Be it due to a lack of or negative practical experience or because speaking in front of an audience, taking on responsibility and the resulting possible consequences cause anxiety: The reasons for this can be as varied as they are supposedly banal and have their origins partly in an unhealthy corporate culture or, in the case of more introverted people, arise from their personal nature. A good engineering manager will recognize these reasons and should support employees individually in improving their communication skills.
Intrinsic motivation to develop your own communication skills is also an important piece of the puzzle during your career as a software engineer. Ideally, you will already take the first steps as a junior engineer to be regularly involved in communication and gain experience. Because by the time you become a senior software engineer, good communication skills and a certain talent for communicating complex issues are usually a prerequisite. The reality is, however, that there is also development potential for quite a few old hands, since individual development opportunities are limited or, in the worst case, non-existent in quite a few companies.
Good communication can be learned
The good news is that you can train and improve your personal communication skills. Depending on your personality, this may take some courage at the beginning, especially for introverts. But you’ll soon notice that you’re becoming more self-assured and confident in your communication – and you’ll also notice that your colleagues are noticing and increasingly accepting and respecting your role as a link between tech and business.
By the way, improving your communication skills is also one of the first and most important steps towards the management track: If you want to move from the Individual Contributor path to Tech Lead, Engineering Manager or other leadership roles, good communication is the basis for these jobs.
The following ten tips can help you prepare for a communication, execute it successfully, and reflect afterwards on how you can improve next time.
Dare!
Communicating also means exposing yourself. If you expose yourself, you will also sometimes face headwinds. This can be a bit intimidating, especially in the beginning. But as soon as you have accepted this fact, you should put it aside and concentrate fully on the topic you want to communicate. If you do nothing, you do nothing wrong, and this is as true in communication as it is in many other things in life. So if you stand behind the topic you want to communicate with a clear conscience, dare to do it and just do it.
One way to take some of that pressure off is to communicate with a teammate. For example, if a demo showcase of the enhanced product is coming up, you can split up the communication and do it together. Make sure that both of you are talking about the same things and that you don’t give different information about the timelines of deliverables, for example.
Direct vs. indirect communication
Especially for important communications (when all recipients must have the same, unambiguous understanding), you should always resort to direct communication. Direct in this context means talking directly to the people involved and not letting the communication go through other people. This is especially important in leadership roles, but should not be underestimated in the role of a tech lead, for example. For example, if there are issues working with the CI/CD pipeline and people keep committing to a failed build, you need to address that directly in the engineering team with the responsible people and should not run that communication through a third party.
Especially with uncomfortable topics, we tend to avoid these conversations and only pass the information on to the recipient(s) indirectly. This is understandable, but at the same time it is the perfect recipe for further misunderstandings, because there is a latent danger that the message will be softened. The background to this is a phenomenon we all remember from the game of “silent mail”: with each additional intermediate relay in a communication, the original topic is further watered down. Each person, knowingly or unknowingly, brings in his or her own perspective and in the end the core message may no longer reach the recipients with the necessary clarity. What is funny in a game, however, can have far-reaching consequences in a corporate context.
What plain English has to do with good communication
Simple language (aka plain English) is a simplified version of the respective language. It is aimed at people who can read less well or for whom the language is a foreign language. Now, the goal is not to build all your communication in simple language. However, you should be aware that only the communication that reaches as many people as possible and from which as much information as possible is retained has achieved its goal. The easier the content is to understand, the greater the chance that many listeners will have understood it.
Especially in the case of written communication or slidedecks, it is therefore worthwhile to double-check what has been written and to delete all unnecessary filler words, incomprehensible and unexplained technical terms or passages that go into too much detail.
Work on your rhetoric
It is worthwhile to analyze the communication of well-known and eloquent personalities a little more closely from time to time. Anyone who has watched Barack Obama’s speeches will have noticed that he uses a simple, yet eloquent form of expression in combination with outstanding rhetoric – which (usually) also reaches the very diverse target group, especially among politicians.
So should we all speak like Barack Obama now? That would probably be quite exaggerated for the vast majority of situations. Nevertheless, it is worthwhile to take a look beyond one’s own nose and, with regard to good communication, to learn something from the people who really excel in this métier – be it in linguistic or written form.
Find your sweet spot
Probably each of us knows those people who are a pleasure to listen to. We like to listen to them because they have a pleasant voice pitch, because they have perfect pronunciation and intonation of the voice, because they can speak grippingly and captivatingly about even the most banal topics or because they make the audience laugh even on serious topics.
Not all of us have the perfect voice (by the way, we ourselves almost always consider the sound of our own voice to be terrible) or the subliminal, sensitive sense of humor. Nevertheless, it is worthwhile to observe oneself and analyze which communication has had the most lasting effect on the recipients. Of course, the point is not to turn every workshop into a show. Nevertheless, small details can make the difference and ensure that the message is received with greater interest by the audience and internalized more sustainably.
Know your audience
In our work as software engineers, we encounter complex problems relatively often. If you have struggled for several hours or even days with an almost unsolvable problem and finally found a solution, you are probably justifiably proud of it. True to the motto “Do good and talk about it”, you want to show this result to the entire staff at the next team meeting and give a 20-minute presentation about your technical masterpiece. The result: polite applause and, judging by the queries, a manageable level of understanding among the audience.
Depending on the type of meeting and according to the audience, the content of the communication needs to be adjusted significantly. In a workshop with other software engineers, you can certainly go into the technical details. In a meeting with marketing and customer success employees, on the other hand, most of the technical information is no longer necessary or plays only a subordinate role. In a team meeting with the entire company, it’s all about conveying the most important information at a contextual level that all employees can understand. If you have the pleasure of a meeting with the advisory board, the people involved will often not even know the programming language used and the information presented should be limited to the strategically most important key points.
Get information to the point
You’ve probably heard of the “Three C’s” for successful communication: Be clear, concise and complete. Not the longest communication is the most successful, but the one that can convey all relevant information clearly and understandably in the shortest time. It also helps to know software systems not only from the inside, but especially from the outside perspective based on the expected outputs, to know about the necessary KPI’s and to be able to relate them to the technical processes.
You can use a kind of “test-driven development” approach in the preparation for your communication and think about what information you really want your audience to retain after the workshop. By doing this, you’re already incorporating your audience’s current level of knowledge into your planning and avoiding monologues on topics that aren’t relevant to them. Think of your communication as a pitch for a startup, where you want to convince a critical audience in the shortest possible time.
The same applies to the infamous slidedecks: here, less is clearly more and you should limit yourself to a handful of slides with the most important key points (if they are necessary at all). Even better than written words are sometimes only visual representations in slidedecks.
Communicate only if you stand behind it
Maybe you remember the time in school when you had to prepare and give papers. Mostly on topics like the most important features of the baroque period, stuff that was maximally uninteresting and not very relevant for the future for most adolescents. These presentations were then also often subterranean bad, which was probably due to the slightly excessive lifestyle as a teenager on the one hand, but on the other hand was also strongly due to the fact that one was simply not interested in the topic.
What can we learn from this? Well, one thing above all: Only communicate about a topic if you feel you have the necessary background knowledge. If that’s not possible and there are still reasons why you need to communicate something unknown or unclear, the next point becomes all the more important.
Be aware of the weak points of your communication
No matter how well prepared you are, there will be one person who spies the weak spot in your communication with eagle eyes. In principle, that’s perfectly fine, because communication is also there to trigger feedback on the information being conveyed. At the same time, there are situations in which queries are more or less obviously used as a good opportunity to highlight weaknesses or errors.
Dealing with such situations in a confident manner is important. First of all, you have to be aware that the moment you communicate, you also expose yourself at the same time. Mistakes happen and are human, you should accept appropriate feedback calmly, perhaps combined with a healthy pinch of humor, and thank them for it. The same applies to critical questions. However, if you get the impression that it is more about covert denunciation and finger pointing, you should strive to deal with the situation effectively. For example, if the questions are too detailed and of no interest to the majority, you can offer to continue the conversation at a later time in a smaller group.
If you are already aware of an inconsistency in your communication, it is best to address it openly. The more transparent you make gaps in knowledge or ambiguities, the less vulnerable you make your communication and at the same time disclose important information.
As a general rule, you should always be prepared to accept feedback. This helps you to further improve your communication skills and, in combination with reflecting on your own performance, represents an important building block in your further development.
Use appropriate communication channels
As a Software Engineer, you will typically communicate either on audio or in written form. The environment is usually meetings, workshops, or situations that require appropriate written communication. People, by nature, have a wide variety of methods for taking in information. These vary between processing by seeing and hearing, by thinking and acting, by reasoning and intuiting, or by analyzing and visualizing.
Good communication enables all recipients to understand the information in their own individual way. For example, it can help to underpin complex processes visually, to record the most important key points in writing even when communicating verbally, or (for example, in the case of product demos) to conduct a live demo directly.
To be fair to people who could not participate at the time of the communication, it is advisable to also provide the most important key points in written form. This can be a message in a Slack channel, an email or short meeting minutes in wiki software such as ClickUp or Confluence.
Conclusion
One thing is clear: you can’t do it without communication. As a software engineer, you have a lot of good reasons to develop and perfect your communication skills from various perspectives. On the one hand, there is a direct correlation between the effectiveness of the information exchange and the collaboration and thus the quality of the results within your own team. On the other hand, the situations in which professional communication is required increase with seniority and are among the basics that companies require as a requirement for the profile of a senior software engineer.
There are enough reasons to consider the individual communication skills as a software engineer as an essential skillset. Considering the high relevance of this topic, the personal benefit and the undeniable benefit for your team and your company, regular workshops, presentations and speeches should be an integral part of your daily work routine. You can also benefit from them in your personal environment and influence how you are perceived and accepted by your peers.
