Product leaders: Help your team embrace the fail

Failure is critical to success. It might seem counterintuitive, but organizations where failure is not permitted (or even punished) often struggle to achieve their goals. Allowing teams to experiment, fall, and pick themselves up to try again leads to innovation. Teams that are free to make mistakes and try and fail are also free to build trust with the team and with the organization.

An organization that embraces failure will come to embrace success.

Fostering an environment where it isn’t OK to fail is one that leads to failure. I once worked for a company that struggled to meet deadlines and had failed to roll out three publicly announced releases. While interviewing the team and meeting with leadership, the problem quickly became clear: Everyone was afraid to deliver bad news of any kind and painted a rosy picture of progress being made.

Leadership would then make commitments based on bad information. The release date would arrive, and the promised features wouldn’t be complete. Leadership would fire people and reprimand the team for failing to deliver. Trust would erode and the cycle would continue. They never got the opportunity to look at why they were failing, try something new, and find a path to success.

I took this lesson to heart when it came time for me to serve a team as Scrum Master. I had a team of developers that had been working together for more than a year with what we thought was a stable pace. We were building a new website for a client and kept falling short of our sprint goals. Our team was following an agile methodology and they were tracking their “velocity” every iteration (every two weeks). Velocity is how we measured how much we finished each sprint—our team had established a velocity from working together in the past, but we were tracking to a lower number than usual. If it kept up, we wouldn’t be able to release the website to coincide with our client’s deadlines.

We talked about it in the retrospective and the team came up with new ideas to try out: more detailed tasking; simplifying the UI; afternoon standups—and yet nothing was working. The next retrospective surprised me: The team decided to start working weekends until we figured out the problem.

Eventually, we solved it with work-in-progress (WIP) limits and delivered the website ahead of schedule. These work-in-progress limits determined how many items could be in development or in testing at a given moment. What we found was that we were working on too many features simultaneously, which was resulting in us having multiple stories partially completed.

When we unpacked that in the next retrospective, we discovered that most of the team was concerned about hitting the deadline and weren’t asking each other for help as much as they usually had. No one wanted to be the one holding the team up. The WIP limits helped us see which features were giving us trouble and allowed the team to jump in and help without needing to be asked. It helped remind us that no one was judging anyone else for needing help and built trust within the team.

Since then, I’ve learned to not be surprised at what teams will be willing to do to succeed. Give them the room and trust to try new things—and potentially fail—and they’ll find the pathway to success. Tear down that trust by punishing failure and you teach your team to avoid failure, which is not the same as pursuing success.

Motorcyclists will be familiar with the term target fixation—when you become focused on a singular object, you tend to ride straight into it. Focusing on avoiding failure will drive you straight into it.

Authored by: Ted Mazza