There is a particular kind of silence that falls over a team channel right after a production outage. The dashboards are red, someone’s fingers are shaking slightly over the keyboard, and everyone is waiting to see how the lead reacts. Not what they say about the database connection pool or the failed deploy — that will come. What everyone is really waiting for, without quite admitting it to themselves, is whether they are about to be treated like a person who made a mistake, or a person who is a mistake.

That split second contains more about technical leadership than most books on the subject. Because the truth is, almost nobody becomes a technical leader by studying leadership. They become one by writing good code, solving hard problems, and being trusted, slowly, with more of the picture. And then one day they are in a room — or a Slack thread — responsible not for a service, but for a person. For several people. For how those people feel on a Tuesday morning when the sprint is not going well.

This piece is about the skill nobody puts on the roadmap: empathy. Not as a soft, decorative virtue that sits next to “communication” on a performance review template, but as an actual working capability — one that changes incident response times, code review culture, retention, and the quiet, unglamorous health of a team that has to keep shipping things together for years.

Empathy gets used loosely, so it is worth being precise about it before going further, the way you would define a term before building on top of it in a spec.

Psychologists usually split empathy into two related but distinct things. Cognitive empathy is the ability to understand what someone else is thinking or experiencing — to accurately model their perspective, almost like building a mental simulation of their state. Affective empathy is feeling some resonance of what they feel — a kind of emotional echo. A good technical leader needs both, in different doses at different times.

Cognitive empathy is what lets you read a terse, one-line Slack message from a normally chatty engineer and correctly infer that something is wrong, before they have said a word about it. Affective empathy is what stops you from responding to that message with a purely transactional “noted, ETA?” when what the moment actually calls for is “hey, you okay? take the time you need.”

2.1 What empathy is not

Empathy is not the same as agreement. Understanding why an engineer is frustrated about a deprecated API does not mean you have to reverse the deprecation. It is also not the same as being conflict-avoidant, or softening every piece of feedback until it is unusable, or letting standards slip because someone is having a hard week. Those are common misreadings of empathy, and they cause real damage — both to the team’s output and, ironically, to the very people the leader thinks they are protecting.

2.2 Empathy as diagnostic information

The clearest way to think about it: empathy is diagnostic information. Just as a good engineer would not tune a system’s performance without first understanding its actual bottleneck, a good leader does not manage a person’s growth, motivation, or mistakes without first understanding what is actually happening for them. Skipping that step does not make you more rigorous. It makes you less accurate.

Technical leadership has always required some measure of people-sense, but a few shifts in how software teams work have made empathy less of a bonus trait and more of a load-bearing one.

3.1 Distance has replaced hallway conversations

A decade ago, if an engineer was struggling, you might notice it in the way they walked into the office, or the fact that they skipped lunch, or a dozen tiny physical cues that never make it through a webcam or a status emoji. Remote and hybrid work removed almost all of that ambient signal. What is left is text, timing, and tone — and a leader who is not paying close attention will simply miss the signs entirely, not because they do not care, but because the old channels for noticing are gone. Empathy today has to be actively practiced rather than passively absorbed.

3.2 Systems have gotten more interdependent, and so has the stress of owning them

Modern systems are rarely a single service one person can hold in their head. They are meshes of dependencies, shared infrastructure, and blast radii that can turn a small change into a company-wide incident. That complexity raises the emotional stakes of everyday work. An engineer pushing a change to a shared library is not just writing code; they are carrying a small, constant undercurrent of “what if I break something for everyone.” A leader who understands that weight manages very differently than one who treats every deploy as emotionally neutral.

3.3 The half-life of technical knowledge has shortened

Frameworks, tools, and even entire paradigms shift within a few years. That means technical leaders are managing a near-constant, low-grade anxiety in their teams: the fear of falling behind, of skills quietly going stale, of being asked to learn yet another new system while still shipping the old one. Empathy is what lets a leader notice that anxiety before it turns into either burnout or quiet resignation.

3.4 People stay for how they were treated, not just for what they built

Engineers can point to almost any company and find interesting technical problems. What is rarer, and what actually predicts whether someone stays for years, is whether they felt seen while solving those problems — whether their effort was noticed, their limits respected, and their mistakes handled like data rather than character flaws.

If you want to see a technical leader’s real values, do not read their mission statement — read their pull request comments. Code review is where empathy is tested more often than anywhere else in engineering, because it happens constantly, in writing, often stripped of tone.

Consider two ways of leaving the same comment on a pull request that has a genuine problem — say, an unhandled edge case that could cause a null pointer exception in production.

Both comments identify the same bug. Only one of them will be received as information rather than as a small wound. And here is the part that is easy to miss: the second comment is not slower to write, and it is not less rigorous. It still names the exact problem. It still expects a fix. The only thing that changed is whether the reviewer paused, for about four extra seconds, to imagine the moment the author would read it.

