September 2020 – The Progressive CIO

🎹 Music for this post: https://www.youtube.com/watch?v=Z5vZovv8cPk.

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.”

Discuss this specific post on Twitter or LinkedIn.

🎹 Music for this post: https://www.youtube.com/watch?v=sh5_NSemt0Q.

By now, I’m sure you have all read about what Tribune Publishing did to its employees.

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:

“We have to educate the users so that they learn to protect themselves.”

(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.

Discuss this specific post on Twitter or LinkedIn.