I had an email conversation with a colleague about when you let people fail versus when you rescue them—how you nurture leadership. The context is with people who are new to management, or new to a particular piece of work in a project.
If you’re agile, I say you pair these people and be done with it. No problem. But my colleague is not agile. So, the first option is not going to work. Well, fine. We need more options.
The next question is when is the point of no return? When is the trigger point for when the risk turns into a disaster? If you are coaching people, or helping people learn something new, you want to help them see their options before the disaster. We need to find the most responsible moment to make a decision.
Let’s talk about the most responsible moment for a little bit. Notice that I did not say the last responsible moment. I said the most responsible moment. That’s because while I might be able to take more time to make a decision, someone with less experience might need more time to make the decision. Hmm, I bet we need an example about now.
My colleague is a test manager in a plan-driven organization. Let’s imagine he is grooming a tester to shoulder more responsibility as a technical lead. This tester is not as able to make the decisions about what the defect data means, nor about what the test case plan/run/pass data means. The tester doesn’t quite understand the fault feedback ratio either. My colleague is coaching the tester to see the big picture from the data. This is fine.
My colleague decides to work with the tester once a week on the test dashboard and ask the tester for the tester’s interpretation about the project’s status. They discuss it, write down their interpretation, and continue through the project. Near the end, as the pressure mounts, they start to meet every other day, and finally every day. The big question is this: When do the testers have to retest which areas of the system?
Part of that question is depends on what the developers change. Part of that question depends on what has regressed. So the aspiring technical lead needs to know about the guts of the system with respect to regressions, and decide when the testers have done enough regression testing.
In a plan-driven project, this is a critical decision. Too much regression testing, and you never release. Too little regression testing and you release defects. You need to understand the release criteria and how the changes affect the release criteria. It’s a delicate balance. Definitely a decision that requires solution space domain expertise. You can’t make the decision the day before the release; everyone needs some notice. What should my colleague do?
This is where my colleague’s brilliance of writing down their interpretations all the way through the project shines. They have a history of their conclusions based on whatever data they’ve had throughout the project. They have a way of discussing their decisions.
The test manager can be transparent about the decision with aspiring lead, for this project and the next. Maybe after one or two projects, the test manager can leave the decision with the lead.
To recap the options:
- Try pairing if possible. Actually, the practice of working with the manager and discussing the decisions during the first couple of projects is a form of pairing.
- Work with someone and be transparent about your decisions even if you are making the decisions so they can see how you think.
- Help people see the date/time by which they need to act or decide when the decision is theirs.
- Help people create plans with multiple checkpoints when the decision is theirs.
- Practice making decisions on smaller projects/with less risky decisions when the decision is theirs.
Things to not do:
- Don’t tell people they can make the decision and then make it for them. That’s grabbing the decision back and is not nurturing leadership.
- Don’t tell people the decision point is artificially early. That’s artificially rescuing them and doesn’t allow them to even come close to failing. It also closes options too early.
- If you think you are seeing someone “fail,” offer feedback. Offer help. Do not interfere. No matter how much it hurts you. Unless you see someone in physical distress.
- Do not be offended if people don’t want anything from you. Tough.
When you nurture new leaders, you ask them the questions before you let them fail. You don’t wait for them to go past the decision point. You don’t take over the decision from them. The problem is when is the decision point.
And what happens if people “fail”? Well how bad can the failure possibly be? When you nurture leaders, you help people learn how to learn from their failures. If you rescue people all the time, they can’t possibly learn.
Reference: Nurturing Leadership from our JCG partner Johanna Rothman at the Managing Product Development blog.