This is cognitive empathy doing very concrete, unglamorous work. It is not about being nice for its own sake — it is about recognizing that a defensive engineer writes worse code, reviews less carefully, and is less likely to ask for help next time, than an engineer who feels safe being wrong in front of their team.

4.1 A small habit that compounds

Some of the most respected reviewers develop a quiet rule for themselves: before submitting a comment that points out a mistake, reread it once as if a stranger had written it about your own code. If it would sting to receive, it probably needs one more pass — not to soften the substance, but to sharpen the delivery.

Nothing reveals a leader’s character faster than an incident. Adrenaline is up, customers might be affected, and there is enormous pressure to find out — quickly — what happened and who touched it last.

The instinct in that moment is often to ask “who did this?” It is an understandable instinct. It is also almost always the wrong first question, because it optimizes for assigning blame instead of restoring service, and it teaches everyone watching that the fastest way to survive a mistake is to hide it, not report it.

Empathetic incident leadership looks almost boringly simple from the outside. It sounds like: “Okay, let’s stabilize first — what do we know so far?” It treats the person closest to the failure as the most valuable source of information in the room, not a suspect. It saves the “how do we prevent this next time” conversation for the postmortem, once things are calm and nobody’s hands are shaking anymore.

And it extends past the incident itself. A leader who checks in privately afterward — not with a lecture, but with something as small as “that was a rough one, how are you doing?” — often does more for that engineer’s long-term confidence than any amount of technical praise. People remember how they were treated on their worst day at work far longer than they remember their best one.

5.1 Blameless postmortems only work if the leader actually means it

Many teams have adopted the language of “blameless” postmortems, but the phrase can become hollow if the leader’s tone in the room does not match it. Empathy is what makes the practice real rather than ceremonial — the difference between a document that says “no blame” and a room that actually feels that way.

Few conversations are more emotionally loaded than the ones about someone’s own performance — whether they are getting the promotion they have been working toward, or being told they are not meeting the bar.

It is tempting to think empathy means making these conversations gentler by making them vaguer. It is the opposite. The kindest, most respectful version of hard feedback is also the clearest one — specific enough that the person actually knows what to do with it, delivered soon enough that they have time to act on it, and framed around behavior rather than identity.

Empathy also shows up in timing. Delivering difficult feedback the week someone is dealing with a family emergency, simply because it is the scheduled review cycle, technically follows the process while ignoring the human being on the other side of it. A good leader holds both the process and the person in mind at once, and occasionally chooses to bend the former slightly in service of the latter.

6.1 Growth conversations are not just about gaps

It is easy for performance conversations to become entirely deficit-focused — a running list of what is missing. Empathetic leaders also pay close attention to what energizes someone, what kind of work makes them lean forward instead of drag their feet, and they factor that into how they shape a role over time. Understanding what makes a person feel alive at work is itself a form of empathy, and it tends to be far more motivating than any gap analysis.

Every new hire arrives with some version of impostor syndrome, no matter how confident their interview performance was. The first few months at a new job are an unusually vulnerable stretch — new codebase, new jargon, new social dynamics, and a private fear that the offer was some kind of mistake.

Empathetic onboarding recognizes that stretch for what it is. It means not assuming someone should already understand internal shorthand or unwritten norms. It means a lead who says, plainly, “there’s no way you’d know this yet, here’s the context,” instead of letting a new engineer quietly struggle in a system built entirely out of institutional memory they do not have access to.

It also shows up in interviewing itself. A candidate who is nervous in an interview is not necessarily a weaker engineer than one who is calm — they may simply be someone who cares a great deal about doing well. An interviewer with strong cognitive empathy can tell the difference between someone who does not know the answer and someone who knows it but is too anxious to access it in the moment, and can adjust — a follow-up question, a moment of reassurance — without lowering the actual bar being assessed.

This is the objection that comes up almost every time empathy is discussed in a technical context, and it deserves a real answer rather than a dismissal: doesn’t all this softness eventually erode standards?

It is a fair worry, because a certain kind of leader really does use “kindness” as an excuse to avoid ever saying something uncomfortable. But that is not empathy — that is conflict avoidance wearing empathy’s clothing. Real empathy is not afraid of hard conversations; it is what makes hard conversations land well instead of landing badly or not landing at all.

8.1 Two dials, not one

Think of it less as a dial between “nice” and “rigorous,” and more as two separate dials that both need turning up at once: how much you understand the other person’s situation, and how honestly you tell them the truth. Low on both dials, you get a manager who is both distant and vague — nobody’s needs are met. High on truth but low on understanding, you get someone who is technically correct but leaves a trail of people who feel unseen. High on understanding but low on truth, you get a manager everyone likes and nobody grows under. The leaders people actually remember fondly, years later, tend to be high on both — the ones who clearly cared about you and told you the truth, even when it was hard to hear.

