Empathy-Driven Development Defined

“Wait. You’re telling me that you never had a single lesson on how to communicate effectively or understand the people you’re building products for?”

“That’s right,” Scott replied. “It was an honor code violation to collaborate with anyone. I guess it just wasn’t seen as important.”

This was me circa 2010 talking with my new business partner, Scott, about his experience earning a computer science degree. I’d recently left my career as a copywriter to build Corgibytes and was shocked at how the skills that I’d spent a decade honing — empathy and communication — were completely dismissed as irrelevant by most of the developers I encountered. My skills were considered “soft skills” — nice to haves that were fluffy and nebulous, so they had no place in the analytical realm of software development where “hard skills” like logic and reason reigned supreme.

My instinct, which has crystalized into a core belief in the decade since, was that the lack of empathy and communication in the software industry is one of the most significant causes of its challenges. There is a skills gap. People don’t understand what empathy is and isn’t. We have ingested the cultural tropes that surround us and bought into the idea that empathy is a something you’re born with and that it’s soft and unnecessary if you’re a software developer. When in reality, empathy is a skill that is learned. Without empathy, you get messy codebases that slow development, biased algorithms that inflict harm, frustrated customers, toxic workplace cultures, and more.

These problems are becoming apparent outside of the software spheres as well. In the Netflix documentary, The Social Dilemma, you see “tech experts sounding the alarm on their own creations.” Media such as this puts a much needed spotlight on real problems. But one can’t help but feel deflated and disempowered after learning about how much we got wrong. What’s the solution? How can we address these challenges head on and course correct? Can we teach developers to approach their work through a lens of compassion? How can we work to close the empathy skills gap?

Empathy-Driven Development (EmDD).

Like other practices that guide decisions through emergence, such as Test-Driven Development, Behavior-Driven Development, Example-Driven Development, and Domain-Driven Design, we can design a flexible framework that teaches developers specific and concrete ways to put empathy at the center of their work. At Corgibytes, we decided early on to center our culture on empathy and have consistently experimented with ways to integrate it into our work. Over the past few years, I’ve written and spoken more about these ideas. Now, it’s time to develop a definition of Empathy-Driven Development that enables these ideas to scale.

So, here it goes.

EMPATHY-DRIVEN DEVELOPMENT DEFINITION

Empathy-Driven Development is the practice of anchoring decisions on the people impacted by and who interact with what is produced. Persistent and proactive effort is made to:

1. Understand empathy as a critical technical skill
2. Reject false dichotomies that delegitimize empathy
3. Treat computers as tools, not people
4. Maximize help and minimize harm
5. Expand observations
6. Source information responsibly
7. Look through a clear lens
8. Honor other people’s feelings and perspectives as their personal truths
9. Seek semantic alignment
10. Create effective communication artifacts
11. Write to specific individuals, not groups
12. Seek input, feedback, and collaboration

First, let’s unpack the definition.

UNPACKING THE KEY POINTS

“THE PRACTICE OF ANCHORING DECISIONS”

Can empathy drive development?

Yes. When you consider other people before you make a development choice, it influences your decision. Empathy-Driven Development is about purposefully and perpetually considering other people as you go about your work. This acts as a forcing function that will inevitably alter the code, architecture, documentation, functionality, and interfaces that are delivered through emergent design.

“THE PEOPLE IMPACTED BY AND WHO INTERACT WITH”

Who, specifically, are we considering when we practice Empathy-Driven Development?

It can feel noble to take a “customer-centric” approach to development, but that leaves a lot of people outside of your purview. Instead, ask yourself who will be interacting with your work. A customer is very unlikely to see code, commit messages, logging, or pull request comments. So if you only focus on customers, you will miss the opportunity to apply empathy to these aspects of a system. Instead, ask yourself who is likely to interact with what you’re delivering. Think of your teammates, the person using your product, a new developer who’s joining your team, or even yourself in the future. We also want to consider the people who will be directly or indirectly impacted by our choices. For example, if you’re a data scientist who is developing an algorithm for bankers to make mortgage qualification decisions, taking a customer-centric approach would have you only focus on the bankers and ignore the applicants whose lives will be impacted by the output your algorithm produces. In this scenario, you are very likely to perpetuate and exacerbate existing biases, even if you didn’t mean to. Empathy-Driven Development helps us uncover non-obvious audiences, encourages us to consider a variety of different viewpoints while we code, and helps us course correct instead of being blindsided by unintended consequences.

“WHAT IS PRODUCED”

What else is produced? I’m a software developer. I ship code. That’s it, right?

Our work product is often the culmination of deliverables that can typically be broken down into smaller and smaller parts. Empathy-Driven Development encourages us to think about our work atomically rather than universally. Instead of thinking of empathy as an abstract and theoretical topic, we make it discrete and apply it whenever we deliver an item of work. This could be writing code, reviewing code, drafting an email, developing a presentation, planning a meeting, participating in a conversation, sending a calendar invite, facilitating a retrospective, analyzing a burn-down chart, creating a scenario or user story, writing an automated test, refactoring a method, and a myriad of other activities that occur as you go about your day.

“PERSISTENT AND PROACTIVE EFFORT”

Isn’t this just a list of guiding principles?

