Empathy is a concept that engineers usually don’t consider integral to successful engineering practices. But I’m here to change that.
Empathy is something we need to be leading with every day if we want to create technologies that can address the true needs of our diverse world. Currently, this isn’t happening; voice assistants are less accurate when responding to female voices and those with accents; facial recognition software doesn’t work as well for those with darker skin tones, and many machine learning algorithms utilize biased data. To improve our future technology, we need to create spaces where diverse team members can share their ideas, be heard, and thrive.
Unfortunately, we have a revolving door in the tech industry when it comes to underrepresented groups. Diverse engineers often have issues getting hired due to bias in company cultures, and once hired, these engineers then face struggles and challenges which drive them out. We need to do the hard work: creating inclusive cultures in our industry where all our team members can thrive.
This is where engineering with empathy comes into play. We can use empathy as the foundation upon which all our interactions are based. Empathy is a skill that can be learned, taught, and improved upon through daily practice (even by logical engineers!) Below I will share what empathy is, and outline areas where all engineers can apply empathy to create those inclusive cultures and products we so need in the world today. Each one of us can impact our company culture. By engineering with empathy, we can do our part to create inclusivity in our orgs, and start moving the needle for diverse teams.
What is empathy?
Before I dive into how we can apply empathy in engineering, I want to take a step back and define empathy. My favorite definition of empathy comes from Brene Brown, a shame and vulnerability researcher, who defines empathy as being made up of four different components:
1. Seeing the world as others see it
As engineers, we have two big opportunities to do this. Seeing the world through the eyes of our customers as well as seeing the world through the eyes of all of our coworkers, no matter their background.
2. Being non-judgmental
Unfortunately, engineering has developed an underlying culture of blame. When something goes wrong and the code breaks, what is the first command that an engineer will usually run? “Git blame” – to see who committed the offending line of code. This runs completely counter to a culture of empathy. What if instead, we treated problems with curiosity and an underlying belief that our colleagues are doing their best? So rather than starting with blame, we communicate with empathy and see why they implemented something the way they did.
3. Understanding another person’s feelings
Do you take the time to reflect on how your actions and words impact both your colleagues and your customers? Do you really understand the needs of all of your customers?
4. Being able to reflect another person’s feelings back to them
This last step may be the most important one when it comes to applying empathy, and it is often the one I see missing. If you can master this step, it will empower you to have difficult conversations, effectively deliver difficult feedback, impact change, and influence others. So often arguments happen just because one side doesn’t feel heard or acknowledged. Take the time when having those tough conversations to ensure you are reflecting the other person’s opinions back to them.
Empathy in engineering
Empathy can be applied to lots of different aspects of engineering, from code reviews to meeting practices, and in choosing features to build in your product. Engineers may not normally associate empathy as key to our career success, but given proper time to reflect, it’s evident that it’s involved in many daily practices: providing feedback to others in code reviews, engaging with team members in meetings, and deliberating with Product on what features to build. We can apply empathy to any situation where we’re interacting with someone else or deciding what features to prioritize. Below, I focus on how we can specifically apply more empathy to code reviews, but it is easy to recognize how a lot of the concepts can be applied to many other aspects of engineering as well.
Empathy in code reviews
Engineers participate daily in sharing constructive feedback through code reviews, yet most of the engineers I know have not received training in effectively delivering in difficult critiques.
What if we start to treat code reviews with curiosity? We can come at it from a place of learning instead of proving something wrong or right. Rather than placing harsh judgment on a coworker, labeling them stupid or lacking in understanding, we should decidedly trust that our colleagues are doing their best work and that they implemented the code in such a way, for a reason.
The language we use in our code reviews is important. A lot of code reviews are done entirely through text and asynchronously in GitHub. Text alone already has an underlying negative bias, so we have to overcome that as we give feedback. I know I’ve been guilty in the past of starting a question in a code review with the phrase ‘why didn’t you…?’ However, if I had taken a moment to think about it, I’d realize that I don’t like being asked questions that start that way as it comes off as accusatory, so why should I use that language when talking to others? I could easily rephrase to ‘I noticed variable XYZ doesn’t seem to be used, should it be deleted?’ To apply empathy in your feedback you want to be objective, ensuring opinions aren’t stated as facts. Be curious instead of accusatory.
Empathy isn’t just for the code reviewer here, it plays an important role for the code creator as well. I know when I’ve finished coding up a project and I’m ready to submit a code review, I’m often excited to be moving on to the next thing. I’ve realized though, that this is one of the times where we need to step back and apply empathy the most. We’ve been living the code day in and day out, and have had lots of interactions with Product and Design. However, peers reviewing our code have not gone through this same journey. It’s on us to paint a detailed picture of what challenges we are solving, how we solved it, and include extra comments in the code review to explain any code that may be confusing. I challenge my devs to reflect: if your colleague had to fix a bug in this code a year from now, is there enough context in the code review to figure out the problem?
Summary
Code reviews are just one of many areas we can apply empathy. As engineers, we can also apply empathy to our customers by really taking the time to understand their diverse needs. I believe even backend engineers should understand the product and the customer. We can apply empathy in how we treat each other in meetings, and in providing feedback on everything from architecture to design.
We are better together, and having diversity in your teams will empower your company to have greater business success. To empower our diverse team members to thrive and be heard, we need to apply empathy to all our interactions and decisions. Only through creating these inclusive cultures will we move the needle of diversity in the tech industry, so as engineers, let’s commit to doing our part. If we each spent 15 minutes a day learning and applying empathy, imagine the technology we could create that would fulfill the true challenges of our diverse world.
