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
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
Humility Vulnerability

We’re All Impostors

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

Thanks go to my brother Rich for sending this Guardian article to me, allowing me to share a final thought for this very long year:

Some pretty smart women claim to be racked by impostor syndrome. Do men just not get it?

The headline asks an interesting question, and I have an educated, but admittedly unscientific, answer: yes, men “get” impostor syndrome. All the time.

What Catherine Bennett describes as “the association of authority with traditionally male exhibitions of extreme assurance” is, from my perspective, the defining mark of a deeply-buried case of male impostor syndrome.

What does true self-confidence look like?

Is it the way that Donald Trump or Boris Johnson or David Cameron or Vladimir Putin behave?

Conversely, what about when Ronald Reagan admitted his mistakes in the Iran-Contra scandal? Or when George H. W. Bush apologized for raising taxes? Or when John F. Kennedy took responsibility for the Bay of Pigs invasion?

Are those illustrations of weakness, or of strength?

Friends, true self-confidence is marked by the ability to openly admit mistakes or lack of knowledge…true self-confidence is all about vulnerability and humility.

Why might you not want to admit mistakes? Do you feel that it might amplify a certain lack of ability, and that others might think less of you? Both of these are strong indicators of personal insecurity. If you are afraid to admit mistakes, you are, by definition, afraid of people knowing your weaknesses. All signs point to some amount of impostor syndrome at this point.

The difference between female and male instances of impostor syndrome, I think, is that women seem to feel more comfortable exploring their weaknesses at a liminal level than men do. Men instead tend to pelt their insecurities down into subliminal territory, creating strong compensating facades of synthesized self-confidence, perhaps powered through the unique delusion of testosterone.

What man (or woman) who cannot admit mistakes and take corrective actions does so for any reason other than fear?

And what could that man or woman be afraid of, other than people beginning to see chinks in their armor?

As I have gotten older, I have developed a belief that most people lack self-confidence for some portion — maybe even a large portion — of their lives. Most people (including yours truly!) become aware of their relative lack of significance in the universe through some lonely moments of self-reflection, and they build up ugly behaviors in order to compensate for this. Ironically, it is the very ability for so many people around us to successfully fake self-confidence through “brio,” to borrow Boris Johnson’s term, that we find the seedlings of self-doubt so deeply sown in ourselves.

If our default human tendency was to openly embrace and exhibit our faults — with confidence! — the world might be a very different place, don’t you think?

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Agility Antipatterns Compassion Humility Leadership Scrum

A Good Friend’s Counterpoint to “Software Engineering Is a Form of Leadership”

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

Before embarking on the journey of reading this unusually long post, please take a moment to reflect on your organization’s technology team.

Are the people friendly? Are they excellent listeners? Do they take the time to empathize with the people they are serving?

Do they work hard to fully unearth and understand people’s problems, designing and collaborating on solutions that reflect where your organization needs to go?

Do they help people feel comfortable with the rapid change that they face in business every day?

Do they exercise servant leadership at every opportunity? Do they exercise transformational leadership when called upon?

Do they serve with humility and compassion?

Does your company believe that, when you invest in software, you are investing in something that requires care and feeding and additional investment, in order to live up to its purpose, which is to reflect change in your ever-changing business?

Does your senior leadership understand that the answer to all of these questions needs to be yes?

Most importantly: Do you have an approach to address the “no” answers you have for any of the above?


In response to “Software Engineering Is a Form of Leadership,” a colleague shared that, “I once had the opportunity to have a conversation with Bill Gates. I asked him, ‘Among your software engineers, how much of the job is technical versus nontechnical?’ He responded that for leaders of software groups, the job was 80% nontechnical, and for his most technical people, the job was 50% nontechnical. Of course, you understand that very well! You have done a good job of identifying the leadership skills that are so important.”

That’s both a great story and a nice compliment, but one of my greatest challenges on The Progressive CIO is to engage folks who are not so lucky as I have been. To date, I have been preaching to the choir: my LinkedIn profile is filled with people who are a lucky and like-minded bunch. Very little of The Progressive CIO is news to them. “Software Engineering Is a Form of Leadership” was written to challenge conventional wisdom. But while I was writing, and even during my subsequent edits, I had a sense its message might not land in the right audience. This turned out to be largely true. Sure, I got a good handful of likes, atta-boys, and agreement from all of the usual suspects. But my network is filled with people who work in functional, healthy, and progressive organizations who already work within the sort of framework we talk about on these pages. I was preaching to the choir.

In my own industry (foodservice distribution),  I can say with certainty that many organizations don’t have great answers to all of the above. Those that do — and I like to consider the organizations that I work for among them — do well in no small part because we treat technology as a key investment in the human condition. We believe that all of our employees, including technology folks, have to bring gobs of emotional intelligence, empathy, humility, and compassion to the table in order to drive our organizations forward.

But why are we a (relatively) rare breed? Well, foodservice distribution is a pennies business. Many organizations try to spend as little as possible on technology as they possibly can. After they put in an ERP system, they want to be done paying for it, so that they can get back to doing what they do best: buying and selling food. What they too often fail to see is that they can’t buy or sell food as competitively and strategically as possible if they put blinders on to the way the world around them has changed in the past 25 years.

Your business may be in a similar situation.

If your organization is one of those who would answer “no” to any or all of the lead-in questions above, you are the target audience for these pages, and this post is here for you. Read on….


Lucky for me — and for you! — “Software Engineering Is a Form of Leadership” elicited the sort of insightful dialog I’ve been hungry for since my earliest writing on these pages.

An adept, articulate, and perhaps even a little angry critical response came to me from one of my closest and longstanding friends. This response is more of a must-read than anything I have written to date on these pages. What pleases me most is that my friend is a fellow rhetorical theorist, as well as an excellent writer and author. That criticism is the focus here today. It sheds light on the very real — and very wide — gap that exists between what some might call my fantasy and so many other people’s realities.