The term “persistent and proactive efforts” was intentionally chosen to refer to the list of activities that comprise Empathy-Driven Development. A principle is a thing that exists, not necessarily a thing that you do. Implementation of these activities requires intention and commitment. It’s work. Effort. And it doesn’t end. It’s persistent. Lastly, individuals take ownership and accountability for deepening these practices as a way to strengthen their code. These are not reactive responses. They are proactive choices. So, when we are referring to Empathy-Driven Development, we describe it as the definition and the twelve “efforts” (as opposed to twelve “principles.”)

Now, let’s dig deeper into each effort:

EXPLAINING THE EFFORTS IN MORE DETAIL

UNDERSTAND EMPATHY AS A CRITICAL TECHNICAL SKILL

Before you can implement empathy into your practice, you first have to understand what it is and isn’t. Stanford-based researcher Jamil Zaki shares how “Empathy suffers from an ‘Inigo Montoya problem’: People keep using that word, but it doesn’t mean what they think it means.” Empathy is not an inborn character trait as many of us grow up believing. Neuroscience research shows that empathy is a skill that can be developed and taught. It’s like language. Nearly all people are born with the capacity for it and develop an innate sense of how to use it by navigating the world and interacting with others. However, both are teachable skills that can be honed through education and practice. Empathy is also a deeply technical skill, marked by specialization and robust subsets and nuances. We need to stop throwing around empathy confetti and just saying “have empathy.” Instead we need to invest ourselves, our teams, and our organizations in the hard work of deepening this critical, technical skill through intentional and regular practice.

REJECT FALSE DICHOTOMIES THAT DELEGITIMIZE EMPATHY

Since the beginning of the computer science era, empathy has been systematically devalued and even labeled as a liability in the software industry. One particularly influential example is a survey conducted by William Cannon and Dallis Perry in 1966 that dubiously identified that the defining characteristic of a satisfied software programmer is that they “don’t like people.” This seed was nurtured by decades of widespread selection bias and pop culture reinforcement until it sprouted into a full-blown stereotype of the anti-social genius coder that still permeates our consciousness and culture today. “Hard skills” such as logic, analysis, and rationality that “technical” people have are seen as more important than the “soft skills” such as empathy and communication that “non-technical” possess. People who are “good with machines” internalize incorrectly that they don’t have the capacity to learn effective social and professional skills. Those who are “good with people” tell themselves that they aren’t smart enough to learn how to code and can’t envision themselves participating in an environment that doesn’t value their skills. We must reject these false dichotomies. Stop using phrases such as “technical/non-technical” “hard/soft skills” “good with people/good with machines.” These phrases foster a polarized “us vs. them” mentality that breeds resentment, prevents understanding, and crushes collaboration. It’s time to rewrite the cultures of homogeneity and shame that have developed by embracing empathy as a skill that matters in software just as much as math.

TREAT COMPUTERS AS TOOLS, NOT PEOPLE

Who do we code for? It’s not the compiler — it’s people. When I speak on the topic of empathy at software conferences, I almost always have a line of people come up to me after my presentation who share how profound this perspective shift is. They’ve been trained to just make the code work in a mechanical way to the point where they imagine themselves having a conversation with the computer. They realize that their internal dialogue personifies their computer. They work to make the compiler “happy” and don’t really think about the person who will be interacting with what they create. A computer is not alive any more than a power drill. It doesn’t have feelings. People do. Computers, compilers, and code are all just tools that we use to solve problems for people. This small shift in perspective is often the first place where people engage with Empathy-Driven Development and it can have a profound impact on what we produce.

MAXIMIZE HELP AND MINIMIZE HARM

Ethics matter and are everyone’s responsibility. Software developers should never be reduced to glorified order takers who are expected to implement someone else’s ideas without question. Unfortunately, that’s the pro forma culture we see today — another example of fallout from the “not good with people” trope. Many people, including Microsoft executives Brad Smith and Harry Shum, have made the case for a type of Hippocratic Oath for people who code, particularly as we grapple with the impacts of Artificial Intelligence on our society. Personal accountability and ownership over ethics is a good and first step to create software that maximizes help and minimizes harm in our society. However, putting the entire onus on the developer’s shoulder shifts the burden away from people who don’t code, particularly executives and other organizational and team leaders. It’s important to recognize the systemic forces at play. As W. Edward Deming said, “a bad system will beat a good person every time.” A personal oath is useless in an organization that actively undermines it. While Empathy-Driven Development helps developers identify opportunities to consider ethics during their daily development, it also calls for broader systemic support.

EXPAND OBSERVATIONS

If we’re going to consider other people’s perspectives, we first need to cultivate the awareness that they even exist. It’s easy to live life on autopilot, unaware of how our choices impact others. Developing the ability to even see the opportunities in front of us to inject empathy into our work takes practice. It requires us to slow down, create space, and make an effort to think beyond our instincts. In his book, Thinking Fast and Slow, Daniel Kahneman describes the practice of slowing down and noticing in a deliberate and conscious way as “System 2 Thinking.” This is in contrast to “System 1” thinking that is automatic, unconscious, emotional, and based on stereotypes and heuristics. The ability to cultivate observational awareness can also be referred to as mindfulness, which Tara Brach, author of the book Radical Acceptance, describes as “a way of paying attention moment-to-moment to what’s happening within and around us without judgment.” When we intentionally expand our own awareness and seek opportunities to develop empathy, we can more readily apply Empathy-Driven Development.

SOURCE INFORMATION RESPONSIBLY

