“You can’t say the word ‘empathy’ at a software company. No one will take you seriously.”
Andrea Goulet couldn’t believe what she had heard. The advice came from a well-intentioned consultant she had hired as she was growing her team at Corgibytes, back in 2009. She had wanted to incorporate empathy as a core value, but was confronted with the industry-wide misconception that empathy and technical skills were irreconcileable.
Fast forward a decade, and it seems that attitudes have shifted. “We’ve come a long way from when people treated empathy as a dirty word. I’ve actually given a few keynotes on the topic now, and engineers are increasingly interested in what I have to say,” says Goulet.
But in her eyes, the conversation is just getting started — and still falling short. “It’s great that we’re in this moment of celebrating empathy and talking about how important it is at work. But we have to be careful that it doesn’t get too abstracted or contained to a surface-level discussion,” she says. “What I’m seeing is that, more often than not, the conversation stops at ‘Be more empathetic!’ We need to take it a step forward and recognize empathy as a skill that can be learned and applied."
For those who believe empathy falls into the nebulous realm of the touchy-feely, that takeaway might seem counterintuitive. But given her background, Goulet is uniquely equipped to draw the connection. She began her career as a copywriter, a role that depends on understanding and fostering a connection with readers. When she pivoted to engineering and founded Corgibytes out of a dedication to building technical wealth by remodeling technical debt, she was surprised to find striking similarities between the seemingly disparate skills of copywriting and writing code.
“Coding and copywriting are more similar than you’d think. There’s a misconception that the programming languages we use are only written for machines,” she says. “But we don’t write code in ones and zeroes, right? We write code in compiled languages so that other humans can read it, whether that’s our team or our future selves. Coding is a form of communication. Communication is rooted in empathy. So software engineers have a lot to gain from leveraging empathy as a tactical skill.”
Today, the co-founder and CEO is proud to say that she did, in fact, concretize empathy as a core value at Corgibytes. Now, armed with her insights from implementing empathy at her own company, she’s determined to change the way that the tech industry talks about this critical skill.
In this exclusive interview, Goulet busts the three myths that are preventing engineers from honing their empathetic expertise. She explains why leaving communication artifacts in your code is an exercise in empathy, and she introduces Empathy-Driven Development, a highly procedural framework for embedding this critical skill into engineering teams. Whether you’re just setting off on the road of empathy or looking to take your practice to the next level, Goulet offers a mix of beginner’s tips and advanced strategies. Ultimately, she challenges entrepreneurs to see empathy not as an abstraction or an innate talent, but as a powerful, actionable tool that belongs in every engineer’s toolbox.
FIRST, DISPEL THESE EMPATHY MYTHS
While the consensus may be emerging that empathy is important, Goulet fears the conversation around this critical skill in the engineering world is leading us astray. “If people don’t have a firm, technical understanding of empathy, it’s easier to dismiss it,” she says. “They might make assumptions about what it means, which ends up reinforcing stereotypes about it, or even taking us backward.”
Here, Goulet dismantles three common myths around empathy to help founders and technical leads understand and develop empathy on their teams.
Myth #1: Empathy is just a feeling.
The software industry’s long-held reluctance to embrace empathy is rooted in a fundamental misunderstanding of what, exactly, empathy is. “Most people believe that empathy is just a feeling,” she says. “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.
“Indi writes that empathy is a noun — it’s the thing you’ve acquired after you’ve listened to someone and truly understood their point of view. She 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.”
Drawing inspiration from Young’s scholarship, as well as the research of Dr. Brené Brown, Goulet developed a working definition of cognitive empathy geared toward engineers: “Empathy is proactive perspective-taking and problem-solving.”
Goulet’s crisp definition enables engineers to dive into implementation and set aside their fears about not being equipped for the task. “If you’re in software, you’re likely an excellent problem-solver. You’ve already won half the battle,” she says. “And once you understand cognitive empathy, it’s the key to understanding the rich world of the other subtypes.”
Myth #2: Empathy is irrelevant to building software.
When most people think about the skills needed to be an effective engineer, empathy is probably not the first that comes to mind. “We need to deal with false misconceptions about engineers and professional skills,” says Goulet. “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.”
While leaning into empathy has proven useful for building diverse and inclusive teams and earning designers a seat at the table, Goulet contends that empathy is an increasingly necessary skill for engineers.
“With commit messages, pull requests, naming, tests, error messages, those are all fundamentally about communicating with empathy,” she says. “If there’s anything that working with legacy code has taught me, it’s that code isn’t written in a vacuum; it’s reviewed and revisited constantly. Your future reader could be a colleague. It could be yourself, six months later,” 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. “And once that gets entrenched, the code base is much harder to remodel. 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.”
Sure, engineers are excellent problem solvers. But I think what gets overlooked is that engineers are also, inherently, communicators. Coding is all about delivering messages to people, as well as machines.
Furthermore, Goulet argues that empathy can help engineers avoid another future problem: baking bias directly into the software they build. “We’re past the point of pretending that code written by humans is immune to human prejudice,” she says, pointing to high-profile incidents where facial recognition algorithms demonstrated racial bias, or when machine learning software reproduced biases against women.
“Diversity and inclusion isn’t just about team composition. D&I is a critical ingredient to building better products that work for everyone — something that all engineers should strive to do,” says Goulet. “Training developers in a deeper understanding of empathy is a crucial first step toward that end goal.”
Myth #3: Empathy can’t be taught.
“People find it easy to say, ‘Learn how to code, and here are the steps you can take.’ But 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. “It’s hard to apply a growth mindset to a trait you think is inherent and fixed. But with a practical breakdown of what empathy is, how to apply it, and how to cultivate it, there’s a path forward,” she says.
“While we of course need to be sensitive and accommodating of individuals who might struggle to express empathy, I think we need to challenge the field of engineering to do better,” says Goulet. “We need to dispense with the incredibly damaging and limiting stereotype of the ‘socially inept engineer.’ It signals that just because someone happens to be good with machines that they don’t need to or aren’t capable of working on other skills that are essential to company and product building. The truth is, you have the capacity to be all of those things.”
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.
Andrea Goulet, CEO of Corgibytes
THE STARTER KIT FOR EMBEDDING EMPATHY INTO YOUR ENGINEERING PRACTICE
Like learning a programming language or training for a sport, building empathy should be part of an ongoing practice. Goulet shares three guiding principles you can lean on as you start to sharpen your aptitude for empathy:
1. Swap blame for honor.
Engineers are probably familiar with this scenario: You revisit old code that’s totally inscrutable, with no rationale to be found. Cue the flare-up of frustration. “The usual reaction is, My god, who was the idiot who decided to do it like this? Blame is literally baked into our tooling,” says Goulet. “If you want to see a history of changes to the code, the default command is ‘git blame’ on the command line. That small cognitive priming conditions developers to look down on the contributions of the people who came before them.”
But shaming the original developer wastes precious time and energy. “We need to move beyond blame and shame. They’re unproductive, and the opposite of empathy,” says Goulet. “Instead, when you approach code, honor the work of the people who came before you. Think Okay, I assume that people did their best work. Why did they choose this solution? That’s when you’ll get far more illuminating answers.”
Goulet suggests thinking about constraints to help you have more empathy for past developers. “No one wakes up in the morning and decides to write the worst code possible. That just doesn’t make sense,” she says. “People are up against real world constraints that impact code quality — time, budget, technical limitations and unrealistic expectations. Follow the constraints and you’ll uncover the deeper reason that the codebase isn’t up to your expectations.”
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.
When it comes to constructing empathetic coding practices, Goulet encourages engineers to envision old code bases as archeological sites.
“When archeologists study an ancient site, they don’t have the whole story about what life was like at the time. They have to look for artifacts: pottery, coins, sometimes writing,” she says. “Similarly, if you leave communication artifacts in your code now, it makes interpreting your code much easier for future developers.”
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, 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. When I try to think of what I can do to be helpful, I’m exercising empathy for those who will come after me,” she says. “Ultimately, that empathy creates trust between myself, team members and future readers, because it’s almost like we’re all looking out for each other.”
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: Merge requests and other similar invitations to review code before it goes into production are ideal places for engineers to practice leaving communication artifacts. “Remember that the conversation you have isn’t just for your code reviewer,” says Goulet. “Think bigger. You’re preserving rationale for your future self. For a developer who is going to have to interact with that piece of code when they’re fixing a bug. For a customer success manager. Take on their perspectives for a second: What will be useful to them? What will help give them context?”
- In your commit messages: “Commit messages are the absolute best form of documentation because they’re tightly coupled to a code base,” she says. “People often forget that a commit is made up of two components: The title and the message. As my friend, Dave Bock says, the title should be the length of a short tweet, and the description should be the length of a blog post, if necessary.”
- In your emails and company messaging system: “Whenever you interact with someone else, there’s an opportunity to leave a communication artifact,” says Goulet. “That might be a short email or Slack message that informs, asks a question, or solicits feedback. Instead of just dropping a link without context or saying, “here’s the thing I did” add some context that shows that you have listened and are open to feedback. A simple sentence such as ‘Here’s what I came up with based on my understanding. What’s your perspective?’ goes a long way to building trust and collaboration.”
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. Many feel pressure to “decorate” their language with extravagant jargon or intricate syntax in a professional setting. Resist that urge. “The most effective language is clear, concise, and natural,” says Goulet. “Good writing is simple writing.”
- Never underestimate the power of the second person active voice. “This is one of the most important pieces of advice I got as a copywriter,” she says. A quick grammar refresher: In second person, the writer directly addresses the reader, using “you.” The active voice makes clear that the reader is carrying out the action. “Second person active voice is the difference between the passive ‘A bug has been detected’ and the active, more empathetic ‘Sorry, you’re experiencing a bug,’” says Goulet.
- Don’t make assumptions. “Don’t assume that everyone who is reading your writing knows everything about what you’re writing about,” says Goulet. “If you’re writing about an esoteric concept, take a bit of time to explain it. If you’re using an acronym, spell out each word the first time it’s used. That way, your writing is more accessible to readers who have different skills and strengths from yourself.”
To help her keep empathy at the center of her practice, Goulet leans on advice she received from her one of her mentors, Sam Horn, early in her copywriting career. “Sam is a brilliant communicator who taught me so much about empathy and ideation,” Goulet says. “She always told me, ‘A short pencil is better than a long memory.’ As you’re working, instead of ignoring the ideas that come up, write them down. Then, find ways to turn your ideas into action by leveraging and sharing the communication artifacts you’re already creating as you go about your daily work.”
All too often, empathetic ideas about how to improve upon a process, or how to clean up code for the next person, get lost in the crush of day-to-day demands. Keeping a running idea log while you’re working minimizes context switching while building the habit of creating artifacts of your ideas. “Over time, the link between idea generation and where to share will become more intuitive as you spot patterns and learn what works best,” says Goulet.
To help get your idea log up and running, leverage the tooling you’re already using so there’s the least amount of friction and context switching to document an idea. “If you’re comfortable on the command line, a quick search for ‘command line journal’ will give you a plethora of tools you can try,” she says. “Alternatively, Git-based wikis such as GitHub’s wiki and GitBook allow developers to keep a log of ideas and notes using a text editor and Git client.”
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.”
The Empathy-Driven Development framework
To illustrate Empathy-Driven Development at work, Goulet gives an example of a problem you might encounter as a developer at a small startup: “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. Odds are, your audience includes a diversity of users,” says Goulet. “In this example, your audience might include a user who’s a freelance artist, a customer success manager at your company and your future self.”
- Consider context. “Once you’ve identified the individuals, think about where they came from, and where they are now,” says Goulet. “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. Finally, consider each individual’s challenges and 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? What will your future self need?”
- What’s the best action to take? “So you’ve gathered valuable information on your audience. Use that new understanding to think about what can be done to help,” she says. “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. Even the smallest actions add up,” says Goulet.
- 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.” She suggests looking at the communication artifacts chart above for inspiration and even creating a quadrant for your project to generate even more ideas. “There are so many places where natural language exists in a software system. It’s not about burdensome documentation. It’s about doing what you’re already doing with more intention.”
Example of Empathy-Driven Development in action
Over time, and with enough practice, these steps start to become intuitive. Goulet recognizes that the process often feels slow and burdensome at first, but encourages developers to keep at it. “Like TDD, Empathy-Driven Development will feel slow at first. In the moment, it’s easy to think that leaving a communication artifact is unimportant, or that you don’t have time. But many artifacts take an extra thirty seconds, a few minutes at most, to complete a thought for a future reader. The marginal gains you achieve by regularly leaving communication artifacts end up far outweighing the short-term time investment,” says Goulet.
“It’s like that checklist you go through when you’re first learning to drive,” she says. “Once you get enough experience driving, checking all the mirrors becomes second-nature. The same goes for Empathy-Driven Development. Once you get into the habit, it becomes a healthy instinct.”
On the other hand, the effect of negligence compounds, as a lack of communication artifacts can constitute an unpleasant inheritance for future readers. “That’s what honestly makes software so much harder to maintain, because then future developers have to go back and reinvent the wheel,” Goulet says. “You already worked on developing your rationale. Now just take a moment to document it before you move on.”
Exercising empathy doesn’t add much time to your existing workflow and the benefits are far-reaching: A clear commit message today saves everyone time and frustration further down the road.
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. “Everyone has a Wiki page that anyone on the team can see, and we keep running notes and reflections throughout the day,” she says. “Everyone has their own flavor of how they like to keep track of these micro-decisions. Some use bullet lists, others use sentences — whatever works best for each individual writer.”
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. I see this all the time on my team. Someone will ask for help and a teammate will give a link and say ‘I had the same thing a few months ago. Here’s my journal. Start at March 7th.’ It’s not a big investment of time to create a journal entry, but the outcomes have been transformative.”
Turn everyone into a customer service representative.
Goulet believes that the fastest route to learn empathy as a skill is through customer service, when you truly have to understand and anticipate the needs of the people using your software. “I was really inspired by Zappos’s culture,” says Goulet, citing the book Delivering Happiness by Zappos CEO Tony Hseih. “The value of customer support is instilled into everyone in the company — and I mean lawyers, developers, everyone.”
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. This is a big part of the Lean Startup movement — to get out and listen to what your customers want. Don’t relegate that to one person or department. Bring everyone into the fold.”
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.
For larger companies, Goulet suggests taking a company-wide empathy training, such as Brené Brown’s program Dare To Lead. “I had a few engineers who went into Dr. Brown’s training feeling skeptical,” she says. “But after the training, the skeptics were often the ones who expressed to me that those trainings really were worth it. Because we made space to have vulnerable conversations, I truly believe my entire team is more trusting and delivers better work as a result of that experience.”
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. “They’re designed to help you get out of the dangerous habit of making assumptions about what another person wants, and instead use qualitative data to inform your decision-making.”
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.
“To get started, grab a copy of Indi’s book or take her training that gives detailed instructions on how to conduct a listening session. Then, have a colleague, friend or partner interview you. This will help you build empathy for what it’s like to be interviewed,” Goulet says. “As you get more comfortable, branch out and interview people with different job titles, or people who have knowledge about a problem you’re trying to solve.”
Approach your subject with a deep well of respect. “Time is the most precious thing that someone can give you. If someone decides to lend you their time, appreciate it,” she says.
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. “The goal is about earning the speaker’s trust and getting to their emotions and reasonings that underlie the superficial.”
Developers can use listening sessions to enhance their engineering practice. “Let’s say you’re a developer working with artificial intelligence. You read an industry report that algorithms are often subject to human bias which can lead to tremendous negative impacts for some groups of people. Empathy can help you take ownership of this problem,” she says.
“Instead of writing it off as someone else’s responsibility and doing nothing, do some proactive perspective-taking. Get curious. Listen. Be open-minded. Then, armed with qualitative data, you can take action and put your problem-solving superpowers to good use," she says. "That might be stopping to consider whether you’re training your deep-learning algorithm on a truly representative data sample, or raising a concern to your product owner addressing an accessibility problem with a new feature.”
TAKEAWAYS AND TRUST FISSION: HOW EMPATHY FITS INTO THE FUTURE OF COMPANIES
While tech has made strides in embracing empathy as a value, Goulet challenges startups to take the next step of treating it like a technical skill.
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.
A culture of trust fission paves a pathway for team members to exercise more agency and become leaders. “Because we took the time to build trust through empathy, my team is constantly ahead of the curve and anticipating my own moves. I’ll propose an idea, and someone on my team will say, ‘You’re absolutely right. I already thought about that. Here’s the progress we’ve made,’” 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?’”