Eddie's Law of Empathy

"The best way to understand the other is to have been the other."

by Ed Weissman

We're really good at connecting computers but we suck at connecting people.

For computers we have the cloud and APIs and services and networks and middleware and sharding databases and concurrent apps and communication protocols and lots of other digi-stuff that no one understands. But where are our protocols for connecting people?

Inside the computer are trillions of ones and zeros. Some of us call that "software". We devote our lives to making it perfect. But what about the other ones and zeros, those inside people's heads? This includes everything we need to build that software. The problem is that we're so busy with the computer, we figure that the people part will just take care of itself.

And how well has that worked out?

We think we're on the critical path, but we're not. Working inside the computer is not working on the most important thing. The world keeps telling us, but we don't listen. Projects fail, not because of technology, but because of people.

Some of us actually do understand how important people are. But we still get it wrong. We focus on the wrong ones and zeros.

People problems don't arise because "nobody knew". Someone always knows. The problem is that those ones and zeros are not where they're needed. They never made it from one person to another. They're locked inside an unconnected gray-matter data base.

The critical path in any multi-person endeavor is what moves between people. Our corporate goal is usually some platitude that's meaningless to those of us who actually do the work, something like "expand market share", "increase margin", or "make billionaires richer".

Our real goal must be to have the plumbing that makes all those things possible. We need a system where the right ones and zeros travel freely along the path of least resistance to the right people. Some call that "Process". Others call it "Culture". I call it "Empathy".

Empathy is for people what bandwidth is for networks.

Empathy?!?
Wait a minute!
This is engineering, not sociology, right?

OK. Then let's make it an engineering problem...

Step 1. Fetch data. A formal definition...

Step 2. Delete the noise. Remove every word less than 5 letters. We're left with Ability, Understand, Share, Feelings, and Another.

Step 3. Drill down into each remaining data element (and recruit a few friends to get meta by employing empathy to describe empathy)...

We keep coming up with brilliant ways to dig beneath the computer's surface. The more we understand what's below, the better we can interact with it. What if we could do the same with people? That's where empathy comes in.

Eddie's Hierarchy of Empathy

Before you think you understand empathy, beware. All empathy is not the same.

I have broken empathy down into 5 levels, going from 0 (where many of us still are) up to 4 (Empathy++).

Level 0
"There's Someone Else?"

This is too common, almost everywhere. Many of us are so caught up with our tech orgasms, we forget that we are not the reason for our own existence. It's way too easy to plow ahead and forget about the people who will be using our software. The results usually suck for all of us.

Level 1
"I Have Empathy."

This is light-years ahead of Level 0 because we have made the most important leap: We recognize the existence of others. Like Copernicus, we understand that we are not the center of the universe. But having some empathy is not the same as having enough empathy. We are still missing too much of what we really need: data, skills, experience, and donuts.

Level 2
"I Know Stuff."

Now we're getting somewhere! Not only have we recognized the existence of others, we have engaged them and learned something. We have collected data using one of 4,287 different "methodologies" (some good, most pathetic). We think we have what we need, but we still lack a lot. And when we do, we tend to blame something else: bad process, bad users, bad management, bad luck. But the real culprit is the same: insufficient empathy.

Level 3
"A Pro"

A mentor once told me, "Once you can manage managers, you can manage anything." I always figured the I.T. corollary was, "Once you can describe one thing, you could describe any thing."

But then another mentor shared one of his favorite quotes, "You can't get wet from the word 'water'." There's a fine line between knowing what to do and having done it. Unfortunately, 94.7% of I.T. people are on the wrong side of that line. (92.4% of my statistics are made up by me.)

Level 4
"Been There, Done That"

This is rare. It can be a programmer who has spent a lot of time with the user on their turf. Or one who has actually done their job, like at one of my former employers who only hired ex-users (or ex-cons) as developers. It can be a developer who has gotten so good at Level 3, determining the Big Fat What, that they could be a user if needed. And it can be someone who is building something for themselves, which has long been one of the best ways to start your own software business.

I call Level 4 "Empathy++". We don't have to spend all day trying to figure out what to do because we already know. But Empathy++ isn't just for figuring out what to build. It can be used anywhere people work together...

"Opponents or Partners?"
Empathy Between Sales and Production

My experience with empathy started with my first real job at McDonald's. I hated that job, but not for the usual reasons. As a counter person, I didn't mind the long hours, the large crowds, the hard work, or Kenny G. on Muzak. But I hated depending upon the cooks.

I'd have 20 customers and half of them insisted on aggravating me with special requests. Why couldn't they just order one of this morning's ice-cold burgers like everyone else? So I made them wait while I found out what was wrong in the kitchen. (Wally and Murdy were out back having a smoke, Hysong was practicing his karate on the time clock, and Smearcheck and Petersen were trying to peek inside McDonough's blouse.)