As we develop our understanding of other people’s perspectives, we need to carefully consider the data we’re using as inputs. Are we just relying on our own gut instincts and assumptions to build empathy? Are we asking leading questions to get the answers we want? Are we only relying on convenient-to-gather demographic information and ignoring higher-quality qualitative research? If so, we’re not deepening our understanding, we’re entrenching ourselves in stereotypes. If we are to build empathy, we need to be aware of our assumptions, take the time to validate or invalidate them, and deepen our understanding through ongoing research with methodologies that help us uncover what people actually feel and believe.

LOOK THROUGH A CLEAR LENS

Humans rely on heuristics to help us navigate the world. These mental shortcuts and patterns can be useful to help us make quick decisions, but we need to be aware that they can also color our perspective when we’re attempting to develop understanding about other people. With Empathy-Driven Development, we are honest and curious about which cognitive biases might be at play as we develop our understanding of other people. We do our best to put our own feelings, beliefs, and judgements on a shelf and observe in a way where our own perspectives don’t cloud our interpretation.

HONOR OTHER PEOPLE’S FEELINGS AND PERSPECTIVES AS THEIR PERSONAL TRUTHS

When we are developing empathy, we recognize that someone else’s experiences are authentic and real to them. We listen openly, without judgement. We don’t debate and try to convince someone that they felt or experienced something they say they didn’t. That’s manipulation and is counterproductive. Instead, we build trust by being curious, respectful, and gracious. It’s important to note that personal truths differ from objective truths. Objective truths are facts that can be debated because they exist outside of personal experience. For example, “The capital of The United States is Washington D.C” or “There are 60 seconds in one minute” are objective truths. The validity of these truths can be debated with evidence and observation. For example, Washington D.C. became the U.S. capital in 1800, so if you’re referring to a date before then, you’d need to adjust your answer. Since we can’t directly observe another person’s inner dialogue, we rely on trust instead. (Side note: There are deep philosophical rabbit holes in regards to defining “truth” such as moral relativism, anti-realism, etc. For the sake of simplicity, we’ll set these nuances aside.)

SEEK SEMANTIC ALIGNMENT

Semantics, or the meaning of what’s being said, matters significantly when we’re trying to understand another person, so we constantly assess if outputs and inputs match. When we are listening or reading, we pay attention to all forms of communication, not just words and syntax. We work to increase nonverbal sensitivity so that we can decode information more accurately by observing and interpreting body language, tone, style, metaphor, eye contact, and other cues. When we are encoding information for another person to absorb, we prioritize clarity and pay attention to words, structure, style, channels and other signals we use. We recognize the importance of communication architecture within an organization and pay attention to how information flows within systems. We also turn this alignment inward by paying attention to our inner dialogue and consider whether the stories we are telling ourselves are accurate. When misalignment occurs in any of these areas, we use curiosity, compassion and non-judgement to reorient ourselves.

CREATE EFFECTIVE COMMUNICATION ARTIFACTS

When archaeologists and anthropologists want to understand a culture from the past, they rely on artifacts and context. The more items that exist, the more complete their understanding can become. With Empathy-Driven Development, we consciously leave communication artifacts, durable documentation of our decisions and ideas, for future people to find. We think of our communication as Stephen King does in his book On Writing — telepathy. King describes how he is transmitting his message in December of 1997 but recognizes “you are somewhere downstream on the timeline from me” receiving the transmission he wrote over twenty years ago. “And here we go,” King muses. “Actual telepathy in action… We’re not even in the same year together, let alone the same room… except we are together. We’re close.” This focus on communication durability becomes even more important as we shift towards remote and asynchronous work. With Empathy-Driven Development, we ask ourselves what someone in the future may need in order to reconstruct a mental model or correctly interpret a nuance? A more descriptive variable name? A refactored method? A well-placed inline comment that describes why a block of code is created in a certain way? A comment on a pull request that reveals more of your thinking instead of just a rubber-stamped LGTM? When you start to imagine all the places where you can leave breadcrumb trails of your thinking, you can start to see how powerful Empathy-Driven Development can be. “But wait,” you may be asking yourself. “Isn’t this just creating more of that burdensome documentation that we are trying to avoid?” No. Because what is being produced is descriptive, not prescriptive. We’re tapping into the needs of other people to make the work that we’re already doing even better. Committing to this emergent form of documentation isn’t overly burdensome, because it’s not pre-ordained or decided ahead of time. Instead we think through what we can feasibly deliver that will be of genuine help. We may never need that specific artifact again, but it might be invaluable for someone else. Creating communication artifacts that are rooted in service of others is the driving force of Empathy-Driven Development. It’s the mechanism that enables the emergent design that can produce higher-quality code, reduce bugs, pay down technical debt, and transform legacy systems.

WRITE TO SPECIFIC INDIVIDUALS, NOT GROUPS

Empathetic concern, which is the emotional response of compassion and concern by witnessing someone else in need, is the fuel that helps us stay motivated when practicing Empathy-Driven Development. Cognitively, we take the time to understand the needs of others through quality research, but it’s our emotional connection, driven by empathetic concern, that drives us to take action and do what we can to help. This means that when we are pointing our perspective, we need to focus on individuals, not groups. When we focus on individuals, particularly through personal narratives that describe feelings and circumstances, we are more likely to increase our empathetic concern. However, imagining a group, especially one with which we don’t identify, can actually backfire and entrench an “us vs. them” mentality. So instead of thinking of “the business” when we’re typing up release notes, we think of Miesha, who told us at lunch last week that when release notes are more descriptive it saves her hours of work because she has fewer customer questions. We tap into Miesha’s frustration and feel compassion to do more than just “check the box.” Instead of saying “who even reads this?!” we take a moment to actually imagine who will read this and do our best to make what we produce valuable to them and their situation. Focusing on individuals keeps us connected to the humanity within our codebase. When we abstract out into groups, we set ourselves up on a slippery slope.

