Why You Should (and can) Code with Compassion
The case for empathy in the workplace
It’s not just engineering and DevOps. Blame uncaring bosses, longtime gender imbalance, or the whole capitalist experiment — no matter the roots, the American attitude has historically been: at work, people should switch their emotions to OFF. You go in. You do your job. You can disagree but don’t dare lose sight of “being rational.”
This is obviously a game of pretend. We can’t switch off our emotions. They are integral to everything we do, our decisions, the way we interpret reality, and imagine future outcomes. No matter how much data we put on the whiteboard, operating at the heights of rationality, we still have to make a choice. And that choice comes from the gut (which has its owns bias).
As Emily Chang recently pointed out in her book “Brotopia,” programmers have been historically hired with the assumption that great coders are anti-social. That’s because they’ve lived their life focusing on pixels not people, they must be good. They deal in numbers and language which perform finite actions. If the machine made a mistake it’s no one’s fault but the code writer. Change the symbols, change the outcome. However, humans aren’t automated and when it comes to architecturing human interactions that foster a healthy, productive, and — bottom line — profitable workplace, believing a discussion stops and starts with smarts is, in fact, not smart at all.
“Very few engineers are thinking about emotional intelligence and empathy,” says April Wensel, founder of Compassionate Coding. Wensel says that’s wrong. “Empathy is a skill that can be grown. If you care, you can build the skills.”
Wensel founded her company in 2016. A computer science graduate of Pomona and former researcher at Stanford, Wensel, through conferences, workshops and boardroom talks, helps managers build better listening and engagement skills from the engineering department out. Her belief is that if development teams can improve their emotional intelligence, that in turn matriculates to improve output for the company. Though engineering is traditionally thought of as a cold field, it, according to Wensel, doesn’t have to be this way.
“Conflicts cost people money. They waste time,” Wensel says. “Feeling threatened cuts our ability to discuss things rationally.”
So how does one solve the workplace empathy problem specifically in coding environments? By making employees feel like they belong, mitigating misalignments, and simply having empathy.
Workplaces have seen great success with embracing bottom-up structures. When bosses are making fewer decrees, and instead focus on listening and organizing, they remove roadblocks and streamline agile development processes. In other words, they foster creativity. While that means more employees are facing ethical decisions on behalf of the organization, countless companies can trace their breakthroughs to someone that raised their hand during a meeting.
However, it’s important for those ideas to keep percolating. One issue bosses often have to wrangle is the “Smartest Person In The Room” syndrome, or any of its cousins. Oftentimes, the expert can shut down the conversation because they know so much. This does not mean experts should waste time on the inane, it means that bosses need to watch — and perhaps take real action on — the effect of someone constantly putting on his or her “smartypants.”
Another age-old difference is the lack of understanding of roles and simple misalignments. Take, for example, engineering versus sales or marketing. Engineers can often view these departments as fun faces that organize happy hour. And when revenue appears in the company’s bank account engineers go further and say the only reason the money hits that bank account is because of their own jobs and roles. This is, quite obviously, a deep failure in logic. It’s like the brain saying to the stomach, you just sit there and get handed food while I do all the work, which is patently untrue.
These sorts of misalignments often stem from not understanding how the other person spends their day. Open office designs and chat apps have started to chip away at it, but Wensel suggests that managers actively ensure teams understand each other. The reasoning is, when employees have a better sense of what other departments does the next time someone says they have an idea, there will likely be more understanding on all ends to realize where things are coming from. This means different team members should be engaging each other more frequently than twice a month: as an engineer, Wensel noted that she often pairs with designers and marketers regularly.
“…when employees have a better sense of what other departments does the next time someone says they have an idea, there will likely be more understanding on all ends to realize where things are coming from.”
Finally, according to Wensel, empathy helps improve the code itself. If a developer has been trained to view their code through the eyes of other people they’ll avoid putting devils in the details. Engineering requires incredible outputs. But then when it comes time to prepare for others to use it, managers need to ensure their coders aren’t building dead ends. It gets into a Bus Factor of one scenario, that dreaded situation where the value of the company lives in someone’s head, not in documentation or numerous employees. Both managers and engineers need to imagine future people with questions.
This even comes down to the way engineers name variables, Wensel says. There’s a world of difference between calling something say, a “monitoring dashboard” versus “PrintDevOpsScreen2.” “You need other people to understand,” she says.
And that’s really what empathy is. It’s understanding that information does not pass between two people as mere text files. It passes with a host of variables that factor into a bigger program called a company, called a culture. Success goes to the system with the deepest levels of integration.
Caleb Garling is a freelance writer and contributor to Built to Adapt, whose has been on staff at Wired, The San Francisco Chronicle, and contributed to numerous other outlets.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.
