Engineering Empathy

What is empathy

Empathy is the function of understanding another person’s mental state and emotional state. Think about taking on another person’s perspective on a scenario from a first person standpoint. In a first person standpoint, you’re in the other’s head: you’re looking out into the world from another’s perspective as you would from your own. Sounds basic, right?

The hard part

The hard part of empathy isn’t the part about entertaining mental states or emotional states that belong to other people; we do this all day long. In fact, the basic capacity to know another person’s mental or emotional state is literally a cognitive developmental milestone. A child typically develops the ability to distinguish their own mental state from another’s around the age of four. The hard part of empathy lies in the role that understanding plays in relation to another person’s mental and emotional states.

I can know how to manage a DNS server, but without a fundamental understanding of DNS I cannot reliably scale it to enterprise resiliency nor could I maintain compliance. Knowing DNS is a very different beast than understanding DNS. I’ll spare you a spiel on epistemic taxonomy. Suffice to say, that the hard part about empathy isn’t knowing that exasperated Alice can’t log into her account for unknown reasons. The hard part about empathy is understanding that exasperated Alice can’t log into her account and that this is blocking her from doing her work. Incidentally, Alice is gunning for a promotion but with the recent disruptions to her workflow she’s losing confidence which compounds her exasperation for a reliable collaboration tool system.

But why is understanding Alice hard?

First, we simply may not care in which case understanding is not so much hard but simply not a priority. Maybe I am merely a maintainer of the status quo which dictates that I just get my job done. I can scrape by supporting Alice, without understanding her thoughts and feelings: all I need to know is the problem and the remediation pathway forward.

Second, we may not know (or know to ask about) Alice’s mental and emotional states. In this case, I don’t really understand Alice’s frustration and experience because I don’t know her motivations, desires, and context. Perhaps I have not taken the time to understand these weighting-values, or perhaps I don’t know that I should take the time to learn about Alice’s weighting-values. In this case, it’s hard for me to understand Alice because I don’t know what drives her: what is she trying to achieve and why? Digging for this level of insight enables reverse engineering a sense of empathy.

Lastly, we may be psychologically blocked in understanding Alice’s mental and emotional states. This is the biggest challenge to practicing empathy. It’s not that we don’t know that Alice is going through something negative. It’s not that we don’t know the weight of the experience for her. Rather, there’s something about Alice’s experience that predisposes me to not get her. Typically, empathy-blockage may take either of two forms but has the same root cause—threat perception. First, Alice’s mental or emotional states are in direct conflict with my own and these internal states are significantly weighted for all involved. The conflict has negative valence and eradicates my motivation to understand Alice from her perspective, emotional or cognitive. Second, I might be the cause of Alice’s mental or emotional states. If my action or inaction directly correlate to Alice’s busted state of affairs, I may feel threatened by Alice’s experience. Threat perception activates the limbic “fight or flight” system, causing physiological response then cognitive appraisal. This cascading affect blocks higher-cognitive practices like empathy.

Engineering organizational empathy

For organizations, empathy should be an engineerable practice, that is, empathy should be a practice that can be designed, built, and deployed within teams, projects, and at enterprise scale. Engineering empathy is about three key notions. (1) Empathy is a skill (not an innate feature), (2) empathy is a way of knowing (not a path to altruism), and (3) we can expect to fail at empathy and we can expect empathy to fail us. Understanding Alice’s context, motivations, desires are data points that identify her weighting-values (aka, value-determining criteria).
Since empathy is a skill, it is something that we can increase and improve upon over time. If there are instances of threat perception, me and my team can openly recognize this and practice empathizing with our user persona. Understanding that Alice is gunning for a promotion and that unreliable access to tooling jeopardizes this aspiration requires us to mirror her experience with one of our own like-kind experiences. I understand where Alice is coming from; I get her. In mirroring Alice’s weighting-values (viz., context, motivation, desire), we understand more fully what drives value for Alice. Alice’s weighting-values delimit the deliverable solution space.

Since empathy is a way of knowing (not a path to altruism), my team and I can reduce our cognitive load by setting aside discussions or worries of good or bad, right or wrong. We can get better at knowing and understanding Alice, and in doing so we trend faster toward a better deliverable solution space. We can be empathetic without having to lay claims to altruism.

We can expect to fail at empathy, and we can expect empathy to fail us: the consistent exercise of attempting to understand another’s emotional states and mental states is the secret sauce. Consistently engineering empathy with your users across your entire organization is the key: yes, I’ve experienced the similar login frustrations, or, no I don’t understand what you’re trying to accomplish can you tell me more, or, no I’ve never had to do that job so please tell me more are indicative of the right organizational empathy-trends.