SEEK INPUT, FEEDBACK, AND COLLABORATION

You can’t form empathy in a vacuum. With Empathy-Driven Development, we are committing to continuously deepening our understanding of other people, and that requires interaction. Not necessarily all the time or in a big group, although coding as an ensemble can certainly have its benefits. Empathy-Driven Development isn’t about instituting a preference of extroverted over introverted. Instead, it’s recognizing that empathy, and the act of creating and maintaining a software system, is an inherently social activity in the first place. People are at the heart of software. Empathy is about understanding and emotionally connecting with people more deeply. So using empathy to help inform the choices we make while we code only makes sense.

2D4A FRAMEWORK FOR DAILY USE

Alright, so we’ve got an understanding of the definition and intent. Now, we can look at the mechanics of how to use Empathy-Driven Development in a more concrete way.

My goal here is not to present a doctrine that should be interpreted as the only way that Empathy-Driven Development could be implemented. Rather, this is the framework that I’ve developed for myself over years and years of practice.

The framework can be distilled down into the term “2D4A” to help you remember the steps, similarly to how Test-Driven Development can be expressed simply as “red, green, refactor.” Does 2D4A sound like the name of a droid from Star Wars? Yeah, probably. If that helps you remember it, go with it. If not and you want to come up with a better name, I’d love to hear your ideas.

PROGRESS OVER PERFECTION

One final thing before we dive into the framework. It’s important to remember this: PERFECTION IS IMPOSSIBLE. You will never be able to completely understand another person. Our experiences are developed through our entire lives and the best we’ll ever be able to share or receive is only a small part of what’s really there. So, don’t get hung up on getting this perfect or precise. What we’re looking for is progress, not perfection. The goal is to commit yourself to the constant practice of deepening your understanding of other people, thinking about how your work will impact other people, and getting better where you can. Start where you are and remember how powerful continuous improvement and marginal gains can be.

2D: DECIDE & DELIVER

The “2D” part of the framework describes when to focus on implementing Empathy-Driven Development — when we are making a decision or delivering a communication artifact. Yes, in an ideal world, we want to have empathy consistently running in the background. And maybe you’ll get to that point with enough practice. But if we begin there, particularly for people who are new to this way of working, the amount of cognitive load becomes overwhelming and frustrating. The 2Ds of decide and deliver help us develop a sort of observational break point that will trigger our awareness.

The practice is to identify these opportunities. Here are some questions and situations to pay attention to:

DECISION OPPORTUNITIES

• Choices (What should I do?)
• Ideas (What could I do?)
• Improvements (What could be better?)

DELIVERABLE OPPORTUNITIES

• Clicking Send, Submit, etc. (ex: emails, pull/merge requests, etc.)
• Recording information (ex: typing, audio recording, etc.)
• Communicating synchronously (face-to-face meeting, phone call, etc.)

The goal is that you build your awareness to the point where you are able to pause briefly before making a decision or submitting a deliverable to ask yourself who is on the other side of your work and what they might need. One quote that serves as a constant reminder for me is this:

“Human freedom involves our capacity to pause between stimulus and response and, in that pause, to choose the one response toward which we wish to throw our weight.” - Rollo May, The Courage To Create

Empathy-Driven Development is about identifying that space before we make a decision or deliver something. We choose to respond by anchoring our decision making on others rather than moving through our day on autopilot. When we do that, persistently and with intention, we find ourselves with stronger teams and better code.

DETERMINING HOW MUCH TO SLOW DOWN

At this point, you might be overwhelmed. “You mean I need to stop what I’m doing and do all this research EVERY time I make a decision or send even just a quick email. How the heck am I supposed to get anything done!?”

That’s a very valid point. We don’t want this framework to impede us from actually delivering value. That’s not very helpful. Instead, let’s add some context to help us figure out the relativity of our pauses.

To help us think about this, let’s use the metaphor of driving a car.

When we’re driving, we’re constantly scanning our environment. When we first learn and get behind the wheel, everything is new and we have a heightened attention on everything. After enough practice, driving becomes more intuitive. Many activities move from “System 2” thinking into “System 1” over time. We are able to reduce the cognitive load required for driving from point A to point B, but even then, we never stop scanning for times when we need to slow down or stop.

Empathy-Driven Development works much the same way. When you first start working with it, you might feel like you’re overly aware. But over time, much of the process becomes intuitive.

However, just like with driving, you’re never completely on autopilot. You’re paying attention to signals for when you should adjust your speed. You’re always prepared to put your foot on the brake when you need to, but that doesn’t prevent you from getting to your destination. With Empathy-Driven Development, the two signals that we’re constantly scanning are 1) how much understanding we have and 2) the potential impact of what we deliver.

SLOW - HIGH UNDERSTANDING + LOW IMPACT

When we’re operating from a place when we have a good understanding and the impact of what we’re delivering is relatively low, we still pause and create space before we decide or deliver, but we probably won’t slow our thinking down too much. In our car metaphor, this would be like taking our foot off the gas, preparing to brake if needed, but likely cruising without much of a reduction in speed at all.

