I know this is one of those topics out there that people might go – “oh great another blog about letting people fail and everyone being happy and unicorns and rainbows and let’s hold hands and save the world, etc, etc, etc…”. And to some extent it might be, to some extend it might not.
One of, if not the hardest part about managing/leading a team is giving your team the opportunity to fail because at some point, the little voice in the back of your end starts connecting the dots and going “Red Alert! Red Alert! We’re going to crash”. And where does that voice come from? It comes from the impression of how that failure will later be imprinted on you. We see it in any sport that requires a goalie where parents steadfastly refuse to have their kids play in nets because if they fail (i.e., let in goals) people will look to them and their kids for having lost the game even though this could not be farther from the truth. It could of been a myriad of things – sun in the eyes, got pushed in the crease, bad line changes, bad pass, no defense, etc, etc – that the goalie had zero control over.
When you see something like that happen on the ice, as a parent are you going to jump the boards and get in front and block the puck/ring from going in? Essentially pushing your kid out of the way? Probably not. Yes YOU stopped the puck and made the save, but YOU also robbed that kid of the opportunity to learn how to fall down and get up quickly, learn to recover and pivot when something goes wrong and adjust their game so next time they can be better prepared for what comes at them.
Now all they’ve learned is how to step aside.
So – back to delivering software – as a leader/manager your goal is to insulate the failure, how can you give people the opportunity to learn and fail without utterly wrecking themselves and the project? Focus on the small win, coach from the sidelines, offer guidance and experience. When receiving estimates for work, if you know they are way off, add in the slush that you think should be there to get the job done. Are they working with a new API and language they have never seen? Probably not going to be done in a day (even based on a – Can do 100%, 16 hour, give it all I’ve got attitude day) . So go to your stakeholders and tell them 5 days, if it needs to be done in 2, gather more resources to help them out. The best time to learn can be in the moment when they start to unravel all that they have to do but they never thought was there before. If they need it lead them through it, but don’t do it, otherwise you’re just 2 steps away from putting on the goalie pads.
The BEST, BEST, BEST part about letting someone fail through the course of implementing a new feature is when you sit down with them afterwards and look back at what was to be done and what was delivered and they realize where they fell off, but where they had to fail to make it better by the end. The Aha moment if you will. They will not only appreciate the confidence you showed in them to not only let them handle it on their own but also the trust and independence in letting them get there and coming out better for it.
And the beauty is – they will keep getting better over time – continually, guaranteed.
