Why Empathy Is a Technical Skill

It was 2:47 on a Wednesday afternoon, and the air conditioning on the 27th floor was losing its battle with three hundred engineers and a Bangkok sun that doesn’t negotiate. Namfon had her headphones half-on, one ear free — the universal signal for “I’m working but interruptible” — and her screen showed a toast notification component with a placeholder where the error message should be. The ticket had no copy. She was waiting for Product to fill in the blank. She’d been waiting since yesterday morning, and in the silence of that empty text field, something was rotting — not in the code, but in the assumption underneath it. The assumption that someone else is responsible for knowing what the user needs to hear.

As the psychologist Carl Rogers once put it, “When someone really hears you without passing judgment, without trying to take responsibility for you, without trying to mould you, it feels damn good.” Your users aren’t on a therapist’s couch, but they are having an experience with your software — and the engineers who build it get to decide whether that experience feels like being heard or being ignored.

We need to talk about empathy. Not the poster-on-the-wall, corporate-values-page kind. The kind that shows up in your code. The kind that’s visible in a git diff. Because the best engineers I’ve worked with don’t just build things that work — they build things that work for someone, the customer. And that distinction, the gap between “technically correct” and “actually useful,” is where most engineering teams quietly bleed value without ever noticing.

The Blank Toast

Let me finish that story. I was standing at Namfon’s desk, looking at the empty placeholder. I asked her what she thought should go in it. She looked at me like I’d asked her to redesign the company logo. Somchai was sitting next to her, so I turned to him — “Hey Somchai, got a minute, what do you think should go in this error message?” Same expression. Stunned silence.

I let the silence sit. I wasn’t going to hand them the answer. I wanted them to think.

Namfon spoke up first. “I think we should have a different error based on whether we’re sure the data wasn’t updated or not.” That’s a good start, I told her. And then we started to design the message together — not the visual design, the experience design. What does the user need to know? Are they scared their data is lost? Do they need to try again? Should we tell them it’s safe?

When the PO came back, he was surprised. Not just because he liked what they’d come up with — he was happy he didn’t have to do the work himself. The designer had a few minor wording tweaks, but nothing that wasn’t a two-minute fix.

Here’s what actually happened in that moment: two perfectly capable engineers had been sitting on their hands, waiting for permission to think about their users. Not because they lacked the ability, but because the process had trained them to believe that user-facing decisions belonged to someone else.

Error 500: Null Reference Exception (Or: How to Tell Your Users You Don’t Care)

The everyday moments where user empathy is visible — or painfully absent — aren’t in grand architectural decisions. They’re in the smallest details. The ones that seem too trivial to put in a ticket.

An engineer without user empathy writes Error 500: null reference exception. An engineer with it writes Something went wrong saving your booking — your data is safe, and we're looking into it. Same bug. Completely different experience. The empathetic version isn't harder to code. It doesn't take more sprint points. It requires one habit: asking "what will someone feel when they hit this?"

As the legendary basketball coach John Wooden said, “It’s the little details that are vital. Little things make big things happen.” He was talking about free throws and footwork, but he might as well have been talking about error messages and loading states. In software, the “little details” are often the only part of your system the user actually sees.

This extends well beyond error messages. Think about edge cases. Most edge case thinking is technical — what if the database times out? What if the API returns a 429? User empathy adds a different layer entirely. What if someone has a Thai name that’s 40 characters long and your form truncates at 20? What if someone’s on a 3G connection in a rural area and your JavaScript bundle is 4MB? When you’re building at Agoda’s scale — users across dozens of countries, vastly different devices, languages, and connectivity — the engineer who holds that diversity in mind catches problems that testing frameworks miss entirely.

Or take performance. Page load time isn’t just a technical metric. It’s a measure of how much you respect your user’s time. An engineer who empathises with a user on a slow connection in Indonesia approaches optimisation differently than one chasing a Lighthouse score. The motivation shifts from “meet the benchmark” to “don’t make someone wait.” Same work, but the empathetic framing produces more thorough solutions because you’re solving for a person, not a number.

The Abstraction Tax

So if empathy is this obviously useful, why does it atrophy?

Fred Brooks identified part of the answer decades ago. In a small team, the engineer is user support. You see complaints directly. You feel the pain firsthand. You build something, someone uses it, they tell you it’s broken, and that feedback loop is tight enough that empathy stays alive almost automatically.

At scale — a hundred engineers, ten scrum teams, a product organisation with layers of PMs and designers and QA — abstractions build up. Not the useful kind we put in code, but the dangerous kind we put between ourselves and the people using our software. PMs write tickets. Designers create specs. QA tests against acceptance criteria. An engineer can go months without seeing a real user interact with their work.

The distance isn’t malicious. It’s structural. But the result is the same: you stop building for people and start building for tickets. The ticket says “add a toast notification.” It doesn’t say “help someone understand why their action failed and reassure them their data is safe.” One is a task. The other is an experience. And the gap between them is empathy.

The management thinker Peter Drucker captured this perfectly when he said, “The most important thing in communication is hearing what isn’t said.” In software, what isn’t said is usually the user’s emotional state — their confusion, their frustration, their context. No ticket captures that. No acceptance criteria account for it. It lives in the space between the specification and the experience, and only an engineer who’s thinking about the human on the other side will fill that gap.