SLOWER - HIGH UNDERSTANDING + HIGH IMPACT OR LOW UNDERSTANDING + LOW IMPACT

These situations are like yielding in our driving metaphor. We have shifted clearly into “System 2” thinking and are paying significant attention to what we’re doing. It’s very likely that we have what we need to proceed, but doing so effectively requires us to step back and make an assessment before we do.

SLOWEST - LOW UNDERSTANDING + HIGH IMPACT

When we encounter ourselves in situations where we have low (or no) understanding and the impact of what we deliver will be high, it’s important for us to slow way down and really think things through. Sometimes, we may even need to stop and get additional information or help in order to proceed.

4A: AUDIENCE, ANALYZE, ACT, ACCELERATE

The next part of the framework are the 4As. These are categories of questions to anchor yourself to as you go about your work. The more confidently you can answer these questions, the greater your understanding. If you feel like you’re coming up with null, like you have no idea how to answer these questions, that’s when you slow your thinking down the most. You most likely will need to do research first before you can proceed.

AUDIENCE

• Primary Individual: Who is the most direct person to focus on? Who is the primary recipient of this message? Who will read what I write?
• Additional Individuals: Who else might be impacted? Are there any other people who might indirectly interact with or be impacted by what I produce? (Think of these audiences now, but when considering the questions below, only keep one individual in mind at a time.)
• Context & Environment: What kind of situation might this person be in when they interact with what I’m delivering? What does their world look like? How might their situation impact what they think, believe, value, or need? What additional information should I consider to help me understand how this person makes decisions?
• Pain Considerations: What challenges does this individual face? What would frustrate them? What do they have at stake? What does this individual stand to lose? What keeps this person up at night? What’s the cost to this person of inaction? What potential harm should I be aware of? How might what I deliver impact this person in a negative way?
• Gain Considerations: What does this individual care about? What do they stand to benefit based on what I deliver? What’s most helpful to this individual? How could I proactively make my artifact as useful as possible for them? How might what I deliver impact this person in a positive way?

ANALYZE

• Data Quality - How confident am I in the data I’m using to understand this person? What cognitive or unconscious biases might I need to pay attention to?
• Possibility - If resources were infinite, what would be the best way to meet this person’s needs?
• Feasibility - What are my constraints? How do resources like time, experience, knowledge, budget, access, and influence matter? What’s preventing me from delivering the ideal solution? What do I need and how easy is it to acquire?
• Risks and Benefits - How will my choices impact this person in a negative way? Positive way? What are the negatives and positives to me personally? My organization? My community? Society?
• Edge Cases - Are there any known blind spots I should pay attention to? Are there any outcomes outside the happy path that should be considered?
• Error Mitigation - Should someone else look at what I produce before I send it? If there’s an error in what I deliver, what would the potential impact be?

ACT

• Medium - What type of outlet(s) or channel(s) should I use to convey the information?
• Message - How can I structure my information so my intent is as clear as possible?
• Discoverability - Where would the individual(s) I’ve identified want to find this information?
• Durability - Can the individual access this information later if they need to? Are there any other places I should archive what I’m creating?
• Artifacts to Create - Which communication artifacts should I create? What is my “definition of done?”

ACCELERATE

• Retrospective - What new information can I glean from this experience? What modifications could I make in the future? How can I integrate what I’ve learned into my future work?
• Share - What would be the impacts of sharing more broadly? If they’re positive, how can I adapt what I produced for another audience?
• Collaborate - Is there anyone I could work with to make future communication artifacts stronger?
• Systems - How do existing processes, tools, operations, policies, and procedures impact how communication artifacts are produced? Are there changes that could save time or improve quality?

PUTTING THE 2D4A FRAMEWORK TOGETHER

Okay, this is a lot of information. Let’s put it into a graphic so we can see how it all works together as a system.

In the outer ring, you’ll see the 2D’s. Each D has a beginning phase and an ending phase. In between each of these is a different type of pause.

Generate: You’ve decided to make a decision. This is when you run through the 4A questions. If you have high understanding and the impact is low, this might just be a couple moments to center yourself with some inner dialogue. If the impact is high and your understanding is low, this process could take time to collect the information you need to make a quality decision.

Execute: Once you’ve decided what to do, you get to work doing the thing, producing communication artifacts, and fulfilling your definition of done. In this phase, you’re using the 4A answers that you developed in the Generate phase to inform what you will deliver. As you get into the work, you may find that you have other questions, which is normal. You’ll also have sub-decisions as you go about the work. As you encounter these opportunities, you’re anchoring yourself back to the 4As.

Review: You’ve created the thing and now you’re ready to deliver. The next pause is a review. Step back from your work, run through the 4A’s, and consider whether you should change anything. If you’re just getting started with the Empathy-Driven Development, this is a really good place to practice your observational techniques. It can be harder to figure out when we start making a decision but we can train our brain relatively easily to pause before we click send or submit. Again, this whole framework isn’t about perfection, it’s about committing to getting better and making progress. If you’re feeling overwhelmed, try making this one the first pause you practice.

Reflect: After you’ve delivered the thing, it’s time to reflect. How was the experience? What did you learn? Did you have what you needed? Were there any impediments? Is there anything that needs to change for next time? This process ties in with many Agile practices, such as retrospectives and makes a huge difference.