Reality

There are literally thousands of companies — both big and small — that operate with, and even promote, behaviors that are self-defeating for their information customers, and that are at odds with the professions of software engineering and IT as they are currently being taught in schools and practiced in the most successful organizations.

It would be all too easy to say that these organizations work out of a sense of ignorance, or of austerity. Even though there might be some truth to that, it would be an unsympathetic assertion. I think it’s more appropriate to say that these organizations work this way out of a sense of experience, exposure, and habit. Engineers and IT people still generally have an awful reputation as propellerheads, and most people are conditioned to view us through the lens of that stereotype. There are still millions upon millions of people in the workplace who have never been exposed to well-trained and human-focused IT or software professionals, because most of the best technology professionals tend to work in a relatively small number of organizations. Universities are trying to change this, but it will take a very long time before that change is complete. Even then, just like in every profession, there will be bad apples who will perpetuate the stereotype.

Given the unfortunate wealth of this sort of experience, exposure, and habit, the questions we need to address are: 1) how do people help their organizations discover and explore alternative habits; and 2) who is responsible for initiating these alternative habits given the chicken-and-egg nature of the problem?

To begin the journey, let’s explore my friend’s experience with their company’s experience, exposure, and habits.

So, at the end of it all, I guess my overall thought is WOW, we have had such different experiences.

Your post starts off with highlighting how great your Dad was, which was nice to know. What an amazing career he had. I loved that you called it “suppertime” because that was what it was. I was amazed that your father expressed his disdain for a computer science degree, that really surprised me. (Just recently I have been reflecting on how important a quality liberal arts education can be.)

But where you start losing me is “Software’s very nature doesn’t merely involve uncertainty. It invites it. It is its raison d’être.” Software doesn’t have a nature. It is a bunch of code designed to get things done. It is a created response to the current perceived problem. Sure, software has to keep changing because the external parameters are changing (I am hesitant to say evolving). The software and the hardware fit together so that people can be more productive. 

“Software doesn’t have a nature.” That popped my brain like a can opener. My friend is right. Only my choir would see it that way…and every one of us would do well to think of this quite differently. Of course, a software engineering academic would want to assert that the code isn’t the important part of the dynamic here. The code merely a single step in the broader context of evaluating and solving a human problem.

But the meta problem here is that the experience, exposure, and habits of many companies cause them to perceive that code is what the software engineer brings to the table. In that sense, then, my friend is completely correct: software itself certainly doesn’t have a nature.

As a response, I offer a something vastly clearer: the situation that leads to software has a nature.

This leads me to something I have wanted to write about for a very long time. In 1968, Lloyd Bitzer, a rhetorical theorist at The University of Wisconsin – Madison, wrote a piece entitled “The Rhetorical Situation” that has become essential reading for anyone engaged in the modern study of rhetoric. Those of you visiting the Progressive CIO for the first time here might not know that my personal style in managing software engineering and IT is driven by a human-first approach that has its foundations in applied rhetorical theory. I believe that the problems in our profession are most effectively addressed through a comprehensive study and understanding of an audience and its attendant needs, calling for supreme skills in Aristotle’s rhetorical triad of logos, pathos, and ethos.

In “The Rhetorical Situation,” Bitzer attempts to describe the sorts of situations that drive the need for rhetorical discourse. What exactly is that, you ask? It’s something that is probably best defined as language that is employed to move or influence an audience, to bring about change. Traditionally, rhetorical discourse is the label applied to speeches and other overtly persuasive pieces of language. Modern rhetorical theory, however, acknowledges that a vast percentage of human communication can be considered rhetorical discourse…even the simplest “STOP” sign.

Lloyd Bitzer, rhetorician. What in the world does he have to offer to the field of software engineering? Quite a bit.

Here are two key paragraphs, presented without ellipsis, from the midsection of Bitzer’s “The Rhetorical Situation”:

Hence, to say that rhetoric is situational means: (1) rhetorical discourse comes into existence as a response to situation, in the same sense that an answer comes into existence in response to a question, or a solution in response to a problem; (2) a speech is given rhetorical significance by the situation, just as a unit of discourse is given significance as answer or as solution by the question or problem; (3) a rhetorical situation must exist as a necessary condition of rhetorical discourse, just as a question must exist as a necessary condition of an answer; (4) many questions go unanswered and many problems remain unsolved; similarly, many rhetorical situations mature and decay without giving birth to rhetorical utterance; (5) a situation is rhetorical insofar as it needs and invites discourse capable of participating with situation and thereby altering its reality; (6) discourse is rhetorical insofar as it functions (or seeks to function) as a fitting response to a situation which needs and invites it. (7) Finally, the situation controls the rhetorical response in the same sense that the question controls the answer and the problem controls the solution. Not the rhetor and not persuasive intent, but the situation is the source and ground of rhetorical activity — and, I should add, of rhetorical criticism.

Let us now amplify the nature of situation by providing a formal definition and examining constituents. Rhetorical situation may be defined as a complex of persons, events, objects, and relations presenting an actual or potential exigence which can be completely or partially removed if discourse, introduced into the situation, can so constrain human decision or action as to bring about the significant modification of the exigence. Prior to the creation and presentation of discourse, there are three constituents of any rhetorical situation: the first is the exigence; the second and third are elements of the complex, namely the audience to be constrained in decision and action, and the constraints which influence the rhetor and can be brought to bear upon the audience.

Lloyd Bitzer, The Rhetorical Situation, 1968

Let’s see how that reads after a bit of search-and-replace:

