Have you ever been certain that your colleague’s proposed approach is flawed, yet despite your warning, he insists on executing the work his way? If you are a manager, there’s an extra consideration: in addition to ensuring that work is delivered, you are responsible for growing your team members. Do you go along with his bound-to-fail plan to allow him to learn and grow?
Making mistakes is one of the best ways to learn, and in many cases, there’s no true replacement for figuring things out yourself. However, when confronted with tight timelines and ambitious deliverables, it can be difficult to evaluate whether or not to let people fail.
A while back, my team took on a major r̶e̶f̶a̶c̶t̶o̶r̶ implementation enhancement in our codebase to improve extensibility for new features. One of the engineers, Tom¹, volunteered for a key part of this project. Tom’s portion required changes to five different parts of the codebase, but once we figured out how to implement one part, the others would follow the same pattern.
This is a fairly common scenario in software engineering. Typically, Tom would design and implement all the changes on his own, which is what he proposed. This would require less overall effort from the full team because the changes across all five parts were similar.
However, Tom was going on vacation soon, so I proposed that he conduct the design, complete one of the changes as an example, and delegate the rest to other team members. Although this would be a larger overall effort because Tom would have to teach others his designs, I did not think he could finish all the work before his vacation. Despite my concerns, Tom insisted on his approach. At that point, I could either override or support his suggestion. I chose to support.
The goal is to develop a team of independent and critical thinkers: people whom you trust to make these decisions in the future.
Three days before Tom’s vacation, it became abundantly clear that he was not going to complete all the changes. We agreed to revise his work scope: he would implement one of them and other teammates would pick up the rest. After a few late nights and a lot of coffee, we pulled through during his vacation without any delays to our external deadlines.
In our retrospective meeting, multiple team members lamented over the late nights and vowed to plan more carefully next time. One of them asked, “Why did you not insist on doing his refactor your way? It could’ve saved us a lot of time, and we effectively ended up with your approach anyway.” To which I responded, “But then people won’t learn from this experience. Many of you mentioned in our 1:1s that you wanted to improve your technical planning skills as well. My goal is to develop a team of independent and critical thinkers: people whom I trust to make these decisions in the future.”
Here were the three steps I took to decide whether to let my team fail:
0. Cultivate an environment where there is room to fail
OK, I lied. This is really a prerequisite before you can even consider letting your team fail. Innovation is often the result of repeated failures. We have all heard the story where Thomas Edison failed 3,000 times before inventing the lightbulb. Instagram started out as a location-sharing app that failed to gain traction before pivoting to a photo-sharing app, which was ultimately sold to Facebook for $1 billion. Fostering a culture where people are consistently encouraged to try out their ideas without fear of failure is essential to any company in a highly innovative space.
1. Remind yourself that the suggestion might not fail after all
Even if you conducted all the research and investigation in the world, it is important to remind yourself that your analysis could still be wrong. In fact, nobody is right all the time. Steve Nash, the best NBA free-throw shooter of all time, still missed nearly 10% of his free throws. Most of Odeo’s investors in 2006 thought some random hackathon project had no potential, yet it grew to a $25 billion business called Twitter². Even if you are dead-sure that your colleague’s approach will fail, she just might surprise you with an innovative approach of which no one has ever thought.
2. Evaluate the impact on the project and company
Before my team discussed the details of the implementation enhancement, I preemptively added some buffer to the timelines to account for unknown unknowns when discussing with external stakeholders. When the decision point occurred, I was confident that even if our internal milestones slipped slightly, the external deadlines would still be met. This gave me extra flexibility in my calculations because our users would not be impacted.
On the other hand, adding another dimension to an employee’s skill set—in this case, technical judgment—provides versatility to the company’s staffing in the future. Since we were in a rapid growth phase with many new hires joining the company each month, this additional versatility for staffing existing employees would be especially valuable.
As the team lead, you should know the business context and impact of your decision points. What are the real deadlines? What is the true problem you’re trying to solve? What else could be impacted by this decision? Answering these questions will allow you to fully understand the tradeoffs of your decisions, enabling you to evaluate the impact on the project and company.
3. Assess the impact on your team member(s)
I knew that my team members learned best by figuring things out themselves and were looking to improve their technical planning abilities. I made the call that this learning opportunity would ultimately benefit the team. If I had insisted on my approach, the lesson would have been lost because instead of experiencing it, they would have had to imagine the counterfactuals.
The way the decision is handled also makes a difference. I had already suggested an alternative to Tom’s approach due to his upcoming vacation. This gave him an opportunity to consider the pros and cons of each approach and justify his decision to the team. As a result, although his approach was unsuccessful, the entire team was able to learn from this experience that depending on the situation, the “textbook” solution is not always optimal.
On the other hand, had I not said a word and allowed him to go down a path I considered suboptimal, it would have been a less valuable lesson for the team. Consequently, they wouldn’t have had the chance to deliberate the two approaches beforehand, as well as re-examine the assumptions afterward.
It is your responsibility as a team lead or senior member to know each of your teammates. What is the most effective learning style for each member? How will the team react to missing an internal deadline and possibly having to work more hours? Can they learn this lesson without the potential suffering? Lastly, will your team members be able to apply this experience to other projects in the future? These are all factors to consider when assessing the impact on your team members.
All this is not to say that you should let your team fail all the time: nothing would ever get done and team morale would go down the drain. My hope is to provide an additional tool in your management arsenal for when the appropriate situation arises. This can be applied to both higher-level strategic decisions and lower-level execution details. More importantly, understand that you will not always be right, and foster a culture where people are encouraged to present and implement their ideas without fear of failure. Who knows? What you think may be a failure just might turn into the next billion-dollar business!
[1] Names and identifying details have been changed to protect the privacy of certain individuals.
[2] At the time of this writing in 2018, Twitter’s market cap is $25 billion.
For more musings on tech culture, organization building, and management, follow me on Twitter @kenk616.