REPETITIVE BY DESIGN

Yes. This process is repetitive. That’s purposeful. Let’s review the first part of the definition. “Empathy-Driven Development is the practice of anchoring decisions on the people impacted by and who interact with what is produced.” We anchor our decisions by constantly referring to the 4As throughout our normal work. We use the 2Ds do give ourselves prompts as to when to check in. Back to our driving metaphor, this is akin to consistently checking our mirrors. We don’t just get in the car and look in the rear-view mirror once. Instead, we are constantly referencing them to help us make decisions and avoid crashes. The same is true with empathy. It’s a reflection that we habitually look at as we drive our work.

EMPATHY-DRIVEN DEVELOPMENT BY EXAMPLE

We’re almost at the end of this long post. Thanks for hanging in there. My hope is that combining all these thoughts together is useful for context to help give you a complete understanding of the idea. The last thing we’ll look at to help you get a sense of Empathy-Driven Development is an example of how this looks in real life.

REAL-WORLD SCENARIO: HELPING A NEW TEAM MEMBER ONBOARD MORE EASILY

My business partner, Scott, developed an internal tool. He, along with two other folks from Corgibytes had been working on the prototype together. Another project came along that became a higher priority and the team members disbanded. We use internal projects as a way to maintain a bench and help onboard new developers. Scott, in preparation for onboarding two new team members, decided to look at the project and see what he could do to make onboarding easier.

Here’s how Scott used Empathy-Driven Development as part of his thought process in this situation. Let’s listen in to some of his inner dialogue as he uses the 2D4A framework to influence his decisions while he navigates his work.

Decision Start: What can I (Scott) do to make onboarding to this project easier for our newest team members?

GENERATE - AUDIENCE:

• Primary Individual: Okay. There are two new developers joining the team next week. Instead of thinking of them as a group, I’ll focus on Dan’s needs as a way to keep me grounded in empathetic concern. He’s joining the team first so this will directly impact him the most right now.
• Additional Individuals: I’ll be working on this project less than I have been, so I’ll also think about my future self and what I’ll need if I haven’t seen this project in at least six months.
• Individual Context: Dan is new to the team and won’t know his way around our internal systems like Nickie and Catalina, who have been here for five years. I’ll want to make sure what I produce is easy to understand and find. I’ll want to check my work to see if I’m making assumptions. As for my future self, my ideas will start to degrade if I don’t document them. It’s so frustrating to come back to a project six months later and forget what you were thinking when you worked on it last.
• Pain Considerations: If Dan doesn’t have good information about the project, he’s likely to feel frustrated. Lots of developers I’ve spoken with, including myself, have felt the need to deliver something quickly in the first days of a job. It’s a new team so there’s a desire to prove yourself. If I leave out important context, Dan will have a harder time getting an issue developed quickly and that will probably impact his morale negatively. For myself, if I don’t document these ideas now while they’re fresh on my mind, they’ll degrade. I’ll lose details and it will be much harder for me to reconstruct them later. If I don’t leave my ideas behind, people will need to ask me, and that will mean interruptions. I’m already struggling to get focus time in, so minimizing the probability I’ll be interrupted is definitely a motivating factor for me.
• Gain Considerations: If Dan has the information he needs to get something delivered relatively independently, he’ll likely feel confident and that will help him feel like he’s part of the team. First impressions really matter, so if he has a good experience, he’ll likely feel like he made a good choice by taking the job. For me, while it might take me a while to produce this artifact, I won’t have to repeat myself once it’s written down. It’s kinda like the Don’t Repeat Yourself (DRY) principle with code, only with my ideas. Since this is information I’ll need to repeat to other people on a regular basis, it’s best to write it down. And it’s best to do it now while it’s fresh in my head because that will be less effort.

GENERATE - ANALYZE:

• Data Quality - For myself, I can trust that I have a good understanding of my needs. For Dan, he might have some specific needs that I can’t identify right now, but I’m pretty sure I can draw upon my own experience and the feedback I’ve gotten from other people when they were new to the team to inform me right now. I don’t think I need to do any more research to proceed.
• Possibility - Let’s see… I could record a video of myself doing a walk through. I could also set up a group coding session with everyone who’s worked on the problem to go through things synchronously. I could take the time to just sit down and type out the information in the README and put issues into GitHub. Maybe Melissa could be a pair partner for me with that? She’s fantastic with helping me articulate bigger-picture things like this. Okay. There’s a lot I could do.
• Feasibility - My biggest constraint right now is time. It’s mid-December so everyone is taking time off. I think coordinating the synchronous events would make this harder given the time of year so I think I’ll need to find a way to do this on my own. The video would be high-fidelity, but it wouldn’t be close to the code and would be really hard to search later. I also have little kids running around since we’re in a pandemic right now, so I’m likely to get interrupted. I think me typing things out is the way to go.
• Risks and Benefits - The biggest risk is that since I won’t have anyone else holding me accountable and I have a lot of other things going on right now, that I might let other things prevent me from getting this done. I’ll make sure to also plan some one-on-one time with Dan when he joins the team, just in case I don’t get it produced the way I envision it.
• Edge Cases - Hmmmm…I do have an optimism bias and tend to think things will go much faster than they actually do. I’ll need to keep that in mind when I decide the time that needs to be set aside for this project. I think I could also prioritize the items so if I don’t get to all of them by the time Dan comes on board, at least I’ll know that I worked on the most important ones first. I can also schedule some extra one-on-one time with him to check in and answer questions once I’m back from my vacation.
• Error Mitigation - Since this is mostly contextual documentation there’s not a big risk if there’s an error. I can ask Nickie and Catalina to contribute their thoughts, but that shouldn’t hold up delivery.

