There is a joke that engineers are not people persons. That they prefer systems over conversations, data over feelings, and a good spreadsheet over a difficult meeting.
It is a funny stereotype. It is also completely wrong.
I have been working with engineers for years, and here is what I actually see: engineers notice everything. They pick up on the eye roll across the table. They feel when something is off in a project before they can explain why. They know when a meeting is going in circles and nobody is saying what they actually mean.
The problem is not that engineers lack emotional intelligence. The problem is that nobody taught them what to do with it.
That is what this conversation with Saskia Slotboom is about. Saskia is a coach and trainer for professionals in STEM fields, working with engineers on communication, leadership, and what she calls the human side of technical work. And one of the first things she said that stuck with me was this: emotional intelligence is not a soft extra. It is part of the puzzle of making projects work.
If your team has the best technical plan in the room but cannot get people on board, the energy leaks somewhere. And that somewhere is usually the part nobody wants to talk about.
Let us talk about it.

Engineers are already paying attention — they just do not act on it
You already notice more than you think.
When someone gives a one-word answer in a meeting, you notice. When a colleague goes quiet after a decision is made, you notice. When something feels off about a project, not wrong on paper, but wrong somehow, you notice that too.
Saskia calls this the raw material of emotional intelligence. And engineers, she argues, have plenty of it.
The gap is not in the noticing. It is in knowing what to do next.
Part of that comes down to habit. If you grew up in a culture or a workplace where feelings were not discussed, where the unwritten rule was to push through and get on with it, then you learned to notice things and file them away. Not act on them. Not name them out loud. Definitely not bring them up in a project meeting.
Those signals you are picking up are information. Useful, project-relevant information.
Saskia gave a practical starting point that I think engineers will actually use. After a meeting, take two minutes and ask yourself: what did I notice? Not what was decided, not what is on the action list. What did I actually observe? The body language, the tone, the moment someone pushed back harder than the situation seemed to call for.
You do not have to act on everything you notice. But if you never look at the data, you cannot use it. Just start looking at the data.
Why most team problems happen below the surface
Saskia uses a model I had not heard before, but immediately drew on a piece of paper while we were talking. She calls it CPR. Not the emergency kind, though the name fits, because it can save a project.
CPR stands for Content, Process, and Relationship. Think of an iceberg.
Content is the part above water. The plan, the product, the technical problem you are trying to solve. This is where most engineering teams spend most of their time. It is also where most meetings stay, even when the real issue is somewhere else entirely.
Process is around the waterline. How the meeting is structured, who has which role, what you are actually trying to decide today. More visible than feelings, but still easy to skip. And when people skip it, you get situations where one person thinks you are brainstorming and another thinks you are taking a final decision. Same meeting, completely different expectations.
Relationship is underwater. The history between people. The emotions that a topic brings up. The trust, or lack of it, that determines whether someone will actually say what they think.
Most teams never go there. But when you are stuck, when the same content-level argument keeps going in circles and nobody is moving, the real problem is almost always on the process or relationship level. You are just not looking in the right place.
You really do not have to turn every project meeting into a therapy session. But knowing the model means you can at least ask the right question when things stall: are we actually disagreeing about the content, or is something else going on?
What this looks like in international teams
Add a language barrier to all of the above, and everything gets a little harder.
In a team where everyone shares a native language and a cultural background, you at least have a common set of assumptions.
- You know what it means when someone goes quiet.
- You know whether direct feedback is normal or rude.
- You know if "that is interesting" means "I agree" (Germany) or "I absolutely do not agree, but I am too polite to say so" (England).
In an international team, those codes are different for everyone at the table.
Saskia made a point that stayed with me: we all make assumptions, all day long. That is not a problem. It is how human brains work. The problem is when we mistake our assumptions for facts, especially across cultural lines.
She moved from Amsterdam to Den Bosch, one hour south in the same country, and noticed the communication codes were already different. Now multiply that by five nationalities in one project meeting, all speaking English as a second, third, or fourth language, and you have a lot of room for things to get lost.
The practical fix is not complicated, but it does require slowing down. It means checking your assumptions out loud. Saying things like: "I understood this to mean we are going ahead. Is that right?" Or after a meeting: "Last time we discussed this, I walked away thinking Y. Did you get the same?"
It feels like extra work. It is actually the opposite. Every clarifying question you ask now is a misunderstanding you do not have to untangle later. In the short term it costs time. In the long term you save it.
One more thing that helps: building a real relationship with the people you work with. Not endless coffee chats. Just enough to know the person a little. Enough that asking a question does not feel like an accusation, and enough that they feel comfortable pushing back if they did not understand you.
Trust, it turns out, is not soft. It is infrastructure.

