Categories
Empathy Trust

The Invisible Propeller

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

[Beanie Illustration]

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.

[Logo]
Categories
Compassion Current Events: 2020 Empathy

Guess Who’s Coming to Phish?

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

[Logo]
Categories
Agility Commitment Foundational Values Scrum

Stop Using Scrum as a Weapon

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

Do we ruin Scrum by overthinking it?

I played clarinet from fourth through twelfth grade. The manner in which I was taught was, to me, extremely disagreeable — a ruthlessly judgmental and competitive environment, with overly serious and intense teachers, brought about to weed out anyone who wasn’t 100% serious about playing as perfectly as possible in an overpopulated New York Metropolitan Area student music scene.

I was very good, but I was unhappy. Mistakes were frowned upon at an early age. The training was intense, intellectual, demanding, and even demeaning. Music should bring joy, but performing it was decidedly joyless by the time I left high school. I haven’t picked up the instrument since.

I still adore music, but not as a performer. Today, I enjoy it as a listener. There are many musicians I admire, both alive and deceased, but one who has long caught my ears and my mind — and who I have had the fortune to see in person many, many times is the great bass player Victor Wooten.

Please take five minutes to watch Victor share something that, upon its debut in 2012, made me cry with both disappointment and joy:

This is such a profound point. How I wish I had learned music that way!

But Scrum — ah, Scrum. Can we learn it that way? Why do we tend to treat Scrum as having essential rules that can never be separated or broken, even while learning it? Plenty of otherwise fine Scrum practitioners will let people have fun in the classroom, but once students proceed to apply Scrum in the real world, things change. This is just wrong.

If we can practice personal point kaizen via “One Small Step Can Change Your Life,” then we certainly can practice Scrum sloppily and joyfully as we learn it. I think we would all be better off if we made an effort to introduce Scrum in the form of something I’d like to call Relaxed Scrum.

Here’s an interesting way to introduce Scrum to a group of the uninitiated. I’m describing an in-person exercise, but you can easily translate it to a virtual world. At the very top of your teaching:

Ask your class to write down the missing word in the following sentence:

Initiatives that have _______________ are the ones that are best suited to being managed with agile practices like Scrum.

Have them write their answers and pass them to you.

Once you have them in-hand, read each answer aloud.

Next, ask the class to have a discussion about these answers, to pick one, and have them elect one individual to deliver the final answer at the conclusion of their deliberations, much like a jury.

With work and maybe a little luck, they will arrive at the answer: uncertainty.

You will have just demonstrated Scrum in the most elemental way possible: an uncertain start; an iterative trial-and-error exercise in the middle; and a completed sentence at the end. Your audience will have applied transparency, inspection, and adaptation. And, they will develop a first-hand appreciation for the significance of the very sentence they worked to complete. Scrum — Relaxed Scrum — doesn’t have to be any more complicated than that.

A colleague of mine recently responded to his early Scrum training by noting that Scrum is really all about psychology…it’s about finding a way to unshackle the mind when it is paralyzed about the uncertainty of a task that lies ahead. A truer observation could not have been made. It’s really that simple, and if you make it more complex than that to the uninitiated, you will be as happy practicing Scrum as I was practicing clarinet.

When was the last time you read the Scrum Guide? In its fully-documented form, with a cover, a full-page table of contents, very wide margins, generous 12-point type, large repetitive footers, and a full-page end note and acknowledgements, it’s only 19 pages. You can read the bulk of it in about 20 minutes.

One of the most overlooked sentences in that guide is “Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.”

Isn’t this an invitation to play?

As you read the Scrum Guide, you will read the core values (commitment, courage, focus, openness and respect). If you were to create a Venn diagram of Scrum values with Progressive CIO values, there would be one overlap: commitment.

In my experience with Scrum (both Formal and Relaxed), commitment is the single most important value to focus on. You can do just about anything you want, so long as you make and keep commitments.