In practice, this means empathy often makes the tough conversation happen sooner, not later — because a leader who understands someone’s situation well enough to time a conversation right, and frame it in a way that will actually be heard, does not need to keep postponing it out of dread.

Some people do seem to arrive with more natural empathy than others, in the same way some people arrive with a natural ear for music. But like most skills worth having, it can be deliberately built, and it responds to practice far more than most leaders assume.

9.1 Ask before you assume

The single highest-leverage habit is remarkably plain: ask people what is actually going on before deciding what it means. A missed deadline might mean carelessness. It might also mean an engineer quietly juggling a sick parent, or a task that turned out to be three times harder than it looked, or a dependency they were blocked on for a week and did not want to “complain” about. The story a leader invents in the absence of information is almost always less accurate, and less generous, than the real one.

9.2 Listen for the sentence underneath the sentence

“This ticket is fine, I guess” rarely means the ticket is fine. Developing empathy means training an ear for the gap between what is said and what is meant — and then gently checking, rather than assuming: “you sound a little unsure about it — want to talk through it?”

9.3 Sit in the discomfort of not fixing it immediately

Many technical leaders are, by training, fixers. Someone raises a problem, and the instinct is to jump straight to a solution. But sometimes what a person needs first is simply to be heard — to say “that sounds genuinely frustrating” before jumping to “here’s what we should do about it.” Resisting the urge to solve too quickly is its own skill, and it is one that engineers, ironically, often find hardest to build.

9.4 Remember specifics, not just names

Empathy compounds through memory. A leader who remembers that someone mentioned a difficult exam their kid had this week, and asks about it three days later, builds trust at a rate that no formal recognition program can match. It signals, concretely, that the person was actually heard — not just processed.

9.5 Get feedback on your own blind spots

Most leaders believe they are more empathetic than their reports would say they are — not out of arrogance, but because it is genuinely hard to see your own tone from the outside. Regularly and directly asking a trusted peer or report, “is there anything about how I communicate that lands harder than I intend?” is uncomfortable, and one of the fastest ways to actually improve.

9.6 Protect your own capacity for it

Empathy draws on a finite reserve. A leader running on no sleep, back-to-back meetings, and unresolved stress of their own will have measurably less patience and warmth available, no matter how much they value those things in principle. Part of building empathy for a team is honestly managing your own load so there is something left to give at the end of the day.

A few objections come up so consistently in real conversations about empathy at work that they deserve to be named, and answered, rather than left hanging in the background as unspoken doubts.

10.1 “Empathy will slow us down.”

In the moment, maybe — a thoughtful comment takes a few seconds longer to write than a curt one. Over a quarter, teams led with empathy tend to move faster, not slower, because problems surface earlier, people ask for help sooner, and less energy gets spent managing hurt feelings or hidden resentment.

10.2 “Some people just aren’t wired for this, and that’s fine.”

Natural aptitude varies, but a baseline level of empathy is closer to a floor requirement for leading people than an optional bonus trait — the same way a baseline level of technical judgment is a floor requirement, even for someone who is not the most brilliant engineer on the team.

10.3 “If I show empathy, people will take advantage of it.”

This does happen occasionally, and it is worth naming honestly. But the answer to a small number of people misusing goodwill is to address those specific cases directly — not to withdraw empathy from everyone else as a defensive policy.

10.4 “Empathy means agreeing with everyone’s feelings.”

Understanding why someone feels frustrated is different from concluding their frustration is correct or actionable. You can fully validate that someone feels overlooked for a promotion, while still explaining, honestly, what the actual gap was.

Most conversations about leadership empathy focus on the manager-to-report relationship, and understandably so — it is the most visible, most consequential version of it. But technical leaders spend a surprising amount of their time in a different kind of relationship entirely: sideways, with product managers, designers, support teams, and other functions that do not share their vocabulary or their incentives.

This is where empathy gets harder, because the instinct to understand someone tends to weaken the less that person looks and sounds like you. A product manager asking for “just one more thing” before a deadline can easily be read as someone who does not understand or respect the engineering effort involved. But a technical leader with real cognitive empathy will pause and model the other side of that request too — the product manager is very possibly under their own pressure, answering to their own stakeholders, trying to protect the team from an even worse ask that is coming from somewhere else.

11.1 Support and customer-facing teams deserve the same generosity

Support engineers often absorb the sharpest edge of a system’s failures — the confused, frustrated, sometimes angry messages from real customers — long before an engineering team ever sees a ticket. A technical leader who treats an escalated bug report with mild irritation, as though the support team is being an inconvenience, is missing an enormous amount of context about what that person’s day has actually looked like. Empathy here means remembering that the ticket in front of you represents someone else’s difficult morning, not just an interruption to your sprint.

