The Little Box Robot is Sad. EMPATHIZE WITH IT.

10 years ago, at 5:06PM on a Friday late in Minnesota spring, I was packing up to leave work. I lucked out in seat selection and had a window looking out onto a beautiful pond and bike trail, so I felt antsy to get outside and do something…not-computery. I closed Outlook and shut down all my active SAP GUI sessions. As my mouse pointer headed down to “Start” to power off my computer, my desk phone rang (that’s how I remember what time it was — I saw it on the little LCD screen). It was a Minnesota number but not an internal company number, so I figured whoever was calling must have a reason to actually call me. I picked up.

We’d just gone live with some enhancements for the company’s SAP Transportation Management (TM) system. Included in this set of enhancements was a special workqueue app (because don’t all SAP modules and systems eventually need a custom workqueue app at some point?), done in the older Floor Plan Manager (FPM) UI framework. This workqueue app was a few screens that the user could view in the NetWeaver Business Client, coupled with a huge set of enhancements and custom code in TM itself that handled special search, retrieval, and transactional capabilities.

It had taken months of tough dev work to get right. I sat in a tiny conference room every day, with a couple other ABAP developers and sometimes a business analyst, banging our heads against the intricacies of the BOPF framework and the TM data model. Once we figured out the data structures, we tried to make FPM reflect how we envisioned a user work flow. It was not easy. I worked with brilliant people in that conference room, and it hurts my brain to think of how many dead ends we chased.

On my 5:06PM phone call was a man who worked at a remote location, just starting to use this app. (I think he got my number from someone who intended for him to reach the super-smart consultant who sat at my desk.) He had a question that I struggled to answer, and we went back and forth on what kinds of things I should look at to try and help him. When we decided to screen-share, it fell to me to do the driving because his PC had an issue with the screen-sharing software.

He talked me through his process on a new order he needed to work, and the scales fell from my eyes as I clicked and listened. Here are some of the things I learned instantly just by sitting in his virtual seat:

• He knew so many details about the thing he wanted to find. But he had to go through a separate search based on those details to find the bit of information that would fit our finely-crafted-yet-very-specific search. If we had just included those other attributes (which we thought about but decided weren’t worthwhile), it would have saved him hours every week.
• In production, this thing was waaaaaaaayyyyy slllloooooooowwwwweeeeerrrr than we realized. If you create your own data and have a tiny limited set to work with, you never feel the pain of just…waiting around for your clicks to make things happen.
• The flow was all wrong. Because of the way he had to stand up and move around his facility to go find various details that the app needed to complete his order, he would know all the things that the final page of the flow needed well before the first page.

I had a laundry list with easily 15 quickly-fixable but high-impact actions to take, and all I had to do was do that person’s job for 10 minutes. I got to click a mile in his shoes.

Empathy

Walking (or clicking) a mile in someone’s shoes, and feeling what they feel. That’s empathy. It’s not feeling sorry for someone. It’s not having a logical breakdown of what they need to type into a field to get the document saved. It’s sharing the experience. It’s knowing what it feels like to be that person.

e techies had worked so hard to make sure the end user’s actions served the system’s concept of what a freight order was, or what a check-in was, that we never stopped to consider whether the system’s actions served the human being performing the check-in. There was no empathy. And it’s not on the level of “let’s just make the computer do anything to make a human happy” — it truly makes a difference in the execution of a business.

I have a lot to say about empathy, more than one post’s worth. But I’ll end this one with an enterprise call to action.

Connect Techies with the People They Build For

I’ve done lots of fun enterprise projects over the years, as an employee and as a consultant. Agile, waterfall, days-long, years-long, and all the style variations in between. I’m beginning to see a pattern: the overall success of the thing I’m working on is strongly correlated with two things.

• Can I accurately describe the overall functions a human being will do in the course of using the thing I’m making?
• How easy is it to pick up the phone/Slack to talk to someone who will use it?

It is absolutely worth the cost to send your techies to the place where their work will make an impact. It is absolutely worth the time that business folks spend talking to techies about how things work. Make those investments early and often.

If the team of nerds can generally describe what people will do with the app and how it fits into the business, and if they can quickly speak to someone who will be working directly with the app…BOOM. Success is waiting.