Why Empathy in Open Source Matters More Than You Think
Cloud Foundry sponsored this post.
In August 2016, I walked into Pivotal’s London office in Shoreditch district for six hours of back-to-back interviews. Throughout the day, I became immersed in learning new testing tools, languages and frameworks. I barely kept my head above water as I tried to demonstrate that I could pick up technical context quickly.
But the one memory that still stands out to me from that day was a brief conversation with Will Martin, a staff software engineer for Pivotal, in which I asked: “What’s the one thing that’s keeping you here?” And he answered without hesitation: “People here have empathy.”
Since joining Pivotal and spending a lot of time as an open source contributor, I’ve been thinking about how to practice empathy in my day-to-day activities as a software engineer and community member. I’ve since learned that being empathetic isn’t just a state of mind, but a set of behaviors and actions that account for the needs and feelings of those around you. One of the key takeaways is that empathy is a set of verbs, not nouns.
Allow me to explain what I mean.
Empathy in Practice
In everyday life, there is a spectrum of ways to apply empathy. “Low-abstraction” empathy is between individuals — with it, you can discover, through a conversation, if your assumptions about someone else’s mindset were correct. For example, if your coworker is regularly late for morning stand-up, rather than nagging them, a more empathetic course of action would be to check in with them and see if everything is alright outside of work.
Then there’s “high-abstraction” empathy, which means applying empathetic thinking towards broader objectives, such as policymaking or product strategy. In “high-abstraction” empathy, it might not be possible to validate that you made the right set of assumptions about your audience, but it’s incredibly important for businesses to think about.
Empathy for Business?
Empathizing with users matters for every company’s bottom line. We can consider the classic, well-validated business case for the lifecycle of a product as it reaches commodification. Once in a while, a technological innovation will be so unique that it captures market share simply because it was the first to solve a problem.
Eventually, companies have to differentiate from competitors on the basis of building the best user experiences. To gain this competitive advantage, it is critical for product teams to empathize with their end users. Without exercising empathy, even the best research teams in the world won’t ask the right questions, won’t identify their own biases and will be stymied by common pitfalls, such as survivorship bias, a fallacy that overemphasizes those who stick around the longest in an environment, without critically examining reasons that others left.
Empathy for Error
Willingness to build empathy into your processes can have enormous, real-world consequences. I recently heard a fantastic talk by Nickolas Means about the Three Mile Island disaster. Most of the popular analyses of the incident trace the root cause to “human error” and stop there. But here’s the thing: chalking things up to human error is lazy. It’s much harder, and more insightful, to prod further at why those human errors occurred.
Once we consider that the men who were operating Three Mile Island were experienced at running nuclear generators, but on submarines, not land — we learn that the decisions they made were correct, but only for preventing a submarine from sinking to the bottom of the ocean and killing the entire crew. After learning that their control room had sirens that were arranged in a basically random physical configuration, we can empathize with the alert fatigue that the team must have been feeling.
Things get a lot more interesting when you stop accepting “human error” as a root cause. In order to truly get better at designing safer and more reliable systems, we need empathy for the people who will use the tools we build.
Yes, Empathy for Business
How does all of this philosophizing map to open source software development? Open source software is becoming increasingly important for operating businesses of all sizes. In the Cloud Foundry ecosystem alone, businesses report saving $100,000 on average per application development cycle by teams that adopt Cloud Foundry.
Here’s how empathy fits into the scheme of open source software development and why we should start paying more attention:
A few years ago, we as a tech community had a big conversation about security in the context of the popularity of the DevOps movement, which emphasized that “everyone is responsible for deploying and running software.” No one believed that security was unimportant; it was just unclear how to fit security practices into the new DevOps model of working.
In response, “DevSecOps” was coined, and the notion that “everybody is responsible for security” gained mindshare and traction on conference circuits.
Today, there are more and more tools for security and compliance automation, making it easier to integrate security thinking into development workflows. Broadly, it is easier than ever to “shift security to the left” in the development cycle — perhaps physically on work visualization tools, such as kanban boards, but also less literally by encouraging teams to change their processes and upskill on security.
Where does empathy come into this? Security vulnerabilities are costly. But so is missing the mark on delivering products that users actually will use. This is not hyperbole — there are so many stories about products that cost millions to develop, only to flop so badly that the entire company files for bankruptcy.
We’re taking security more seriously today in open source. Where’s the same conversation about thinking seriously about empathy, and bringing empathy “to the left” in our development lifecycles?
Empathy for Everyone
Even without the financial motivations, empathy is something that we as product builders should care about because it is the right thing to do. By trying to see the world through our users’ eyes, we can design software that is more politically and socially responsible. Software designed without due diligence for empathy can have negative consequences ranging from dark-skinned hands not being detectable by soap dispensers, to people being sentenced more harshly by an algorithm that factors in their ethnicity, to far, far worse outcomes.
On the other hand, placing people at the center of our problem-solving processes can literally save lives. As a really great example, I want to give a shout-out to Ellie Ereira and Aly Blenkin for their work on Pivotal Act, an initiative to apply human-centered design to humanitarian challenges, such as improving sanitation in refugee camps.
As Ashley McNamara and John Allspaw talked about on Twitter: Empathy is no longer a “nice to have.” Empathy is a requirement for operating in an interconnected world. Pulling conversations about empathy into the world of open source software development will not only position companies that depend on that software for success, it helps regular users, as well as contributors and maintainers build the muscles for designing more impactful and humane technology.
Come see Denise Yu’s keynote at Cloud Foundry Summit in Philadelphia this April 2-4 at the Pennsylvania Convention Center.
Feature image via Pixabay.
