When is Done Done?

Tom — Mon, 18 Jul 2016 07:30:00 +0000

In this episode:

When is the software done?
When should you share bad news?
What about office politics?

Resource Downloads:

Miscommunication Cheat Sheet - free download

When is “done” done?

Episode 10 – the Four Levels of Thinking as a Geek Leader

4 Levels of Thinking as a Geek Leader - Free Download

Episode 8 – Leadership lunch and better networking –

Questions for your Leadership Lunch - Free Download

Episode Transcript

Becoming a Geek Leader, Season Two, Episode Six.

[00:00:05] Tom: I spoke with Dr. Peter Bamberger from Tel Aviv University’s Business School about engineers becoming leaders. And he said…

[00:00:14] Dr. Bamberger: If you take an engineer and you want to turn him into a leader in our organization, you can’t just assume that you promote them and they’ll learn over time how to become a leader.

[00:00:25] Tom: Right.

[00:00:26] Dr. Bamberger: Some of them will. The vast majority won’t.

[00:00:28] 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.

[00:00:51] 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.

[00:01:21] 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?

Introduction

[00:01:43] In today’s episode, I’m going to talk about three aspects of your career and your work. And all three of them are tied to the way that you work with other people. In the Tech segment, I want to talk about the question when is done, done? In the Mentoring segment, I’m going to share a story with you about a client who almost lost his job because nobody was willing to give him bad news. And finally in the Thought Leader segment, I’m going to talk about how you ought to handle office politics.

[00:02:13] I’ve got a lot to cover in today’s episode so I want to get started. All the topics in today’s episode are skills you’re going to want to start thinking about when you’re at level two of the four levels of thinking as a Geek Leader.

[00:02:26] Now it’s been awhile since I’ve talked about all four of them and if you want more information and a description of all four levels of thinking as a Geek Leader, I want you to check out Season One, Episode Ten. And there will be a link to that episode in the show notes as well. Today, we’re going to focus on level two of the four levels of thinking as a Geek Leader.

[00:02:47] Man: Level two, team member. Level two is where you work well with others, and together you all succeed.

[00:02:56] Man: Tech segment. In the Tech segment, Tom talks about tools, processes, and theory related to agile, projects, systems, and more.

[00:03:10] Tom: In the Tech segment, I want to talk about software development, and I’m going to answer an email from Gina. Gina writes, “Tom, I keep getting in trouble with my boss because he says our code is late, but that’s not true. What really happens is we deliver on time but our customers aren’t happy with our code. Their requirements are awful and we do the best we can. We give them exactly what they ask for and then they demand we rewrite it. We’re doing what the customer wants but then we’re getting dinged for not delivering what they want. What are we going to do about this? Can you help?”

[00:03:46] Gina, I feel your pain. I’ve been there. Have you ever seen that t-shirt that says, “I am a software developer. I deliver complex applications based on precision guesswork from unclear requirements.” Man, now that’s funny because it’s got at least a kernel of truth to it. Right?

[00:04:05] The problem comes about because to our customers, the work we do is essentially magic. And they don’t really understand how to translate their business needs to into technical specifications that we can understand. And that’s really the root of it. Often the problem is not well defined.

[00:04:24] When I was overseeing developers, I can’t tell you how many times I heard them tell me, “It’s done,” only to find out that their definition of done didn’t match my definition of done. And I think that’s really the answer to your question. What you’re asking is how am I going to know when we’re done?

[00:04:42] And I really appreciate Jeff Sutherland’s thinking on this. If you don’t know who Jeff Sutherland is, you can check out his website jeffsutherland.com. He’s one of the inventors of the Scrum methodology, and he has a lot of great things to say that are really powerful when it comes to the art of software development.

[00:04:58] Now in one of the postings on his blog a while back, he said that it’s one of the thorniest problems to deal with as a team. And he says done is done when the code is feature complete, code complete, has no known defects, and is approved by the product owner.

[00:05:18] Now what that means is if it’s feature complete all the intended functionality of the final version, it’s in the software. If it’s code complete there’s no entirely new source code that’s going to be added to that release. No known defects I think really means no showstopper defects because all code has got some kind of bugs. And approved by the product owner means it meets all the defined business goals.