Relaxed Scrum is playful, and encourages learning by applying rules conveniently and selectively:

  • We can have a single Sprint where we commit to do some research (one or more Spikes), without having to have a real Product Owner. Such a Sprint might not have a formal backlog — it might just consist of one thing to do. This Sprint might not even have Daily Scrums, and yet it might even wind up resulting in a final release.
  • We can have a Sprint with no Daily Scrum at all. If a team is communicating well and communicating regularly, the intellectual exercise of a quality Daily Scrum might get in their way of feeling the liberation that Scrum should provide, especially early on.
  • We can have a Sprint with no Retrospective, most especially if things are already flowing well.
  • We can have a Sprint with no monolithic Sprint Review at the end, if people have mini-reviews as they roll along.

I am sure you can think of your own rules! The only things you really need to implement Relaxed Scrum are: 1) a problem you commit to work on; 2) time to do the work; and 3) a commitment to review the work at the end of a period of time. If you are able to find a subsequent problem to work on at the end, then you are cooking with gas!

(For a real-world example of what this can look like, refer back to the two-part post: There Are Two Sides… / …To Every Commitment.)

As we grow to appreciate Scrum more — and as we jam with professionals — we will slowly get better and learn the value of its finer points and common practices. But we should not take ourselves so seriously en route! As Victor Wooten pointed out, we can laugh at mistakes, and even embrace them.

The point here is —

If your organization is not working to apply an agile practice like Scrum — Relaxed or otherwise — in some form, one of two things is happening:

  1. You have no uncertainty in your business
  2. You are missing something very powerful

In the case of item number two, if you are avoiding the power of doing something like Scrum because you are intimidated by it, then do everything in your power to think this way rather than this way.

As we proceed on our journey together, you will come to see that I am very fond of agile methods, and of Relaxed Scrum in particular. Relaxed Scrum happens almost organically in a culture that shares the foundational values we discuss on The Progressive CIO:

  • Vulnerability: An ability to admit something you did that was wrong, turning the shame into learning.
  • Humility: Remembering that we are human and learn from mistakes.
  • Empathy: When we seek to understand other viewpoints, we get the best of all possible worlds.
  • Patience: We are willing to put the time in to get to whatever is right even if we are unsure how long it will take.
  • Compassion: We understand that helping others on an uncertain journey requires us to be active in how we reach out to help them.
  • Curiosity: We are eager to learn new things.
  • Commitment: We know that doing something is hard, but doing nothing achieves nothing and actually prolongs our difficulties.
  • Willingness: We want to push ourselves forward to do something to effect change.

The three pillars of Scrum are underpinned by these values:

  • Transparency: A combination of vulnerability, humility, commitment, and willingness
  • Inspection: A combination of vulnerability, humility, empathy, curiosity, commitment, and willingness
  • Adaptation: A combination of empathy, patience, compassion, commitment, and willingness

If you create an environment with our eight values, you will have the essence of Relaxed Scrum without any other rules! Most critically, you will invent your own way to apply the principles of Scrum across a wider variety of initiatives. So why not find your own way of getting there…and do it with a playful spirit, with as few rules as possible?

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Strategy

You Don’t Have to Talk About Strategy

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

Many blog posts — including my very own — seek to provide inspiration through some length of writing. But some subjects are so overthought that brevity brings greater insight. Strategy is one of those things.

Do you have strategy meetings? If so, does the very idea of them turn your stomach? Why do you suppose that is?

I say: all too often, it’s because people have a hard time differentiating the tactical from the strategic, and the meetings lack focus. Here’s a way to get that focus:

Tactical items are the things you have to do.

Strategic items are the things you choose to do, to make yourself different from your competitors. These items are always, always optional. But they make a difference.

Paying people is tactical.

How you pay people is strategic.

You take it from there.

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Compassion Love

Successful and Happy People Love People. Not Work.

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

Do you agree that love is the single most important part of our lives?

If that is the case, why do we talk so little about it in our business life?

Love takes many forms, but love is what our life revolves around. It is our appreciation for love that drives our compassion for one another.

What does work have to do with love? Everything, and nothing.

When we deal with others at work — whether we are eliciting requirements, listening, solving problems, or just about anything else — if we do not remember that the ultimate goal is to allow people to spend as much time as possible with their loved ones, then we will surely fail. We would do well to endeavor to work as little as necessary in order to love as much as possible.