GENERATE - ACT:

• Medium - I’ve already ruled out video in favor of a text-based medium. I could write this on our internal wiki, but I think this information needs to be as close to the code as possible. The README file might work, but I think that what I have to say is a bit long for that file. Maybe creating a markdown file in a Docs folder in the source code repository? That could work.
• Message - The sections would probably be: Project Overview, Project History, Domain Knowledge, Objectives, Mission/Vision, Future State, and Milestones. I might come up with others as I start putting it together. I definitely want this to be less formal, so I’ll opt for a conversational style with active voice. When I’m writing out directions, I’ll write in the 2nd person and use lots of “you” language to keep it conversational. I’m tempted to split all these out into separate files from the get go, but I think that’s probably an over-optimization at this point. I’ll stick to one file right now and use headings for each of the sections so it’s easy to read. I can break it up later if I need to. I’ll also lean on bullets and numbered lists to break up the content and make it really scannable when someone glances over it.
• Discoverability - Let’s see. Dan will be using the wiki a lot during his onboarding, so he’ll probably look for some information there. Do we even have a wiki page set up for this project? Hmmm… doesn’t look like it. Maybe setting up something simple and then linking to the docs as the source of truth is the way to go. That won’t take me much time and it will be really useful for other people. The second place I’d look would be in the README. I already decided that I don’t want to put all this content there, but it would probably make sense to update the README and mention to the new file I’m going to make so people don’t get confused.
• Durability - Where I’m going seems pretty durable. I’ve already considered whether the information is searchable and decided to keep it close to the code. I think I’m good here.

Artifacts to Create - Okay. So here’s what I decided, in priority order.