[00:05:45] When I was overseeing teams who were responsible for deploying software in production environments, I also added a fifth item. I added production ready to Jeff’s list. And what I mean by this is that the operational documentation is complete, the configuration files have been delivered to production, system settings are in place in production, and the app runs without developers ID and it’s finally been accepted by the people who are going to have to operate the code.

[00:06:10] Now this information is available in today’s show notes and I want you to feel free to go over to the website and download the document that’s called When Is Done, Done. And that’s going to help you identify or articulate these items for your organization. Now I’m not suggesting that your answers to when is done, done ought to be exactly the same as mine or Jeff’s but I think you need to have that conversation if you want to be clear about when you’re really finished with the requirements from the customer.

[00:06:41] Now the question of when is done, done, it’s a tough one. It really is. Because a developer, for example, might think it’s done when he figures out how he’s going to write the code, or maybe when the code compiles without errors. The QA might think it’s done when it passes all the tests, the unit tests, and the regression tests. The product owner might think it’s done when the code runs and the documentation is complete. But the customer doesn’t think it’s done until it solves their business problem. And unless we’re all on the same page about what does done mean, you’re not going to get there.

[00:07:19] Have you ever heard the expression, “If you don’t know where you’re going, then any direction is just fine”? I think that’s what happens to us at work. We don’t have clarity about exactly where we’re going.

[00:07:29] So to wrap up this segment, Gina when is done, done? It starts by asking the question, “For this work, how are we going to know we’re done?” And it boils down to having a conversation about what do we want to complete in order for this to be finished, and how will we know? What measurement will we use to make sure it’s done? Until you have a measurement of success, how is anybody going to be able to say you’re done?

[00:07:55] The next time you’re planning a feature or you’re getting a project assigned to you, don’t accept the assignment unless you and the other folks agree on your measurement of success. And don’t accept the cop-out of, “I’ll know it when I see it,” or, “It’s obvious.” It’s not. If you accept that, you’re headed for frustration and pain. So, Gina, I hope that answers your question. And that’s today’s Tech segment.

When should you share bad news?

[00:08:19] Man: Mentoring segment. In the Mentoring segment, Tom tackles tough issues based on his years of experience.

[00:08:26] Tom: In the Mentoring segment, I want to talk about sharing bad news. We all hear bad news, we all know bad news, and we all at times are called on to share bad news. This segment is about when to share it. Now unlike wine, bad news does not improve with age. You need to share bad news as quickly as you reasonably can do it. And today I want to share a story about Eric and Paul.

[00:08:57] Now Eric is a senior technical lead in a large company. He’s been there a few years, and he’s been responsible for running a program working with an internal customer. They’re doing customizations and product enhancements to support the needs of an internal customer. Now the company leadership brought me in to work with Eric.

[00:09:17] Now Paul is Eric’s boss. Paul had some reports from folks inside the company that Eric was not delivering as much work as the customer wanted. And Paul also had some complaints from that customer about arguments the customer had with Eric. Now let’s talk for a minute about Paul. Paul is a smart, highly technical expert himself. And he’s a boss overseeing a number of folks like Eric, and each of those guys has programs they’re responsible for.

[00:09:47] Now when Paul heard these complaints about Eric, he did mention those issues to Eric but not really severely. Almost a casual or in a passing way. In such a way that Eric really didn’t think it was that big a deal. Not only that, but Paul didn’t mention to his boss that Eric’s primary customer was really unhappy.

[00:10:10] Now our story today is about a boss and a team member, but the principle is the same whether you’re talking to a peer or you’re talking to somebody who reports to you. And that’s why this is a skill you’ll start using at level two of the four levels of thinking as a Geek Leader. You can use it with a team member even if they don’t report to you.

[00:10:26] So let’s get back to Paul and Eric. Imagine that you’re Eric. You’ve been doing good work. You’ve got a lot on your plate. Your internal customer is completely unreasonable and extremely demanding. In fact, he asks for the world and gets angry when you don’t deliver it. And for some reason, he gets away with acting like a jerk while he’s doing it.

[00:10:48] Now in this scenario, Eric’s customer is actually pretty politically savvy. He knows his stuff technically, and he knows what measurements his bosses are interested in. He is aggressive about working his relationships and working the system and he’s figured out whose toes he can step on without getting in trouble. And he’s been able to behave badly because the organization is so focused on financial results that they are willing to overlook the metaphorical trail of dead bodies left in the wake of the customer.