This article is based on episode 22 of the English for Engineers podcast.
Three things you can start doing this week
None of this requires a personality transplant. Here are three practical starting points.
Notice, then reflect. After your next meeting, take two minutes before you open your laptop. Ask yourself what you actually observed, not what was decided. Who went quiet? Who pushed back harder than the situation seemed to need? Where did the energy in the room change? You do not have to do anything with it immediately. Just start looking at the data.
Check your assumptions out loud. Pick one assumption per week and make it explicit. "I understood this to mean we are going ahead. Is that right?" It takes ten seconds and it saves hours. Once you start doing it, you will notice how many people around you are relieved that someone finally asked.
Go one level deeper when things stall. Next time a meeting goes in circles, try shifting the question. Instead of repeating the content argument, ask: "Are we clear on what we are actually trying to decide today?" That is the process level. If that does not shift things, try: "I want to double-check we are talking about the same thing. How are you feeling about where this is going?" That is the relationship level. You really do not have to go there every time. But knowing it exists means you have somewhere to go when the usual approach is not working.
These are small moves. But in international teams, across cultural codes and language gaps, small moves compound quickly.
What you can do next
If this is the part of engineering work nobody taught you at university, you are not alone. Most engineers I work with are already picking up on these signals. They just never had a framework for what to do with them.
What I do is help engineers, native and non-native English speakers, navigate exactly this: the language and communication pitfalls that show up in international teams. If you want to find out whether that is relevant for your situation, book a free 15-minute call. No pitch, no pressure.
Book your free 15-minute call.
Not sure soft skills are even something you need to work on? Read this first.
Frequently Asked Questions
Emotional intelligence for engineers is the ability to notice and use human signals, body language, tone, silence, tension, as useful information in technical work. It is not about becoming more emotional. It is about recognising that people are part of every project, and that understanding them makes your work more effective.
Yes. Engineers notice a lot: the eye roll across the table, the colleague who goes quiet after a decision, the meeting that feels like it is going in circles. The gap is usually not in the noticing. It is in knowing what to do with what you observe.
CPR stands for Content, Process, and Relationship. Content is the technical problem you are solving. Process is how the team is working together: roles, decisions, meeting structure. Relationship is the trust and history between people. Most team problems that feel like content disagreements are actually process or relationship issues in disguise.
In international teams, people bring different cultural codes, different communication styles, and different assumptions about what is normal at work. Emotional intelligence helps you slow down, check your assumptions, and ask the right questions before a small misunderstanding becomes a big problem.
Yes. It is not a personality trait you either have or do not have. It is a set of skills: noticing, reflecting, asking questions, slowing down, that you can practise. And as an engineer, you already have the curiosity and the analytical mindset that makes learning them easier than you might think.
Yes, that is actually the core of what I do. I work with engineers specifically on the English they need for international technical work: meetings, emails, presentations, stakeholder conversations. If your soft skills are already strong, we skip straight to the language. Book a free 15-minute call and we will figure out exactly where to start.
Book your free 15-minute call: https://marcode.org/contact
Original article published on 24 July 2025, last edited on 29 June 2026



0 Comments