Some people seek to love their work. That misses the point. People should not be expected to literally love their work — or anything else inanimate, for that matter. Remember, your possessions or your job will not weep for you when you are gone. Only people or your pets will. American radio host Bruce Williams once famously shared: “Never love anything that can’t love you back.”

Try to look at how love is at the root of the professional decisions that you make. If you are developing an IT governance policy, is it to help ensure that your employees can sleep better or spend more time with their loved ones when they are not at work? If you are developing software, is the goal to reduce the time people spend working so that they can spend more time with their loved ones? If you develop a product or service for your customers, will it help them with their loved ones? If you succeed, will it help your employees earn enough to be more present for, and provide for, their own loved ones?

If not, why not? Is it possible that you or your teams aren’t making decisions with love at the core?

Why should anyone spend time having business discussions with you if this time doesn’t — in some way — result in more or better time with their loved ones?

More to come. In the meantime, love.

•

Postscript, February 2023: Two and a half years later, The Economist published another set of thoughts on this topic that is worth your time.

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Compassion Empathy Invisibleism Love

What Makes the World Go ’Round?

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

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:

  • Communication
  • Leadership
  • Negotiation
  • Risk Management
  • Scheduling

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?

  • Psychology

The survey was administered to two groups of 32 project managers. There were strikingly similar results in each group:

Group 1 results
Group 2 results

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.

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Current Events: 2020 Technology of the Year

Technology of the Year, 2020 Edition

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

Lest you forget I am a technologist, this column is for you.

I’m 52 years old. The very first computer I ever used was a DEC PDP-11 over a dial-up connection.

The year? 1980; I was twelve.

The second computer I used was a Commodore PET. Third? A friend’s Sinclair ZX81, built from a kit. Fourth? A Commodore VIC-20, which was the first computer I came to own. From there, I worked with all of the famous 8-bit computers, from the Atari 800 to the Apple II to the Commodore 64.

The years 1980-1985 were inarguably the best time in history to be a computer nerd. Beyond these famous 8-bit computers, we saw so many other interesting computers:

  • The Tandy TRS-80 Model III (1980)
  • The Texas Instruments TI-99/4A (1981)
  • The IBM PC (1981)
  • The BBC Micro (1981)
  • The Jupiter ACE (1982), which ran Forth!
  • The Franklin Ace 1000, an Apple II clone!
  • The Sinclair ZX Spectrum (1982)
  • The Compaq Portable (1982)
  • The IBM PC XT (1983)
  • The Apple Lisa (1983)
  • The Amstrad CPC64 (1984)
  • The IBM PCjr (1984)
  • The Apple Macintosh (ahem, 1984)
  • The IBM PC/AT (1984)
  • …and the Commodore Amiga, introduced in 1985

All of these were much more different from one another than computers are today. Different ideas, different technologies, different ways of programming them, different features and benefits. Each idea had something to challenge the other, and standardization was not a thing just yet. The idea was to be different, and to try new things, often. This was a remarkable period of time!

If you were a teenager — with all that attendant attitude — back then, one thing you did not care to own was an IBM PC of any kind. Why? Because, compared to almost all of the alternatives, it was boring. IBMs — and Apple IIs, for that matter — lacked the sprites and player missile graphics of the Commodore 64 and Atari 400/800. They lacked the sound synthesis of the ’64. They lacked the 256 color palette of the Ataris. The IBM PC tried to convince you that it was a great PC because it was a 16-bit machine. But it had an 8-bit data bus.

The IBM PC sucked. All the kids knew it.

You could say that all the things we — the kids — valued were only important to gaming, but we young programmers back then would have disagreed with you. We knew that, in order to create any sort of engaging experience on a computer, sounds and visuals were important. Would you, today, enjoy using Excel if it looked like this?

[Lotus 1-2-3]

Nonetheless, this sort of thing literally excited all of the adults of the period. You know, these kinds of adults:

Michael Douglas

Do you remember the phrase, “Nobody ever got fired for buying IBM”? I do. I wasn’t alone in thinking: this is a strange form of suicide.

Of course, if you are in charge of Wall Street, and the world, you do have a lot of control over the markets, and what gets bought and sold.

