A decade ago I wrote about empathy because I believed it was critical to engineers and that developing it was important. Today, I still lean heavily on that skill, a lot of the times even more so than I used to. There are a few facets of software engineering where the skill applies and where I’d encourage you all to have a go at practicing it.
Leadership
I have watched a leader’s empathy change a team’s trajectory. Everyone works from a different situation with a different set of motivators, people are different and that get energy from different things.
Some engineers thrive when given tough problems and the time to solve them. Others may want frequent check-ins and small wins. Treat them the same and you will get the average of both.
Understanding your people is how you get the best outcome without burning anyone out.
Practice opportunity: Next time you have to ask someone to do something, first find out what they spend their energy on, both inside and outside of work, then see if you can transform the ask into something similar. For example, if you know someone who jumps at the chance to join a customer interview or spends a lot of their time on understanding the customer, try to help link your ask to the customer need, help them connect the dots if they don’t ask you directly.
Product engineering
Product engineering is where I have watched that skill pay off. It requires understanding your customer: who they are, what they want, how they work, etc.
You can only build what a customer wants if you actually know what they want. Most importantly, someone with a strong empathy muscle is able to bypass a lot of their own biases to discover the real customer problems that need solving, our biases often hide things from us without us even realising it. Empathy helps you overcome that. For those platform engineers out there, the skill still applies. Your customers are other engineers, in fact empathy is more important and much harder to apply because you have a lot more biases as an engineer.
Practice Opportunity: Next time you’re building a feature of your platform, don’t assume what you know about development is what other developers want, go out and ask them. For example, if you are building a visualiser for git commits, your workflow tells you that you only really need to see the latest 5 that you have committed, reject this assumption, instead go out and ask one of your fellow engineers on another team and see what they say. They might say the last 10, they might say the most recent one or they might even tell you that they don’t need a visual, each of these is worth finding out before you even go and start building it.
Just plain getting stuff done
The best outcomes I have seen are created by teams.
I don’t mean teams on an org chart. I mean groups of people from across the organisation coming together to build something, often across teams and functions. You need empathy here as well.
You are negotiating a system design with a team you have never worked with. Understanding what they know, what they don’t, and what spurs them on gets you to a point where you start truly working on a solution together. You’ll start talking the same language, there’ll be less surprises and more trust. Only then can you zig and zag together.
Working apart
Empathy is harder for me to keep up when we work apart. My team is spread across time zones, and it’s much harder to gain empathy when you don’t have the opportunity to strike up a casual conversation. But in a digitally distributed and AI automated world, empathy is increasingly important. Understanding why someone else does something means you can more easily predict what they will do, less surprises in a world where course correction moments are increasingly rare and it’s the only way we can get things done together.
Establishing empathy in this world means being intentional. Writing things down, asking questions and triple checking assumptions before they harden.