Contextual Empathy: The Curiosity Multiplier

Here’s something I’ve come to believe strongly: raw empathy isn’t enough. “I should think about my users” is a nice sentiment, but it’s hopelessly vague. What transforms empathy from a platitude into a technical capability is context — and what gets you to context is curiosity.

Take the Agoda extranet — our platform for hotel partners. If you’re working on that product, you know that most of your users are hotel staff working on desktop computers in back offices or at front-desk reception. They’re multitasking between check-ins, dealing with interruptions, and they need to complete tasks quickly because there’s often a guest standing right in front of them.

That knowledge completely changes your engineering decisions. Knowing “desktop, not mobile” isn’t just a responsive design checkbox. It tells you the user probably has a mouse, so hover states are useful. They’re likely on decent WiFi — hotel back-office connectivity — so you can be slightly less aggressive about bundle size. They might have multiple tabs open. They’re probably being interrupted mid-task, so saving state matters. Each of those is a technical decision informed by user context that you only have because someone was curious enough to learn how these people actually work.

I think of it as a progression. Empathy is the mindset — the willingness to consider the user at all. Curiosity is the fuel — it drives you to learn who they are, where they work, what their day looks like. And context is what makes it actionable — it turns “think about the user” into specific engineering decisions that an engineer carries with them every time they open a file.

An engineer who has all three doesn’t need to be told “think about the user.” They already carry a mental model of that hotel receptionist with them when they’re writing code. They don’t need a ticket to tell them the error message should be reassuring. They already know the person reading it is probably stressed.

As the anthropologist Margaret Mead observed, “Always remember that you are absolutely unique. Just like everyone else.” Your users are unique — different countries, different devices, different contexts — and yet they all share the same basic need: software that respects their time, their intelligence, and their situation. Curiosity gets you to the uniqueness. Empathy helps you act on it.

Practical Habits, Not Lectures

I’m not going to stand here and tell you engineers should “care more.” That’s both patronising and useless. What I will say is that empathy is a muscle, and like any muscle, it atrophies without exercise and strengthens with routine.

The exercise isn’t complicated. Engineers sitting in on user research sessions — not to redesign the product, but to see how people actually interact with what they’ve built. Reading support tickets regularly, even just skimming the top ten from the past week. Dogfooding your own product with genuinely fresh eyes, not the “I know where everything is because I built it” version.

At Agoda’s scale, the challenge becomes more specific: what does it look like when an engineer in Bangkok builds something for a hotel owner in rural Japan? You can’t fly there. You probably can’t call them. But you can read their support tickets. You can look at their device analytics and understand the constraints they’re working within. You can talk to the people in your organisation who do interact with those users directly — the partner services teams, the support agents. Every one of those actions is a small investment in contextual empathy, and they compound.

The key is making these habits routine rather than exceptional. A team that reads support tickets once a quarter is checking a box. A team where engineers casually mention something they noticed in a support ticket during sprint planning — that’s a team where empathy has become part of the engineering culture.

The Outcome Argument

If empathy feels too soft for your engineering sensibilities, let me put it in terms we all understand: outcomes.

Teams where engineers hold user empathy produce fewer “technically correct but useless” features. Rework drops because you build the right thing the first time more often. Support ticket volume drops because your error messages actually help people resolve problems instead of generating more confusion. The things you build actually get used — not because they’re feature-rich, but because they fit the way real people actually work.

You’re not asking engineers to become designers. You’re not asking them to run user research or write product specs. You’re asking them to carry the user’s perspective as context while they do engineering work. It’s an additional input, not an additional role.

And here’s the part that might surprise your product team: engineers with user empathy actually reduce the load on PMs and designers. When Namfon and Somchai designed that error message themselves, they didn’t just save the PO time — they made a better decision faster because they understood the technical context (what could go wrong, what the system could confirm) in a way the PO never could. The PO’s job shifted from “write the copy” to “validate the approach,” which is a much better use of everyone’s time.

The Bottom Line

As the author Kurt Vonnegut once wrote in advice to young creators, “Use the time of a total stranger in such a way that he or she will not feel the time was wasted.” He was talking about writing, but he captured something fundamental about any craft that exists for other people. Your code runs for someone. Your UI appears in front of someone. Your error message interrupts someone’s day. The question is whether those moments feel considered or careless.

User empathy isn’t a soft skill bolted onto engineering. It’s a technical capability that shows up in your code — in your error handling, your edge case coverage, your performance decisions, your state management. It’s the difference between Error 500: null reference exception and Something went wrong — your data is safe, and we're looking into it. Same codebase. Same sprint. Completely different product.

Most of the time, engineers are entirely capable of putting themselves in the user’s shoes, especially for the basics. It’s not a question of ability — it’s a question of habit. And the irony is that it tends to be the complexity of harder problems that scares people away from attempting the easy ones. We overthink it. We wait for the ticket. We assume someone else is responsible for knowing what the user needs.

They’re not. You are. You’re the last person who touches the experience before it reaches a human being. That’s not a burden — it’s a superpower, if you choose to use it.

Now, if you’ll excuse me, I need to go check on an error toast message that one of my teams shipped last week. I have a sinking feeling it says Error: BOOKING_UPDATE_FAILED_EXCEPTION. But hey, at least the HTTP status code is technically correct.