I’ve been waiting to share some antipatterns to the type of leadership we talk about on these pages. Bingo! Got one today.
Imagine the writer of today’s Wall Street Journal feature: The Covid Crisis Taught David Farr the Power and Limits of Leadership. In his presence? A prideful ass. This is a portrait worthy of an M.C. Escher illustration, splendidly serving the article’s two very different intended audiences. It’s a masterpiece — you must read it, really — but be prepared to need an Alka Seltzer by the time you get to the end.
Here are a few pearls of wisdom from the man himself:
“We have a company to run.”
“We have customers to serve and we can’t frickin’ do it if nobody is here!”
“Why did we miss it?”
“I might be wrong, but we get paid to make decisions and make calls.”
“I would never jump off a cliff without knowing a bit about what is at the bottom. But I know you have to take jumps.”
“I got into a lot of heated battles around here in St. Louis because I had the opinion that you can live with this virus.”
“I’m not going to die.”
“I’m too busy to die.”
“I’m not dead, though people have tried to kill me. I’m still quite strongly in charge. And as long as I’m here, our dividend will not be cut.”
“We’ve gone that route, rather than where everyone wears a mask.”
“If there’s more of us around, you got to be doing the right things, you’ve got to be following your own rules.”
“Look. I make s—, and you can’t tell me how I’m making s— when you’re sitting in your goddamn living room.”
“Get your a— out to my factories, look at my people on the line, and tell me if they’re telling me the truth or lying. That’s what you’re supposed to do. That’s why I pay you $25 million a year.”
“It was very energizing to be on the plane.”
“It’s all going back to trying to make people feel like we’re back in business, it’s back to normal, it’s safe, I’m here to talk.”
“People are getting tired of and stuff like that.”
“I can’t believe this thing. It’s July 7th.”
“I got to see some of them for the first time in several months. It was pretty exciting, and I drank too much.”
“People were a little closer than 6 feet.”
“We’re going to have to bring in automation.”
“We’re going to have to take labor out.”
“As soon as you hear someone say ‘the new normal,’ plug your ears, and say, ‘bulls—’.”
Most of all, do read the comments. Hook, line, sinker, check.
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 in writing here on The Progressive CIO is engaging with folks who are not so lucky as I and my peers are. To date, I am preaching to the choir: my LinkedIn profile is filled with people who are a fairly 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 felt like it was not going to land in the right audience. This turned out to be largely true. Despite the post’s novel perspective, there were not too many people in my limited network who seemed to find anything novel or inspirational in it. Sure, I got a good handful of likes, atta-boys, and agreement from all of the usual suspects, similar to what I shared above. 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 great 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 you, dear reader, “Software Engineering Is a Form of Leadership” elicited the sort of response that I have been eager to get ever since my very first article on The Progressive CIO.
I received an adept, articulate, and perhaps even a little angry critical response from one of my closest and longstanding friends. It was the very sort of counterpoint to “Software Engineering is a Form of Leadership” that I needed to help reach the audience I wanted to reach. That response is more of a must-read than anything I have written to date on these pages. What tickles me most is that my friend is a fellow rhetorical theory major, 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 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 (both internal and external), and that are at odds with the profession of software engineering (and IT) as it is 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 statement was like a can opener for my mind. Yep, my friend is right. Only my choir would see it that way…and everybody in our little choir 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 is but a single step in the broader context of evaluating and solving a human problem. We all know that.
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? Well, rhetorical discourse 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.
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 suggest 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. But 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:
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?
But Dilbert is not just a comic: it is an anti-pattern. 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.
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.
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 — ahem, 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:
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.
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 twobooks 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:
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?
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?
In the spirit of invisibleism, are all team members paying attention not only to what they see, but what they do not see?
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?
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?
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:
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.
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.
This post appeared on LinkedIn this weekend, to resounding huzzahs.
“People First; Technology Last,” this isn’t.
Ms. Carter appears to miss that her clever footer amplifies email’s worst traits: email as “The Game of Hot Potato” and email as “Look at me! Working so hard in the off hours!”
Oh, and it gives the recipient even more to read. A lose-lose.
It’s natural and even reasonable to send emails in the off-hours, but such emails should never have to be considered essential to respond to. If you are working after hours and expect an off-hours response, employ something other than email to communicate.
If your after hours email is likely to be interpreted as important enough to force an after hours response in anyone, I suggest you consider the following:
Think about what it is in your personal work relationships that would cause someone to feel compelled to respond in the off hours, and work on that aspect of your relationships. If you need to employ a footer like this, something is amiss in your work culture and/or your work relationships. It might just mean that people don’t know you well enough. Work on that.
Save the email as a draft and send it when you truly need the response.
Compose the email, and employ your email program’s scheduling tool to send it out during business hours.
Or, perhaps, don’t send the email at all. We lived for millennia without email. Schedule some time during a day to talk in person. When we speak in person, we eliminate both the “Hot Potato” and “I’m working hard, see?” aspects of email that are so abhorrent.
Filling up someone else’s inbox just so that you can empty your outbox isn’t respectful in any way, shape, or form.
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:
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!