The Three Modes of Communication: Expressing, Explaining, and Presenting

Published December 8th, 2025

When you study computer science in college, you typically focus on learning hard technical skills to apply to your first job after graduation. But once you start working as a professional software engineer, you soon notice that coding does not make up 100% of your time. A plethora of soft skills are just as important as hard technical skills, and in this post I'll cover the one I think has been most important in my career: communication.

Communication is the foundation of many other skills, and good communication is like good code readability. You may be a genius, coding unimaginary complex things - but if you can't write readable code - you're going to have a hard time working with other engineers. And spoiler alert: you will have to work with other people.

I identified three scenarios where it's important to have good communication skills to work more smoothly with others. Usually I feel something shifting in my brain when it comes to communicating in these moments, so I felt like exploring each scenario in depth.

I find myself either:

  • ❤️ Expressing something emotional
  • 🧠 Explaining something logical
  • 🎤 Presenting something important

"Expressing" is the most interpersonal, "explaining" is the most technical, "presenting" is the most performative.

These three modes require similar subskills, but to differing degrees. They all have underlying common denominators such as clarity of speech, and awareness of your audience. But you'll need some subskills more than others in each scenario. The purpose of each mode determines the degree to which a subskill is needed.

❤️ Expressing

When you're expressing something, your communication relies heavily on emotional intelligence. It's about communicating your emotions constructively while remaining professional, as well as being able to understand another's point of view and the feelings tied to it.

Expressing yourself well is especially important in situations involving conflict. The constructiveness of communication in the workplace is determined by how much closer to a goal a conversation is moving towards. You're talking for a reason, the outcome of the discussion should be resolution.

Listen

The smartest thing you can do when there's conflict is to listen. You'll never be able to form an appropriate response until you've understood everyone's position. A good tip is to purposefully remain silent, leaving space for others to express themselves. To do this you'll need to get comfortable with awkward silent pauses.

If you're one of the more senior engineers in a meeting, waiting to speak before sharing your opinion also prevents you from influencing others. You don't need to hear someone else restating your own opinion. Practice listening in these cases.

Listening can help you guide others to their own points. Sometimes people will say things and then forget what they said, even in the same conversation. If you listen well you can remind them of previous points they made to guide them towards their original thought, or find contradicting points of view to help them think better.

Be sure to acknowledge feelings. No one needs to share how they feel, if someone builds up the courage to share something, acknowledge it. Sometimes just validating a feeling can be 90% of the work needed to move forward. You want to work with the other person, not against them. Make it clear that you're both working together to resolve the issue.

Never attack

In cases where someone's performance comes into question, avoid criticizing. Otherwise you create a dynamic where the other needs to defend themselves from your criticism. The conversation will go nowhere because your comments will prevent you from receiving a truthful response. Instead, the other person will react to your criticism by thinking of ways to defend their position, not answer your question.

Avoid this with careful wording.

Don't ask: "why haven't you reviewed my pull request yet?".
Try: "is there anything I can do to make it easier for you to review my pull requests faster?"

Don't be reactive

Ask yourself if what you're saying is what you really wanted to say, or if it's just a reaction to what you just heard, bringing you further away from your point.

This is the other side of "Never attack". If you're on the other end, consider that the criticism may simply have been poor wording. Try and identify what answer the other person is looking for, instead of automatically going on the defensive.

Disagree and commit

Your goal is to move forward, consider disagreeing but accepting the outcome. If you need to deliver a feature and your performance improvement isn't a blocker to shipping that feature, save it for a future iteration. Then support the agreed upon solution as if it was what you originally wanted.

🧠 Explaining

When you're explaining, you're often on the spot (no time to draft a response), and you need to be as clear as possible and adapt what you say to the listener. You're relying less on emotional intelligence and more on critical thinking. Usually you'll feel some pressure here because this is mentally straining, your knowledge will be tested and you might even be shocked to discover that you don't actually know as much as you thought. The skill here is taking all the information you know, condensing the relevant parts, and delivering everything in order along with the right context. But you don't want to showcase your knowledge, your mission is to help others think clearly.

Acknowledge Your Knowledge Gaps

If you don't know something, just say so. Avoid causing confusion by pretending you know something or hiding the fact that you don't. You can always get back to someone after you do more digging, or point them to someone else that can better help them.

Why

Common pitfalls when explaining are: taking knowledge for granted, explaining an unrelated topic, or simply rambling. When communicating with someone that doesn't have your same technical background, a trick is to keep asking yourself "why". This helps keep yourself aware of any knowledge you're taking for granted and brings focus on what you're saying.

Ask Questions

To give a good explanation, you can actually let the other person talk. Ask them if what you said made sense to them, or pause to give them space for clarifying questions. This live feedback process should actually click for software engineers. Our jobs require iteration by nature. Picture your listener as your client and iterate on your explanation. Unlike when expressing or presenting, you're actually invited to repeat yourself when explaining - as long as you're trying to improve on your explanation.

🎤 Presenting

When you're presenting something, you're dealing with the art of entertainment. Consider it a performance. At the very least, try keeping people engaged without letting them fall asleep. Unlike when you're explaining, when presenting, you're in a situation where you've had a chance to prepare yourself beforehand.

The Basics

The effectiveness of your verbal communication can be boiled down to 4 variables:

  1. Pace: the speed you're talking at. Change your pace according to the importance of what you're saying. Slow down when you need to make a point.
  2. Tone: the pitch of your voice. Avoid being monotone and use inflections to highlight key words.
  3. Word choice: avoid saying “uh” all the time. Be comfortable with pauses. Those pauses will give everyone's ears a break and build up to what you're going to say next.
  4. Word clarity: enunciate as best you can. This just takes practice, more for some than others, and that's perfectly fine.

Questions

The order in which you present things is everything. Structure your presentation so as to encourage your audience to ask themselves the right questions, then answer those questions in your presentation.

I had a computer science professor in college that gave great lectures. One day I asked myself what made him so good at lecturing, and then I noticed that his lectures made you ask questions that would soon be answered by the presentation itself. In almost every class someone would raise their hand, ask a relevant question, and my professor would grin and reply “the answer is on the next slide” (and it really was).

Giving

Approach your presentation with a giving mentality.

Don't think: “I'm in the spotlight and this is my moment, I'm going to take it”.
Think: “this is a moment for my audience, what can I give them?".

This helps you focus on the value you're bringing and on your audience, instead of yourself.

Conclusion

I divided communication into three modes: expressing, explaining, and presenting. But real life scenarios don't always have a one-to-one relation with each mode. That's why the best communication actually lies at the intersection of the three modes. You can go even further if you take the interpersonal, technical, and performative aspect of each mode and mix them with one another.