Hence, to say that SOFTWARE is situational means: (1) SOFTWARE comes into existence as a response to situation, in the same sense that an answer comes into existence in response to a question, or a solution in response to a problem; (2) SOFTWARE is given significance by the situation, just as a unit of discourse is given significance as answer or as solution by the question or problem; (3) a SOFTWARE situation must exist as a necessary condition of SOFTWARE, just as a question must exist as a necessary condition of an answer; (4) many questions go unanswered and many problems remain unsolved; similarly, many SOFTWARE situations mature and decay without giving birth to SOFTWARE; (5) a situation is SOFTWARE insofar as it needs and invites SOFTWARE capable of participating with situation and thereby altering its reality; (6) discourse is SOFTWARE insofar as it functions (or seeks to function) as a fitting response to a situation which needs and invites it. (7) Finally, the situation controls the SOFTWARE response in the same sense that the question controls the answer and the problem controls the solution. Not the SOFTWARE ENGINEER and not persuasive intent, but the situation is the source and ground of SOFTWARE activity — and, I should add, of SOFTWARE criticism.

Let us now amplify the nature of situation by providing a formal definition and examining constituents. SOFTWARE situation may be defined as a complex of persons, events, objects, and relations presenting an actual or potential exigence which can be completely or partially removed if SOFTWARE, introduced into the situation, can so constrain human decision or action as to bring about the significant modification of the exigence. Prior to the creation and presentation of SOFTWARE, there are three constituents of any SOFTWARE situation: the first is the exigence; the second and third are elements of the complex, namely the audience to be constrained in decision and action, and the constraints which influence the SOFTWARE ENGINEER and can be brought to bear upon the audience.

The remarkable thing about Bitzer’s essay is how effortlessly interchangeable the ideas of rhetorical discourse and software are. The piece does not sound completely ridiculous with these simple substitutions. I believe that this is because software is itself a form of rhetorical discourse, in that it is language that is employed to move or influence an audience, to bring about change. I suppose you could argue this over several beers in any college town in the world, but I would still tell you that software is a form of discourse. In another way of looking at it, software is an expression of thought, and it is a dialogue. It is written for humans, by humans, to express ideas and thoughts, and it is changed in response to the needs of its interlocutors.

Unfortunately for me, a Google search for “is software a form of discourse” (in quotes) as of this writing returns one of those sad “No results found” messages. There are, however, three or four references to “software is a form of discourse,” one of which seems truly interesting. I think we’re onto something. Let’s check back in a few years. I digress…

In rhetoric, the person responding to the exigency and who creates the rhetorical discourse is known as the rhetor. The rhetor’s counterpart in our world is the software engineer. The most challenging work for both of these individuals is in the mise en place:

  • Listening
  • Empathy
  • Audience analysis
  • Situational understanding

Both rhetoric and software seek to drive movement and change. The rhetor’s ultimate product is the speech; the software engineer’s ultimate product is the program. The wordsmithing of these two products is significant, no doubt, but the magic is all in the mise en place. If that is done poorly, the end product will be irrelevant. Nobody will be moved, and nothing will be changed. In software engineering, there is a maxim: the requirements and the documentation are more important than the code. If you lose the code but still have the requirements documented, you can create new code to address the requirements. But if you lose the requirements and have the code, all you have is a solution to a problem that nobody understands anymore.

This is why the academic practice of software engineering pays special attention to the practices of requirements elicitation, group dynamics, and human factors. This is where the key elements of Aristotle’s Rhetoric — logos, pathos, ethos — come into play, every day, all day, for software engineers. In order to be successful, software engineers have to not only look at things from a logical perspective, but they also have to empathize (deeply) and develop a sense of trust in their approaches and their responses to the situation at hand. They will not be able to create the sort of durable and lasting relationships with the people they serve if they fail in these skills. And because software is always an ongoing journey (it is designed to change, constantly, relentlessly), if you do not maintain healthy relationships between those serving and those being served, you will wind up with what, in our industry, we would call a “legacy software” situation.

My friend’s cogent response continues:

Then you say Scrum is great because it allows us to “manage the invited change and uncertainty, by taking one step at a time.” Well, not all change is invited, and it would really be nice if we could look ahead a little farther and anticipate what Hell this change is going to create when we are three steps down the line.

Side note: Several years ago, we had a “lunch and learn” at our company at which the director of the IT department explained Scrum to all of us with PowerPoint slides and everything! Basically, it was their justification for why they worked on which projects/problems. At the time, there were eight people in the IT department, and they would meet every morning to discuss their priorities for the day. If an urgent problem or issue arose, they would have to evaluate what they could set aside so that they could refocus their attention. Multitaskers they were not. 

Prior to them worshiping at the altar of Scrum, they had a spreadsheet list approach. All issues and problems from all departments were catalogued (it was a Jira system). As each department became more and more frustrated that progress was never being made, the IT department decided to call a monthly meeting with the people who had entered the Jiras. We were all supposed to review the list as a company team so that we could understand their overwhelming burden and conflicting priorities. What actually happened was they lost ALL control because the individual departments started organizing their work for them, and those groups were setting the priority ordering. We never had another meeting, and they found Scrum.

Friends, we need to listen to this; these are profoundly important points that illustrate key anti-patterns that our industry faces. For certain, not all change is invited. When we select to use software to address our problems, however, we are making a decision to employ something that was designed to be changed. Back to my father’s point, we use software because changing (electronic) hardware is just too difficult, and in all too many circumstances, we need to allow for change, because change is the natural state of things.

So let’s get down to some experience, exposure, and habits regarding Scrum. Scrum is one of the most abused, misused, and misunderstood ideas of the modern workplace. I’m not a betting man, but I would bet that, in 80% of all implementations, Scrum is FUBAR. Is Scrum bad because it’s so easy to get wrong? Perhaps. But that would be like saying nobody should perform ballet because it’s so easy to get it wrong. Ballet is ridiculously hard to do well. But, holy cow, when it’s done well, it’s breathtaking.

