What do your teammates call the audience for the software you create or deploy for your organization?
Employees
End users
Humans
Associates
Users
Customers
If I were a betting man — or a cheap psychic — I might bet that your answer is 2 or 5. Despite my wary ways, however, I wouldn’t hesitate to bet that you didn’t answer with 3.
Over my decades in this business, I confess that employed answer 5 many times. With each passing year, though, when I say “users,” I feel more and more ashamed of myself. I’m going to be lazy here and quote myself from an interview I did in 2019 with Phil Weinzimer:
I encourage my teams to avoid the terms “users” and “end users” whenever possible. These terms imply a class divide. Arguably, our industry has adopted these terms to help us empathize with people who we are not. But I find that to be an incomplete thought. It’s a very condescending concept when you think about it. We are all people, and we share similar limitations. If we are solving problems, and we create an “us” versus “them” scenario, we are really not putting ourselves in the same bucket as our customers. Some people will say to this, well, if I create something that works for me as an engineer, it will not work well for a non-engineer. I say: don’t create something that works for you as an engineer. Create something that works for you as a non-engineer. If you cannot get in touch with your inner non-engineer, then I believe you have further personal development to do!
Listen to your teams over several hours or days. You will likely hear the term “users” pop up from time to time, and it might just start to feel like weeds or crabgrass in your lawn or garden in mid-summer. I suggest that this as useful an indicator of an opportunity for elevated humility that you can find in our teams.
It’s wise to remember that we are all simple bags of blood and bones. No one of us is more special than another. We may be asked to perform duties because of certain willingness or abilities, but the people who we serve deserve every bit of us being just like them that we can give them. You will never — never — deliver a brilliant solution to the people you serve when you come to the table as the person who you are, but who they are not. This gets to the root not just of humility, but of empathy as well.
Will you admit that you are a small, meek animal in a universe that is infinitely larger than you are? Will you admit that you really understand very little, and that you will never truly understand everything about your life?
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?
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?
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.
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.
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.
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.
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?
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.
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.
We lean on each other to get through the tougher parts of life. On our best days, we are eager to help one another.
We watch a friend or colleague struggle with a new task that we have practiced. We want them to know that it will become second nature to them, too, once they get through it a few times. We want to give them hope and promise. We say:
It’s easy! Let me show you.
With those six simple words, offered innocently, we introduce a heap of risk.
Have you ever struggled with a task, only to been told by someone else that “It’s easy!”?
How did that make you feel?
“It’s easy” is possibly the most commonly-tendered unwitting expression of condescension known to mankind. In the world of software deployment, in the context of The Invisible Propeller, it’s downright deadly.
It would take more than both hands of every software engineering and IT professional who ever lived to count the number of times that “It’s easy!” has made people pretend to know what they are doing when learning a software feature.
When “it’s easy” for you (a technology professional) and not for me (a “mere user”), why do I want to admit to you that I now feel like an idiot?
Is there a handy remedy for this? Try this on for size: instead of suggesting that something is easy, experiment with admitting that something is actually a pain in the neck, even if you no longer think it is. We all connect better with others when we come from below them, rather than from above them. In other words, keep a keen eye on lowering your status when helping others.
This doesn’t have to sound negative:
“This might be tricky the first few times you try it. Let me see how I can help you get there. Let’s try this together.”
Although this can create a strong human bond:
“Oh gosh, yes, this can be such a pain. Let me show you some tricks I’ve learned.”
These phrases are disarming. They are vastly more likely to result in open conversations that will get people to admit what they don’t know, without fear of feeling stupid. More pertinently, they are more likely to wind up helping your audience members get where they want to be.
It’s harder to do all this than it is to say “it’s easy.” But every time you try, you will gain momentum…and ultimately, you’ll become a more helpful human. That’s a nice place to be!
Those differences are telling. Two years ago, post-election, with our cold civil war a-brewing, politics was our fascination. Today, we are weary for just about anything other than entertainment. Our brains and our souls need a rest and a reset.
Interest in work-related topics is also in an ebb cycle. People are not in the mood to read books, columns, or blogs that consist of generalized advice aimed at improving their work lives. I suspect people realize that questions about what’s truly going on right now in the workforce have no easy answers. What’s truly going on is that our cold civil war has bled into our work life.
The Progressive CIO was borne out of my epiphanies in the wake of COVID-19 — a long and turbulent wake that we are still navigating. My writings have reflected my work and encounters along the way. In recent months, however, I’ve slowed. I have nothing to offer that I think can address our cold civil war, and writing more about the eight foundational values of The Progressive CIO seems tone-deaf at the moment. While those values are — and always will be — important, getting back to considering them will require navigating out of our current wake, which requires addressing politics.
We’re not supposed to have politics in our workplaces, though, right? As it turns out, it’s too late for that. As we attempt to return to offices, COVID has brought politics into the workplace as never before, for a simple reason: the semiotics of the face covering.
I cannot think of any symbol in the workplace — or in everyday life — that has communicated a political stance so overtly in my lifetime as the manner in which face coverings are (or are not) worn. This is not to say that wearing a face covering or not is, unto itself, a form of political expression. As with a tree falling in the forest, it’s the junction of the act and the audience where meaning takes shape.
Take a look at these four different face-covering scenarios, and reflect on what they say to you:
At least one of those will strike a nerve within you, wherever you sit on the political spectrum.
Semiotics are a part of everyday communication and everyday life. Face coverings fall into the non-language communication subset of semiotics, which are distinct from the more-commonly-encountered non-verbal communication. Non-verbal communication involves a language; that is to say, a system of communication with a learned form and structure. Music is a language, for instance. Non-language communication, on the other hand, lacks any system or learned form and structure. Lines on our roads are non-verbal communication; a driver swerving around those lines is non-language communication.
Non-language communication isn’t discussed much outside of academic circles. If it were, I suppose we might have a better public dialog about face covering techniques. I suspect, however, that it wouldn’t have an impact on our current cold civil war at work. Whether we like it or not, masks have become a form of wearing one’s politics on one’s face. The bigger issue is that non-language communication, through its very nature, makes verbal analysis more challenging.
At the present, only fully-distributed workforces are in a position to avoid face covering controversies in daily work life. We know, however, that not all workforces can be fully-distributed.
Proposed vaccination and testing rules are about to increase the magnitude of the COVID-19 wake, before the current tide has finished going out. How a company reacts to and addresses these rules puts politics on a company’s face as well.
When we are in a place where we know the solution is: “Take politics out of the workplace” and those politics are now a way of life as a matter of public health, then where does that leave us?
It leaves us doing our jobs and trying not to think about them when we don’t have to. It leaves us tired of politics, even if we are energized by them. (Which leaves me to ponder: If one is energized by politics, then what does that say about that person and their priorities?) It leaves us retreating to our homes, our families, entertainment, and the things that truly matter in life. That’s not all a bad thing. But if our lives require us to work, we’re all in a pickle for the time being.
Back to those eight foundational values of The Progressive CIO: I would be remiss if I didn’t take a moment to reflect on them, and how they play a role in getting ourselves out of our current situation:
Vulnerability: Are we willing to be honest and open with one another about how our current world is affecting us? This will include senior leaders acknowledging that these vulnerable voices need to be heard.
Humility: Are we willing to recognize that this situation is bigger than all of us, and that it is a comedy of errors, of sorts, if not a true human tragedy? It’s difficult to laugh at, but I believe we have to if we are to collectively solve it.
Empathy: No matter your politics or attitude, will you try as hard as you can to see the validity in the other side’s point of view? This doesn’t mean that you agree that the other side is right; it merely means that you work hard enough to try to understand and not summarily dismiss.
Patience: This might be the hardest thing of all. People were tired of not getting their hair colored one month into the pandemic. Do we have the collective patience to deal with one another to move past where we are today? We don’t have a choice, because it will be a long haul. If we can acknowledge this, we stand a chance to get a clearer understanding of what the path to progress looks like.
Compassion: Do we genuinely care about each other, to the extent we are willing to go out of our way to bring comfort to others?
Curiosity: Are we willing to explore the new and unseen options that we have not yet explored to get us past where we are today?
Commitment: Are we willing to make true commitments to one another, and follow through on those commitments?
Willingness: Do we have genuine willingness to do all of the hard work above?
Given how tired we all remain, who can we expect to initiate this sort of effort on a meaningful scale?
Only those who govern us.
I’m not talking about legislation; I’m talking about leading by example, living those eight values. If that sounds like a tall order, it most certainly is. That’s because there is a chasm between politics and governance.The government I am alluding to does not exist today, and has probably not existed in our lifetimes. Until we can pack up our politics, no governing will happen. Until we can pack up our politics, no leadership will happen. Until we can pack up our politics, our workplaces will not flourish. Until we can pack up our politics, the world will not be the place we want it to be. The good news? Packing up our politics starts, apparently, with the books we buy.
Postscript
A friend shared the following response:
I loved your start – the comparison of the top books is quite telling, and I would not have thought to make that comparison. I am right there with you throughout your article until the end. Who should or will initiate these changes? For me it’s all of us, it’s the workers, it’s the everyday people in the workplace, it’s you and it’s me. I think we can be sure right now our leaders are quite absent, especially those who govern.
One of my favorite quotes I encountered along the way of my doctoral studies comes from Ralph Stacey, “Change can only happen in many, many local interactions.” For me, this means it is in the small conversations that spark other conversations and so on that we begin to change culture, that we begin to change each other. I is in those times of making space and being vulnerable that we listen to others and that we speak our truth. In those moments one or the other or both are truly changed, and that sparks a change in the next conversation that we have. For me, it is in this process that true change happens. Not in the top down, governed-inspired or directed change.
But that’s me, and perhaps I am missing some of what you are concluding or alluding to.
I agree with this in spirit—and I had wanted to end with this sentiment. But after reviewing the how the foundational values might address this, and pondering how realistic this would be, I felt this conclusion would sound trite. There is a realist at work in my brain right now. This sort of change benefits from top-down work of unimaginable magnitude. Imagine the impact our governing bodies could have if they demonstrated these values in their everyday actions!
In the “DVD bonus feature” spirit of allowing you to choose your own ending, I encourage you to do just that with this post. I would love nothing more than for everyday people—rather than government—to achieve this change.
In the end, if this post merely encourages discussion, then it will have served a purpose.
When you get to know someone, do you focus more on what’s wrong with them, or what’s right with them?
Is there a benefit to focusing on one or the other?
How do you feel about your own flaws? Do you admit them, or do you try to hide them or compensate for them?
Why do you think that’s the case?
When I was a young executive, my boss once shared the following pearl of wisdom with me…it’s explicit, but this is the way I learned it:
If you look up someone’s ass, you’re always going to find shit.
—H. Eliot Subin
Every one of us has something that, once discovered, will be off-putting to others. If we look hard for these things, we are certain to eventually find them.
When we find someone else’s poop — knowing that we each have our own — why does that so often surprise us, and make us think differently about them? Perhaps because most people like to like people. When we get to know a person and we like that person, it brings us joy; it makes us feel like the world is a better place. We like the honeymoon period, before we find the poop. We like the Hallmark Channel.
When we discover flaws in people, it’s all too easy to feel let down. But it’s a terrible mistake to dismiss someone else when we discover their poop. How would you feel if the shoe were on the other foot?
If you’ve been in business long enough, you’ve undoubtedly been asked about the leaders who have inspired you on your journey. For me, the most immediate answer has long been George Martin. He’s an admittedly unusual choice. I’m a lifelong Beatles fan, and while I love the Beatles’ music, I find their group dynamic even more intriguing.
The Beatles were four young men who loved music, and who had a deep appreciation for one another. But despite a few friendly and intense years in the early half of their career, they were decidedly not in love with one another. In fact, their creative peak paralleled their social nadir. They had different values in life and in their music. They worked hard to keep themselves together in the way the world expected, and George Martin’s greatest contributions were in providing musical balance to complement their competing ideas. Watching his deft, delicate, minimalist hand at work in Peter Jackson’s recent Get Back documentary series is a powerful illustration of this. As their closest colleague in the studio, he routinely mediated compromise, helping four very different people become something much greater than they were individually.
At this point, it feels appropriate to revisit the quote from Victor Hugo on The Progressive CIO’s home page, which presaged this very post two years ago:
“But who among us is perfect? Even the greatest strategists have their eclipses, and the greatest blunders, like the thickest ropes, are often compounded of a multitude of strands. Take the rope apart, separate it into the small threads that compose it, and you can break them one by one. You think, ‘That is all there was!’ But twist them all together and you have something tremendous.”
—Victor Hugo, Les Misérables
If you lead teams of talented and smart people, they will have differences with one another — sometimes significant ones. They will find things to dislike in each other’s philosophies, politics, lifestyles, or approaches. It is your ability to embrace, cultivate, coach through, and complement these differences that paves the road from disaster to brilliance. What does it take for you to develop a deft and delicate hand to manage this?
First: Never forget your own flaws. This requires humility.
Second: Get comfortable talking about those flaws, which will be reassuring to those who you serve and who you lead. This requires vulnerability.
Third: Develop an ability to not be surprised or disappointed when you find flaws in others. In conjunction, develop the ability to lock, arm-in-arm, in your shared humanity, This requires compassion.
Fourth: Understand that what you perceive as a flaw might not be perceived that way by others. Try to look at this perceived flaw from different perspectives, and consider invisibleism along the way. This requires empathy.
Fifth: Learn to take a breath and stay calm when others find flaws and react in unbecoming ways. This requires patience.
Sixth: When walking through these concepts with someone who is struggling with what they have found: stop, smile, and share Eliot’s quote.
Then, explore the dialogue that opens this post. This requires willingness.
Finally: Teach these lessons forward.
Of course, there are limits that, from time to time, you will confront in managing this dynamic. The Tyranny of Competence comes to mind. The best way to address this, should you need to, is through compassion, and not through anger, remembering that we all have our flaws. This will give you the best shot at addressing difficult interpersonal situations before someone simply has to go.
I think many workplaces understand the need to manage differences; what differentiates the best ones is the way they manage the flaws we discover in one another. There will be failures. There will be break-ups. Even George Martin’s work couldn’t keep the Beatles together. But a great team’s finest work comes only with significant attention to managing their reactions to one another’s flaws, however ugly they may be.
How many essays have you read about the power of active listening? Given the volume of writing on the topic, are you curious about why so many people seem so bad at it? I have an idea: there is not enough written about the complementary idea of shutting up.
Our ability to learn when to shut up is arguably more valuable than any active listening techniques we can master. Try something the next time you are tempted to speak: Stop, count to three, then ask yourself: Why am I about to open my mouth? Is this about me (merely demonstrating something that I know or wish to share because of how it makes me appear)? Or is it genuinely for the benefit of others?
More than any of us would like to admit (or perhaps more than any of us fully appreciate), we speak merely to increase our status or relevance in a series of conversations. Many years ago, I participated in an Agile Systems Engineering Workgroup for INCOSE, and was fortunate to spend time with a particularly well-rounded engineer who introduced me to the work of Keith Johnstone, an improvisational theater pioneer. In his famous 1979 work, Impro: Improvisation and the Theatre, Johnstone offers a valuable and breathtaking illustration of how this sort of dynamic plays out in everyday conversation. I promise that once you have read the following excerpt, you will never see a meeting or simple daily interaction the same way again:
When I began teaching at the Royal Court Theatre Studio (1963), I noticed that the actors couldn’t reproduce ‘ordinary’ conversation. They said ‘Talky scenes are dull’, but the conversations they acted out were nothing like those I overheard in life. For some weeks I experimented with scenes in which two ‘strangers’ met and interacted, and I tried saying ‘No jokes’, and ‘Don’t try to be clever’, but the work remained unconvincing. They had no way to mark time and allow situations to develop, they were forever striving to latch on to Intetesting’ ideas. If casual conversations really were motiveless, and operated by chance, why was it impossible to reproduce them at the studio?
I was preoccupied with this problem when I saw the Moscow Art’s production of The Cherry Orchard. Everyone on stage seemed to have chosen the strongest possible motives for each action—no doubt the production had been ‘improved’ in the decades since Stanislavsky directed it. The effect was ‘theatrical’ but not like life as I knew it. I asked myself for the first time what were the weakest possible motives, the motives that the characters I was watching might really have had. When I returned to the studio I set the first of my status exercises.
‘Try to get your status just a little above or below your partner’s,’ I said, and I insisted that the gap should be minimal. The actors seemed to know exactly what I meant and the work was transformed. The scenes became ‘authentic’, and actors seemed marvellously observant. Suddenly we understood that every inflection and movement implies a status, and that no action is due to chance, or really ‘motiveless’. It was hysterically funny, but at the same time very alarming. All our secret manoeuvrings were exposed. If someone asked a question we didn’t bother to answer it, we concentrated on why it had been asked. No one could make an ‘innocuous’ remark without everyone instantly grasping what lay behind it. Normally we are ‘forbidden’ to see status transactions except when there’s a conflict. In reality status transactions continue all the time. In the park we’ll notice the ducks squabbling, but not how carefully they keep their distances when they are not.
Here’s a conversation quoted by W. R. Bion (Experience in Groups, Tavistock Publications, 1968) which he gives as an example of a group not getting anywhere while apparently being friendly. The remarks on the status interactions are mine.
MRS X: I had a nasty turn last week. I was standing in a queue waiting for my turn to go into the cinema when I felt ever so queer. Really, I thought I should faint or something.
[Mrs X is attempting to raise her status by having an interesting medical problem. Mrs Y immediately outdoes her.]
MRS Y: You’re lucky to have been going to a cinema. If I thought I could go to a cinema I should think I had nothing to complain of at all.
[Mrs Z now blocks Mrs Y.]
MRS Z: I know what Mrs X means. I feel just like that myself, only I should have had to leave the queue.
[Mrs Z is very talented in that she supports Mrs X against Mrs Y while at the same time claiming to be more worthy of interest, her condition more severe. Mr A now intervenes to lower them all by making their condition seem very ordinary.]
MR A: Have you tried stooping down? That makes the blood come back to your head. I expect you were feeling faint.
[Mrs X defends herself.]
MRS X: It’s not really faint.
MRS Y: I always find it does a lot of good to try exercises. I don’t know if that’s what Mr A means.
[She seems to be joining forces with Mr A, but implies that he was unable to say what he meant. She doesn’t say ‘Is that what you mean?’ but protects herself by her typically high-status circumlocution. Mrs Z now lowers everybody, and immediately lowers herself to avoid counterattack.]
MRS Z: I think you have to use your will-power. That’s what worries me—I haven’t got any.
[Mr B then intervenes, I suspect in a low-status way, or rather trying to be high-status but failing. It’s impossible to be sure from just the words.]
MR B: I had something similar happen to me last week, only I wasn’t standing in a queue. I was just sitting at home quietly when …
[Mr C demolishes him.]
MR C: You were lucky to be sitting at home quietly. If I was able to do that I shouldn’t think I had anything to grumble about. If you can’t sit at home why don’t you go to the cinema or something?
Have you ever been Mrs. X, Mrs. Y, Mrs. Z, Mr. A, Mr. B, or Mr. C? I suspect you have been all of them at one time or another; I certainly have. More distressingly, we’ve witnessed this very same dynamic play out before our eyes every day of our lives. More often than we realize, we speak in an attempt to elevate our status, rather than for the benefit of others.
Whenever I revisit this excerpt, it amplifies my desire to shut up in almost every situation imaginable; it’s better to let others have the silly status competition, I remind myself.
Speaking and status play become especially problematic during the sorts of discussions that occur during daily software engineering and IT work, which was the context for the conversation with my INCOSE colleague who introduced me to Impro. Allow me to share a story from my career (with names changed) to illustrate this point in ingeniare situ.
The scene: A requirements elicitation meeting with software engineers; a business analyst (Hal); a CEO (Stan); and the CEO’s right-hand man (Oliver).
The context: Discussion of a thorny business process problem with no clear answer. Stan & Oliver have very different views on what the solution might be, and they are both quite strong-willed in their vision. Hal is an eager engineer, always ready to offer solutions to any problem at hand, with a seemingly bottomless pouch of solutions.
The group gathers in a small room to discuss the issue. The entire team, including the software engineers, has heard about the business process issue for a few weeks, and everybody came prepared to listen to Stan & Oliver with the intent of bringing everyone’s different perspectives to the table.
Stan & Oliver begin to argue about their competing visions in front of the whole group. All the meeting participants ask questions and make suggestions, but both Stan & Oliver resist feedback. Hal, in particular, makes several false starts at articulating what he clearly feels is a brilliant idea (attempting to gain status), but Stan & Oliver are not ready for it. They are more interested in fighting each other’s views than hearing from anybody else.
After 20 minutes of this, both Stan & Oliver start to slow down, betraying a certain weariness. At long last, they begin looking around the room, with an openness to feedback. Their eyes, however, are more certainly trained on Hal, who they trust more than anyone else present. They look to Hal in a way that a golden retriever might, after being deprived of food for two days. Hal, a dutiful lieutenant, is ready with what he perceives to be a brilliant solution (and to embrace the status he has been granted), and the mood of the room — weary of the arguing — allows him, at last, to go into great detail about the idea he has been pining to offer.
Stan & Oliver seem relieved, and let Hal know that they think his idea might be the best solution. The group agrees to codify the new process into software for the next sprint.
After a week of hard work and a sprint review, the solution is put into production. Everybody is happy, particularly Hal. He’s proud that he was able to diffuse such a difficult situation with his ingenious idea.
But a week after that, Stan & Oliver are not happy with the solution.
Hal is devastated. He comes to me, and tells me the backstory. “My first idea was a failure. But I have two more. What do you think I should do?”
I suggested to Hal that none of his ideas mattered.
“Hal,” I said, “You will undoubtedly need to have another meeting similar to the one you had two weeks ago. But this time, I want you to do something different. Stan & Oliver will once again argue in front of the whole gang. But when they look to you, I want you to remain silent. The issue is that our suggestions are enabling them to avoid the difficult conversations they need to have in order to come to a solution that they both believe in. They want you to feel special, but that won’t solve their problem. I tell you what: I will join your next meeting to support you. If I think you are going to open your mouth in a way that allows them to avoid finishing their difficult disagreement, I will send you a message over instant messenger to help keep you in check.”
Hal agreed. We scheduled the meeting for the following day.
The format and tone of the second meeting was uncannily similar to the one two weeks’ prior. Stan & Oliver continued their now-infamous argument in front of the gang. But the room was quieter this time; Hal had shared my conversation with him and had asked all of the software engineers to take a back seat, as was his own plan per our conversation.
After another 20 minutes of arguing, Stan & Oliver once again grew weary. Predictably, their eyes veered toward Hal, with the very same golden retriever look that Hal had experienced before. Hal looked so incredibly eager to give in. There was a tremble, a redness, an eagerness…then I typed “Shut up” into the IM window in my laptop.
Hal looked down. He looked back up. He took a breath. Stan & Oliver looked at him for about 10 seconds, with no sound uttered. They looked at each other, and at the floor, and at each other, for what was probably only 60 seconds but what seemed like an eternity.
Then, eyes were back on Hal. But Hal dutifully kept quiet.
After 15 or so additional seconds, a magical thing happened: Oliver said to Stan: “I think we need to take this offline.”
The look on Hal’s face was the look of someone who was able to breathe after two minutes underwater — a palpable sense of calm and relief. The meeting ended as any meeting of this type would…with a unanimous eagerness to leave the room and move on to better things.
Stan & Oliver argued daily for two weeks after that meeting.
At the end of those two weeks, Oliver came to Hal and explained that he and Stan had come to an agreement, and they determined a way to address the situation in a surprising way: changing an upstream business process that the engineering team assumed was essentially immutable.
The team got busy writing up specifications and coding the new solution. Two weeks later, the revised software and business processes were put into production, putting a definitive end to the arguments between Stan & Oliver. (Well, at least about this issue.)
This is what led me to coin the phrase “Speaking is disempowering.”
Hal’s desire to offer a solution enabled — in the negative sense of the word — Stan and Oliver to avoid their obligations to argue. In opening his mouth, Hal got in his own way in providing a solution to Stan and Oliver’s problem.
My advice to anybody in a similar situation is to remember that when we take center stage, we force others to the edge of the stage. That presents a real danger.
I believe that “Speaking is disempowering” tells a different story than the more traditionally-offered “Silence is golden.” (Although I do love the modern twist: “Silence is golden. Duct tape is silver.”) It is wise for us to remember that speaking carries a high degree of risk: risk in interfering with the status of others; risk in alienating others; risk in short-circuiting conversation. We often believe that opening our mouth will bring about positive change (feeling like a form of power), but the change it brings is just as often at odds with what we want or need to achieve.
The more we shut up, the more that people within earshot of us are able to draw their own conclusions, in ways that are both satisfying and lasting for them. Our real power comes from the self-control that allows that to happen. When we speak — when we are on center stage — we actively remove the privilege for others to speak and be heard.
Don’t ever forget to listen. But please raise a glass for shutting up.
“The difference between an engineer who can communicate and one who cannot…is a room with a view.”
In other words, if your communication skills aren’t top-notch, your career opportunities — and resultant lifestyle — will be limited. It’s my opinion that this should be the first lesson in any aspiring engineer’s education, lest we set students on a miserable journey toward dashed career expectations.
This is not what you see from the window of your parents’ basement. (Pix4free)
I once had a software engineering student at RIT who told me that he was skeptical about the value of his own major (which is distinguished by a balanced emphasis on human and computing skills.) He said something to the effect of “too many software engineers can get away without knowing anything about computers. Only computer science majors truly understand computers, and I would hire them to program before I would hire a software engineer.”
And there I had it: an otherwise progressive young man within my own field, denigrating the value of what many condescendingly call “soft skills” that are essential to success.
I asked the young man to consider doctors for a minute.
There are MDs who supervise medical research in laboratories for companies. MDs who consult for the government. MDs who work for insurance companies. MDs who perform pathology or radiology. Then, there are the MDs who “lack bedside manner” (many fine surgeons). These doctors are at their best when they are handed an established problem to solve. In software engineering, we might call these people coding monkeys.
But these are not the doctors who elicit problems from patients.
The doctors we tend to value most are those who interact well with us when we don’t feel well, and help us figure out what might be going on. Through keen listening and empathy skills, they are able to turn vague symptoms into accurate diagnoses. These are the doctors most of us seek as a first resort, always ready to lend a listening ear, a thoughtful mind, and a sympathetic eye.
“You,” I shared with my student, “are like one of those doctors.” Computer scientists may be better-trained for the laboratories of our field, away from the patients the software engineers are better-trained to serve, but it’s one thing to understand computers; it is an entirely other thing to understand people.
I’d like to revisit the condescension of soft skills.
What are “hard” skills? Math, science, logic, and other formal methods that bachelors of science work to master. These skills do not come naturally, and are learned through reading, formal exercises, and other pedagogy. Hard skills can be tested objectively.
What scientists refer to as “soft skills” can only be tested subjectively, making them easy for scientists to dismiss. Whenever the term is uttered, the hairs on the back of my neck stand up in the same way that they did when I — as a computer-programming, clarinet-playing, poetry-writing youngster — was called “wuss,” “fool,” “sissy” or many other hurtful things. “Soft skills” is condescending because it is a dismissive epithet, deliberately crafted to distinguish these skills as something “fuzzier” and less legitimate than scientific methods.
Fact is — and I didn’t invent this phrase inasmuch as I arrived at it on my own at some point — the soft skills are indeed the hard skills to find in quantity and quality in the workforce. Most people seem to agree that the Venn diagram of great scientists and great communicators does not have a huge union. (Indicators of the presence of this notion tend to be hidden in comments to articles like this one.) Despite what scientists might like to believe, however, development and testing of subjective skills can be done effectively. Just ask a liberal arts professor.
How would a scientist feel if I were to condescend or dismiss their hard skills by calling them “soft,” given my own capabilities for communication, audience analysis, listening, empathy, vulnerability, trust, and so forth? (I admittedly do this from time to time, just to make a point.) Is it possible for us to move on to a world where we use less judgmental terminology?
We could go with: Objectively-Testable Skills and Subjectively-Testable Skills? OTS and STS.
Let’s posit that engineers who are asked to work with other humans on a regular basis should possess something approaching a 50:50 ratio of OTS and STS. Computer Scientists can be successful with a higher OTS:STS ratio; Software Engineers and IT professionals will be most successful with a higher STS:OTS ratio. I don’t care what the scientists say; that’s a maxim.
If STS and OTS sound novel to you, then I’d ask you to appreciate the fact that I’ve deliberately snowed you. What this is really about is nothing new; it’s simply arts and sciences, in balance with one another.
Great scientists benefit from experience and practice in the arts of life. Scientists don’t serve science; they serve humans. Those who learn this lesson will always have a room with a view.
![[Logo]](https://theprogressivecio.com/wp-content/uploads/2020/07/ProgCIO-1024x1024.png)
