“And it definitely involves feelings. However, that conceptualization of empathy is really limiting.”
In her quest to build a case for empathy, Goulet stumbled upon Indi Young’s Practical Empathy, in which the author, a researcher who started her career as a programmer, delineates not one, but six types of empathy. “That sub-categorization really struck me. I thought if something could be divided into six subsets, then it must be pretty dense and technical,” says Goulet.
…also dives deep on one of those subtypes called cognitive empathy, which is a rational process that’s used to uncover another person’s beliefs, values, preferences, and points of view. This process is already ingrained in the work of marketers, UX researchers, writers, designers, even many front-end engineers,” says Goulet. “My goal was to really study Indi’s work, that’s so well established in the UX community, and then find a way to extend it for people who operate more on the back-end.”
Empathy is not this abstract, metaphysical enigma. It’s a skill we need to respect and a muscle we need to flex.
Myth #2: Empathy is irrelevant to building software.
“For example, I hate the ‘Are you technical or nontechnical?’ question. It’s not binary. You can be technical and know how to be a skilled, empathetic communicator. I would argue that if you want to be an excellent engineer, you should know how to communicate, in addition to knowing how to make a machine work the way you expect it to.”
“With commit messages, pull requests, naming, tests, error messages, those are all fundamentally about communicating with empathy,” she says.…
“If you don’t take the future reader into consideration by clearly communicating your reasoning, you’re creating problematic legacy code,” says Goulet. “Operating without empathy is directly linked to one of the biggest problems that plagues engineering teams. So don’t tell me that it’s not relevant to your day job.”
Coding is all about delivering messages to people, as well as machines.
Myth #3: Empathy can’t be taught.
“…there’s a misconception that empathy is either something you have or don’t have, and that it can’t be developed”, says Goulet.
Acknowledging that empathy is a trainable skill is the first step in improving on it. “…with a practical breakdown of what empathy is, how to apply it, and how to cultivate it, there’s a path forward”, she says.
“We need to dispense with the incredibly damaging and limiting stereotype of the ‘socially inept engineer.’ ”
The technical skills gap may very well be real, but consider the other side of the coin: Most computer science students aren’t developing the communication and empathy skills they need to collaborate and successfully build products that work for everyone.
THE STARTER KIT FOR EMBEDDING EMPATHY INTO YOUR ENGINEERING PRACTICE
Goulet shares three guiding principles you can lean on as you start to sharpen your aptitude for empathy:
1. Swap blame for honor.
You can’t begin to solve problems, much less modernize an entire code base, without empathy. Analyzing problems through another engineer’s perspective is hard, sophisticated work that’s rooted in understanding why someone made the choices they did.
2. Consider your project like an archeological dig.
While she’s long argued that communication artifacts give you an operational advantage when you’re “re-architecting legacy code and pulling out from a mound of technical debt” (excerpts linked at the beginning of this blog post), Goulet has since realized that the act of producing them is also, at its core, an exercise in empathy.
“Yes, if I leave communication artifacts behind, that’ll save the next person time. But these breadcrumbs of my thinking also serve a dual purpose that’s deeply rooted in empathy. It really goes back to that definition of empathy, that proactive perspective-taking and problem-solving.
Many software luminaries have invoked the old Scouting rule by saying, “Leave the code better than you found it.” When you practice empathy, you’re supercharging that motto.
She identifies three touchpoints where engineers can leave communication artifacts that make an impact on code, and leave a legacy of trust.
In your code review
In your commit message
In your emails and company messaging system
3. Think like a copywriter.
Given that writing is perhaps the most frequent vehicle for delivering empathy in the workplace, engineers can benefit from a few lessons from the copywriting world. “Writers need to hone empathy early on, because they’re writing to connect with an audience,” says Goulet. Whether you’re crafting commit messages or an email, Goulet offers her best writing tips for engineers:
Keep your tone casual and conversational
Never underestimate the power of the second person active voice
Don’t make assumptions
ELEVATE YOUR EMPATHY: AN ADVANCED FRAMEWORK FOR EMPATHY-DRIVEN DEVELOPMENT
For those engineers who love a good framework, Goulet breaks down a procedural model of cognitive empathy, creating an algorithm of sorts that teams can integrate into their workflow. She calls it Empathy-Driven Development.
“Test-Driven Development can be described as red, green, refactor. Likewise, Empathy-Driven Development can be distilled into audience and action,” says Goulet. “First, consider your audience, the people who are going to be interacting with your content, which includes your code and the communication artifacts you leave behind. Then, take action. Think about how you can proactively anticipate their needs.”
“Let’s say you’re tasked with writing an error message for a bookkeeping app. How might you leverage empathy in this situation?” In this scenario, you’re leaving a primary communication artifact (the error message) for your audience.
First, consider the audience:
Identify individuals. “List out the individuals you anticipate encountering your work product, in addition to the end user.
Consider context. “The artist uses the app on his phone; the customer success manager is responding to a support ticket under pressure; your future self is reading your own code while fixing a bug, six months later.”
Define their needs. “Pain points aren’t always evident. Ask questions, read articles — do all that you can to find out about them,” she says. “What does the person using the app and the time-strapped customer success manager need from you? …
Then, take action:
What’s the best action to take? “So you’ve gathered valuable information on your audience. … “You want to validate the user’s frustration with the error message. For the customer success manager, you want to make an easy reference code in the error message. For your future self, you might want to fix all the bugs right now.”
What’s feasible? “You won’t always be in a position to do the best thing to help, so consider what you actually can do. What do you have the time and resources to execute, to make their lives a little better? There’s almost always something you can do. Think tiny and atomic.
Create secondary artifacts. “Once you’ve created your primary communication artifact — a great, clear error message — your job isn’t over. Include secondary artifacts into your definition of done,” Goulet says. “Secondary artifacts are durable evidence of your ideas, rationale, and constraints that have come up while you’ve been working on the primary artifact, and can take many forms.”
EXPANDING EMPATHY BEYOND CODE
Your codebase isn’t the only thing that benefits from a dollop of empathy — engineering teams and entire companies do as well. From team practices to cultural paradigm shifts, Goulet shares her advanced practices for elevating empathy IRL.
Let your team read your diary.
Leaving communication artifacts in your code isn’t the only way you can exercise empathy on a software team. In addition to a #shoutouts channel on Slack, Goulet’s team adopted the practice of keeping daily journals. …
As with communication artifacts in code, the time spent on daily journals ends up returning on their investment. “It usually takes less than 15 minutes at the end of the day to type up,” says Goulet. “I’ve had colleagues tell me that they were able to save so much time, because they were able to refer back to their thinking six months ago, or share with a colleague who is running into a challenge you’ve already encountered.…”
Turn everyone into a customer service representative.
Early-stage startups are in a particularly advantageous position to begin to integrate an empathetic, user-centric ethos. “Early on in a startup’s lifespan is the perfect time to start to bake empathy into your culture. You can establish norms that everyone can adopt as your company grows: We’re going to value feedback from users. We’re going to constantly ask questions to understand them. …”
Empathy and seeking to understand the customer are skills that are commonly associated with user-facing roles. But when empathy is part of the mission and culture from devs to designers, it truly sets the company apart.
Lend an empathetic ear.
To take proactive perspective-taking a step further, Goulet suggests hosting listening sessions, another concept borrowed from Indi Young’s work. “Unlike casual conversations, listening sessions are explicitly tied to the goal of understanding another person’s reasoning, reactions and guiding principles,” Goulet says.
If you’re a back-end engineer writing a function, it’s easy to abstract people out of your work. The more you seek to understand others, the easier it will be to consider their points of view while you’re coding.
Once the listening session has begun, leave your judgments at the door. “Remember that you’re there to collect data, not change minds. Just listen without shame, expectation or criticism,” says Goulet.
Final notes
For engineers looking to flex the muscle of empathy, start by dismantling long-held myths. Invest the time to create communication artifacts that will light the way for future readers of your code. Use Empathy-Driven Development to proactively understand your audience, then address their needs. Finally, uplevel your work by sharing journals with your team and building your own awareness of the broader ecosystem where your product operates.
Once teams and companies treat empathy as a skill and a habit, they can begin to experience a snowball effect of incredible cultural and technical gains. Goulet refers to this effect as trust fission: the compounding, accelerating, exponentially proliferating benefits that come from a team operating in harmony.
“People always say that the most important thing is to create and accelerate trust on our teams. Well, trust is the output of empathy. Empathy is what we can optimize for when we’re trying to generate a culture of trust,” says Goulet.
… “That’s the end goal with empathy: Cultivating a culture where everyone proactively asks, ‘Is there something that I can do to make this just a little bit better for the next person who comes along?’”