The interesting thing to observe in the experience, exposure, and habits of my friend’s company is that they misunderstand who should be practicing Scrum. It’s not the IT team! And the IT team is not the one to set the priorities for what they work on! Businesspeople are the ones who are supposed to set the priorities for the organization; businesspeople decide what must stop if something else must take priority; businesspeople decide how to invest in staffing the IT teams with the quantity and quality of people who can help them achieve what they require. If you ever find an IT team with this sort of control, it means that the businesspeople, all the way up to the top, have simply abdicated their responsibilities. In Scrum, the Product Owner for an initiative is not on the IT team. This is all a behavioral anti-pattern.

It is because of this that I very much appreciate that my friend’s IT team “lost ALL control because” the operating departments “started organizing their work for them.” Good for those departments! Take control of what you are supposed to control! Unfortunately, from afar, the radio broadcast here seems to indicate that the IT team found a way to use Scrum to regain apparent control. I have no idea how this happened, but it certainly sounds like a horrible human mess. That’s not Scrum. At all.

Back to the post, now we are talking about the definitions of leadership. “Supervision is the practice of overseeing people to ensure they’re doing their assigned tasks.” Okay, I can agree to that. 

“Management is the practice of nurturing someone’s career so that they can achieve what they aim to.” That may be what it is supposed to be, but that certainly isn’t my experience (and I really don’t think I am alone here). In my experience, management is about the managers relying on other people to get work done and then taking all of the credit for themselves. Support, encouragement, and/or appreciation is not offered because “you might think too much of yourself.” Management is concerned with protecting their position and their salary.

Also, the idea that management is interested in my goals is foreign to me. They are interested in their goals (see above: protecting their position and their salary). If I can help with that, then I will be included without being a truly engaged partner in the process because all information is on a need to know basis. 

I’m as guilty of throwing idealistic definitions of supervision, management, and leadership around as the next guy. I’m lucky to not only believe in these definitions, but to work with others who do as well. But take a moment to absorb the above. Despite all of our best wishes, this is what happens at many organizations. Need proof? Why does Dilbert exist?

Dilbert is not just a comic: it is daily illustration of anti-patterns. If you prefer reality over cartoons, then refer to the above. It’s real.

So, if your management behaves this way, what can you do? One passive-aggressive thing to do might be to print this article and post it somewhere. But stupid people don’t read, so that’s not going to work for you.

What can you do when you feel like a mere peon but are interested in making your organization better (ahem, being a true leader)? Let’s use an example from my friend:

Last month, we had an all-staff meeting. Our new President’s big news was that our Board passed the budget. He thanked Percy, our new CFO, for what a great job he did putting the budget together, and what a great job he did presenting it to the Board. It was just so wonderful, and he did such a great job. What a testament to him that the budget was unanimously passed.

Hmmmm, interesting that it is his success. All of the managers worked on their department budgets (fussing about costs and ways to save), entering and revising all of the numbers in the budgeting software when they decided to cut all travel and training for 2021. The individuals in accounting also provided us with all kinds of reports and help.

But let’s be grateful to Percy, who, by the way, could/should have said, “I couldn’t have done it without my team” or anything that acknowledged that it was a group effort.

Nope, nothing — no surprise there.

The best guidance I can offer you from the limits of this page is this: employ the power of the question to make your leaders think. Find an opportunity to ask a question like this: “Do you have any thoughts on why our department managers’ morale is so low?” Even though you are smarter than your organization’s management, ask the question as if you don’t know the answer. Then see how it goes. If you do this enough, over a period of time, the lazy people you are talking to just might want to know if you have any ideas. And it’s always your option to say, “I have no idea, I just wanted to explore.” If you do this enough, you will be able to get a more detailed picture of who feels what, and you will be able to do a lot with that information. Remember that human beings love to be given an opportunity to share their thoughts, and little bits of unexpectedly useful information will always come your way if you are skilled enough to shut up, sit back, and take it all in without offering anything in return. They call it “the power of the question” for a reason: collecting all of that perspective gives you the power and time to figure out how to put it to good use.

Of course, this is only one option. Another completely valid option is to find a better job. You deserve it! But please do take an opportunity to experiment with the power of the question no matter where you work, because your ability to do this will help in so many situations, even in the very best organizations, under much better circumstances.

Back to my friend:

“Leadership is the practice of taking people on a journey to an unknown place while managing their natural anxieties about this journey.” Hmmmm, that hasn’t been my experience either. 

Friends, leadership is one of the most debated terms in all of business. I am going to tell you, unequivocally, that the very nicest organizations to work for all agree that leadership is the idea of moving a novel (and typically uncomfortable) idea forward, regardless of where you sit in your organization.

But remember my friend’s perspective. There are a lot of organizations that aren’t the very nicest. These definitions don’t mean much to them.

Back to software:

But next comes the real stunner: “When software engineers use frameworks like Scrum to assist them in their efforts to drive change, they are living the very highest form of leadership.” Wow, I read that I thought, are you kidding me? Because they code software, because they use Scrum, they are leaders. What? They aren’t thinking outside the box, looking at the future, creating a path forward for the organization. They are solving the computer problem in front of them which has been tagged as a priority. You soften it a bit by saying “Everyone worthy of being called leader needs regular nourishment in these skills, software engineers in particular.” But still, WOW. 

Maybe it is the person who comes to the software developer and says, this is what I am envisioning (beyond a reaction to an issue), this is what would make things better, this is what would move us forward, maybe that is the person who should be heralded. 

Once again, my friend nails it. For many organizations, the programmers solve “the computer problem in front of them which has been tagged as a priority.”

Is that what your organization’s programmers do?

Software engineers are there to help with human, business problems. Not computer problems. In fact, well-trained and thoughtful software engineers will discourage the use of software when they think it’s the right thing to do, just as civil engineers will discourage the use of concrete barriers when visibility is more important than sturdiness. In many process workflows, human input is more important than automation. Software engineers who are members of ACM or IEEE have a code of ethics that underscores their responsibilities in this regard.

