Empathy Is an Engineering Discipline

There’s a moment most engineers experience exactly once, if they’re lucky. They sit down to watch someone use their software — really watch them use it. The engineer has one of three reactions. They’re amazed by the new perspective; they’re disquieted by what seemed obvious from the inside; or they start explaining to the user how to adapt to the software. (If you’re in the third camp, come back here after reading “In Service of Whom.”)

That moment is the beginning of empathy as a discipline.

The best engineers think like the people they’re building for. Not just when writing user-facing features, but also when designing APIs, building internal platforms, configuring alerts, selecting tools … Every interface has a user. Every decision either serves that user or doesn’t.

Platform teams are the most common offenders. It’s easy to build tooling optimized for the people who built it — tools that assume familiarity, skip explanation, and reward expertise they already have. The resulting platform is coherent to its authors and opaque to everyone else. The gap between “it works” and “anyone can use it” is where empathy lives.

Practicing empathy as a discipline means two things. First, ask “who is this for?” before every decision — not as a formality, but as a constraint that shapes the work. Second, hold yourself to a standard where your users never have to ask why. Why did this fail? Why does this step exist? Why can’t I just do the obvious thing? Every “why” is a signal that something wasn’t designed with its user in mind.

This is a design requirement, not a soft skill. The engineer who has sat with a confused user, watched a teammate wrestle with a poorly-named config option, or been paged at 2am by an alert that describes the symptom but not the cause — that engineer builds differently. They’ve closed the distance between themselves and the people their work affects.

That distance is worth closing deliberately, before a moment of discomfort forces it.