11.2 Empathy toward people you will never manage

Open-source maintainers, engineers at partner companies, even the anonymous author of a library your team depends on — these are all people too, usually invisible in the day-to-day, easy to treat as faceless infrastructure. A curt, demanding issue filed against an open-source project, written by someone who forgot there is an actual person maintaining it, often for free, in their spare time, is a small but telling failure of the same muscle. Leaders who model empathy consistently, even toward people entirely outside their reporting chain, tend to build teams that treat each other better too — the habit does not stay neatly contained to direct reports.

11.3 Mentoring, without the ego

Mentoring is often framed as a one-directional transfer of knowledge — the senior engineer imparting wisdom to the junior one. Empathetic mentoring looks a little different. It starts by understanding what the other person is actually trying to become, rather than what the mentor assumes they should want, and it stays curious about that even as it shifts over time. Some junior engineers want to become architects; others want to go deep on a narrow specialty and stay there happily for a decade. Neither is a lesser path, and a mentor who quietly nudges everyone toward their own version of success, rather than the mentee’s, is optimizing for the wrong thing entirely.

Across the industry, teams that talk publicly about their engineering culture tend to circle back to a similar idea in different language: that trust and psychological safety are what let engineers report bad news early, admit uncertainty, and ask for help before a small problem becomes a large one.

None of that is possible without a baseline of empathy running through how people actually treat each other day to day — in code review, in incident channels, in 1:1s. The specific practices vary by company and change over time, but the underlying pattern is consistent: teams that feel safe being honest tend to also be the teams that ship the most reliable systems, because honesty and reliability, at the root, depend on the same thing — people telling the truth about what is actually happening.

It is worth noticing that this is not really a story about any single famous leader or company. It shows up, quietly, on ordinary teams everywhere — the manager three cubicles down, or three Slack channels over, who somehow gets more out of people not through pressure, but through being genuinely paid attention to.

It also shows up in the smaller, structural choices an organization makes without necessarily calling them “empathy” at all. A team that builds in slack time after a major release, instead of immediately loading the next sprint, is acting on an understanding that people need recovery time after a period of sustained intensity. A company that lets an engineer step back from on-call for a cycle after a particularly rough incident is making the same kind of quiet, human-shaped decision. None of these choices show up as a line item anywhere. They show up, eventually, as whether people still want to be there in three years.

These are the questions engineers and new leaders quietly hold onto without always feeling comfortable asking out loud. Each one deserves a direct answer.

Is not empathy just a personality trait — either you have it or you do not?

Temperament plays a role, the same way some people find writing or public speaking more naturally comfortable than others. But the specific behaviors that make empathy visible — pausing before reacting, asking a clarifying question, rereading a message from the other side — are learnable habits, not fixed traits, and they improve with deliberate practice like anything else.

How do I stay empathetic when I am the one under pressure?

This is genuinely one of the hardest parts of the job. It often helps to build in a tiny buffer before responding to anything emotionally charged — even thirty seconds — and to be honest with your own manager or peers about your own load, so you are not trying to run on empty while giving to everyone else.

What if my own manager is not empathetic — can I still lead this way?

Yes, and it often matters more in that situation, not less. The way you treat your own team does not have to mirror how you are treated. Many of the most empathetic leaders learned exactly what not to do from a manager who was not.

Can too much empathy become a problem?

It can, if it is not paired with honesty and boundaries — leading to decision paralysis, or absorbing everyone’s stress as your own. The goal is not unlimited softness; it is accurate understanding, applied alongside clear standards.

Does this apply the same way in very senior, architecture-heavy roles?

If anything, it matters more. Senior technical leaders often influence dozens of people indirectly through the decisions and tone they set, even if they no longer manage anyone directly. A dismissive comment from a principal engineer in a design review can shape how junior engineers feel about speaking up for years afterward.

How do I know if I am actually getting better at this, or just telling myself I am?

Look for outside evidence rather than internal confidence. Are people bringing you bad news earlier than they used to? Are quieter voices in meetings speaking up more over time? Is your 1:1 time filled with real conversation rather than status updates that could have been a message? These are slower, noisier signals than a performance metric, but they are the honest ones, and they tend to move in the right direction only when the underlying behavior actually changes.

If there is one idea worth carrying away from this piece, it is that empathy in technical leadership is not softness dressed up as a virtue — it is accurate information about what is really happening for the people you lead, and everything else you do with them is more effective because of it.

The dashboards will eventually go green again after every incident. The architecture will be replaced twice in the next decade. What lingers, and what people carry with them long after they have changed jobs, is the quiet accumulated memory of how they were treated in the small moments — the ninety seconds after the deploy failed, the first line of the review comment, the tone of voice in the room after the postmortem. That is the surface area on which technical leadership actually operates. Empathy is not the decoration on it; it is the material it is made of.