top of page

How To Let Others Fail


Have you ever decided between letting someone fail (aka face another important lesson or learn from their own mistakes) and jumping in to “save the world”? As Coaches, we often coach others to let folks experiment and learn. It is especially difficult for very technical folks who just became managers. Rather than empowering their team members to make their own decisions, they often jump in and tell them exactly how something should be done. As a Coach, on many occasions, I found myself having those tough conversations with managers and executives on different levels of an organization. What I heard back was often, “The people on my team are too inexperienced, and so I have to tell them what to do.” As a Coach, you do all in your power to get folks out of this “I need to control things” mentality, but it is one of the most difficult ones to crack (especially when there are tight deadlines and there is no room to “fail”). In this blog, I share how I found myself to be that controlling person, what it took NOT to jump in, and how I was able to let others make mistakes.


I am sitting in a meeting, listening to people discussing with passion something as a major pain point, thinking, "If only you stopped for a second and gave the floor to others to share their experience, you could have been done hours ago." I saw this pain point for the first time seven years ago. I have solved this pain point in many companies and among many teams, but when offered help, I was NOT taken up on it. It seemed as if perhaps they still needed to prove themselves, and so they wanted to show their thought process and their expertise. How do you share your expertise when nobody is asking you for it or showing any interest in listening to you? In this case, the discussion was about how to estimate and forecast the project using story points (a technique to estimate using the relative sizing concept) when you have to report progress to stakeholders who only understand “hours.” It did not stop there. We were planning a large Program Increment Planning, and once again, although I mentioned many times that I have organized and facilitated hundreds (without exaggeration) of these PI Planning sessions, I was not asked to share my expertise. Never in my life have I thought that I was the smartest person in the room, but on this occasion, I was 100% sure that I had the most experience on the call when it came to PI Planning sessions. I had to tell myself to give other people a chance to either shine (which I was truly hoping for) or learn from their own mistakes if it didn’t go well. I had to remind myself that I had coached others for years to do the same, and it was my turn to control my own ego. It is hard!


As we gather in the conference room on day one of the PI Planning event, I see one of the walls used for the Program Board. As expected, a blue painter’s tape is used to divide it up, so each team has its space to display their work. Without going too much into the details of the event itself, I will mention that I immediately noticed how regular sticky notes (instead of the super sticky ones) were going to be used, and those don’t work very well. They start falling off the wall pretty quickly, and to avoid that, you can use push pins (depending on the wall), OR you first put flip charts on the wall, secure those, then put blue tape on top of that, and then your sticky notes go on top of the flip chart. I also noticed that there was nothing to show what color of sticky notes represents which team, and there were no directions (in the form of a visual representation) on how we would mark dependencies. There was also nothing posted on what should be on each sticky note (for example, team name, ticket#, sprint#) to make sure that when it falls off, we know where it belongs. I also noticed that there was no schedule posted anywhere in the conference room and the list went on. It is easy to immediately notice what is missing when you have gone through hundreds of them and held hundreds of retrospectives with many different teams to know what it takes for the PI Planning session to run as smoothly as possible. With all of this, it was not until the audio did not work properly that my judgmental ass went into full gear. I could not understand how we were all there for the last 45 minutes, and it was not until the event was kicked off we realized that we could not hear anyone who was remote. How could people be so sure of themselves that they did not bother doing a dry run before? I immediately recalled one of the last PI Planning sessions I facilitated in person before the pandemic and all the checklists that were put together and all the prep that it took and how many dry runs we had.

Then, the facilitator said, “Well, folks, this is a great example of how we learn from mistakes and become stronger as a team”!

There it was. A good wake-up call for me. I was that facilitator years ago, and I have learned through many of my own mistakes. Who am I to take that opportunity away from folks embracing this journey? What do you think I should have done differently?


My friend Ilona, a business owner, could relate that it is difficult to step back when you feel you can greatly help by getting involved. She also agreed that depending on the situation, it could be the only way that allows people to learn.

She then asked, “In what capacity were you a part of that call? Were you hired to coach the team or observe and analyze? Because sometimes, people are not willing to listen to your expertise unless they retain you for a specific task or ask you specifically for an opinion. It happens in business and life.”

The answer was, “It depends on who you ask.” In general, Agile Coaches are hired for their expertise, but this particular audience did not ask for a coach. She then shared the following analogy, which sparked all kinds of thoughts in my brain!

She then said, “The best parallel I can think of is seeing your children doing something that will bring them to failure or will make a situation more difficult. However, you have to step back for them to learn from their actions to make better decisions in the future. To get involved or not, to offer your expertise and help or refrain from it also depends on how often you see this team making the same mistakes. If it’s the first time, it could be logical to allow them to figure out many steps independently. But if the cycle repeats itself and the problems persist, then it becomes a completely different conversation.”

Karen followed up with the parenting parallel and gave a great suggestion of what could be done differently! She said, “It’s almost like parenting, you need to let people try and fall, but you also want to be there to catch them after, or put on Band-Aids, or pick up the pieces! For example, in your case, perhaps you could have brought a box of pushpins in your purse. Or messaged a remote person on the side to see if they could hear!”


I just let it play out. I took the position that it was not my place, and there were many qualified people involved who were passionate about their craft and were vested in this event's success. If they felt confident, it was not my place to not give them the floor to shine.


  • It is always good to assess the risk of the potential “failure” and, based on its probability and severity, devise various backup strategies.

  • Even if people don’t ask for your expertise, if, based on your experience, you anticipate something going wrong, share your thoughts via various channels to ensure the message gets consumed.

  • Even if people don’t listen to what you offer, have people’s back by having a backup plan on standby in case “saving” needs to occur.

  • Some “failures” are ok to tolerate, especially for someone’s growth.

77 views0 comments


bottom of page