Empathy, the foundation of strong engineering teams

I had an engineer once who was consistently late on deliverables. Not by a lot, a day here, two days there, but it was steady. The easy read was that they weren’t managing their time well. The real story, which I only found out in a one-on-one several weeks later, was that their mother was ill and they were handling a lot outside of work. They hadn’t said anything because they didn’t think it was appropriate to bring it up.

That’s what lack of empathy in a team environment costs: someone struggling alone for weeks because they didn’t feel safe asking for a lighter sprint.

Empathy isn’t soft. It’s information. When you understand what someone is actually dealing with, you make better decisions about how to work with them.

What empathy actually changes

The abstract case for empathy (“teams collaborate better when people feel understood”) is fine but not very actionable. The concrete case is more interesting.

A developer who understands that a PM’s shifting priorities aren’t arbitrary will have a different conversation during sprint planning than one who sees it as someone moving the goalposts. A QA engineer who understands the pressure developers face when a deadline is close will write more useful bug reports, not just technically accurate ones. A developer who understands what a user experience problem actually costs a user will make different decisions when they’re implementing something that has ambiguous spec.

These aren’t big emotional moments. They’re small adjustments in perspective that change the quality of hundreds of daily interactions. Over time they compound into a team that operates with lower friction.

Where managers make the most difference

The places where a manager’s empathy has the highest leverage are usually one-on-ones and moments of failure.

In one-on-ones, the instinct when someone raises a problem is to immediately go to solutions. “Okay, so what if we do X?” That instinct is often wrong. People frequently need to be heard before they’re ready to hear suggestions. The question I’ve trained myself to ask first is “what’s making this hard?” not “how do we fix this?” The answer to the first question is usually more useful than anything you’d say in response to the second.

In moments of failure, a missed deadline, a bug that reached production, a feature that landed badly, how a manager responds defines what the team thinks is safe to bring forward. If the first question is “why did this happen?” with an accusatory tone, people learn to minimize failures. If the first question is “what do we know and what do we need to figure out?”, people learn to surface problems early.

Leading by vulnerability matters here too. When I tell my team about a decision I made that turned out to be wrong, or a time I misjudged a situation, I’m giving them permission to be human. That’s not weakness. That’s the fastest way to build the kind of trust where people tell you things before they become crises.

Empathy across the functions

The teams I’ve seen struggle the most with cross-functional work are usually ones where engineers have a low opinion of product management or design, and vice versa. The friction is mutual and often becomes self-reinforcing: engineers feel like product doesn’t understand technical constraints, product feels like engineering blocks everything with complexity.

The way through it is perspective-taking, which is just empathy by another name. When engineering managers take time to understand the pressure a PM is under from leadership, they negotiate differently. When developers spend a day in customer support listening to real user problems, their attitude toward “trivial” bug fixes tends to shift.

Customer support escalations are a good example. Engineers sometimes see them as noise. But each escalation is a user who hit a problem severe enough to contact the company, which usually means dozens more hit the same problem and didn’t. When engineers see them that way, the response changes.

The teams that do this well don’t make it a policy. They make it a habit: regular cross-functional touchpoints, engineers in user research sessions occasionally, designers in sprint reviews, product in architecture discussions. The exposure builds the empathy, not the other way around.