Why your project will probably fail – BGLS5E6B

Becoming a Geek Leader

Why your project will probably fail - BGLS5E6B

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 / 11:01

RSS Feed

Share

Link

In this Episode

• I cover the 4 major tips from OldCodeGuy on why projects fail and how you can fix that problem

Transcript

Tom Cooper 0:03

I’m squeezing in a short bonus episode for this season that I call why your project is probably going to fail. And four things you can do about it. Leaders, if you oversee project teams or you lead people who work on project teams, you need to take a few minutes of your next team meeting and play this episode. Seriously, there’s some really good stuff here. And as I get started, I want to give a massive shout out to the content creator, old coder guy OCG on YouTube and Tiktok for this message, I saw his recent video on why projects fail. And I just had to repeat what he’s saying in my own words, and why not just share directly what he said, Well, there’s some copy write protection, intellectual property stuff that’s to be concerned, but also a good deal of his contents not for, shall we say sensitive ears. I will say he has a lot of wisdom. And he’s pretty funny too. But in this video, he was talking about the dynamics of project communication and why we miss communicate and why we fail. So let’s assume that you’ve got a project team that’s made up of two different departments, and they’re not communicating well, you’d like to think that they are, they’d like to think that they are, but they aren’t. In fact, one of my favorite quotes on communication is the biggest problem with communication today is the illusion that has taken place. The tragic thing is we really believe these team members can communicate basic and essential information, but they can’t. And if we’re open with ourselves, we have to admit that often we can’t, either. So this team is made up of a couple of different departments. You’ve got a manager and a worker from one department and a manager and a worker from another department. We’ll call one of the bosses Steve and his worker, we’ll call Joe. Now Joe’s new Joe doesn’t want to look stupid and project meetings. So he keeps quiet. Unless he’s 90% sure of what the answer is going to be. And then he’ll speak up. But generally speaking, Joe’s not saying anything to anybody, and his hope, secretly is that he can grab Steve later and have Steve explain whatever it is to him in a way that makes sense. But unfortunately, for Joe, Steve has a problem, too. You see, Steve has been around a while. And when he was new, he behaved exactly the way Joe does. And he never got around to asking fundamental questions about his domain. And so he never learned the essentials of the domain, he’s working in the domain that he’s supposed to be the manager of. Yikes. So worse than that, Steve is now in this position. And he is terrified that people are going to figure out he has no idea what he’s doing. And so now he is 100% committed to faking his way through it. He’s been repeating and typing the same acronyms for so long. They might as well be English words with no known definition. But he’s been able to kind of gloss over that and seems to kind of get away with it. And Joe’s got no idea what’s going on. Steve has no idea what’s going on. And because everybody has the fear of being found out, nobody speaks up. Joe, ask Steve and Steve fakes his way through the conversation, and Joe is confused, but he just figures he’s stupid for not getting the simple thing that Steve clearly understands. And what’s bad for Joe, and for Steve and the company is they’re afraid, because they don’t believe they can handle the damage to their ego, if people figured out that they just don’t know. And what’s Nutty is this problem is not limited to Steve and Joe. In fact, I worked in and with large organizations in and with small organizations. And I’m telling you, I see this kind of thing happen all the time. Just today, as I record this, I was on a call with a business owner, she recently had a senior leader depart. And as she was digging into the situation, she discovered the leader who had left had been mismanaging her department, but hadn’t been comfortable enough to speak directly about the fact that she was struggling to be able to do her job properly. Now to that departed leaders credit, she did mention to the big boss that she felt like she was failing and disappointing the boss. But the boss didn’t hear exactly what the leader was saying, because she was busy with other things. And that miscommunication led to that departure and the failure of a number of projects that were under her area. So what can we do to solve the problem? after this quick break, I’ll come back and tell you exactly what you can do.

4:07

As a leader in a software team, you know, you want to help your team perform at the highest level. And you know that with the tools we have, it’s never been easier to write software than it is today. But it’s still hard. I’m Tom Cooper, and for the last decade, I’ve focused on coaching and training software leaders and their teams to help them make the small but important improvements to help them perform as one team and to achieve their potential. How much better would your results be if your team communicated clearly managed conflict well delegated work that stayed delegated, and then created an executed on great work plants. It shouldn’t have to be this hard to write great software. And the good news is it doesn’t have to be are you ready to take the next step? Head on over to brightfield group.com So you can learn more