[00:11:17] Eric, on the other hand, he’s a pretty typical technical expert. He focuses on knowing his stuff. He knows the platform, the platform capabilities and he works with his team members to deliver as much work as he possibly can for this crazy customer. But the problem is that while Eric is focused on these things, his customer is looking at the metrics his bosses care about. And he’s working the system and Eric isn’t doing that.

[00:11:43] Now as time goes on, Eric gets more and more frustrated because he feels like he’s overworked and he’s underappreciated. And one day when he’s just at his limit, he has it out with the customer. Voice were raised on both sides. Not nice things are said by both people. But this customer now is so angry with Eric that he complains bitterly to the senior leadership three levels over Eric’s head. So here we are. Eric’s boss’s boss’s boss thinks that the lack of results are entirely Eric’s fault.

[00:12:18] Now here’s where Paul comes in. Paul has not worked with Eric to help him really correct the problem. And Paul never told his boss there was big trouble brewing between Eric and the customer. When the news comes to Paul’s boss that Eric has to go, Paul’s boss is completely caught off guard. The next thing you know, Eric is put on a performance improvement plan, or a PIP, with human resources. Here’s the deal. If he doesn’t turn around his performance in the next few months, he’s going to lose his job.

[00:12:48] Now this is the point where they brought me in to work with Eric. During my initial conversation with Eric and Paul, it seemed very clear to me that Eric had no idea his job was on the line. Now I took Paul aside after the call and I asked him about it, and he told me he never told Eric he was likely to lose his job if things didn’t turn around. Are you kidding me? Wow.

[00:13:09] Now we could go into the ways that Eric had already turned a deaf ear to negative feedback and the ways that he managed to tweak his customer and frustrate his customer both intentionally and unintentionally. But that’s outside the scope of today’s story. Today’s story is about giving bad news as quickly as possible.

[00:13:30] What I want to highlight here is the lack of clear guidance that Paul gave to Eric. It would’ve been a lot better if six months before Paul had taken Eric aside and said, “Hey look, you got to watch out for this customer and you better make some investments in relationships with him. And watch out, because this person is really politically savvy. You better be careful.”

[00:13:51] Now I just read an article in Harvard Business Review talking about the question of negative feedback. Nobody wants to have to give bad news. Nobody wants to be the bearer of bad tidings because it seems really, really awkward and uncomfortable. But here’s the thing. The fact is your team members don’t enjoy hearing that they didn’t do a good job. That’s true. Nobody enjoys hearing that. But they really want to hear it.

[00:14:16] There was a survey that was done and the respondents said some really interesting things. One of the things they said, 92% of them said negative feedback if delivered appropriately is effective at improving performance. 92% said, “If you give me negative feedback appropriately, it’s going to help me to do a better job.”

[00:14:37] And 57% were asked if you had to choose between getting positive feedback and getting negative feedback, which would you choose? 57% said they would rather receive corrective feedback over positive feedback. That means that most of the people you work with, even though it’s uncomfortable, A, recognize that it’s important to hear, and B, actually prefer to get negative feedback over positive feedback because then they can do something that improves their performance.

[00:15:07] So this whole conversation starts with the question, “May I offer you some feedback?” Now if you want more information about that, I want you to download my miscommunication cheat sheet. It’s got simple scripts of what to say and how to say it. Now you can find that in the show notes for today’s episode.

[00:15:26] Much of the problem we had here would’ve been resolved if Paul had been willing to have a tough conversation much earlier. Now here’s where this got off track. As I talked with Paul his story in his head was, “Look, I got a lot going on right now, and I just don’t have time to think about that. And it’s probably going to be okay. I probably don’t have to worry about it.”

[00:15:48] Now the fact is that that story is just not true. Thinking it’ll be okay if I do nothing, that’s a false story. Problems do not go away by themselves, particular people problems. Remember that people know negative feedback is helpful. And even though it’s unpleasant to hear, they benefit from it so much that they’re willing to endure the discomfort to get to better results. Unlike wine, bad news does not improve with age. May I offer you some feedback? And that’s today’s Mentoring segment.

What should I do about office politics?

[00:16:22] Man: Thought Leader segment. In the Thought Leader segment, Tom brings in ideas from today’s best thought leaders.