The Lisa of 1983 and the Macintosh of 1984 were, famously, incredibly different from everything else that came out before. And they were 32 bit machines with 16-bit data buses. Whoa.

But 1985 saw what was, perhaps, the most interesting computer of the entire decade: The Commodore Amiga.

With the same Motorola 68000 processor of the Mac, a color palette of 4,096 colors and things like https://en.wikipedia.org/wiki/Hold-And-Modify, it was the first personal computer that could really do photorealistic graphics, address 16MB of RAM, 8-bit PCM sound with tricks that could achieve nearly CD quality, it was like nothing else that had come before it. Then came the Video Toaster, and the Amiga simply boggled every geek’s mind. Many, many things led to the Amiga’s demise, and you can read about that in Ars Technica’s spectacular 12-part series.

But: these were the days in which regularly-released new technologies would raise pulses a little bit.

A little while later, Macs got color graphics and got to full 32-bitness; IBMs got there, too. Processors got fast. Windows 95 came out. Then VAX/VMS somehow became Windows NT, and then Windows 2000, and then XP. XP became Windows 7, Windows 8, Windows 10. Then 64-bit. Etc.

Linux came out, and that was incredibly interesting and important, but it’s just an operating system kernel.

Mac OS merged with NeXTSTEP and became Mac OS X.

The smartphone era occurred. iPhone came out and changed, well, phones. That was important (and, of course, was a key step toward this very year and this very article). But pulse-quickening? Not at the same level as 1980-1985. Not to me, anyway.

Not much else has happened since 1985 to raise a pulse as high, other than the NeXT computer in 1989. What NeXTSTEP did to popularize object-oriented programming was utterly, completely, groundbreaking.

Of course, the things that you could DO with a computer in those interceding years? Sure, those have been exciting. You know, the Internet and all. But computers themselves? Meh. A processor, a graphics chip, memory, storage, some IO controllers. Sure, faster, whatever. Apple makes them. Lenovo makes them. Dell makes them. Bleh. DDR4? Yawn. PCI Express? Shoot me. Thousand+ watt power supplies! Do you lack testosterone or something? These are useful alternatives to sheep and Nyquil Pure ZZZs. They do not quicken my pulse. They are evolutionary, and maybe even devolutionary.

In 2020, my pulse quickened. It’s been a long time. The Apple M1 is the most important thing to happen to the personal computing hardware landscape not just this year, but in the past 30.

That’s why there’s so much written about the M1 already. If this is news to you, I recommend you start with these three articles:

As a bonus, don’t miss Linus Torvalds’ initial reaction to Apple’s announcement back in June.

Linus has never been one to say good things about Apple, or anyone using monolithic microkernels for that matter.

The M1 represents the first complete re-thinking of the general-purpose personal computer since the 1980s. It is exciting in the same way that each of those very different 1980s computers listed above was. Let me put it this way: As a result of the M1, one of two things will happen, and either of them will be profound:

  • Microsoft and its hardware brethren will have to completely rethink how they deliver personal computing solutions; or
  • The Mac will become the go-to personal computer solution for most people.

Why does this matter here, on The Progressive CIO?

Because apart from the geek fact that the current bulk of personal computers are a bore, there is the human fact that personal computers still, to large degree, have not fully met an important goal: to honor the human condition.

This week, my boss, the CEO, told me that his Lenovo laptop speaker sounded really bad. I said, “Mine too! You know why? Because the cooling fans blow hot air right over the speaker, causing the voice coil to malform. A bad design decision.”

Have you spent time using Microsoft Teams and Zoom this year? Do these applications sometimes make your laptop’s fans go wild after hours of use? Teams, for all its ubiquity, is a ridiculously resource-hungry app. It’s written in Electron, after all. It cares not one bit for saving your computer’s power. It’s designed to be easy to port to multiple platforms above all other things. It’s developer-focused, not end-user-focused.

