In the last couple of years, most companies have transitioned from an on-site, office-based, company, towards a remote-friendly workplace, with people working from all corners of the world, in a multitude of teams. In such workplaces, there is a lot of emphasis put on how, and when, we communicate. This is because communication is the main factor that keeps chaos away and the machine running smoothly.

The companies I worked in always had an extremely dynamic environment, and because of this, there has always been a clear expectation that any engineer — especially one that is in a Senior or higher role — will be able to act independently, communicate clearly and be capable of explaining technical topics to anyone in the company.

In almost all places that I worked in, I encountered situations in which engineers were presenting a subject in a meeting, but the used language was too technical. Looking at webcams, I could see confused faces, mostly coming from non-technical people, trying to figure out what the speaker is talking about. In most cases, the confusion evolves into disengagement, and when the talking stops, there are still plenty of questions to be asked.

For software engineers, the first few years of their career is focused on improving their coding skills, learning the processes and methodology used in software development, as well as building healthy relationships with their peers — designers, product and project managers as well as other engineers.

As an engineer progressing through your career, you will notice that the amount of, and manner, in which you communicate changes proportionally with the seniority. Sometimes, a promotion will translate into increased expectations about the way in which you communicate inside and outside the business.

When you make the transition to a Lead position, communication is key. This is when you become the main point of contact between the business and the engineering team. Scope negociations, technical consulting, advising, mentoring and coaching become day-to-day tasks.

Awkward situations are easily avoidable when some aspects of communication are followed. Here is a list of what I usually take into account when presenting a complex, technical, subject:

1. Know your audience

The main takeaway here is: adapt your discourse to match the knowledge and roles of your audience. Avoid having deep technical discussions during the wrong type of meetings.

The first thing to take into account when you are preparing for a meeting is to take note of the other people attending and their roles in the company.

There will be times when you will find yourself in the posture of a representative for the engineering team. In those situations, it is very important to tailor your vocabulary to the technical knowledge level of your peers. Using technical jargon with non-technical people could do more harm than help, due to confusion.

Of course, there are situations in which a technical discussion is required. The temptation is to start explaining to the others in the meeting, in great detail, what the issue is, going into how the system works and the interactions between parts of it. In such cases, my best advice is to try to avoid starting a technical discussion. Come to an agreement that a decision cannot be made until a separate group has the technical discussion, and schedule another meeting if necessary.

When multiple engineers are attending the meeting, it is inevitable for technical discussions to appear as the meeting progresses. As long as the discussion is quick and focused, the benefit might outweigh the possible confusion of the other attendees. But, when the discussion deepens or goes off track, it is the time to step back. Schedule a new meeting to figure out the needed details and make sure to keep everyone in the loop with the results.

In my opinion, everyone should be thinking about each other department as “niche”. Similarly to how some engineers do not want to be distracted by the details of how others are doing their job, the others will appreciate if engineers avoid using complicated technical language around them.

2. Understand the scope of the meeting

The main takeaway here is: avoid opening topics that are irrelevant to the main topic — the scope of the meeting

In meetings, discussions bring up sub-topics that arise from the main topic — or the scope of the meeting. Most of them are focused, valuable topics, but some of them end up being irrelevant, unfocused and distract everyone from the initial scope.

It is very tempting to start such a topic as an engineer, as most conclusions of a discussion will eventually become engineering tasks. It is important, though, to understand that some technical discussions can be delayed. Try to create yourself a mindset based on this, where, when there is an occasion to start a discussion, think twice how relevant it is to the conversation and if this is the place it needs to happen.

As an example — demo meetings always give context for plenty of discussions about the product. As an engineer, it is important to pay attention to what is being discussed and not intervene unless you are asked to, or if you consider that the information you want to share is key to the topic. A demo meeting’s scope is to see the progress on the product and receive feedback or suggestions, not figure out technical details about approaches that can be taken to solve an issue.

3. Put everyone into context

The main takeaway here is: paint the whole picture before, to enable clear, focused, conversation. The extra 2–3 minutes to formulate the context always pays off.

A common thing I see in meetings is that, sometimes, people start presenting topics without sketching the business context in which the topic applies. This is a huge mistake and it can be decisive to whether people choose to be engaged with you or not.

The structure I follow when I start talking about a subject is:

1. Put the participants into the business context (eg. present a very specific situation in which the topic applies)
2. Present how is it relevant to the current topic, if it might not appear related at first sight
3. Summarize the current behavior of said feature
4. Present your suggestion(s) on how to fix or improve the behavior
5. Ask for opinions about your suggestion(s) and other participants' input

If you follow the list above, you should be able to help the participants understand the topic better and have enough information to engage with you.

4. Use a practical example

The main takeaway here is: Start from concrete and move towards the abstract, not the other way around.

When the subject of a discussion requires heavy cognition, a great thing to do to simplify it is to swap it with a concrete example, preferably one about which you have a good understanding to give as many details about.

This approach will enable you to start the conversation from a clear situation and reach some conclusions based on it. Later on, you can extend the conclusions to the abstract case, which will be easier to understand.

5. Jump in and help if you can

The main takeaway here is: don't be afraid to jump in and help your colleagues. It is better to intervine than to let the conversation go off track.

When you are in a meeting and you see that the conversation is going off track, it is very tempting to stay silent and let the conversation continue. But, if you can help, do not be afraid to jump in. Most of your colleagues will appreciate it, and your help puts the conversation back on track.

In some situations, you can help by rephrasing the question or answer, so that it is much easier to understand. In other situations, you might be able to provide a concrete example that will help the conversation move forward.

6. Simplify your ideas

The main takeaway here is: when people are confused, simplify your ideas and use analogies in your discourse

There are times when it is extremely difficult to make the participants fully understand what you are trying to communicate to them.

The easiest way of simplifying an idea — in my opinion — is to create analogies with other features or situations. Using a structure similar to “it is like …, but …” can help you put the discussion back on track, as it gives the others a familiar place to start from.

7. Repeat the conclusion

The main takeaway here is: repeat the conclusion when a conversation topic is over, to have everyone aligned

When one is reached, it is important to repeat the conclusion, formulating it in the easiest way possible. This will help everyone understand what the outcome of the discussion was and what the next steps are.

In most cases, the conversation will continue after the meeting, and a simplified conclusion is always a good starting point.

Thank you for reading, and I hope that these tips will help you at least as much as they do in my day-to-day work. Please reach out if you have any questions or feedback!