Software engineers are there specifically to collaborate with others to think outside the box, look at the future, and create a path forward for their organization.

To the very point of “Software Engineering Is a Form of Leadership,” software engineers are leaders in this context in the very basic sense that software, as a journey, has no known end (remember: if there were a known end, we would just create hardware). This journey is filled with uncertainty and anxiety, if nothing else. If this weren’t the case, then ERP implementations would not cause nightmares and waste billions of dollars, year after year after year.

All of this brings us to Scrum.

Scrum — as difficult to get right as ballet — is a key tool to helping manage this anxiety. Scrum says: let’s take our uncertain journey one step at a time. Let’s be transparent with one another about our feelings and anxieties, and let’s commit to inspecting each step of our journey, and let’s commit to adapting based upon what we find after each step.

The three pillars of Scrum — transparency, inspection, adaptation — are Leadership 101. We’re going to try something new. We don’t know exactly what’s going to happen, but that’s OK. We will talk often, review what’s going on and how we feel about it, we will make decisions about what’s next, and there will be a person to encourage us along the way.

To be fair, Scrum isn’t only practiced by technologists. It’s practiced by everyone involved in a key initiative. But technologists are the ones who have such a colorful palette of solutions to the problems discovered through Scrum. As a bonus, they (today) learn Scrum in a university setting, and are practiced not just in employing it, but in teaching it.

All too often, however, these points are lost on so many organizations who hire these technologists…all because of their experience, exposure, and habits.

What can you do about this?

Back to the power of the question: “Are we taking the time to learn the ins and outs of Scrum to our advantage? I hear it’s really difficult to do well, like ballet. What could we do to learn more?” Or perhaps, “Do we think that we are effectively confronting and addressing the problems we face today? What are our anxieties about what lies ahead, and what are we willing to do about those anxieties?” Or something like that. You’re smart. Take it from there.

Finally:

So, what you describe is your experience; it certainly is not mine. Maybe I really don’t understand what a Real software engineer is and how hidden beneath his exterior is a true leader waiting to be acknowledged — if only given the chance and “proper care and feeding.” So much for the rest of us saps, who toil at our tasks and aren’t offered the six-figure salaries of those in the IT department. Did you consider that maybe these software engineers aren’t interested in a leadership position? I just don’t understand why they and using Scrum makes them so much more worthy than the rest of us.

But, like I said when I started this, we have just had such different experiences.

The best software engineers — excuse me, leaders — are trusted guides who we look forward to being with, because we know that they will get us where we need to go, and we return to them routinely to seek their guidance and help. If you have software engineers who do not appreciate this opportunity, then you have what we would call code monkeys. Code monkeys are fine. But they are not worthy of being called engineers, let alone leaders. The “programmers” of 30 or 40 years ago who never kept up with the times would be considered the code monkeys of today.

If your organization uses code monkeys and not software engineers, do you care? If you do care, what can you do about it?


I hope you agree that my friend’s willingness to share their organization’s experience, exposure, and habits was a real gift to our dialogue. I am sure, too, that when we have friends like this, that we do everything possible to help them either move their organizations forward, or move on to greener pastures. Sometimes, the problem is that you are the smartest person in the room, and the best option is to leave the room.

I posed a question earlier in this post that I haven’t forgotten about:

Who is responsible for initiating these alternative habits given the chicken-and-egg nature of the problem?

You are! Yes, you. It’s not a chicken-and-egg thing at all. While it might appear that nothing can happen unless your management takes the first move, there is always a chance that your management needs you to make the first move. Sure, if you are wrong, then you will need to move on. But: you already care enough to read about these things. You are smart. You can employ the power of the question to lead from wherever you are today. And if you never try, then you never lead.

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Current Events: 2021 Humility

Slate Star Codex and the State of Things

🎹 Music for this post: https://vimeo.com/70051022.

If you, like I, came of professional age in the earliest days of the Internet boom (we’re talking the early ’90s), you might have been exposed to the overwrought sense of intellectual entitlement and rationalization endemic to the San Francisco Bay area. This has mushroomed in recent years to the point of ridiculousness. And you, like I, might have walked away from it.

I grew up in the New York Metro area, and am no stranger to Regional Superiority Syndrome. Like-minded people in large metro areas, living a balls-out Darwinian oval track race, trying their best to out-think one another, all the while shrouding their self-esteem varia with a veil of civic pride. “We’re a great city, filled with the best minds, surrounded by the best culture the world has to offer. Not here? Sucks to be you!”

Generations of people in Silicon Valley (and in the New York Metro) have produced important things; this is not up for dispute. But starkly missing from this sort of culture is a genuine appreciation for, and sense of, humility.

It is this lack of humility that I find myself responding to in the work that I do. An important part of a CIO’s job is to protect the companies they work for from the incredible amount of bullshit that is threaded through our industry. Promises of AI; new features that are always on the way; so much software that is apparently so great, so easy to use; anything can be solved with an integration or an API; Object Linking and Embedding is architecture of the future (or maybe it was ActiveX); Citrix is good; Cisco is great; Access is wonderful; SAP is amazing; Electron is groundbreaking; Apple is doomed; blockchain can solve issues with tracing lettuce from farm to table; every report is valuable. If you are a CIO, add your own bullshit to this list. I will not disagree.

In this vein, part of our jobs as technology leaders is to pay attention to the culture from which these issues emanate. You might be like me, and you might fail to drag yourself out of bed to do this once as often as you should. I tired of it long ago, but there are moments where I take a deep breath, dive in, and catch up.

An article in yesterday’s New York Times is my latest diving board. Once I came up for air, I realized that I need to share this: If you are a technology leader, this piece is worth your while.

But…TL;DR:

