Technical empathy

August 31, 2016

Recently, I was observing a conversation between a respected developer and the product owner (PO) for our team. I can’t recall the specific effort or feature they were discussing, but after a particularly technical comment from the developer, our PO responded: “I am sure you can appreciate how much I can't appreciate that.”

I love that quote. It wasn't that our PO didn't care about what the developer was talking about—it’s that he doesn't need to understand the work at that detail. Maybe he could, but it would be a distraction. He needed to know what end result was being delivered, not how we got it there.

It underscores a fundamental fact about the relationship between developers and product people: they’re often focused on different aspects of the same thing. Academically, it’s probably something we’re all aware of, or at least would admit if pressed, but often take for granted. A lot of developers never learn to truly work well with their product folks because they don't learn to practice technical empathy. At Workiva in particular, technical empathy is a key competency we look for in developers. But what is it?

Technical empathy is the ability to relate to the technical knowledge of another person and see the technical world through their eyes. It’s understanding that product owners will talk in output and delivery, not implementation details. It’s acknowledging that all of the technical expertise in the world doesn't matter if product isn't delivered. Technical work is critical, but only insofar as it delivers some output. Developers with technical empathy understand this and will talk in terms of value and output, not just implementation. This may sound harsh, but allow me to clarify.

Developers with technical empathy:

  • Understand the story about what they are building and why it’s important

  • Ensure their PO understands what value a given set of work will deliver to end-users

  • Verify the acceptance criteria of tickets they are working, so they know what they are providing

  • Emphasize performance improvement results instead of the implementation used to get them

  • Want to ship a successful product as much as they want to write great code

  • Adjust their message based on audience—they can be technical with devs or talk about features with their POs

  • Realize that technical results are truly measured by how much they affect users

If this list of traits sounds familiar, it should. These are the behaviors of the most successful developers at Workiva. While they have impressive technical knowledge, they always understand those skills exist to deliver a product, and their technical empathy helps them change their focus/terminology and work with a product owner. They focus on what needs to be done, whether it’s design, code, a meeting, tests, etc., to get the high priority work out the door. That’s what makes great tech leads here: not a focus on technical details as the name implies, but a focus on shipping great products to users.

I want to be clear, this doesn't mean that technical skills aren't important or that developers shouldn't be passionate about how they do their jobs. Developer skills are the building blocks of every product we have, but not everyone needs to understand them. For example, I want my surgeon to be obsessed with surgical techniques and always be improving his or her craft. Knowledge of one’s field is paramount. But at the end of the day what I (the consumer) really care about is the result—can he or she fix what’s broken? The content of my surgeon’s knowledge and skills that make me whole again is an abstraction that I don't need to see through. Above all, I want to hear my surgeon tell me, "Don't worry, I've got this—I will take care of the problem for you" and believe it. That is exactly what we want to hear from our best developers too—bedside manner is a valuable tool in the hands of both occupations!

So ask yourself, how much can you relate to a nontechnical person? Do you understand the why behind the ticket you’re working on right now? Could you explain the value of that work if your PO was on vacation? Is dev, QA, product management, and delivery management on the same page about what work is the priority? These are the questions we expect every developer to be able to answer. They are the questions that raise our technical empathy and produce amazing product developers.