In the ongoing debates over SaaS and SaaS transformation is the belief that software engineers must do dev-ops to acquire empathy.
It sounds so good in principle. The problem is that the engineers don’t understand the problem because they don’t care! So let’s make them do the job so that they can understand the problem and care.
No one ever asks – what if the software engineer sees the whole experience as a tax on his life that adds very little value. That their brain doesn’t work in a way where doing is the best form of learning. And why wouldn’t a well-crafted document suffice? What if the engineer is the kind of person that doesn’t function well in a high-stakes operations crisis but can deliver complex systems?
And then there is the emotional blackmail of the use of the word empathy. It’s not that I don’t understand the problem because you haven’t explained it to me. It’s because I am callous.
My other favorite is that you must feel the pain so that you do what is necessary.
In short, the argument sounds like this to me:
- No pain, no gain.
- To grow, you must suffer.
It’s like a certain superhero’s origin story.
You don’t use your superpowers (in this case, writing code) because you don’t understand the good you could do (by doing more operational software).
I preferred the original – “With great power comes great responsibility.”
Enough.
When software lacks features, it’s because the engineers weren’t given prioritized requirements; it’s not because they lacked empathy.
I feel like the last 20+ years of interaction design have passed the entire world by.
And having owned operations at scale and done product development at scale, I feel like I am uniquely qualified to say “No” when people tell me it’s about empathy.
And as someone who has struggled with empathy because of how my brain works, the statement – “you lack empathy, and that is why you can’t build the right software” – when I have – is plain infuriating.
About 20+ years ago, the science of human-computer interaction emerged. And the idea was that software could be better if, instead of forcing human beings to change, the software met us halfway.
A book called About Face articulated that well. I still remember the aha.
About Face argued that software engineers did a terrible job of building software for their customers because they didn’t understand them.
And that there was a systematic approach to understanding the customers that could allow software engineers to build the right software.
That methodology became the art of software design.
And it has produced a much better user experience for software than ever existed.
Operations of software in a SaaS environment has a new persona, the operator. And the operator is not the software engineer.
And having the software engineer build UXs for the operator without the same kind of design discipline that we have for other products produces user-experiences from the 1990s.
In fact, the whole empathy argument is in many ways a rejection of over 20+ years of insight into the process of software design.
What the process did was to translate the user goals and aspirations into something that software could solve. And when you combine brilliant designers and brilliant software engineers, great things happen.
So the next time you are told you need empathy, inform the person screaming about empathy that moral arguments didn’t produce great software design. Great designers produced great software designs. And have the design team look at the problem with you.
If doing the job is a great way for you to learn, then do the job. If reading a document is a great way for you to learn, do that. If listening to a talk is a great way for you to learn, do that.
But learning what to build doesn’t require empathy; it requires a definition of what needs to be built.
Leave a Reply