[00:16:36] Tom: In today’s Thought Leader segment, I want to share some ideas about office politics that I found in some of my recent reading. Now earlier in today’s episode, we talked about how Eric almost lost his job because of poor guidance from his boss. Now, of course, there was a lot more to it than that. Eric had ignored office politics and he thought that his great work alone would save him.

[00:16:57] Now that’s an assumption I know that technical experts make all the time. My great work, my brilliance is what matters the most, but it’s not. Time and again, I hear Geeks say things like I’m too busy to waste time with all that people stuff. I got a lot of stuff to do and not enough time to do it. The last thing I need to do is spend time talking to people about sports at the water cooler. Now I’ve heard that kind of idea more times than I’ve ever counted.

[00:17:23] But here’s the thing. Mahatma Gandhi said, “Anyone who says he is not interested in politics is like a drowning man who says he’s not interested in water.” Anyone who says he’s not interested in politics is like a drowning man who says he is not interested in water. Here’s the thing. You are already enmeshed in politics, and it’s going to help you in huge ways to understand that you’re in the water. If it’s handled poorly, you’re going to drown like Eric almost did. And handled well, you’re going to be able to swim, maybe even as well as Michael Phelps. Now this is another level two thing on the four levels of thinking as a Geek Leader. You need to start working on this skill long before you find yourself in a formal leadership role. This kind of thing pays off and big time.

[00:18:11] Now let me ask you, have you ever been in a position where the leaders seemed well dumb? Have you ever been frustrated because your customer just doesn’t get it? I remember a guy on my team said, very sincerely, “Our customers, Tom, are idiots.” Wow. But you know you’ve been in a place where you’ve thought, “I’m smarter than this leader” or “How did that person get promoted? They really don’t understand.”

[00:18:39] I remember a time when I was at Marriott. One of the vice presidents asked me, “Why do we spend money on your department? You make it so that software gets installed on desktop computers, but what’s the big deal? I download stuff from the Internet all the time. Nobody makes that work for me.” This was my boss’s boss. And yet nobody had told him, for example, that when we were using a consistent package to install Visio, that the number of helpdesk calls related to Visio plummeted and that follow-up visits dropped as well. He didn’t get it.

[00:19:09] But he was the boss and I got to tell you at that time, that was baffling to me. I didn’t have the insight about the fact that he had delivered significant business results earlier in his career that allowed him to be put in a position where he was in a role of leadership because the company said, “Hey, this person gets things done, and we want to have him getting things done.

[00:19:32] So why is it that less technically competent people get promoted and the people not as technically savvy as you are are put in leadership positions? It’s because politics matters. Many years ago, John D. Rockefeller, one of the richest men in the world said, “The ability to deal with people is a commodity, just like sugar or wheat. And it is a commodity for which I will pay more than any other commodity.” Now let that sink in just for a second. The ability to deal with people is a commodity just like sugar or wheat and it is a commodity for which I will pay more than any other commodity. According to the richest man in the world, the most valuable commodity on the planet was the ability to deal with people.

[00:20:25] Now in his day, he was dealing with big technical problems like how to transport oil, how to refine it into lamp oil, kerosene or gasoline. He had a lot of geeks that worked for him, probably as many, if not more than any of the other robber barons, and he said the most valuable skill was dealing with people.

[00:20:46] So let me put this out here for you. Maybe it’s time to look more carefully at that skill set. It’s not that your technical skills aren’t valuable. They are very valuable. In fact, I just read an article where somebody said that software development skills are the most precious resource on the planet. I’m not sure that I totally buy into that, but they are valuable. But what if you added political savvy to your toolkit? How might that help you?

[00:21:14] I came across an article in Harvard Business Review about New York Police Chief Bill Bratton. He was talking about implementing change in an organization and I’d like to read just a little bit from the article entitled Tipping Point Leadership. Here’s what it said. “Organizational politics is an inescapable reality in public and corporate life, a lesson Bratton learned the hard way.

[00:21:40] “In 1980, at age 34 one of the youngest lieutenants in Boston’s police department, he had proudly put up a plaque in his office that said: ‘Youth and skill will win out every time over age and treachery.'” Oh man. I’ll continue the quote. “Within just a few months, having been shunted into a dead-end position due to a mixture of office politics and his own brashness, Bratton took the sign down.