Personal computers, as they have evolved — even Macs, to some degree — are janky. They still crash and burn way too often. IT people love computers that don’t need a reboot, but it’s 2020, and most of our computers need to be rebooted at least once per month, if not per week. They have fans that blow incredibly hot air over very important parts that don’t like to get hot. They have batteries filled with ridiculous chemicals that can explode under the right conditions. They are bedrooms of private information that are riddled with vulnerabilities that need to be constantly patched. We spend a good portion of our computing horsepower analyzing what’s going on under the hood to make sure that those vulnerabilities aren’t being attacked. Our computers get hotter, and less, reliable, and things just get worse in a vicious cycle. Apps like Microsoft Teams are written in Electron, which is running on JavaScript through an encapsulated web browser, which is compiled to an API framework for the OS it’s running on, which is talking to the OS kernel that is running on the bare metal. This is at least six layers of abstraction away from the hardware. It’s a miracle that the computers work at all.

How does the M1 change all of this? Well, for starters, the term SoC (whatever happened to Silicon on Ceramic? I digress.) has been wildly overused. The M1 seems to meet the real definition. Everything about it is designed to work together, in harmony. It encapsulates multiple CPU cores, high performance graphics with multiple cores, specialized I/O and storage controllers, image processors, fast and unified RAM, neural processing, and much more. All bespoke and specifically designed to support the heavily object-oriented and declarative design standards that Apple has promoted for a long time now, starting from NeXTSTEP and continuing up to, and through, SwiftUI.

The real kicker, of course, is how the M1’s RISC instructions are so much easier to optimize in out-of-order-execution pipelines with multiple instruction decoders. And the M1 has — gasp! — eight of them. CISC ecosystems just cannot do that sort of thing. While Intel’s CISC approach eventually killed the RISC-based PowerPC, it was because the PowerPC couldn’t scale without generating significantly more heat. Intel won Apple’s heart because of the need to keep computers cool and quiet. Now the shoe is squarely on the other foot, and the endgame looks decidedly different today than it did 15 years ago.

Back to the human condition:

One of the complaints that we’ve all heard this year is how our need to work apart, using videoconferencing applications, has reduced or removed the key cues we need in order to have truly quality conversations. We can’t make eye contact. We can’t hear the small gasps or intakes of breath that are passive ways of saying: hey, can I speak for a sec? Those little gasps and intakes of breath, though, are what make conversations flow, rather than feeling like this.

Whether you know it or not, our computers and smartphones spend an inordinate amount of processing power to filter out background noises. This includes not just the TV in the background, or your labradoodle barking at the Amazon driver. It includes the damn fan in your laptop, which also sounds a lot like moving air breath.

When our computers run cooler, they run more reliably. They last longer. Their sound input systems don’t have to waste additional power filtering out the sounds that the computers themselves are making. They don’t burn our laps, or our palms. Their speakers don’t melt. Their batteries last longer. We get more done, more smoothly, so that we can finish using them, and get back to our real lives.

Good computers are also fast at what they do, and honor the human condition by allowing humans to be finished using them, more quickly, with less drama. Computers are a means to an end, and if that end involves too much time or pain, they are simply not good.

The M1 is fast. It runs cool. And it is fast. Yep, I said that twice. It significantly changes the dialog about what a personal computer can be, for the first time in three decades.

That’s why the M1 matters on The Progressive CIO, and why it is the Technology of the Year, 2020.

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Antipatterns Leadership

Lionization of a Lunatic

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

I’ve been waiting to share some antipatterns to the type of leadership we talk about on these pages. Bingo! Got one today.

Imagine the writer of today’s Wall Street Journal feature: The Covid Crisis Taught David Farr the Power and Limits of Leadership. In his presence? A prideful ass. This is a portrait worthy of an M.C. Escher illustration, splendidly serving the article’s two very different intended audiences. It’s a masterpiece — you must read it, really — but be prepared to need an Alka Seltzer by the time you get to the end.

Mr. Farr keeps five baseball bats in his office, including one signed by St. Louis Cardinals greats Stan Musial and Albert Pujols. He likes to swing the bats while he thinks. During earnings calls, he is known to poke people with a bat if he thinks they aren’t doing a good job of talking to investors.

