Leadership Lessons Learned the Hard Way; Part II – Sometimes the best thing to do is nothing!

My first post in this series described one of the most important leadership lesson I learned – to allow your team members to become better leaders themselves by simply getting out of their way.

One way to support that effort is, when there is a problem, to resist the urge to jump into the fray and come up with a solution on behalf of the team. Sometimes the best thing for a leader to do is nothing! Project leaders often feel the incredible urge to show that they are getting things done. The temptation is to be able to say that they tried rather than admit they did nothing at all! The situation is worse when they jump in to solve the problem without all the facts and figures at hand and without waiting for the project team to complete their analysis. This derails the team and creates additional churn.

As quoted in 100 Rules for NASA Project Managers, “Sometimes the best thing to do is nothing. It is also occasionally the best help you can give. Just listening is all that is needed on many occasions. You may be the boss but, if you constantly have to solve someone’s problems, you are working for him.”

I can think of two instances where I applied this to much success.

A couple of years ago, one of the projects in my organization had hit a roadblock. A supposedly big problem was holding up our next milestone, and much to the frustration of the team, there was no solution in sight. The problem was quickly escalated to me as a risk to the project and a meeting was scheduled to discuss the consequences. In attendance at the meeting were all the immediate stakeholders who were contemplating the unthinkable.. a schedule slip.

Since some of the stakeholders  were consumers of the product and not very close to the implementation, I requested the team to go up to the whiteboard and draw up the current architecture being considered, and then draw up the problem encountered. One of the key questions I asked was, “Let’s go back to the basics. Can you explain to me in simple terms the overall problem?”. The engineering team had to explain the problem in really simple terms and talk through the issues in plain terms. It forced the team to take a step back from the details and draw up a simple overview of the problem. What a difference that made! The solution became immediately obvious to the engineers and stakeholders. The solution was not at the point the team was stuck at, but upstream of that component.  No heroic efforts were necessary to solve the problem thereon, and no schedule impact was seen either. Just a simple fix and the problem was solved! It was a huge moment for the project team to have resolved the problem themselves.

Another intance where this approach was successful was when my project team was at odds because two people could not agree on a solution. Bringing them together into a room and having them talk to each other about all the details, the pros and cons, and potential outcomes, was all it took to reach a consensus. All I had to do was to setup the meeting and ask simple questions. The team took care of the rest by themselves.

It is important that your team tries to solve a problem themselves, and patience is key. Your role is simply that of a facilitator to the proceedings. Give them the forums and the facilities to make these huge leaps, and the situation can be a postive learning experience for all people involved.

Do you have any such examples to contribute from your experience? I’d love to hear how this has been successful for you.