I did this for a year, begging my bosses to let me cook. They never did, so I went back there, taught myself, and eventually became McDonald's #1 Bun Man (no, not that kind of bun man).

How did I get so good so fast when so many others failed? Because I had suffered on the other side. I knew what not to do because so many others had done it to me. And I was determined to never do that to anyone else.

I learned many lifelong lessons in that first job. Be prepared. Work hard. Keep learning. Never eat a Big Mac before a workout. But the most important? You get good by doing your job well. You get better by treating others how you want to be treated.

Every server had to cook. Every cook had to serve.

I managed restaurants for seven years before becoming a programmer and I used this lesson repeatedly. I got so tired of cooks and servers fighting, I rotated them every once in a while just to shut them up. Every server had to cook and every cook had to serve. This didn't settle all our conflicts, but it helped everyone realize how their abnormal behavior affected others. I never found any Suckcess Factors training program that worked nearly as well.

It's amazing how much you learn from walking in the other's shoes. It's a lesson I'd never forget, especially when I became a programmer.

"Do Someone Else's Job First"
Empathy Between Programmers and Users

I started my first programming job at Steel City Electric in March but I didn't write my first line of code until September. Why? Because I had to do everyone else's job first.

They made me report to a different department every Monday. And I had to do the job, not observe, not study, but actually work. I did everything everyone else did. Then I had to take a test and file a report every Friday.

I even got to go to happy hour and play golf with the executives. (That was the best. They had it way better than anyone else.)

At first, I didn't understand whay I had to do all this stuff. Eventually I understood the hidden wisdom. So when I started building software, I was rarely surprised by any assignment. I knew these people. I had worked beside them. I understood their world. We loved and hated each other. So I was eager to help them.

Looking back, I realize how lucky I was to get that first job. That training program made me. I got good fast. I got better even faster.

Now when I run into some junior developer in their fifties, I wonder how things may have been different if they had had my opportunity. How could they have one year's experience 30 times instead of 30 years experience one time? Didn't they ever learn empathy?

"Play for Both Teams"
Empathy Between Corporate and Division

In that first job at Steel City Electric, I was a staff programmer at corporate headquarters. A lot of people in the divisions depended on us. And I couldn't believe how horribly we treated them.

There were never any discussions about building software. Corporate I.T. decided what to build, how to build it, and who got it. Division (you know, the people who actually do stuff and make money) had no input and had to live with it.

The usual scheme was to purchase some fancy best of greed software package, install it on corporate servers, make it available to the divisions, and expect them to figure it out. This was always a trainwreck and needed someone (usually me) to sort it out. I traveled to the divisions, got to know the people, and did whatever it took to get the software working right.

Eventually I was promoted to I.T. Director at one of the divisons. I had been part of the corporate pathology that made others suffer, so I was determined not to let that happen to me. It was McDonald's in reverse.

When things went wrong, I didn't have to be like the poor suckers in the other divisions waiting years for support tickets. I had already worked at corporate, so I knew who to talk to and how to get things done. It didn't always help, but sometimes the best way to handle a bully is to have been one yourself.

"Know Their Play Book"
Empathy Between Consultants and Employees

When I worked at XLK Night Flyers, the Debit Surgeons in accounting decided to restructure. Our single company would become several. Our single database would become several. We would need 5,286 new programs to keep it all in sync. And since Debit Surgeons are smarter (and more powerful) than anyone in I.T., they engaged their own Pig4 auditors to run the I.T. project.

They brought in 25 consultants to "analyze" for six months. Things got interesting in Month 7 when they invited us six in-house tech leads to join them. What they didn't know was that I had already worked on their side six other times, including once for their own Pig4 firm!

I knew all their tricks because I had done them myself. Their "Business Requirements" and "Technical Specifications" were useless. They had never talked to a single user or programmer. I recognized many of their standard forms from my own sordid experience. They just downloaded pdfs for our industry and inserted our company name. Many data elements and business processes had nothing to do with us. And many unique to us were missing.