Here are a few pearls of wisdom from the man himself:

  • “We have a company to run.”
  • “We have customers to serve and we can’t frickin’ do it if nobody is here!”
  • “Why did we miss it?”
  • “I might be wrong, but we get paid to make decisions and make calls.”
  • “I would never jump off a cliff without knowing a bit about what is at the bottom. But I know you have to take jumps.”
  • “I got into a lot of heated battles around here in St. Louis because I had the opinion that you can live with this virus.”
  • “I’m not going to die.”
  • “I’m too busy to die.”
  • “I’m not dead, though people have tried to kill me. I’m still quite strongly in charge. And as long as I’m here, our dividend will not be cut.”
  • “We’ve gone that route, rather than where everyone wears a mask.”
  • “If there’s more of us around, you got to be doing the right things, you’ve got to be following your own rules.”
  • “Look. I make s—, and you can’t tell me how I’m making s— when you’re sitting in your goddamn living room.”
  • “Get your a— out to my factories, look at my people on the line, and tell me if they’re telling me the truth or lying. That’s what you’re supposed to do. That’s why I pay you $25 million a year.”
  • “It was very energizing to be on the plane.”
  • “It’s all going back to trying to make people feel like we’re back in business, it’s back to normal, it’s safe, I’m here to talk.”
  • “People are getting tired of and stuff like that.”
  • “I can’t believe this thing. It’s July 7th.”
  • “I got to see some of them for the first time in several months. It was pretty exciting, and I drank too much.”
  • “People were a little closer than 6 feet.”
  • “We’re going to have to bring in automation.”
  • “We’re going to have to take labor out.”
  • “As soon as you hear someone say ‘the new normal,’ plug your ears, and say, ‘bulls—’.”

Most of all, do read the comments. Hook, line, sinker, check.

Imagine how much more shareholder value he might be able to provide if he were better perceived by analysts.

Would you really want to work for someone like David Farr?

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Current Events: 2020 Technology of the Year

Well, That Didn’t Take Long

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

In reference to Technology of the Year, 2020 Edition…

Here you go: Bloomberg: Microsoft Designing Its Own Chips for Servers, Surface PCs

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Albums of the Year Current Events: 2020

Albums of the Year, 2020 Edition

🎹 Music for this post is the music for this post.

Always remember: work is a means to an end. The things that are not work are the most important things in life. For me, music is one of those things. I like the challenge of distilling a year’s worth of music into five favorite albums. This awful year, I gave myself permission to select six that I want to share with you, my dear readers.

1. Fontaines DC – A Hero’s Death

https://www.fontainesdc.com/

A great work, by a young post-punk band with the same raw talent you might have seen from U2 in 1980, Billy Bragg in 1984, and Nick Cave in 1986. If you need convincing, just watch.

2. Chris Cornell – No One Sings Like You Anymore (Volume One)

https://chriscornell.com/

You will miss Chris Cornell even more when you listen to this late 2020 surprise, a love letter to artists he admired. His cover of John Lennon’s “Watching the Wheels” is better than the original. If there is a Volume Two, it will be hard to live up to this. Let’s hope.

3. Wire – Mind Hive

http://www.pinkflag.com/

Wire is, inarguably, one of the best bands of all time. I cannot think of an album ever made by a band of 45-year industry veterans that is as vital as Mind Hive. An unexpected surprise in this very grim year.

4. Sharon Jones & The Dap-Kings – Just Dropped In To See What Condition My Rendition Was In

https://sharonjonesandthedapkings.com/

Another great posthumous album of brilliant covers. Losing Sharon Jones was a tragedy. What a joy to hear her once more.

5. Idles – Ultra Mono

https://www.idlesband.com/

2020 was a year that was made for punk music. Reviewers seem to like this album less than 2018’s Joy As An Act of Resistance. I respectfully disagree. This is vital, timely, and just what my soul needed.

6. Kelly Stoltz – Ah! (etc)

https://www.kelleystoltz.com/

This is comfort food for people of my vintage, so it might not be your thing. Take a little of The Byrds and throw in some Robyn Hitchcock, and you have the makings of something wonderful. The vintage cover artwork is the cherry on the sundae.

Happy holidays to you and yours!

Discuss this specific post on Twitter or LinkedIn.

[Logo]