1. Calendar invites for two one-on-one sessions with Dan
2. Markdown file named [overview.md](http://overview.md) with subheadings
3. Docs folder in the repo for [overview.md](http://overview.md) and similar files to live
4. Link in Readme to overview.md
5. Page in the wiki that links to project and says [overview.md](http://overview.md) is the source of truth
6. List of issues in GitHub if there’s time

It should take me about an hour, maybe 90 minutes, maybe less but I want to remember that optimism bias. I’ll set aside my Thursday focus block for this. That should work. I’ll time-box this one so if I don’t get through it all, that’s okay.

DECISION MADE & EXECUTE

Scott has made his decision. Since he feels like he understands the audience well and decides the impact of what he’ll deliver is relatively low. He doesn’t need to gather more research and he decides that he’ll write down the definition of done in his calendar, but that he doesn’t need to take extra time to make his analysis more durable.

On Thursday, when Scott sits down to produce the artifacts, he constantly asks himself if Dan would find what he’s creating valuable. As he makes micro-decisions, like which words to use, or which content is important to highlight, he’s going back to what would help Dan most. He also considers himself in the future as a secondary audience.

READY TO DELIVER & REVIEW

Scott set an alarm to help him stay within scope and set aside 15 minutes to review what he put together. He completed tasks 1-4 but didn’t end up having time for the list of issues. He makes a note to add that to the agenda for his meetings with Dan so they can create an issue together when they meet. He’s been committing his work as he goes along but takes a look with fresh eyes to review what he’s put together from Dan’s point of view. He notices a couple places where he references other internal tools and remembers that Dan may not know where to access them, so he decides to add some links for reference. He packages everything up and merges his changes.

DELIVER & REFLECT

Scott writes about his experience in his work journal that gets shared with the team. He links to the docs and shares how easy it is to forget to add context about a project as you build it. As he reflects, he thinks about ways he might address this in the future. He asks Dan at their one-on-one if what he put together was helpful and if there were ways he could have made it more useful. The next week at a user group he shares his experience and a friend tells him she started adding user documentation into her definition of done and how that small tweak helped her keep more contextual documentation in sync. Scott thinks that’s a neat idea and mentions it to Nickie, Catalina, and Dan at their next meeting. Dan says he’s willing to give it a go as an experiment and will use the project Slack channel to ask questions that he’s unsure about. Scott has gathered more intel that he’ll use to inform his next decision.

NEXT STEPS & DIVING DEEPER

Whew. Okay. After 8000 words, it’s probably time to start bringing this blog post to an end. I hope you can see more clearly how you can use empathy in a very specific way to help you produce higher quality work and collaborate better with the people around you. Empathy isn’t a feeling or something you’re born with perfect proficiency in. It’s a practice, something you actively develop in order to understand other people.

So, what’s next?

START A CONVERSATION

Tell us what you think about Empathy-Driven Development in the comments. Have you used it? What’s worked? What questions do you have?

SPREAD THE IDEA

Share this article with others. Experiment with Empathy-Driven Development on your team. Find a buddy who can help you build up your empathy skills. You can also follow me on Twitter and LinkedIn where I talk about empathy in tech.

ANSWER A SHORT SURVEY

We’re also developing ways that we can bring this practice into the world. Fill out this survey to let us know how you’d like us to help you learn more about it and what resources and tools we should develop first.

I truly hope the ideas here bring you lasting value and help you deepen your personal connections, write better code, and build products that make the world a better place.

With empathy,

Andrea Goulet

REFERENCES

Armstrong, C. E. (2016). Teaching innovation through empathy. Management Teaching Review, 1(3), 164-169. https://doi.org/10.1177/2379298116636641

Beck, K. (2003). Test-driven development: By example. Addison-Wesley Professional.

Brach, T. (2004). Radical acceptance. Bantam.

Brown, B. (2013). Daring greatly: How the courage to be vulnerable transforms the way we live, love, parent, and lead. Penguin UK.

Brown, B. (2018). Dare to lead: Brave work, tough conversations, whole hearts. Random House.

Cannon, W. M., & Perry, D. K. (1966, June 27). A vocational interest scale for computer programmers. ACM Digital Library. https://dl.acm.org/doi/abs/10.1145/1142620.1142628

Chang, E. (2018). Brotopia: Breaking up the boys’ club of Silicon Valley. Penguin.

Cikara, M., Bruneau, E. G., & Saxe, R. R. (2011). Us and them: Intergroup failures of empathy. Current Directions in Psychological Science, 20(3), 149-153. https://doi.org/10.1177/0963721411408713

Deming, W. E. (n.d.). A bad system will beat a good person every time. The W. Edwards Deming Institute. https://deming.org/a-bad-system-will-beat-a-good-person-every-time/

Derby, E., Larsen, D., & Schwaƒber, K. (2006). Agile retrospectives.

Dovidio, J. F., Johnson, J. D., Gaertner, S. L., Pearson, A. R., Saguy, T., & Ashburn-Nardo, L. (2010). Empathy and intergroup relations. In M. Mikulincer & P.R. Shaver (Eds.) Prosocial motives, emotions, and behavior: The better angels of our nature (p. 393-408). American Psychological Association. https://doi.org/10.1037/12061-020

Evans, E. (2004). Domain-driven design: Tackling complexity in the heart of software. Addison-Wesley Professional.

Fourie, M. M., Subramoney, S., & Madikizela, P. G. (2017). A less attractive feature of empathy: Intergroup empathy bias. Empathy - An Evidence-based Interdisciplinary Perspective. https://doi.org/10.5772/intechopen.69287

Ganguly, P. (2018, February 5). Empathy and bias are more intertwined than we often think. Massive Science. https://massivesci.com/articles/empathy-bias-produce-groups-emotions/

Gray, D. (2016). Liminal thinking: Create the change you want by changing the way you think. Rosenfeld Media.

Jaray-Benn, C. (2019, February). Empathy as a source of motivation in language learning and language teaching. Humanising Language Teaching. https://www.hltmag.co.uk/feb19/empathy-as-a-source-of-motivation

Kahneman, D. (2011). Thinking, fast and slow. Farrar, Straus and Giroux.

King, S. (2001). On writing: A memoir of the craft. Hachette UK.

(n.d.). Manifesto for Agile Software Development. https://agilemanifesto.org/

Marsh, A. A. (2011). Empathy and compassion: A cognitive neuroscience perspective. Empathy, 191-205. https://doi.org/10.7551/mitpress/9780262016612.003.0011

Martraire, C. (2019). Living documentation: Continuous knowledge sharing by design. Addison-Wesley Professional.

May, R. (1994). The courage to create. W. W. Norton & Company.

Microsoft Corporation. (2018). The future computed: Artificial intelligence and its role in society.

Niezink, L. W., Siero, F. W., Dijkstra, P., Buunk, A. P., & Barelds, D. P. (2012). Empathic concern: Distinguishing between tenderness and sympathy. Motivation and Emotion, 36(4), 544-549. https://doi.org/10.1007/s11031-011-9276-z

O’Neil, C. (2016). Weapons of math destruction: How big data increases inequality and threatens democracy. Broadway Books.

Orlowski, J. (Director). (2020). The Social Dilemma [Documentary Film]. Exposure Labs in association with Argent Pictures distributed by Netflix.

Park, A. L. (2019, February 21). Injustice ex machina: Predictive algorithms in criminal sentencing. UCLA Law Review. https://www.uclalawreview.org/injustice-ex-machina-predictive-algorithms-in-criminal-sentencing/

Riess, H. (2017, May 9). The science of empathy. PubMed Central (PMC). https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5513638/

Riess, H., & Neporent, L. (2018). The empathy effect: Seven neuroscience-based keys for transforming the way we live, love, work, and connect across differences. Sounds True.

Sirin, C. V., Valentino, N. A., & Villalobos, J. D. (2016). Group empathy theory: The effect of group empathy on US intergroup attitudes and behavior in the context of immigration threats. The Journal of Politics, 78(3), 893-908. https://doi.org/10.1086/685735

Smart, J. F. (2014). BDD in action: Behavior-driven development for the whole software lifecycle. Manning Publications.

Van Inwagen, P. (2013). Philosophy, politics, and objective truth. Euresis Journal, 5, 191-208. https://humstatic.uchicago.edu/philosophy/conant/Inwagen.pdf

Ventura, M. (2018). Applied empathy: The new language of leadership. Simon & Schuster.

Young, I. (2015). Practical empathy: For collaboration and creativity in your work. Rosenfeld Media.

Zaki, J. (2019, September 20). Empathy: What it is (and isn’t) and how companies can put it to good use. LinkedIn. https://www.linkedin.com/pulse/empathy-what-isnt-how-companies-can-put-good-use-jamil-zaki-1c/