Soft skills for software engineers - part 1

You do not need empathy with a customer to solve their problem

Picture by Jerzy Gorecki

There are parallels between principles of good software engineering and the soft skills of problem and change management of software.

I started thinking about this when we encountered a customer who would respond violently with threats and lawyers whenever her research site encountered a problem with our software.

It seemed to me that we could apply a principle in software engineering called information hiding. Information hiding is a software design principle, where certain aspects of a program or module (the “secrets”) are inaccessible to clients. The primary goal is to hide details of the implementation from a caller who invokes the module. There are many different ways to actually implement this - using RESTFUL API services, or protocol buffers for example, but the principle remains the same.

There is an urban legend told on social media by people who never supported angry, frustrated tech customers that you need empathy to support customers’ problems.

Actually not.

You need to solve their problem and not get involved in their personal narrative and drama.

To solve their problem, your biggest blocker is separating the person from the problem.

If you’ve tagged the user as an idiot — you cannot solve the problem effectively.

This requires a form of information hiding in 2 ways:

1. Hide the person from the problem

“Don’t flip the bozo bit” is a phrase used in software engineering to caution against making judgments about people based on their flaws or behaviors.

In early generation Apple hardware, the “bozo bit” referred to a hardware bit that wasn’t real but was often humorously mentioned in technical documentation and discussions. It was said that flipping the “bozo bit” on a person implied that they were considered a “bozo” or someone not to be taken seriously. This was an inside joke among Apple engineers I believe.

Once you flip the bozo bit on a person on the team (or a customer), it’s really hard to flip it back.

The trick is hide the person from the problem.

2. Hide a person’s actions from their behaviors

The second form of information hiding is a bit more subtle: you need to separate a person’s actions from their behavior.

First we hide the person from the problem. Now we hide actions from behavior.

Code does not shout at you that she has 51 lawyers just waiting to sue your ass off if you don’t solve her problem now.

I first tried to understand this challenge by looking at it in terms of what is called “Fundamental Attribution Error” which is a specific type of attribution bias.

Fundamental Attribution Error is our (erroneous) tendency to assume that a person’s actions are primarily influenced by their character or personality traits. Their behavior, on the other hand is driven by the situation.

In other words, a persons actions belong to their problem and their behavior belongs to the person.

That’s very good.

It enables us to cleanly separate the problem (actions) from the person (behaviors).

A customer has their internal drama, personal life, pressures, goals and interactions which have absolutely nothing to do with the problem in your software.

Don’t judge. Solve their problem.

Their personal drama is their own. Not yours. It has nothing to do with you.

To quote Scott Belsky —

Stay humble, don’t judge, and focus on beating yourself at your own game