Tag: management

  • 10 Times You Should Listen to Your Fear of Failure

    You and your entire team are before the senior managers getting yelled at, and before you know what happened, you are fired in a theatrical display before all your colleagues. O, the shame you’ll feel on that walk out. Then the quiet weeks that turn into months as you you scramble for a new job, and before long you find yourself bragging about your in-depth knowledge of ramen noodles and all’s its salty flavors. Ha, well, I guess it’s not really that bad, it has some nostalgia of college, and well you survived just fine then and will do so again. And with all that time, perhaps you can finally create that blog about “Living off Ramen”, attracting a huge following with all sorts of ad revenue coming in. So what are you worried about? Time to squash that fear of failure and press on. The project definitely has a small percent chance of success, you just need to work harder, and even if the worst case happens, no big deal, it’s just ramen.

    Until you wake up from this dream, and recognize that the worst case is actually that this project may never end! It is a future of endless weeks of you arguing with your gut, and fighting a battle that is only fought by the cowardly. It’s easy to let the project live, it takes true bravery to kill the project, and failing to learn before you fail to learn. 

    So when should you summon up the bravery to end a project that is doomed to fail? This article will describe ten times you should listen to your fear of failure. And it’s not just the easy indicators such as lack of funding, technical obstacles, or business climate, but rather about the things you see and hear from your team, from your organization and from your gut.

    Let’s start with your team.

    The team is embarrassed by the product

    I was once leading a software project with an aggressive (shall we say made up) timeline, and I pushed the team to work long hours to reach our ship date. On that date, I invited the team into a room, and held up a symbolic DVD with the product name and asked everyone to sign it, as I was going to put it up in the hallway to reflect our pride in the software we had created.

    The lead software architect laughed, stood up and walked out of the room. I still held up the DVD, and gradually the team did sign it, mostly because I was asking them to do so, or they were too new to the product to know any better. At the end of the day; however, they did not want to see that DVD on a wall, and I think in a few weeks it quietly disappeared. The team was not proud of their work. In hindsight, I should have cancelled the product launch then and there. Instead it was the client who effectively cancelled the product when they embarked on a quest to break the all-time record on support call volume. 

    So, if your team is not proud of the work, if they make excuses on why it’s not a good idea to do a demo… Listen to what they are saying. It’s time to pivot, for your team should be proud of what they have made, even if its imperfect. They should be excited to show demos and glad to sign the memorabilia.  

    The team does not believe they can succeed

    As I passed their desk, I asked one of the devs about their ability to achieve our quarterly goals, which just so happened to be tied to our variable compensation, and they replied, “Oh those, I’ve already given up on those.” As they were just a couple weeks old, it should have been clear to me, that they had no chance of being met. After a little digging, I discovered that feeling was shared by others in the team. They still came to work, still tried and some even worked late, but nobody believed they would succeed. The morale was low, it was just a group of people working because they had to, they were working for a paycheck, and perhaps a chance at a little more if a miracle would happen, but no one was working to succeed. At the end, they were right, we did not make our goals, and in fact, we just reset the goals … over and over again.

    When your team says, it’s impossible, ask why. Ask why again and again until you get to the root causes of the problem in front of the team. If they are solvable, action the change. If they are not solvable, or you are not in a position to action on the change, propose to kill the project, before it kills you.

    Major stakeholders don’t want you to succeed

    As I stood up to give a review of a project just underway, I happily introduced myself and my new title of [xyz] program manager. At that point, one of the stakeholders who was new to the project, interrupted and asked me, “Where did you get that title? I do not have a [xyz] program!” And before I could explain that it was from my manager, another major stakeholder, they jumped into a diatribe about my project and expressed frustration that it even existed. Other stakeholders argued back, and by the end of the meeting, the project was still alive and we convinced the unhappy stakeholder to “disagree and commit.” Except, that they seemed to forget the “commit” part as soon as the meeting ended. Everywhere this stakeholder went, they expressed the frustrations and deprioritized my requirements from other parts of the company. After a few months fighting this ongoing collateral damage, the project collapsed and I had a new addiction to antacid chewables. 

    Of course it would be easy for me to say the project failed because of the vendetta the disgruntled stakeholder carried against the project, but the reality is the project failed because I did not manage the stakeholder. At times, I had even started to ignore him, and other times I felt he would see the importance of the project just as soon we had that first release… if only we could get to that first [impossible] release. 

    Instead, I should have stopped the project until agreement was reached or a true “disagree and commit” relationship could have been established. You must have stakeholders on your side, not against you.

    No one cares if you succeed

    I had prepared the presentation deck very carefully, rehearsed my speech many times, and even had reviewed answers to possible questions that may come up in the scheduled review of my project. My team and I showed up, and had everything ready early. Then no one showed up to the meeting. This was during a time were we had a loose software process where we did not require attendance, so our stakeholders did not show up. Which now makes me wonder how many projects are only visible because attendance is forced… At any rate, this happened a few more times in the project, and when they did show up, they showed up with a laptop to look at other work. This project was simply not on their radar. My boss told to me to brush it off by saying that the project was run so well, no one was worried. Of course, my ego was boosted, but when the funding did not show up in the following budget cycle, I knew it was because the priorities were not aligned with the business and more importantly there was no significant value for our clients.

    Looking back, I should have looked at our priorities and questioned very hard the value of what we were building. Does it deliver real value to our clients? If it does, then communicate that value and make sure the stakeholders see it and understand it. And of course, if there is value is lacking for our client, it would be better to pause the project and refocus efforts on one that does. The lack of interest is a just a small sign that alignment is needed, not that folks don’t care.

    You are not setup to succeed

    I was in a brainstorming session with a senior manager who was reporting to me, and as we drafted a few ideas, he then went to a white board and made a matrix listing each project as a row, and then for each column he listed project manager, architect, QA, then and number of developers. At the time I was frustrated as I would not be able to get the funding to start the projects with the resources he wanted, and he would not budge without them. He was wise. A few years later, I was in a similar boat and showcased a matrix and watched as my manager erased a few resources and said, make it happen, times are tough. As I loved the project, I jumped in, and I tried, but as you have probably guessed from reading these entries, it did not happen. In fact, during one review session with the key sponsor, he turned to me and told me how much he loved the idea, but flatley said that it was also apparent I was not setup to succeed, and to come back when I was. Then he would believe me. Project was paused.

    The lesson I learned here, is that you need a plausible path to success. If it is not possible due to a lack of funding, resources, and you have exhausted your capacity, then call it out and hold your ground. Be the one to pause it until you have a real plan, that you believe in and is achievable. 

    Your strategy is being lucky

    The outsourcing manager told me that I was extremely lucky to be able to get their best developer, and I was thankful for it. I had a team that did not have the experience nor the time to learn the new technology, so I was lucky to find the experienced and available developer. He was indeed very good, and well-qualified for what we needed, but after a few days of digging into our requirements, he looked at me as if I were from another planet as the amount of work was insane. I told him not to worry as we had interns coming, and we were lucky again, as one of them seemed to have a built in knack for the software language, and we actually pulled off a miracle. We were lucky. It did not last though, and in fact, as the project scaled, our reliance on lucky recruiting was not able to find the skills we needed, and we delayed the project month after month until it fizzled. 

    Looking back, it’s great when you find the right person [resource, sponser, low cost, etc …] by chance, and you should use that to your advantage; however, you should always plan that you will not, and work to find the right person [resource, sponser, low cost, etc…] If you do not have a plan to succeed than acknowledge that you are planning to fail.

    Plan B is the strategy

    “Well,” he said, “I’ll do as much as I can until we buy another company that has done it right.” He surprised me when he said this. He was one of the busiest leads in the company, yet, now it seemed he was only working at impossible tasks to pass time until another solution was found. He was unaware of other companies being acquired, or side ventures being funded. He simply assumed that our company would have to go with this approach, because that what was done in the past, and it was the best plan B he could think of. He struggled for many more months until plan B became not an acquisition but a new project. I hope he is not still busy waiting for another plan B.

    If a project is not setup to succeed, and you are secretly hoping a non-existent plan B happens, then stop the project. Create a plausible plan A that is setup for success.

    You are unable to end the “fake it” phase of “fake it until you make it”

    I was walking in the hallway and I saw a video of a product demo that I made over a year ago. While the video had elements of working software, it also had a lot of creative editing. I had used it to share the idea of the product vision, and to fake it until we made it. I had since left the project to work on other projects, yet I was able to get an update from the new project manager. When I asked for a demo, I got a video. They were still having to fake it, until they make it. And I knew, with all these videos still being shown, many would believe it was ready, when it was far from ready, and the team was driving the stakeholder head on into a collision with reality.

    At times, you do need to fake it in order to demonstrate the ambition and vision, but you should stop as soon as you have buy in and move as quickly as possible to live demos. Live demos that are good and/or bad. Especially if they are bad, as that helps you set the expectations and leverage the learnings. In time, the demos will be good, and the demos will be live code and the project will succeed, but not if you keep faking it over and over and over again, year after year after painful year.

    You have a pension

    I have actually heard on multiple occasions, from multiple folks, “I would quit in a heartbeat. This project [has no chance of succeeding | is crazy | is taking us in the wrong direction]; however, I only have a couple more years before my pension kicks in, so I’ll ride it out.”  What? What kind of career is that? It’s the kind where the passion has ended and hopelessness has set in. The project will not succeed, or if it does, it will likely be a mediocre project.

    If you are in a project that thrives on support only from those who cannot quit, and they all want to, then you should. Find a project that people would work on, even if they had no pension.

    You don’t want to succeed

    There is the old story of a guy who is the best in his class of tree cutters. After clearing a huge section of forest, he climbs a nearby tree to discover he is in the wrong forest. Suddenly his desire to cut down another tree is greatly diminished. Even if all the other tree cutters tell him otherwise, he is done cutting trees in this forest. Similarly, I have been involved with projects that will end with a product no one wants, or ends with a result that will negatively impact performance (such as projects that introduce unnecessary management bureaucracy). For these projects it was best for me to leave them as soon as possible.

    And if you find yourself on a project whose end goals don’t align with yours or that the project you are working on doesn’t align with the companies… You are in the wrong forest. Time to end the project and move on, even if everyone else tells you otherwise.

    Now with all these ten reasons to listen to your inner fear of failure, you may want to abandon all hope, as you may have projects with some or all these elements. It may be true that some of your projects you need to bail on; however, it may be true, that you can fix it. Sometimes it is a stand-down with your stakeholders, exposing the flaws, and recalibrating expectations and setting yourself and the project back up for success with a real chance of success. It may be terrifying to do that, yet, if you don’t, the results are more terrifying. So be brave, be courageous, and be the leader you were meant to be, and act to put yourself on the path of success.