“Silicon Valley’s Safe Space” focuses on Scott Alexander Siskind, creator of Slate Star Codex, a (now-preserved) blog-cum-support-group for Silicon Valley intellectuals who shared thoughts related to rationalism in technology. In the echoes of the dialog from these Bay Area rationalists, you get the sense that these people felt that they were doing something new and different. The naïveté of that notion is amusing.

It would be fair to say that Slate Star Codexers practice (technology-) applied rationalism in the same vein that I practice (technology-) applied rhetorical theory, the principal difference being that rationalism has been regularly and predictably applied to technology throughout history, whereas rhetorical theory has definitively not.

What’s clear from reading the Times article is that many of these folks would like to shelter their discussions from scrutiny and counterpoint from less-than-likeminded individuals. This is why, despite my short summary, I think you should take the time to read the entire Times article, as well as many of the links within. Many folks might be tempted to focus on some of the right-wing versus left-wing issues in the article and in the blog’s content; that would be a waste of time, because there is little notable to be found in that aspect of the story. The bigger story is one of perspective lost to self-importance.

I particularly recommend perusing the Slate Star Codex post titled “Gender Imbalances Are Mostly Not Due To Offensive Attitudes,” a carefully self-disclaimed, pseudoscientific attempt to dissect gender representation in special interest groups.

The post highlights a dividing line between “humanities/empathizing/intuitive” people and “sciency/systematizing/utilitarian” people (the rationalists), and treats the former with a predictable and carefully-buffered dose of contempt.

Next up is a link to a TechCrunch article titled “Geeks for Monarchy: The Rise of the Neoreactionaries.” The Times piece cites angel investor/Andreesen-Horowitz General Partner Balaji Srinivasan opining that he and his cohort “could not let that kind of story gain traction,” ostensibly because it might prove to be perfect fodder for the outsiders, providing a tad too much insight into who these people really are.

Lest you have lost track of how far along we have come, this circle of people includes Mark Andreesen, creator of the world’s first graphical web browser, NCSA Mosaic, as well as its commercial offspring, Netscape Navigator. Mark was the archetype of the perky, Internet wunderkind of the 1990s. Today, his goals are scarier, more divisive, and more threatening than his earliest work, targeting the Bay Area rationalists through a media outlet via his a16z brand.

You also should not overlook Scott Alexander Siskind’s response to yesterday’s Times article on his Astral Codex Ten blog, in which he defends himself in awkward ways, evoking rationalization rather than rationalism.

Ultimately, what the Times piece helps us see is that the Bay Area technologists’ rationalism is a powerful underpinning for yet-another-inwardly-focused media empire, as if the world needs more of that sort of thing. Poynter’s David Cohn summarizes this point nicely.


Rationalism is helpful. Anything remotely involving science benefits from it. What I find troubling about this era of Bay Area Philosophy is that its philosophers’ rhetoric is regressive, rather than progressive. It is Plato vs. Aristotle all over again. Recall the first line of Aristotle’s Rhetoric: “Rhetoric is the counterpart of dialectic.” In that single phrase, Aristotle acknowledges the need for dialectic, but warns us that there is more to life than logic. In Aristotle’s world, we consider not just logos, but pathos and ethos in equal measure.

Scott Siskind’s “sciency/systematizing/utilitarian” people may have a hard time with “humanities/empathizing/intuitive” because it is more comfortable to suck the safe teat of logic. But humans are rarely logical, and we are fools to believe that we are rational. Only through humility can we come to terms with this. “Sciency/systematizing/utilitarian” people sometimes like to label matters of ethos and pathos with a dismissive epithet: “soft skills.” These cannot be empirically evaluated through rationalism, therefore they are not worth the time to pursue. What the rationalists fail to see is that this philosophy itself is a logical fallacy: an enthymeme, better-known as “a syllogism where one or more of the premises are implied rather than stated.” You can thank Aristotle’s Rhetoric for that.

As Times author Cade Metz put it:

“Slate Star Codex was a window into the Silicon Valley psyche. There are good reasons to try and understand that psyche, because the decisions made by tech companies and the people who run them eventually affect millions.”

If the people who run our tech companies fail to nurture humility, vulnerability, and empathy, then they will never be able to solve humans’ thorniest problems. What we see in the Times article is a classic imbalance between objectivity vs. subjectivity, and a call to do more. All fields need to consider the relationship between these two viewpoints; one is not more relevant than the other.

Will our profession allow these Bay Area rationalists alone to define what gets said, and what gets funded? Or will we (hopefully) promote a more balanced discussion? Read the Times article. Get up-to-speed. Please do your part to contribute to a balanced conversation.

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Humility Truth

The Problem With Truth Is That We Think It’s Easy

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

Lies take many forms. The most troublesome ones involve the liar taking advantage of the audience’s trust when the audience would benefit from the truth more than the liar would…and when it’s far easier for the audience to trust than it is for them to seek the truth.

Every lie’s potential success is dependent upon its audience’s trust. In too many situations, trust trumps truth, because trust is easier.

I am sometimes troubled by the lack of effort that we put into our endeavors to discern something approaching truth. How can we help others if we don’t adequately comprehend the time that we must invest to gather the details we need to truly understand them, and their circumstances? In our profession, employers all too often don’t cultivate a culture that supports this way of working.

Most people would not rush to have surgery until they have had many doctor visits, discussions and tests over several days or weeks. But when we develop or introduce technology solutions for our “patients,” why do we so often fail to allocate the time to understand them, and their problems?

It’s because we think too highly of ourselves.


Take a moment to recall grade school art class. I hope you can recall learning about the differences between realism and impressionism.

That puts me back in the 1970s. At that time, photography was a mature, nearly 150-year-old practice, positioned in stark contrast to its older sibling, painting. Back then, however, even the finest photographer’s technique couldn’t adequately replicate the color range and dynamic depth of real life. Nonetheless, photographers made every attempt to get as close as they could.

