These days, it's less important for your company, organization or project to solve technical, nuts-and-bolts problems, and more important for them to have empathy in what they do: both external, and internal. Empathy means the fruits of your labour are more likely to be useful to the people you made it for; empathy means that your employees' instinct is to treat each other with respect and care.
"Why switch from programmatic skills to people skills?" is a question that we only ask because, over decades, barriers have been erected around so-called "soft" skills in order to dismiss them for all sorts of reasons (many of them misogynistic). At the same time, and especially in the last ten years, diminishing returns have crept up on the old strategy of just battering away at technical problems and hoping for success. CMSes, frameworks, services and server provisioning can nowadays be off-the-shelf services, with bespoke development accepted as being as much a risk as a benefit.
Duretti Hirpa recently began a foray into the advantages of empathy by explaining that:
When we examine software built [in the 1960s] , we find that it’s chiefly built for machines as well as for the sheer machinery of it; less for people. Today? Computers don’t take up a full room, we can fit them in our pockets. We need to remember we build things for people. As such, we’re going to talk about the secret sauce of building things for people: empathy.
Indeed, as Duretti goes on to explain, a lot of usability research is basically "organisational empathy", which is a phrase I've lifted from Kate Griffin here:
An organisation can’t empathise with you, but usability gives it the tools to behave as if it does. It’s impossible for an organisation as a whole to care about or respect or listen to its customers, because it’s not a human being. But the framework of usability allows an organisation to behave as if it’s capable of caring, respecting and listening.
Interestingly, though, Duretti goes on to turn empathy inwards, and to think about it beyond how the organization presents itself to the outside world:
We need to start feeling empathy for [teams like Sales and Marketing] and treating their work as valid — as valid as engineering work. For instance, in the case of Sales, often they’ll have a quota they have to hit, else they literally lose their jobs. It’s an incredibly high-stakes profession. As engineers, we won’t be fired for building fewer features; in fact, we’ll probably be promoted if we manage to simplify the feature-set.
She then comes up with four main areas where teams can straightforwardly improve their empathy: actually comment code; conduct code reviews in an empathy-oriented way; document what needs documenting; and automate what you can. (I gloss, of course, and you should read what she actually wrote.)
At first glance, what she's mentioned seems really obvious. But, honestly, how much CSS do you see that isn't commented beyond the nearly useless minimum? How many organizations really do code reviews properly, using a gatekeeping model like pull requests? How often do projects require documentation updating as part of the acceptance process for code changes? And what manual tasks are your developers doing over and over again—maybe going via the same manual CSV/XLS conversion to get some inbound data set to work, every time some other tool spits it out—without you having any process in place to pick up on those behaviours?
Empathy cannot get away with being theoretical and verbal, like a sympathetic opinion. Empathy is an internalization of someone else's experiences: to be convincing as such, it needs to involve acting as if those experiences were your own. Organizations: put your claims of empathy where your mouse is. Act on them.