5:02

In this video, old coder guy makes four recommendations that I think are excellent and can be very, very helpful. First of all, old coder guy recommends we just open up about our ignorance and ask more questions. Years ago, I was at a conference and the speaker kept using an acronym I had never heard before. And I could tell from the context of his speech that it was important, like really important to the whole message. And I was feeling pretty stupid for not knowing what was going on. And so I could not stand the not knowing I was in a conference room with maybe a couple 100 attendees who are listening to this guy speak, I raised my hand and I interrupted him. And he stopped in the middle of his speech, he had no idea that was totally inappropriate, but I was really baffled. And he said, Yes. And I said, What does daddy mean? And he looked at me incredulously and said, direct access storage device disk. I felt dumb. But the talk made a lot more sense after I understood that. And I, as I look back now, it’s clear to me, there must have been other people in that room who had no idea what he was talking about also. So I think I did a service to myself and to them, but boy, did I feel embarrassed in that space. Now, the second recommendation that OCG makes is, after you ask those questions, and you’re working to understand what’s going on, you say out loud, I think what we’re saying is x, and then say, can somebody point out how I’m wrong? You see, our pride says that if we show people we don’t know things, that’s us displaying weakness, and we think if somebody sees us make a mistake, and pointed out that it’s going to reflect badly on us. But as somebody who has overseen teams, I was always grateful to learn when and how people were confused. And if one person is confused, I bet you other people on the team are confused as well. And here’s the magic of this step. As we get involved in these projects, there’s so many details that get left behind as we build things and make plans. And many things are missed on every project, taking the time to ask questions, even so called dumb questions, and then repeat what we think is happening is very valuable, because it causes the team to walk through that journey together. These things that slipped through the cracks are the things that turn out to be missed requirements, and things that slow down or stop projects altogether. My eldest son is working on a project in a big company, and the project was supposed to ship early last month, but right before the deadline, they learned there were a bunch of assumptions that turned out not to be true. And right now they’re in the midst of revisiting all of the deliverables and creating work items for things that were missed. My kid is slammed with new work that could have been caught if somebody had followed these steps. Thirdly, OCG says, draw a picture. Man, he is right about this paper pencil drawing tools like draw.io, or fancier tools, but draw a picture. A while back, I was working with a colleague at a company that was spending millions of dollars every month on software development. And he began to draw pictures of the process as he tried to understand it, he asked people to point out how he was wrong and made adjustments to a very complex drawing that he was creating. Every time he made updates, he would review changes with technical team members. And he asked him, them to point out what he was doing wrong. Every single time. Over and over again, there were modifications and nuances that nobody else had mentioned, nobody else had seen. Now, I want to point out that we’re very smart engineers on this project, and the CTO. He’s one of the technically sharpest and hardest working folks I’ve met in the business. And when we presented our learnings, we documented 47 round trips of data between the client and the server. And the CTO said, That can’t be right. But it was, nobody had caught it for the very reasons OCG talked about. I draw lots of pictures. And I encourage my kids in their professional work to draw lots of pictures, because it really helps people to see the things we talk about. Finally, OCG recommends we ask other people to explain what they think is happening. The magic here is often they’ve never verbalized it and taking the time for them to say what they’re thinking helps them to better process and understand. We know when we teach something, as we begin to teach it, we learn better how the thing works. And this is an example of that, as you ask them to explain what they think is happening, you’re going to help them find the mistakes. And once you followed all these steps, put your drawing and those deliverables on a single slide and ask people Hey, given what we now know, do these dates do these deliverables make sense? And you’re going to be seen as a project genius and nobody who matters is kind of care that you admitted you didn’t know anything. Except maybe Steve when you take his job. So as a wrap up, here are the four steps one, ask more questions, even dumb questions, to say what you think is true out loud and ask people to tell you how you’re wrong. Three, draw a picture and four make other people explain what they think is happening. With all the projects I’ve been involved in over my career. I’m telling you if you follow these four steps, your projects are more much more likely to succeed. Are you facing a software horror story? I’m your guy for action oriented workshops and executive coaching for technical leaders in their teams. Thanks for joining us for this latest episode in the software horror stories Podcast Series. For more information about brighto group, please check out www dot bright Hill group.com that’s www dot bright Hill group.com for bright Hill group, I’m Tom Cooper.