In this episode:
We all hate conflict. Learn how to disarm the conflict and get back to being on the same page.
Hear about a new way to take advantage of a helpful tool in your toolkit – a tool that that will multiply your effectiveness.
I also talk about the behind the scenes of the podcast and share some tools that I use to document some of the processes required to make the podcast run well.
4 Levels of Thinking as a Geek Leader – This easy-to-read graphic clearly illustrates the 4 Levels of Thinking, individually breaking down each level.
Conflict Resolution Worksheet – Got a conflict to work out? This worksheet helps you figure out how to use the CORE and XYZ methods for your specific situation.
DISC assessment video
Articles – How to: Resolve Conflicts at Work by Emma Johnson, Engineering Management May be the Most Unnatural Act of All by Michael Driscoll
Link to Shotgun sound effect
Becoming a Geek Leader, Season 2, Episode 8.
Sponsored by Geek to Great
Tom: I spoke with Dr. Peter Bamberger, from Tel Aviv University’s Business School, about engineers becoming leaders and he said…
Dr. Bamberger: If you take an engineer, and you want to turn them into a leader in an organization, you tend to presume that you promote them and they’ll sort of learn overtime how to become a leader.
Dr. Bamberger: Some of them will. The vast majority won’t.
Tom: Some of them will, but the vast majority won’t. So here you are. You’re a talented engineer. Maybe you’re running a team of technical folks. But the fact is, they won’t magically get better at things like communicating clearly or delegating effectively, or dealing with conflict in a healthy way. They need to learn those skills. That’s why I created Geek to Great 101. It’s a simple way for you to help your team members with an easy plan to improve these skills and more. For less than $500, your team can start to make progress. Find more information and get immediate access to your first free lesson at brighthillgroup.com/helpinggeeks. That’s brighthillgroup.com/helpinggeeks.
Welcome to the Becoming a Geek Leader Podcast. My name is Tom Cooper. As a geek, I’m on a mission to figure out better ways to lead others at work and at home. Through the Becoming a Geek Leader Podcast, I’m sharing what I’m learning so I can help make you more effective at leading people too. Ready?
This episode is a powerful one on conflict. Conflict, we all have it. Most of us hate it, and even when we find ourselves in a lot of conflict most of us would rather avoid it. Today, I’m going to cover some great ideas about how to lead your way through conflict. And I’ll also be covering a very simple way for you to increase your effectiveness using a tool that you’ve already got in your toolbox. Let’s get started.
Tom: I’m talking about conflict again today. Why? Because we all have conflict. We hate it, but it happens. I like to say, where you have people, you have problems. One study found that U.S. workers spend 2.8 hours per week dealing with conflict. That’s almost an hour a day of conflict. Now, what does that do to morale or to overall team performance? Well, whatever it is, I can tell you it’s not good. Learning to manage conflict with others is a skill you can really leverage when you get to Level 2 of the four levels of thinking as a geek leader.
Announcer: Level 2: Team Member. Level 2 is where you work well with others, and together you all succeed.
Tom: In my life, I have made a lot of mistakes when it comes to conflict. I remember years ago I was working for Price Waterhouse. At that time, I shared an office with a technically brilliant, but pretty abrasive engineer. He really liked to push people’s buttons. Just for fun, he hooked up speakers to his desktop, that was back before most computers had soundcards, and he set up his new mail sound to be the sound of a shotgun cocking. Imagine having this sound behind your back intermittently all day long. [shotgun cocking]
This guy was smart, and he was hard-working. He did a ton of great work. But he used that great work as a weapon to compel management to tolerate his antisocial behavior. Now, one day, I remember I was having a particularly bad day, and I had had enough of his pushiness, and I snapped. I turned around and I said something nasty. Now, conveniently, I guess I don’t remember the details of exactly what I said, but I’m sure it was not nice. He responded in kind and before you knew it, we were both standing up and yelling at each other.
As we were proceeding in this dangerous game, he got closer and closer to me, and at one point he was a couple inches away from my face and he was yelling at me. I remember thinking, “Is he going to hit me?” and then thinking, “Well, if he hits me, am I going to hit him back?” I immediately decided that I was not going to blows over this, but we were at a pride standstill and it was tense. Thankfully, that conflict eventually deescalated without punches being thrown. But how much work do you think we got done that afternoon?
I saw a quote the other day in an article on TechCrunch that said, “Engineers are a unique bunch, persuadable by logic, yet driven by ego.” I can remember a ton of times where ego got in the way of the results. Today, I want to share some ideas that came from an article in SUCCESS magazine called “How to Resolve Conflicts at Work.” In the article, Emma Johnson outlines 11 tips for refereeing office disputes, and I’ll include a link to both articles in the show notes for today. Johnson says disputes can’t be avoided, so we have to deal with them when they occur. She also says we can’t expect team members to just get over it.
I have to inject some commentary here. This is right on the money. I believe you have to teach people every little thing. Recently, I had a client ask me, “Why is this so hard? Aren’t these people grown adults?” Actually, no. My mentor, John Maxwell, says, “People claim with age comes wisdom. They are wrong. Sometimes age comes alone.” As influencers, sometimes we need to step in and to help mediate the conflict, to help take the edge off and equip people with the skills they need to fix the problem, rather than just back away and stay mad at each other.
Tip number four, make each person acknowledge the other person. That other person has strengths, and that other person is worthy of being heard out. Number five, focus on expectations. Man, that is the truth. The gap between what we expect and what we experience is a huge contributor to the conflict we have. Let me just say that again. The gap between what we expect and what we experience is a huge contributor to the conflict we have. Number six Johnson suggests is, challenge the people having the conflict to come up with a solution. Let them find some common ground and come up with a plan, even if their plan is not as good as your plan. Because if it’s your plan, they’re not going to be as bought in. It’s good to have them do it.
Number seven, help them say it out loud. What’s the plan, and what are the next steps? Who is going to do what, and by when? Number eight, do not separate the people having the conflict. I can’t help but think of a time we were on a road trip. Boy, you can’t get separated when you’re inside the car. Right? Two of my boys were bickering endlessly. Oh, it was so frustrating. So I decided that when we got to the hotel we were going to get to the bottom of this. When we got there, I made them stand in the bathtub, balancing on one foot, until they found a way to work it out. You can’t get away with that at your office. But find ways to get the people who are having the conflict to be together to try and work it out.
Number nine, Johnson says, “Unite them in solving a crisis bigger than the argument.” Find a common enemy, find a dragon they can work together to slay. Number 10, Johnson says, “Consider personality assessments like a disk assessment to help them find ways to communicate more effectively based on the other person’s style.” Now, that’s something I can help your team with and I’ve got a link that I’ll put into a video about disk assessments in the show notes as well. Number 11, teach them how to do it. I always ask my complaining kid, “Have you spoken to your sibling about this?” They know the rule is they have to talk to each other before they escalate to me, and you can challenge your team members to do the exact same thing. “If you’re upset with somebody on the team, go talk to them before you come talk to me.”
Now, check out Johnson’s article. She’s got more information in the article, and some examples of these principles in action. Again, there’s a link in the show notes to the article. I highly recommend it. Conflict is sometimes no fun. But it’s also the key to innovation and disruption of the old ways of doing things. Teaching your team members to work it out can have a big impact on performance. I’m also including in the show notes a downloadable worksheet that’s going to help you work out conflicts, and that is today’s Mentoring Segment.
Thought Leader Segment.
Today’s Thought Leader Segment describes a skill you can start to use when you’re at Level 1 of the four levels of thinking as a geek leader.
Announcer: Level 1: Individual. At Level 1, you may even be a superstar technical resource. Level 1 focuses you on improving your technical skills.
Tom: The U.S. Government decided to set up a research facility to understand more about how software is created. Through funding from the U.S. Government, the Software Engineering Institute at Carnegie Mellon University was created. Now, they came up with the Capability Maturity Model for software development. If you haven’t ever heard of it or you’ve never looked at it, it’s fascinating. It describes the process of what does it take to be really good at writing software.
In addition, because software projects have so many people problems, they’ve created the People Capability Maturity Model, and that identifies the key components that lead to excellent people and processes around people in organizations. Like the CMMI for software, the PCMMI for people outlines the things that you need to know to lead to outstanding performance. Now, there are a ton of great ideas in the PCMMI, and today I want to talk about one specific idea, and that is repeatability.
As geeks, we are used to using our expert judgement to create repeatable processes using technology. That’s what we do. That’s what code is. Right? That’s what machines are. Machines are systems that automate the work. Our job, as highly technical experts, is to come up with tools to make it easier for other people. These systems we build make it so that you don’t have to have that expert judgement at every single step along the way. You can repeat a set of steps without having to make that expert judgement decision every single time about what should be done next.
A major idea inside the PCMMI is that we need to have repeatable processes that we can use over and over again to make it so we don’t have to make decisions over and over, and over again. You might be thinking, “Well, that’s kind of intellectually interesting, Tom. But I’m not sure how it relates to me.” One of the things that I try to do in this podcast is make sure that the information I give you is actionable. So what can you do to make your work more scalable? How can you make your work impact more people, more processes, more projects, without having to work crazy hours? There’s a simple tool that I bet you’re already using, at least a little bit, that will improve your influence and your effectiveness. What’s the tool? It’s a checklist.
Really? A checklist? I mean, come on, Tom. You’re kidding, right? Back in 2007, Dr. Atul Gawande published the story of another doctor, this one from Johns Hopkins by the name of Peter Provonost. Provonost realized that to safely install a central line, medical personnel needed to complete a series of five steps perfectly. Now, a central line is used for patients that get a lot of drugs put in their system, and it’s a fairly common procedure. But apparently, it’s also relatively dangerous. On observation, in more than a third of patients, doctors consistently skipped at least one of five steps. See, our memory is just not quite good enough to remember to do everything all the time.
In combination with some cultural change, the results were incredible. To quote from The New Yorker article by Dr. Gawande, “The results were so dramatic that they weren’t sure whether to believe them. The 10-day line infection rate went from 11% to 0%.” So they followed patients for 15 more months. Only two line infections occurred during the entire period. They calculated that in this one hospital the checklist had prevented 43 infections and 8 deaths, and it saved $2 million in costs. Think about that for just a minute. Implementation of a five-step checklist saved lives, eight lives, and millions in costs. Now, in fairness, without the extreme commitment to cultural change that went along with creation of the checklist, because creating the checklist isn’t enough…But without that commitment to cultural change, other hospitals have not seen the same scale of results.
But the principle is that we as people forget things. Sometimes, something as simple as a checklist becomes a really powerful and effective tool. Let me ask you this. What are some things you’re doing today that could be improved by using a checklist? Back in 1994, I was working as a wide area network guy. My employer had a group of software engineering centers across the U.S. and in international locations too, and one of my jobs was to upgrade the routers at each location. Now, I didn’t have the luxury of complete documentation. The system had been set up originally before I had started with the company, and frankly I wasn’t an expert in all the different hardware models that we had in each location.
My ego, however, couldn’t stand the impact of failure. There were a million details that had to be just right in order to make the upgrade process a success. I had to fly in to each location, swap out hardware as needed, upgrade the operating system on the router, and then make sure the network links all came back online before the developers needed to access those systems that were onsite. I remember as I was getting ready for those trips, I was always a little bit nervous. I over-packed. I took extras of just about everything that I could think of, just to make sure that I wouldn’t run into difficulty. Now, I wasn’t sure about the exact cables that I’d need, so I had a big variety of them that I took with me. I took backup copies of the software and extra disks, and everything I needed. I was consistently surprised when things went wrong.
Every time, I had to scramble to overcome yet another unexpected problem. That was stressful. I think I got through maybe four of those upgrades, when I went to my boss and I said, “Hey, boss, I think maybe I should make a list of things to remember.” Really? I was going to rely on my intellect and my technical skills. I did manage to pull things off that frankly should have failed it. I was lucky, except for that one time in Chicago when the phone company had installed a link between our location and their office, but hadn’t extended the network back to Bethesda.
I was able to get everything done pretty much in one trip. But have you ever tried to get the phone company to make a fast change to anything. That one required a second trip. But how would it have been different if I had created a checklist that included, “Confirm the technical requirements of the LAN link with the phone company two weeks before the upgrade date?” It wouldn’t have been that tough, and it certainly could’ve saved me a trip to Chicago. Checklists can be a huge help.
Going back to that New Yorker article, Gawande relates the story of the B-17 Flying Fortress. This was an incredible aircraft. It was faster, it had longer range, and it had five times the payload capacity that the Army Air Corps even requested. This plane had tremendous promise. It was going to be an amazing tool for warfare. That’s how it got the name the Flying Fortress. During the flight competition, they really believed that the Flying Fortress was going to so outperform the competition that it was not even up for grabs, that the Flying Fortress was so much better than the alternatives.
But here’s what happened. For the demonstration flight, the plane took off smoothly, it climbed to 300 feet, and then stalled before a spectacular crash that killed two of the five crew members. This pilot was an unquestionable expert in aircraft and flight. He was the head of test flights for the Army Air Corps. But he had forgotten a single step in the operation of this crazy complex machine. If he’d remembered to unlock the elevator and rudder controls, he’d have been fine. But he forgot, because he’s a person and people forget things. Now, this incident was almost the end of the aircraft, which had been believed to be one of the future aircraft to help us fight wars that were coming up.
But what happened instead was the introduction, for the very first time in our aircraft operation, the creation of a checklist to help remember the myriad details. Once that checklist was implemented and adopted, that cultural change that I talked about, the Flying Fortress flew 1.8 million miles without any incidents. Let’s take a moment right now, and just spend just a moment or two thinking about your work. I know how it is. You are probably swamped. You’re pressed for time. You’re overwhelmed, too much to do. How is creating a checklist going to help you?
Many years ago, I worked in Fortune 500 IT, and we had a major project to roll out that required new servers to be built. These servers were finicky. We needed our installation process to work perfectly. If you didn’t install and configure every single component in exactly the right order, the process just would not work. Now, when we started the process, we looked at expert judgement, time and again, “Okay. What steps should we do next? Exactly how are we going to go about that? How do we configure this? What are the settings for that?” We did eventually create a repeatable process through trial and error, and I can remember installing that iTMS software, oh, dozens of times to be able to get it down.
What we learned is that even when we as experts knew what to do, we still managed to blow it sometimes, and that led to unpredictable results. Now, we had become really knowledgeable and even we had trouble getting things done perfectly. It was too complex for us to do it right. So that meant there was no way we could ever delegate it. Right? Actually, after we realized how frequently we missed a step, or we missed several steps, we decided to create a server build guide that included every single step, every step, from specifying power and networking requirements before the box was actually put into place, to the operating system and installation options, to configuration files, specific software tools, and manual settings, every single step, one at a time, and in order.
Now, using that build guide, our success rate for server build went up so high that we were able to hand off installations to the operations team, rather than depend on expert engineers to make the right choices all the way along the way. Handing that off to the operations team allowed us to tackle other even more complex tasks. Let’s get back to your task list. What tasks are on your list? What things could you document? What task, no matter how complex, would you be able to hand off to somebody else who’s not quite the expert that you are? What would it take for you to document the process, so you don’t have to be involved in every single step?
Now, you might say, “Well, Tom, I can’t do that, because it’s just far too complex.” Okay. Let me assume that that’s true. I’m not sure it’s true, but let me assume it’s true. Could you document 80% of it and hand off 80% of it, and only get called in for that portion that required your expert judgement? What would that do to free you up? Using a checklist solved my iTM server build problem, and a checklist definitely would’ve helped me with my network upgrades. It helped the Army Air Corps master the Flying Fortress, and it saved lives and millions at Johns Hopkins. Repeatability and consistent performance, isn’t that part of the elegance we seek as engineers? Finding a way to package our expert judgement and pass it along to others is one way that you can improve your effectiveness. Checklists do that, and that is today’s Thought Leader Segment.
Tom: As I record this episode, we’re in the dog days of summer. My teenage son, Joel, as you know, is the producer for this podcast. That means he’s responsible for all the post-production edits and mixing the episodes, as well as making sure that all the technical bits of getting the recordings posted online actually happen on time so that you get your episode when you’re expecting it. Now, as you might think, our routines have been pretty disrupted by our summer activities. Over the last couple months, Joel has been handling some school work, and he’s been involved in two different week-long camps as well.
When I created the podcast, one of the first things I had to do was figure out all the technical bits, all the processes I wanted to follow, and how I was going to go about doing each podcast episode. When I wanted to bring Joel in to be the producer, I wanted to create a process and document that process. So I’ve used some cool software called Clarify. It makes it simple to take screenshots and mark them up. You can add detailed notes about exactly what to do and in what order. It turns out that there are about a zillion little things you need to do to make the podcast run really smoothly.
While Joel has been gone, I’ve had to step back into the technical editing process in posting some of these episodes. Now, I’ve told you before that I am not a detailed guy. I generally operate at a pretty high level. I can do details, but they just make me tired. But because Joel was busy doing other things, I jumped right in with both feet and I edited the first episode I had edited in a while. It was after I posted it that I discovered I’d forgotten one of the steps in the edits to the introduction. If you go back a couple of podcast episodes ago and the very beginning of the episode doesn’t sound exactly like the rest of the episodes, yep. That’s me.
In the next episode, after I posted it, I realized I’d forgotten to add ID3 tags to the MP3 file. Oops. I guess that will screw up my SEO. Now, let me ask you. Do you think I actually used my checklist? Nope. You’d think I’d know better. I mean, I created a checklist and I remembered almost everything. But that reminds me of a story my Uncle David told me. My Uncle David is a flight instructor, and he had a friend who was a pilot, who refused to use a landing checklist. I guess he didn’t get the memo about the Flying Fortress. Right?
Now, my uncle’s friend had flown for years and years, and years successfully, and he landed well over and over, and over again, until that one day where he landed his plane with no landing gear. After that, he switched to using a checklist. My Uncle David says there are old pilots and there are bold pilots, but there are no old, bold pilots, and that is today’s Family Segment.
Tom: In today’s episode, we talked about conflict. Why? Leading geeks is a unique challenge. We’re persuadable by logic, but frequently driven by ego and pride. Where you have people, you have problems, and improving your conflict resolution skills is a great way to improve team performance. For the Episode Hack today, I want to challenge you to think about something you do frequently, something you’ve been reluctant to ask anybody else to do because you’re too important to the process. For that activity, I want you to take some time and document the steps into a checklist. Once that checklist exists, you can use it to make sure that it actually works, that you remember to put down your landing gear.
After you’ve done that a few times, think about who you could delegate that task to, and use the checklist as a foundation for training them to do it well. That’s today’s Episode Hack. Oh, and I’ve mentioned before that licensing intellectual property matters to me, making sure that the people who create content are recognized and rewarded for the work that they do. I am very grateful for Creative Commons and other public domain-type licenses that make it possible for me to take advantage of sharing great ideas and great content with you. Special thanks today to Rob Sun God for the shotgun sound effect, and for offering it under the attribution-only license, making it free for me to share with you. Thanks for listening.
If you like the podcast, can I ask you to give me a hand? It turns out it’s a big deal to have a rating in iTunes. Now, I’ve heard other podcasters asking for ratings and reviews, and I wondered why they kept going after it again and again, and again. Do you want to know? Because almost no one actually does it. It only takes a minute and it’s a huge help. So why is that? Great ratings help iTunes decide that this podcast is worth promoting, and when you put a rating or a review, it helps it appear as a top podcast in the iTunes search. Would you please take a moment to do it right now? There are three simple steps. One, go to the iTunes store podcasts. Two, search for “Becoming a Geek Leader”. Three, give the podcast a great rating. Thanks.
This is Tom Cooper. Thanks for listening. Be sure to join me next time for another episode of Becoming a Geek Leader. Join me in my mission of discovering better ways to lead others at work and at home.