[00:22:07] He never again forgot the importance of understanding the plotting, intrigue, and politics involved in pushing through change. Even if an organization has reached the tipping point, powerful vested interests will resist the impending reforms. The more likely change becomes, the more fiercely and vocally these negative influencers, both internal and external, will fight to protect their positions, and their resistance can seriously damage, even derail, the reform process.” Bratton learned there were powerful forces at work, forces that his youth and skill could not overcome.

[00:22:46] I want to encourage you to be like Bill Bratton. Recognize that there are powerful forces at work and you can either find ways to work with them or around them. But let me assure you that if you ignore them, you will find yourself, like Bratton, in a dead-end position. Office politics make or break projects and companies and if you pretend they’re not there, you are going to end up drowning.

[00:23:12] Now here’s the thing. I understand. We all want to believe that great work wins. We want to believe that the best ideas rise to the top. But the fact is that’s not how it works. It isn’t how the world works today and it never has worked that way.

[00:23:29] In another article I read the story of Jill. Jill was a technical leader whose career got sidetracked. And as she began to explore how and why it happened, she said, and I quote, “I didn’t want to play office politics or be perceived as a brown noser, self-promoter, or somebody who rose because she was buddies with so-and-so. I was always told that the cream would naturally rise to the top.” But that’s not how it works. The cream doesn’t always rise to the top. The way it works now, and they way it’s always worked, is for you to get your work noticed and in the hands of as many people as possible.

[00:24:04] Now just as a quick analogy, I want to ask you to think for a moment about pop music and movies. Now do you think that the things that are the most popular are the absolute best creative products? Of course not. Some of the biggest sellers are hugely talented but an awful lot of them are in the right place at the right time with the right connections to be heard. And this is true for you, too. You need to know who the influencer’s are, what problems they have and how those people can help, or hurt your efforts.

[00:24:36] If you choose to opt out of politics what you’re saying is, “There’s a whole world out there that has immense influence over my success and I don’t want to be part of it.” But politics is not big and scary and you don’t have to be the guy with no technical skills who stands at the front of the room. You don’t have to sell out to be able to engage politically.

[00:24:57] Let me share just a couple of places where you could improve your political savvy. First, look at the team members, your peers. What could you do to help them achieve their goals? Second, look at your boss. What are three major goals that your boss is working on and how can you help. Now if you don’t know, ask. Go to your boss and say, “Hey, I want to make sure that I’m doing everything I can to be helpful to you in every way that I can. So what are three big things that you’re working on?”

[00:25:29] And third, build your network. Now I covered details about this in Season One, Episode Eight and I’ve got a resource in the show notes that’s called Questions for your Leadership Lunch. And those questions can help you make and maintain the connections you need to make at work. And they’re going to help you with those political forces as well.

[00:25:51] Remember, Mahatma Gandhi said, “Anyone who says he is not interested in politics is like a drowning man who says he is not interested in water.” Knowing who the influencers are and how to swim in the ocean of politics makes the difference between drowning and success. Now as I said before, you don’t have to sell out to be more savvy about politics. And that’s today’s Thought Leader Segment.

[00:26:16] Man: Episode hack. In the episode hack segment, Tom shares one action-oriented takeaway from this episode, something you can apply right away.

[00:26:27] Tom: In today’s episode, we talked about when is done, done, and how getting specific about how everybody agrees that it’s done is a game changer. In the Mentoring segment, we talked about Paul and Eric and how Paul’s reluctance to give Eric bad news almost cost Eric his job. And finally in the Thought Leader segment, we covered ideas of how the best solution doesn’t always win and why your ability to learn more about office politics is going to make a huge difference in your overall success.

[00:26:57] Today’s episode hack is focusing on speaking up when you’ve got bad news. In the show notes, I’ve got a document called the Miscommunication Cheat Sheet and that gives you some specific tools that you can use to help give feedback to a team member. And remember, the conversation starts with, “Hey, may I offer you some feedback?” And that’s today’s episode hack.

[00:27:21] Is the podcast helping you? Make sure you don’t miss out on the latest info. Head over right now to brighthillgroup.com/join to be sure that you stay in the loop. When you do, you’ll get my PDF, Become a Geek Leader in Two Easy Steps and you’ll be notified as soon as new podcast episodes are available. Plus you’ll get updates and ideas that I don’t share on the podcast. Head over to brighthillgroup.com/join right now.

[00:27:55] 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.