I couldn't resist. So I called them out. I asked dozens of questions I knew they couldn't answer. Standard stuff that even the most alcoholic brain-damaged software engineer on oxycontin would know: questions about data element definitions, formatting, frequencies, communication protocols, systems of record, special processes, and so on. Every answer was either, "It's all in Sharepoint," or "It's there, just not in a form you're comfortable with." (They were right. I'm not comfortable with science fiction.)

It eventually became clear to everyone that they had no idea what they were doing. They had produced nothing of value. Ten million dollars later, the project was cancelled and restarted a year later using in-house resources. I liked to call this blunder "The Consultant's New Clothes". It was crystal clear for me to see this because I had empathy from having played for the other team.

"The Revolving Door"
Empathy Between Managers and Programmers

The #1 problem I've ever had at work has been the lack of respect from my bosses. Few of them ever understood who I was, what I could do, what made me tick, or how to get things done with me as a resource. What most companies still don't understand is that all the team-building B.S. in the world means nothing until they fix their boss problem.

So the five times I was a manager, I promised myself I would never treat others like that. I got to know all my direct reports and found a way to structure the department so that everyone contributed in their own special way. And I made sure I did the three things every manager should: I gave them their assignments. I gave them the resources they needed. And I left them alone. It didn't always work out perfectly, but almost everyone told me I was the best boss they ever had.

How did I do that? With special Suckcess Factors "management training"? With super technical prowess? With enterprise magic? No! With empathy! Empathy is the first ingredient to better management. I had been in their place, so I made sure I treated them the way I should have been treated. That's half the battle.

"Evolve Past the Other"
Empathy Between Vendors and Customers

I took an assignment as a Sales Consultant for Broken Software Associates. Their package was a slickly presented small business application that looked perfect for many of my customers. I traveled to the corporate office to join eight others for product training.

On the first day, we started entering data. Since I had already written and sold my own software, I decided to beat theirs up the way my customers had beaten up mine. When I entered my first customer, I pulled out my own credit card and purposely transposed the last two digits, making it automatically invalid. But their system accepted it! It had no way to reject obviously invalid data. Worse yet, I gave my second customer a new name and address, but the same credit card number as the first one and it was also accepted.

This started a long heated discussion about credit card fraud and I soon realized that it was me against the world. No one else understood the issue and none of them seem to care, not their dev team nor the other Sales Consultants. I concluded with, "I would never sell this to a customer I cared about." That pretty much ended my engagement with that company (although I did purchase some nice t-shirts and a mug from their gift shop with an old credit card).

A year later I learned that the software publisher had abandoned the product and all eight other Sales Consultants were selling services (or Amway) instead. Once again, my little acid test, based on my experience from the other side, saved me tons of time and pain. How could a small business system with no awareness of credit card fraud be any good? Or as one of my mentors taught me, "If they don't do the little things well, how well do you think they do the big things?"

"Abuse the Abuser"
Empathy Between Acquirers and Acquirees

We Make Nothing, Inc. acquired ten other companies during my incarceration there. Each required an I.T. integration. And we screwed up every one.

Each integration had two major components: move their data into our database and enhance our software to do something theirs did but ours didn't. Moving data usually went smoothly but amending legacy software? Not so much. The pattern was always the same, "The data is moved so what's the problem with the software? Hurry up and get it done!" This led to bugs and missing functionality. In several cases, the data had to be moved back to the original system until the enhancements were fixed years later.

So when we were acquired by a giant conglomerate, I made a list of how we had screwed others up to prevent someone else from doing the same to us. That list saved our bacon when they made the project plans and business requirements.

Sometimes empathy is as valuable for defense as for offense.

"No Substitute for Doing"
Empathy Between Programmers and Workers

As the only I.T. person at Stuff For Less, I couldn't contain my Steel City Electric DNA, so I did every job. I entered General Ledger Journal transactions. I helped assemble the catalog. I answered phones and entered orders. I unloaded trucks. I hung out in the break room and complained about the boss. And of course, I filled orders in the warehouse.

After sitting on my butt writing software for years, it only took one day of working the floor-to-ceiling carousels to be sore in places I didn't know I had. And as a lazy programmer, I whined the inevitable question, "Why do we have to climb ladders and bend over so much? Why can't we just put the most popular stuff between our knees and shoulders so it's easier to reach them?"

It was just like the Bridge Marathon in college: say something profoundly stupid and everyone in the room suddenly realizes what a good idea it is.

Knees and Shoulders. A one time project that printed money forever. No programmer imagined it was needed. No warehouse worker imagined it was possible. But how could a programmer working in the warehouse not imagine it? That's empathy!

Don't imagine what someone else is going through...
Go through it with them!

Many believe that the best software is built by the people who need it. That's probably the motivation for the startup adage, "Build something you need yourself." This is no accident. Translating details through multiple layers loses precision. The best way to reduce the loss is to reduce the number of layers. The optimal number of layers is zero, when you already know what you want.

We rarely have enough experience of the other. So we invent all kinds of magical hacks to connect with them: systems analysis, business analysis, functional specification, Value Stream Mapping, waterfall, agile, scrum, even my own Big Fat What. So the more opportunities we have to get behind the other persons's eyes, the less need for silly hacks. This is empathy.

�When I was a boy of 14, my father was so ignorant I could hardly stand to have the old man around. But when I got to be 21, I was astonished at how much the old man had learned in 7 years.�
- Mark Twain

I've had a great career as a software engineer turning ones and zeros into building blocks for others. Yet I don't recall a single piece of tech that helped me or my users more than simply connecting with them.

There is no elegant code snippet, no algotithm, no hack that can replace caring about and listening to another. And there's no better way to do that than by adopting Eddie's Law of Empathy.