Quarterly earnings pressure is the silent killer of empathy initiatives in tech. A well-intentioned empathy workshop in Q1 often vanishes by Q2, replaced by sprint velocity goals. Yet a handful of Bay Area engineering leaders have built empathy practices that survive reorgs, budget cuts, and product pivots. This guide distills what they do differently — and what the rest of us can borrow.
Where Empathy Practices Show Up in Real Engineering Work
Empathy in a tech context isn't about being nice during stand-ups. It's a structured practice that changes how teams make product decisions, handle incidents, and design for edge cases. The most durable empathy practices we've seen are embedded into three concrete workflows.
Product Specification Reviews
One pattern that repeatedly surfaces is a mandatory empathy review during spec sign-off. Before a feature moves to engineering, someone on the team reads the spec from the perspective of a user with low digital literacy, a user with a disability, or a user in a low-bandwidth region. This isn't a rubber stamp — it's a checklist that blocks the feature unless accessibility and inclusivity criteria are met. Teams that do this find that empathy becomes a design constraint, not an afterthought.
Incident Postmortems
Another durable practice is the blameless postmortem with an empathy component. Instead of asking “who caused this outage,” teams ask “which user segment was most impacted and how can we prevent that harm next time?” This shifts the focus from finger-pointing to user protection. One composite team we studied added a mandatory section in every postmortem titled “User Impact Narrative,” where engineers describe the outage from the end user's perspective. That simple addition reduced repeat incidents by roughly a third over two quarters.
On-Call Rotation Handoffs
Empathy also shows up in on-call handoffs. Rather than just passing a pager, teams now include a brief “emotional state check” — acknowledging that the outgoing person may be exhausted or anxious. This small ritual prevents burnout and makes the handoff more human. It's a low-effort practice that costs nothing but has high retention value.
Foundational Misunderstandings That Derail Empathy Work
Before we look at what works, we need to clear up what empathy practices are not. The biggest mistake teams make is treating empathy as a personality trait rather than a skill. That leads to hiring for “empathic people” instead of building empathic systems. Here are three common misconceptions.
Empathy Is Not a Training Event
Many companies run a two-hour empathy workshop and call it done. But empathy atrophies without reinforcement. A one-off session creates a temporary awareness spike that fades within weeks. Durable empathy practices are woven into recurring rituals — like the spec review or postmortem mentioned above — not isolated calendar events.
Empathy Is Not Agreement
Another confusion is equating empathy with consensus. Empathy in a engineering context means understanding another person's perspective, not necessarily agreeing with it. A product manager can empathize with an engineer's frustration about scope creep while still holding the deadline. The practice is about acknowledging the emotion, not caving to it. Teams that conflate empathy with softness often drop the practice when conflict arises.
Empathy Is Not Just for Customer-Facing Roles
Empathy practices are often siloed to support or design teams. But backend engineers, data scientists, and infrastructure teams also need empathy — for the users affected by their API changes, for the colleagues who will maintain their code, and for the junior engineers who inherit their systems. The most durable practices are cross-functional, not limited to product roles.
Patterns That Usually Work
Based on patterns observed across multiple Bay Area tech organizations, three approaches consistently produce empathy practices that outlast quarterly churn.
Embedded Rituals Over Standalone Events
The most successful pattern is embedding empathy into existing meetings rather than creating new ones. For example, adding a five-minute “user check-in” at the start of sprint planning. Each person shares one observation about user behavior they noticed in the past two weeks. This takes no extra budget and doesn't require a facilitator. It becomes part of the rhythm. Teams that do this report that user-centric thinking increases noticeably after six weeks.
Metrics That Track Empathy Outcomes
What gets measured gets done. But empathy metrics are tricky. The durable approach is to track proxy outcomes rather than empathy itself. For instance, measuring the percentage of features that include accessibility testing before launch, or tracking the number of user-reported issues that get a personal follow-up within 48 hours. These are concrete behaviors that reflect empathy without trying to quantify a feeling.
Leadership Modeling
Empathy practices fail when leaders delegate them. In teams where practices survive, the VP of Engineering or CTO visibly participates in empathy rituals — they attend postmortems, they ask about user impact in all-hands, they admit mistakes publicly. This signals that empathy is not a junior task but a leadership competency. One engineering director we heard about starts every one-on-one with “How are you, really?” and waits for an honest answer. That simple act sets a tone that ripples through the org.
Anti-Patterns and Why Teams Revert
Even well-intentioned teams fall back into old habits. Understanding why helps us design practices that resist regression.
Blaming Empathy for Velocity Drops
The most common anti-pattern is treating empathy as a trade-off against speed. When a sprint slips, empathy practices are the first to be cut. But the teams that sustain empathy treat it as a quality investment, not a cost. They track how empathy practices actually reduce rework and escalation. For example, a spec empathy review might catch an accessibility gap early, saving weeks of remediation later. Leaders who frame empathy as a velocity enabler — not a drag — keep it funded.
Rewarding Hero Culture
Another anti-pattern is celebrating engineers who work all night to fix a crisis, while ignoring the systemic failures that caused the crisis. This hero culture undermines empathy because it rewards individual sacrifice over team well-being. Durable empathy practices explicitly call out systemic issues in postmortems and reward engineers who prevent fires, not just those who fight them.
Empathy Theater
Some teams go through the motions — they hold empathy workshops, send Slack surveys about well-being, but nothing changes. This is empathy theater: performative actions without structural follow-through. The fix is to tie every empathy activity to a concrete outcome. If you run a workshop, require each attendee to commit to one behavior change and report back in two weeks. If no one follows up, the practice is theater.
Maintenance, Drift, and Long-Term Costs
Empathy practices are not set-and-forget. They require ongoing maintenance, and they drift if not tended. Here's what that looks like.
Drift During Reorgs
When teams reorganize, empathy rituals often get lost because the new group has no shared history. The antidote is to document the empathy practice as a lightweight playbook — one page that describes the ritual, its purpose, and who participates. New team members can read it and adopt it within a week. Without documentation, the practice dies with the original champion.
Cost of Sustained Attention
Empathy practices have a cognitive cost. They require leaders to hold space for emotions, which can be draining. Teams that sustain empathy build in recovery time — for example, rotating facilitation of empathy rituals so no single person bears the load. They also explicitly acknowledge that empathy work is real work and count it in capacity planning.
When Empathy Becomes Weaponized
A rare but serious long-term cost is when empathy is used to justify overwork. A manager might say, “I know you're tired, but the team needs you to finish this feature for the user.” That's empathy as guilt trip. Durable practices include a boundary: empathy is about understanding needs, not exploiting them. Teams that succeed have a clear norm that expressing empathy never obligates someone to sacrifice their well-being.
When Not to Use This Approach
Empathy practices are not a universal cure. There are situations where they can backfire or waste energy.
During Active Crisis or Safety Incidents
If a team is dealing with a security breach, a legal threat, or a physical safety issue, empathy practices should pause. The priority is containment and clear procedure, not emotional processing. Trying to run an empathy workshop during a crisis can feel dismissive or performative. Wait until the immediate threat is resolved, then use empathy practices to address the human impact.
In Toxically Positive Cultures
Some organizations have a culture that punishes negative emotions — they expect everyone to be “on” and optimistic. Introducing empathy practices into such a culture can backfire because empathy requires acknowledging pain and frustration. If the leadership isn't ready to hear hard truths, empathy training becomes another tool for surface-level positivity. In those environments, it's better to first build psychological safety before layering on empathy rituals.
When There Is No Leadership Buy-In
If the VP or CTO is openly skeptical of empathy, any practice you build will be undermined. It's better to invest in one-on-one conversations with leadership to build understanding than to roll out a program that will be killed in the next quarter. Without executive modeling, empathy practices are fragile.
Open Questions and FAQ
We frequently hear the same questions from engineering leaders trying to build durable empathy practices. Here are honest answers.
How do you measure empathy without making it weird?
Don't try to measure empathy directly. Measure behaviors that correlate with empathy: frequency of user research sessions, time spent in spec reviews, number of blameless postmortems. Those are concrete and non-intrusive.
What if the team is remote and distributed across time zones?
Empathy practices actually work well in remote settings if they are asynchronous. For example, a shared doc where team members post user observations before stand-up. The key is to make participation easy and visible. Avoid synchronous empathy rituals that penalize people in far time zones.
How do you handle a manager who says empathy is “weakness”?
This is a values conflict. We suggest framing empathy as a risk management tool: it helps you catch user issues early, reduce churn, and retain talent. Use business language if that's what they respect. If they still refuse, it may be a sign that the organization isn't ready for empathy practices, and you may need to build coalitions elsewhere before confronting the resistance.
Can empathy practices scale to hundreds of engineers?
Yes, but they need to be lightweight and delegated. Train team leads to facilitate empathy rituals rather than relying on a central team. Provide templates and playbooks. Scale through repetition, not through a single program office.
Summary and Next Experiments
Empathy practices that outlast quarterly earnings share three traits: they are embedded into existing workflows, they are measured by proxy behaviors, and they are modeled by leadership. They avoid the traps of one-off training, empathy theater, and hero culture.
Here are three experiments you can start this week:
- Add a user check-in to your next sprint planning. Spend five minutes asking each person to share one user observation. Do it for three sprints, then assess whether it changes how your team prioritizes.
- Document one empathy ritual. Write a one-page playbook for your current practice (postmortem template, spec review checklist, or on-call handoff). Share it with the team and ask for feedback.
- Audit your last postmortem. Did it include a user impact narrative? If not, add one to the template. Commit to including it in the next three postmortems.
Empathy is not a soft skill. It's a design constraint, a risk mitigator, and a retention tool. When treated as a practice — not a personality trait — it can survive the pressure of quarterly earnings. The difference between a practice that fades and one that lasts is not budget or headcount. It's whether the practice is built into the rhythms of how work gets done.
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!