The photographic frame is an incredibly small, two dimensional window into a 360°, three dimensional moment and place in time and space. It is always a mere selection of a world that the photographer decided was important to capture. A photograph represents a decision, more than anything else. While photos might achieve realism in a way that paintings cannot, they remain impressionistic documents, whose intent it is to convey something that the human behind them wanted to convey.

When I was young, I became fascinated with photographing the nighttime version of our world. Neon lights, twirling gas station signs, dimly lit people, the lines of red and golden beacons emitted from the back and front of automobiles grizzling by. The tools available to me as a young photographer in the 1970s were limited. It was impossible to reproduce on paper what my eyes perceived.

Today, this problem has been largely solved. Our latest cell phones can produce photographs that resemble the incredibly challenging high-contrast spectacle of our nighttime vision.

To achieve this, our phones take hundreds of photographs in rapid succession, computationally stitching them together, taking the richest and most optimally exposed details from each frame. The final result is a stunning composite that replicates your natural perception better than any tools we’ve ever previously had.

The film photographers of my youth would (and still do!) cry foul, asserting that these photographs are pure artificial trickery. Our eyes would disagree. This illustrates something interesting: in order to achieve something that is closer to “truth,” we must collect multiple views, from different perspectives. It seems paradoxical that conveying something as simple-seeming as truth requires such complexity. Hence the Yiddish proverb:

Truth is the safest lie.

Photography is only one tool in our communication arsenal; the written and spoken word are far more regularly employed. Do we consider that our utterances have the same limitations as the simple photographs of yore? More often than we would like to admit, words are ambiguous, and they are always strung together by imperfect creatures. When any person speaks or writes, there is a good chance that their words will be perceived differently by different people. A simple set of words alone cannot adequately express an idea, in the same way that one simple photograph cannot convey a scene with the depth, breadth, and dimensionality of real life. Language is, at best, impressionistic.

Yet, the vast majority of public discourse today assumes that a few simple words can convey truth. If you don’t believe this, then you may have never visited Facebook or Twitter.

Just as one photograph is not enough, one word is not enough. One sentence is not enough. One paragraph is not enough. One book is not enough. To discern something worthy of being called truth, people need to gain perspectives from multiple photographs…multiple words…multiple sentences…multiple paragraphs…multiple books.

Of course, this is the essence of learning. But in recent decades, we have seen learning increasingly demonized. Should something take too much effort to understand, we are told that it is “intellectual.” Sometimes, we are told that learning is an exercise for “elites.” If something is “complex,” we are encouraged to postpone digesting it until we have time.

But learning demands that we find multiple perspectives. It requires critical thinking, looking through and past the imperfections in our written and spoken interpersonal communications. This takes time. We like things to be simple, but truth isn’t simple.

Is it fair to say that calculus should be simple? Or that it’s a bunch of bull because it’s complex?

Is it fair to say that the theory of relativity is a bunch of malarkey, by the same standards?

Is it fair to say that British history is bollocks?

The conceit of modern humanity is to believe we can distill truth from a few soundbites, whether through one or two books, or one or two social media posts. The arc of this extreme conceit arguably began in September 1982, when USA Today published its first issue. That conceit — however attractive it was at the time — continues to erode our comprehension of the difficulty of truth to this day.

No matter how hard we study language in school, every one of us struggles to successfully communicate the many goings on in our world. Unfortunately, our choices seem to be either a) perceived as a complex, talkative bore, or b) to be perceived at all. We too often choose the latter. That choice promotes ego over truth.

Our egos are a bigger problem than we think. Not only do they prioritize our simple desire to be heard over producing something worthwhile to hear, but our egos lead us to believe that our capacity for language is a magical, God-given gift that makes us superior to other creatures. You and I have been programmed to believe that a paragraph like this one is vastly more sophisticated than a dog’s bark. If that were true, this might be the last essay ever written about truth.

It’s no wonder why dogs so often ignore us.

Discuss this specific post on Twitter or LinkedIn.

[Logo]
Categories
Antipatterns Compassion Invisibleism Leadership Vulnerability

Revisiting Patrick Lencioni’s First Team: It’s a Fractal!

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

As I’ve mentioned before, I’m not an avid reader of business nonfiction bestsellers. Books that have been foundational to my thinking have been at least somewhat academic (and unfortunately esoteric) in nature, like Aristotle’s Rhetoric and Kenneth Burke’s Language as Symbolic Action. If you’ve been following me on these pages, though, you know that I delight in citing two books that are straightforward yet uncommonly seen in offices around the world. There is, however, a third approachable book that I am fond of, which you might have read before, since it is comparatively well-known. That book, nearing its 20th birthday, is Patrick Lencioni’s The Five Dysfunctions of a Team.

As with all things popular, critiques of Five Dysfunctions are in no short supply. The book’s Wikipedia entry does its job on this, citing some thoughtful summary criticism, noting that the “book is explicitly a work of fiction; it is not based on research and its practical recommendations lack empirical support.” There is truth to that, but if you have been following me on these pages, you will remember that I have a firm belief that truth is best derived from considering multiple perspectives over time. The many sorts of responses to Five Dysfunctions that have been penned over the years have brought helpful real-world framing to the book’s core concepts, adding value through a globally-shared dialog.

Here is yet another response, albeit one that I hope you find to be new and refreshing.


Like seemingly everything else from Five Dysfunctions, the “First Team” concept has been through the point-counterpoint wringer over the past two decades. If the “First Team” concept is unfamiliar to you, then let’s listen to Patrick Lencioni himself introduce it:

I’d like to suggest that, rather than eschewing ideas (such as this one!) that might not be strictly empirical, we consider them, at the very least, to be valuable thought exercises.

