For engineers, one of the most important soft skills is empathy.
The level of empathy within an engineer is usually highlighted when talking to business/product people.
Tech people love going into details and are most effective when everything is crystal clear, with no ambiguity. We are so into details that we obsess and argue about everything: keyboards, chairs, note-taking apps, exceptions vs. errors, design patterns, you name it.
On the other hand, business people live in a world of holistic views and abstract ideas and work with uncertainty every day.
Introspection time
How many times did you accuse the business of not giving you enough details?
How many times did you underestimate a non-tech person just because they made a mistake trying to describe something?
How many times were you accused of not really understanding the idea behind what they were asking, or the intent behind the requests?
This usually happens when we default to our own communication style - going too much into details too quickly.
Most of the time, the regular business people don't care about our detailed and beautifully crafted explanation.
Usually, all they think about is
- "what is the result"
- "how does this affect the end customer"
- "what are the effects/implications for the business".
Keep that in mind and the discussions will go very smoothly next time.
Why empathy?
Everyone ultimately wants the same thing: to make the product succeed, to actually solve problems.
But we need to understand each other's worlds and look at each other as partners. That requires empathy.
For tech professionals, it means recognizing that anything we communicate will not only drive technical progress but also inform critical business decisions, expectations, and outcomes. By refining our communication skills to fit business needs—concise, outcome-oriented, and focused on implications—we contribute more effectively to the entire organization’s goals.
Here’s the thing: empathy in communication builds trust and fills the gap between technical and non-technical team members. Collaboration becomes a powerful tool, not a struggle when everyone feels understood and aligned on the end goal.
Understand the chain of information
Also, we tech people need to realise that anything we communicate to product/business will be used further down (or up?) the line to communicate with their stakeholders.
We are there to contribute to their output as well.
For example, product/business oriented people need that when they:
- do damage control when shit hits the fan for business clients or customers
- need to communicate pushbacks on timelines
- need to communicate what is the current status
- do (technical) sales
Practical example
The clients don't care or understand that
"well, see, we have this Ay-double-you-ess Lambda function that becomes cold every once in a while and we need to warm it up"
You
But they understand that
"we can improve the user experience during peak usage times and for first-time users by optimizing our service.
By doing this would make the experience smoother and help us achieve our engagement and customer satisfaction targets.
We have some promising strategies, but it requires configuration and testing to ensure it’s stable.
Once we address this, users will have a consistently fast experience, even during their first interaction with the app, which will help our growth goals."
Still you
By focusing on the outcome, business implications, and a clear plan*, you can communicate the need and set the expectations without going into details.
*If there is no clear plan, then say that you need time to investigate and give an exact date/timeframe for when you'll come back with the results.
Frustration
Yes, there is a lot of frustration. And it's OK to feel frustrated.
You may be right to shout "WTF are you talking about? Just shut up, they're all idiots". But don't just yet.
Let's be honest, we don't necessarily get to choose who are we working with, especially in outsourcing.
But first let's work on changing ourselves and be the improvement in the company that we work with/for.
If that doesn't work, don't feel bad. I forgot where I saw the quote but it goes something like:
"If you can’t change your company, change your company."
Thank you for reading! If you enjoyed this post and want to explore topics like this, don’t forget to subscribe to the newsletter. You’ll get the latest blog posts delivered directly to your inbox. Follow me on LinkedIn and Twitter/X. Your journey doesn’t have to end here. Subscribe, follow, and let’s take continue the conversation. This is the way!
Found in:
Software development