Empathy in Engineering as an Engineering Leader

I have been making products for a long time. I think it started with this WP Plugin when I needed a simple event management system for my college fest.

Then a client of mine needed a basic form for their website. After delivering it, I realized that I could also sell a more advanced version on Envato. That is how my journey as a product creator started, and I have been making products ever since.

It’s been around 15 years since then. Today, I am not just a product creator but part of a broader product team. I get to brainstorm and ideate, and also implement or help my team implement those ideas. I listen to active users of the product and learn about use cases and scenarios we never thought of. Sometimes, those use cases become the most interesting features of the product.

Today, I want to reflect on my journey and talk about the most important thing I have learned along the way: empathy. I think it is one of the most important qualities an engineering leader can have, and it can make or break both the product and the team.

Empathy in Engineering

We all know what empathy is: the ability to understand and share the feelings of another. Let’s see how it materializes in product and engineering.

It is day one, and you launch your product. You are excited to see the first few people using it.

But then comes the feedback, sometimes brutal and harsh.

I think, as product makers, our reflex is to immediately dismiss the naysayers. Those of us who learn to manage this reflex are often able to create better, more popular products.

Let’s boil it down.

Empathizing with the Customers

I think this is the most important skill a product maker can have. Yes, I know: you’ve spent countless hours, blood, and sweat creating the product.

But at the end of the day, this product is not just for you. It is also for your customers. You may want a particular experience, but it may not be what your customers want.

If you see enough feedback and reviews, then it is time to rethink and rebuild.

We need to make our customers’ lives as easy as possible. We are not just selling a product; we are selling a solution—one that should help customers get the best outcome with the least effort.

It is easy to think, “We are supposed to do X, not X+1. Customers can build the rest on their own.” But this is where we need to stay open-minded and empathetic. If enough customers are asking for something that does not seem to fit within the product’s core value, perhaps it is time to reconsider where that boundary should be.

Empathizing with the Team

In my experience, many great ideas and use cases also come from within the team. Think about it. Your team is building and supporting the product. Often, they are talking with customers and seeing the UX firsthand.

As the engineering leader, you can’t have your eyes and ears everywhere. That’s why you delegate.

But like delegation, empathy also needs to extend towards your team. Listen to them, actively ask for feedback, ask what they think is best, and act on it.

When you do that, you will see that they care not only about the product but also about how effectively they can deliver it.

Actionable Behavior & Workflows

I don’t want you to just read this and say, “Yeah, that’s all theoretical. I will keep it in mind.” I want you to think about how you can put this into practice in your behavior and workflows.

Exactly how you do it will depend on the type of work you’re doing. I can only give you some examples from my own experience.

Always Look into Support

This is the greatest (and also the noisiest) source of feedback. You need to filter out the real issues and use cases.

In my experience, even if you have a great team and engineers are doing support, they can still miss obvious platform improvements that could come from it. It is understandable. I think if you start doing support yourself, you will also miss many things. We tend to solve the problems in front of us and then move on instead of looking at the bigger picture. It happens even more when there are a lot of tickets and you’re pressed for time.

This is where you, the engineering leader, come in. Make it a habit to:

Go through the support tickets.
Talk regularly (maybe once a week or once a month) with the support team and ask if something stood out to them.
See if there are obvious wins you can get from a pattern of tickets.

Do this often enough, and you will start seeing patterns and use cases that you never thought of. Even 1% of negative feedback can turn into a 10% improvement in your product. That is the power of empathy.

And how do we cut through the noise of so many support tickets? Use your team and your judgment 😉.

Talk to the Customers

Sometimes you will find similar product makers who are also your customers. Talk to them. Ask them what they like and what they don’t like. Ask them what they think is missing.

Conversations with your high-value customers often lead to the most interesting use cases and features.

Document What the Product Can Do

Empathy also means not making customers spend time exploring the product just to find out whether something is supported. Well-written documentation—even something short, like a changelog entry—can go a long way. It helps customers find an answer without relying on trial and error.

This has a cascading effect in the age of AI. A customer may ask an AI assistant, which then searches the web for an answer. If it can find clear and accurate documentation, it is more likely to give the customer a useful response. Good documentation now helps both the customers reading it and the systems answering questions on their behalf.

Write Code Along with your Team

We are engineers at the end of the day. We love to code and build. This is what keeps us going.

As the engineering leader, you may not be able to code as much as you want. But I think it is important to get your hands dirty every once in a while.

But what if your time is limited? I have a solution for that: code reviews.

Often, I don’t just leave review feedback. I also make small changes and improvements myself.

If the feature is in active development and the review is for the architecture and design, I find myself exploring hands-on and creating a few POCs before giving my feedback.

I think this does two things:

You stay close to the codebase and the product. You understand estimation and risk better.
You show your team that you are not just a manager, but also a fellow engineer who is willing to get his hands dirty and help them out.

For better or worse, I think this is a great way to empathize with the code.

Talk and Sync with the Team

I don’t just mean the usual Slack messages, end-of-day updates, or progress reports. Discuss the task and its ins and outs with your team. Ask what they think of a feature and whether they are enjoying (or hating) it. Ask what they think our engineering process lacks and what could make us happier and more productive.

Many internal tooling and process improvements have come from these discussions. And I think this is a great way to empathize with your team and their work. I believe happy shipping is better than fast shipping.

This is also the process I enjoy the most, too much, to be honest. I can give you a few concrete examples:

We had some e2e tests written in an outdated framework with a limited license. Only one team member had the skill to work on them, and they didn’t like doing it. The framework was also slowing us down when writing new tests, so many team members were just documenting the e2e tests in an Asana task and doing it manually. We sat down and discussed the problem, and it took us only a little time to come up with a migration plan. This was before the time of AI. We spent around one engineer-sprint migrating the tests, but in the end, our shipping speed increased and the risk went down—a lot.
Another example greatly improved our public-facing documentation. We were using an outdated documentation platform. It was slow, and none of the engineers liked it. We would write documentation only when we were forced to. Many documentation ideas came up, but they were shelved because either we didn’t want to touch the platform or it didn’t support the way we wanted to write. We took on a bigger ambition and decided to migrate. Two months later, our shiny new platform was live. A year later, everyone on the engineering team had contributed to the documentation in one way or another. We are happy, the business is happy, and most importantly, our customers (and LLMs) are happy.

Empathize with Yourself

Finally, I think it is very important to empathize with yourself. We need to know our limits and recognize when we are stressed and running out of ideas.

As engineering leaders, our teams look to us as the fail-safe. We are the ones expected to have the answers.

But that doesn’t mean we have to pretend when we don’t have them. I find a straightforward approach works best. Discuss the problem with your team, brainstorm ideas, and trust that you will find a solution together.

I hope this article helps you in your journey as an engineering leader. I would love to hear your thoughts and feedback. Please feel free to reach out to me on Twitter or LinkedIn.