As a leader, there is no doubt you’ve been saturated with writing and lessons in empathy. Since empathy was at the center of my life studies, there was a time when I was going to write a book about it. As some folks might say: “But Amazon.”
Given all that, what could I offer you in regard to empathy that you might not have already read?
You and I likely agree that, in order for you to do a world-class job at eliciting requirements in any discipline, your ability to hone your empathy skills is of utmost importance.
But one thing that I will share with you that many other writers might not is: no matter what your experience with empathy, if you are to get somewhere great, the work is very, very difficult. After all, if it were that easy, why would there be so many books to try to teach you how to make it easy? Empathy is a lot like running, biking, swimming, or weightlifting. It takes regular exercise and practice to keep you at the top of your game.
When I teach software engineers about empathy, nothing I have found illustrates how hard it is to empathize well better than the following exercise:
The next time PowerBall or MegaMillions begins to ramp up to an insane value, have everyone in your team buy a ticket. Not in the shared office sense, mind you…no, have every single person buy his or her own ticket.
(In order to really do this exercise well, it’s important for each person to have actually bought a ticket. Disclaimer: please don’t do this if you have a gambling addiction. I do care for you.)
Knowing that each person has an actual chance at winning (while simultaneously acknowledging the old adage that the lottery is a tax on people who failed math), have each person ponder:
“What will life be like if I won?”
You will find your teammates saying all sorts of interesting things. But here’s the rub: If you don’t get at least a little scared of a few things, you’re not thinking hard enough.
I’m not going to try to explain why in this post — I can follow up on that at a later time. But the point is: if you cannot empathize with a future version of yourself, how can you empathize with somebody else?
The answer: because empathizing is hard.
Almost all work is a requirements elicitation exercise. From coal mining to neuroscience, from taking orders for tacos to sending people to Mars, we all spend much of our time at work understanding other people’s problems so that we can formulate solutions.
The key to successful requirements elicitation is in understanding the people we are serving, and empathy is the key.
When you are introduced to new businesspeople as a technologist, how do these people begin to see you?
What sorts of biases might they have about what they expect from you?
Why do you think that might be the case?
It is entirely possible that you might not suspect any biases. If that is the case, I hope you find something of interest in this chapter of our journey together.
Arguably, many of us in the field of technology are coarsely viewed as “engineers” by those we interact with and serve. While “engineer” typically connotes a high degree of assumed intellect, the label has a certain amount of baggage that is unwise to ignore. People tend to assume that engineers:
Will talk above the heads of people around them from time to time
Might view others as having an inferior degree of understanding of technical issues
Will want to dissect details and debate minutiae
Will unrelentingly challenge arguments that have holes or weaknesses
Are more interested in things than in people
Take a moment to reflect on your past. Have you, dear technology leader, ever offered a simple observation about a business situation in non-technical terms, only to be asked to stop being technical? If you haven’t, then perhaps you haven’t lived!
Over the decades that I have nurtured the talents of young engineers in the workplace and in the classroom, I ask that, when they walk into a room of businesspeople for the first time, they develop an awareness of a certain propeller on their heads — a propeller that they themselves cannot see, but which is possibly quite visible to those who they are newly serving.
There is a simple way to identify whether or not your propeller is visible: your audience will come to you with solutions, rather than with problems. Have you ever wondered why so many businesspeople do this? Have you ever had the privilege of being a fly on the wall in the meetings leading up to the meetings with you or your teams?
Here is an abject lesson: throughout the world, businesspeople prepare thoroughly to provide as much detail as possible about what they want done before they meet with engineers, often to the point of becoming armchair engineers themselves, all in an effort to run out of the room as quickly as possible when the day finally comes.
If you are a salesperson, you want to meet people and sell to them.
If you are a CEO, you want to meet people and cultivate relationships.
If you are an accountant, you want to crunch numbers and make projections.
Think about every other position in your business, and you will see a trend.
When the time comes to meet with the software engineers and IT people in your business, the idea is: get in, get out, and get back to what you were doing. You want the software engineers and IT people to give you what you ask them for. You know the business, and they (sadly, all too often), simply do not. As much as those engineers know their stuff, your job is to convey to them things about your customers that they do not know as well as you do, and they need to listen to what you need.
All of this is a sort of horrible setup for bad things, I hope you can see. But I am sure you have seen it all before.
Businesspeople do this because engineers have a long history of being a pain in the ass. Your option, as a person with the label (whether you asked for it or not) of “engineer,” is to not be a pain in the ass. The best way to do that is to assume that you might be, in fact, a pain in the ass. Hence, the invisible propeller.
Now, it is entirely possible that people do this simply because they want to be helpful, or that they enjoy armchair engineering. Even in these cases, it is a fair indicator that there may be a lack of awareness of the engineer’s duty to develop an understanding of the problem that is there to be solved.
Before I go much further, I must acknowledge something important, lest I be an invisibleist. Developing a sense for this might be quite difficult for the fair chunk of technologists who are on the spectrum — not an insignificant portion of our population. I have an anecdotal belief that the history of engineering culture owes at least some part of its reputation to this, which is why I am happy to see companies like Auticon, Aspiritech, and even Microsoft address this with programs that cultivate these talents with special attention.
How do you transition from being a pain in the ass — a propellerhead — to a trusted human colleague? There is a small minefield that technologists must get through. The journey begins with steering the conversation to focus on the problem your customer is facing. To demonstrate this, I like to offer an exercise.
Imagine that you are having chest pains, and you run to your doctor, telling him: “Hey! Doc! I’m having a heart attack!”
What do you think the doctor is going to do?
I’ve asked this question in job interviews and classrooms for the better part of two decades, and the answers I have gotten run a wide gamut. In a future column, I hope to share an analysis of the answers I have collected from students over several years of guest lecturing at RIT and other schools.
But back to you: what do you think the doctor is going to do?
Is she going to apply a defibrillator? Is he going to give you aspirin? Is she going to rush you to the hospital? Is he going to ask you how you would know that, given that you are not a doctor? Or is the doctor going to ask you, “Tell me more about your symptoms?”
As the patient, do you go to the doctor with your own pre-determined diagnosis, wishing for the doctor to implement your solution to your problem? Or do you want the doctor to listen to your problems, and determine the solution that he or she thinks is best for you?
We should expect the same in our engineering relationships. However, customers expect something from engineers, and an empathic discussion is often not one of them. As a matter of fact, for engineers to thoroughly walk to the empathic, they sometimes have to risk making their customers feel like they got into more than they bargained for.
Imagine an empathic software engineer being asked to add a new field on a screen of an application. Rather than responding with “OK” (which is tantamount to our doctor applying a defibrillator without asking about symptoms), let’s suppose the engineer replies with:
“Interesting! Help me understand what your business process is.”
What do you expect could go wrong? Our customer’s reaction very well might be:
“What? I don’t have time for this – not something I expected to have to discuss with you.”
That feeling itself is valid; it’s a result of years of avoiding bad conversations with bad engineers.
A truly thoughtful engineer — one who sees the invisible propeller — has to be prepared for that sort of response.
Let’s go back to the doctor scenario. What’s one thing you hope the doctor won’t do? You hope he won’t be, well, a pain in the ass.
“How would you know that you are having a heart attack? You are not a doctor! I will be the one to tell you that you are having a heart attack!”
Yet, how often have you heard an engineer say something like that?
“What makes you think you need that field? If I add that, it could cause all sorts of problems!”
A thoughtful engineer who can envision her invisible propeller will bring a fundamental empathy to the table, and will respond with something that honors the underlying anxiety:
“Yeah, I get that. And I know your time is very valuable! I want to make sure I take a moment to truly understand your underlying problem so that I can ensure that, together, we achieve the results you expect. I will work hard not to take too much time when I do this, and my experience tells me that you’ll be happier. If now isn’t a good time, do you want to schedule something?”
Notice how the word “but” — or words like it — doesn’t appear in her response. It takes a great deal of finesse to honor the validity of your customer’s feelings, and not diminish them. There are a variety of other perfectly good approaches as well.
The goal here is to develop a relationship with your customer — a relationship where your customer begins to trust that the time spent with you is worthwhile. Through the results that you produce, your work will get easier, because your propeller will eventually, and truly, disappear.
The journey from propellerhead to trusted advisor starts with accepting the unfortunate legacy that years of engineers created before you. Those who are able to make this journey will find their careers immeasurably rewarding when compared to those who do not. As Lisa Hermsen (the Caroline Werner Gannett Professor of Humanities at RIT) once shared with me,
“The difference between an engineer who can communicate and one who cannot…is a room with a view.”
Does your organization perform internal phishing tests?
If so, do you feel you do it “better” than Tribune Publishing did?
In what way?
Is it necessary to perform phishing tests?
Why do you think so?
If you know me by now, you might have an idea where I’m going. I think it’s a good idea for your organization to consider reasons why it’s not good to do these sorts of tests at all.
Phishing, by its very nature, will get evermore convincing. That is its entire point.
You do not need to test people to discover this.
What you will discover when you test is that a select group of individuals will fall victim to it.
You will be surprised at some, and not at others.
You will “educate” them about what they did to fall victim.
You will do it again, and you will get different results.
Lather, rinse, repeat.
If you get really “good” at administering phishing tests, you will lose satisfaction with the results. You will realize that the phishers up their games all the time, and that you need to, too. And you might, in fact, wind up doing something similar to what Tribune Publishing did in order to “really show those users” how at-risk they are.
Where does that get you in the end? It puts you squarely into the “us versus them” — “IT versus users” (and I use that horrible term with purpose, here) — position that gives IT a bad name. This is the very reason why I sometimes claim that “IT is a two-letter four letter word.”
Is that what you want?
What would it look like if you were to suggest to your IT leadership and teams that the time for phishing tests is over? What do you think they would say?
“The only way for people to really know how vulnerable they are is to do an objective empirical test that allows us to show them!”
“Those phishers are a moving target, and we need people to see how vulnerable they really are to the newest techniques!”
I am going to get vulnerable with you, in two ways.
First off, several years ago, I, too, thought these tests were novel and useful. In particular, I was interested in creating a dialog with senior leaders about their own vulnerability to phishing. It is a fairly commonly-accepted fact that senior executives are the most successfully-targeted people for phishing initiatives, because phishers have the most to gain, and executives are generally under greater-than-average pressure to quickly plow through their emails.
But I also know that, over the years, I have come very, very close to falling for some very sophisticated phishing myself — to the point where I once performed an action that I had doubts about, and had to quickly employ technical processes to mitigate what I had done. I was very lucky.
If I were a betting man, I would bet that your IT teams feel that they would not fall for phishing as easily as the rest of your organization.
And therein lies the inflection point for your cultural conversation with your IT teams.
Let’s assume that your IT team could educate your workforce to be as “good” at avoiding phishing as they feel they are. Ask your IT teams, “Are you 100% immune to phishing?”
If they tell you, “yes,” then I think you know the work you have to do with them.
If they tell you, “no,” then ask them, what are the best ways to protect you from that fact? Should the executive team do a phishing test on you?
If someone says, “Yeah, that would be kind of cool!” then I suggest that you warn them it would have to be pretty compelling in order to have the desired impact. Show them what happened at Tribune Publishing. Ask them how they would feel if you did that to them.
I suspect that you and I both know where that conversation will lead.
Language of the following sort nauseates me:
(There it is again…isn’t the term “users” disgusting?)
Do organizations perform phishing tests to primarily benefit their employees, or to primarily benefit the organization? If a victimized employee came to you after being phished, do you suppose that their initial response would be: “Gee, I wish you had tested me so that this wouldn’t have happened!”
It is our very industry that has created the holes that attackers use to take advantage of people. With more thought, our industry could have created operating systems and protocols that presaged human nature and mitigated the need for humans to worry so much when engaging with our creations. Back in the 1970s, some significant work was done to anticipate the need for more secure operating systems that might have fundamentally changed the direction of personal computing, but these ideas never took off once the computer wars of the 1980s ensued.
Given that it is our industry that created the mess that we are in, is it fair to so effortlessly thrust the results of our laziness on our customers?
Now, I am certainly not the first person to write this sort of opinion piece about phishing tests. But I am fairly confident that I am the first person who will frame this topic in the following manner:
Did you ever watch Guess Who’s Coming to Dinner? It’s a powerful movie that portrays the emotions of an interracial couple — and the reactions of their parents about their desire to marry — during the Civil Rights Era. In a particularly powerful scene, the son, played by Sidney Poitier, reacts to his father’s assertion that he has to do what his father asks (not marry a white woman), simply because his father brought him into this world. Take a few minutes to watch this powerful scene:
Think of our industry as the father, and think of our customer as the son. We owe our customer everything. Why can’t we do a little more — no, a lot more — to pick up the slack?
In fact, there are proven tools to help us mitigate many types of phishing. The single most valuable tool is a well-implemented security risk assessment, wherein you identify the things that you think are vulnerable to phishing, and create practices that harden those areas.
What was the Tribune trying to do with its phishing exercise? From all appearances, they wanted to see if they could lead employees to share credentials for ostensibly nefarious use. But if those systems were hardened with multi-factor authentication, what would a phishing test achieve?
IT teams can spend money to embarrass people. But wouldn’t it be better to spend the same money protecting people? If it costs more to protect people than to embarrass people, then might it be worth discussing whether or not you want a culture like they have at Tribune Publishing?
I encourage all IT professionals to remember that we are like the father in Guess Who’s Coming to Dinner. We represent an industry that made imperfect choices. Giving our customers technical responsibilities that make our lives easier is distasteful and disrespectful.
To paraphrase Sidney Poitier: We owe them everything.
When you sit down with people at work and ask them about the problems that they are having — the problems that you are there to solve — How often do you think about the following?
Is the person recently married?
Is he going through a divorce?
Is she having a child?
Is he having an affair?
Is her mother ill?
Is his father dying?
Does her son have cancer?
Is his daughter going through a divorce?
Was her best friend hurt by her boyfriend?
Is he spending enough time with his children and wife for them all to be fulfilled?
Is her husband fighting in a war overseas?
If you are speaking with a man, what role does his gender play in how he considers his relationship with you?
If you are speaking with a woman, what role does her gender play in how she considers her relationship with you?
What about your own gender? What about your sexuality? Do these have an impact on the way that you work with others?
Are any of these things less important than the work at hand?
There’s a phrase you’ll sometimes hear at work: “Leave your personal life at the door.” Good leaders will do their best to do that, but not everyone can be expected to be so skilled. If you expect everyone to be able to let go of the most important things in life when they walk into the office, you are fooling yourself. Remember, as universal and important as work is in our culture — and while it provides a wage that allows us to live in our commercial world — you can, in fact, live well enough without work, as many people on this planet do, and have done, for eons. You cannot, however, live well without love.
When you are in the business of solving problems — which is, in fact, what people in software engineering and information technology get paid to do — you will not succeed without taking people’s psychological state into account. Love — whether romantic, familial, or otherwise — is arguably the most primal component of our psychological well-being.
Not too long ago, I was asked to speak to two groups of project managers for a professional development conference. At the top of each presentation, I asked the audience to identify the top three and bottom three skills for project managers. The list contained six skills. Five of these skills were uniformly found in ten different lists of top ten skills for project managers that I found online. These five skills were:
Keep in mind that ten different people or organizations agreed that these five skills were of utmost important to project managers. None of them could actually be considered unimportant in any way, shape, or form. This was a trick question!
The sixth skill, which I selected for inclusion in this little survey, was not on a single top ten list that I could find. That skill?
The survey was administered to two groups of 32 project managers. There were strikingly similar results in each group:
Both groups of project managers uniformly picked Communication, Leadership, and Negotiation as the top three skills for project managers.
But the bottom three skills? Psychology, Risk Management, and Scheduling.
Remember, Risk Management and Scheduling can be routinely found in many top ten lists of skills for project managers. Credit is due the respondents for including Psychology in the middle of the pack, even though it merely made the top of the bottom three skills. I could be a cynic and interpret these results as implying that Psychology is the number one unimportant skill, but a fair number of each group put Psychology in the number three position, implying otherwise.
Nonetheless, there was agreement among the bulk of these respondents that Communication, Leadership, and Negotiation were more important than Psychology.
Is that a surprise?
For any of you out there who don’t think that Psychology is the most important skill that a project manager — or, frankly, most anybody in a role to solve other people’s problems — can have, please take a moment to ask yourself:
How can you communicate if you don’t understand what your audience is going through?
How can you lead if you don’t understand the people you are leading?
How can you negotiate effectively if you don’t understand the unique perspectives and current mindsets of the involved parties?
How can you manage risks if you don’t understand the mindset of the people who can bring about change?
How can you schedule with great effectiveness if you don’t understand what your resources are going through?
As I pointed out in my third post here, there has been almost too much written about empathy. If you have gone through good leadership training, you have, no doubt, been taught of its importance. But as we apply empathy, do we always go as deeply as we should to consider the psychological — or, the love — condition of the humans we serve?
If you yourself know that love is the most important thing in your life, why might it be so easy for you to carve that out of your view of others? I suggest that this is a frequent sign of invisibleism. Reflect on the cell phone scenario of our August 27, 2020 post for a moment. Doesn’t that have everything to do with love?
The problem is that love is such a deeply personal thing, and we are not often privy to its details outside of our own purview. On your journey, keep in mind how private you keep your own love matters. It’s safe to assume that others are doing the same. But if you assume — correctly — that love is the single biggest driving force in people’s lives, you will begin to find indicators.
Someone not interested in talking to you for several days?
Someone need to leave work unexpectedly and postpone a meeting?
Someone generally unhappy?
Someone incredibly happy and distracted from work?
Someone doesn’t care to learn the new software you wrote or deployed?
Someone refusing to take the time to read your training materials about phishing?
In situations like this, how might love be involved? You may not be entitled to details, but you are entitled to consider what’s behind these behaviors. The empathic and compassionate are more likely to be able to figure out what’s going on, and that information just might provide the insight needed to approach work situations more effectively.
If you empathize about only one aspect of people’s lives, make it love. You’ll be sure to get something valuable back for your investment.
What might happen if we could see inside someone’s head, and gain a better understanding of what makes that person tick?
We’ve all had it happen. You kick off a new project, and you’re working hard, meeting with all sorts of people to understand what’s required. You schedule a meeting with a key person. But on the day of the meeting, he’s completely disengaged. No worries! You reschedule. The new meeting day arrives, but he cancels. What could be happening?
Or, you may have a meeting with someone you’ve worked with a for a long time. But on the day you meet, she’s “off.” Everybody has a bad day, so you reschedule. When you finally meet, you notice that your dear colleague just…seems…different these days.
What do you do? Do you get visibly frustrated? Do you complain to the person, or to someone else?
Or do you sit back and think, what could I be missing?
How do we better engage the disengaged, or the people who are acting in ways we don’t quite understand?
The Invisibleism Grids are most useful when you are having an issue engaging with someone in the context of solving a business problem (which includes eliciting requirements, service and product development, process engineering, and other similar activities.) The grids are not a complete list of human conditions by any means; they are merely a reflection of my own 30+ years in the workplace, representing the spectrum of personal situations that I have experienced with others. More pertinently, these are all characteristics or conditions that, if you are armed with a little knowledge, you can accommodate or work through to achieve a business goal.
The grids are useful when you wish to develop a more meaningful relationship with anyone, whether in a business or personal setting. But that is not their primary purpose.
How to use the grids
When you have an issue engaging with someone in the context of solving a business problem, scan through the grids, which are divided into the following core categories of human conditions:
Considerations of Self
Think about each item and whether it might be at play. There are more than 60 things to consider in these grids, none of which I would say are uncommon.
The first grid, Psychological Issues, is special, and different from the grids that follow. It includes 38 indicators that will guide you to consider whether a psychological condition might be at play.
The 38 indicators are not an exhaustive collection of symptoms for the conditions at hand; they are merely the indicators that are easiest for a person like you or me to observe.
I am resolutely not a psychologist, and you might be in the same boat, but we are all entitled consider the implications of these conditions in the lives of people with whom we interact. The key difference between us, the mere amateurs, and those with a Ph.D or M.D. is that we can merely surmise, while the doctors can diagnose.
Have a look at the conditions, and think about the possibility that the person in question might be experiencing one or more of them. I have provided a pair of links for each overarching condition — one from an authoritative nonprofit that contributes to the understanding of the condition by the general public, and a second from an authoritative medical source like the NIH — that will help you gain a better understanding if you think you are onto something.
The Addictions grid is decidedly non-exhaustive. I’ve listed four key sorts of addictions I have managed through in my career, with a handy link from the Mayo Clinic that will help you identify personality traits that surround all manner of addictions. If you think you are dealing with a person who has an addiction, there are numerous resources at your disposal through a Google search.
The remaining grids (Comparative/Positional/Relational, Self, Situational/Environmental, Personality, and Abilities) are broken down into subcategories, with many things to consider in each. Where I have been able to find an authoritative or useful article online to help you develop a better understanding of how that human condition might relate to your work at hand, I have linked to one. Where it makes sense, I provide an illustrative spectrum of 3-4 levels of these conditions, and how those levels may be manifest.
As with the Psychological Issues and Addictions grids, there are portions of these grids that are not exhaustive. For example, the “Abilities” grid lists merely two “invisible” things; but these two things are, in my experience, most likely to have an impact on your day to day business work with someone else.
If you take the time to consider the 60+ conditions and the 38 psychological indicators, you will have considered nearly 100 different things that might be going on in a person’s life, all which are generally much more difficult to discern than race, gender, age, and (sometimes) class. As you work through the aspects of the grids, you will reduce your odds of becoming an Invisibleist in the situation at hand.
Two critical considerations
Please do not use the Invisibleism Grids without considering these two points:
First, never forget that your own behaviors will affect how others respond to you. To best use the grids, we would do well to exercise a great deal of situational self-awareness, to understand how our own personal traits affect others and the conversations we have with them. Think about aspects of the grids that describe you, and spend time to increase your understanding of how those things may affect your own interactions.
Second, there is no doubt that aspects of both your human condition and mine can be unearthed via the Invisibleism Grids. You and I are as subject to the discrimination that comes from invisibleism as anyone else. If your goal in using the Invisibleism Grids is to better discern what might be causing difficulty in your interactions, remember that personal vulnerability goes a long way. If you are comfortable enough to share the invisible aspects of your world, you will increase the odds that your interlocutors will feel comfortable making the invisible visible to you, easing your understanding, and enhancing your relationships.