I am fond of the “First Team” thought exercise. Why? Well, I have been part of no fewer than five senior management teams in my career, and each one of those teams was at its weakest when we were not attendant to one another, and when we spent the majority of our time in our vertical silos. We were not as strategic, and our teams were not as tightly focused on the company’s mission, when we were more attendant to our departments than to senior teams. Anecdotal? Perhaps. But at the very least, I have developed an opinion that the “First Team” is worth talking about from time to time, wherever you may work.

A “First Team” Thought Exercise Extension, in Two Parts

Part The First

Whether we like it or not, our jobs are at least somewhat framed by our titles, whose primary purpose is, more or less, to denote our roles. These titles, apart from “President” and “CEO,” always connote some form of swim lane that we work within.

New-age management philosophies like Teal and Holacracy aim to reduce the significance of titles in an effort to encourage an organization’s members to better appreciate (and contribute to solving) the many challenges that exist across its functions. However, these management styles present their own challenges. First off, they are wholly unfamiliar to the majority of the working population. More notably, however, in accordance with the valiant mission to decentralize power and decision making, they sometimes confuse people who feel uncomfortable making certain types of decisions, and who would better serve an organization when given at least some amount of explicit direction. Human beings are animals (which we too often forget), and animals are conditioned to exist within a power structure, whether we like that or not.

This is not to say that Holacracy or Teal are unworthy of further work and refinement; they most certainly are. What’s more effective to say is: work is not what we want to do in comparison to the better parts of life (if it were, we wouldn’t get paid for it), and doing what we can to help it be less of a drag will vastly increase the likelihood that our employees will stay with us to solve the problems we are paid to solve. One thing that seems to resonate with all workers is when power structures are absent enough to allow people to breathe and bring their own values to the table, yet present enough to provide clear direction when needed.

All of this is to suggest that there is a desirable balance between power presence and power absence, and that power absence is something that needs focus, since it is not as natural as power presence. The “First Team” thought exercise is most useful, in my opinion, in helping organizations find that better balance. That’s because, when we encourage a First Team mentality, we have to work hard ensure that the teams of people who report into the First Team have healthy team dynamics of their own. More on that in a bit.

I think teams struggle to identify when it’s time to engage further with the “First Team” thought exercise, to calibrate their work toward its prescribed dynamic. Here are six questions that will help you know:

  1. Are the team members aware of each other’s professional issues, and are they willing to spend the time to contribute to each other’s success in overcoming those issues?
  2. Are the team members aware of each other’s personal issues, to the extent necessary to help others empathize with their challenges meeting professional expectations?
  3. In the spirit of invisibleism, are all team members paying attention not only to what they see, but what they do not see?
  4. Do the team members have a rapport that allows for vulnerability on a routine basis, wherein a team member can openly share a personal deficiency or fear without reprisal, and with compassion?
  5. Does any member of the team feel that it’s a “drag” to spend time with their “First Team” when compared to spending time with the team who reports into them, or with their customers/stakeholders?
  6. Are there “factions” within the team that draw a subset of the team together more powerfully than the entire team is drawn to itself?

If you can answer yes to any of these six questions, it’s time to recalibrate your First Team dynamic.

It’s entirely possible for the First Team concept to go too far. That is easier to identify through these two anti-patterns:

  1. When the team too often feels like an “escape” from the difficult work any of its members have to do, and First Team members abandon their responsibilities to their Second Teams.
  2. When (you are lucky enough to hear grumblings that) the team is a “clique” who merely likes to enjoy lunching and drinking together, and is inaccessible to outsiders.

Remember, this is all about balance.

Part The Second

Sometimes the best way to see where you are is through triangulation.

In this case, let’s consider what all of the above means to the team of people who report into you, who students of Lencioni might call your “Second Team.”

As a leader for your Second Team, you would do well to encourage them to be a First Team unto themselves (and I do mean that they, without you, comprise this First Team). Despite all that has been written about Patrick Lencioni and his work over the years, this is not a conclusion that most people seem to draw, yet I suggest that this is, in fact, your most important responsibility as your Second Team’s leader.

In other words, don’t limit the “First Team” thought exercise to your executive team. Understand that it is fractal in nature, and you would do well to encourage it wherever you find leadership groups in your organization. Wherever a First Team exists, the Second Team will need to be able to better self-manage when their leader needs to tend to his or her First Team needs, and the First Team thought exercise will be especially valuable to prepare that Second Team for those moments.

Are you creating an environment where your Second Team can answer “yes” to the six questions above, while avoiding the two anti-patterns?

If so, then congratulations.

If both your First Team and Second Team are exhibiting the optimum balance, then hats off to you: it’s time for a well-deserved, relaxing vacation.

But we are imperfect creatures, living in an imperfect world. Most of the time, we will find ourselves working on maintaining the right balance between nurturing our First Team while helping our Second Team nurture its own First Team dynamic.

Remember: what we are looking to achieve, in the end, is an appropriate balance at any given moment between power presence and power absence for the people who are looking to us for leadership. If your Second Team is able to be its own First Team, then step away and work on your First Team. If your First Team and Second Team are both having problems, do not focus on your Second Team at the expense of your First Team, but don’t walk away from them, either. Seek to help your Second Team regain its balance while you remind them that your First Team needs balancing, too. Make the balance part of the conversations you have with both of your teams.

But keep a close eye on anti-pattern #1. None of the above is to suggest that your Second Team should ever feel like they have been abandoned by you. They deserve your leadership. Power abhors a vacuum, and our animalistic conditioning for leadership structures will ensure that your unofficial replacement is eventually found. That would be a tragedy for your team.

The “First Team” is a handy tool. It is a fulcrum for introspection, and it can help you achieve the some of the best elements of Teal and Holacracy without completely reinventing your organization. Keep it in a front pocket, use it often, and don’t neglect your duty to pay it forward to the teams you lead. It’s good for them today, and should you depart — whether through attrition, retirement, or otherwise — it will condition your organization for smoother succession tomorrow.

Discuss this specific post on Twitter or LinkedIn.

[Logo]