Monsters Under the Bed!

Over the years I have seen teams become paralyzed for a variety of reasons.  Some get mired down in studying problems to death, often referred to analysis paralysis.  Others suffer from one form or other of team dynamics issues.  I'd like to focus on one of my favorites, irrational fear or as I like to call it, fear of monsters under the bed.  Trust me, this can grind progress to a standstill.

I led a team responsible for developing a power conversion product and when I arrived the team was mired in a series of endless technical debates and it was very hard to sort fact from fiction.  One of the most hotly debated issues had to do with a safety requirement.  Both sides started dragging out allegations that dire consequences would result if we chose the other guys design approach.  After a particularly heated meeting I went off and did some research.  It turned out that neither side had any facts on their side.  I told them we would implement both approaches and test the performance to get real data.  I made the team sit down and decide on test criteria in advance.  As it turned out the first design worked very well but when we reviewed the data one of the guys struggled to accept the results.  I explained (as patiently as I could) that he could suggest additional testing to further validate the design but that if he could not, we were moving on.  After some period of grumbling, even he moved on.

This example is the best way I know how to deal with unknown fears.  Turn on the lights and make the alleged monsters them show themselves.  This means rigorously going after facts and making sure that when endless debates arise about concerns, that we work with our teams to get them back on fact based tierra firma.  Work with the team to first understand from a strictly fact based point of view what the concerns are, in the case I was describing above the team passionately argued that failures could result in building fires.  It turned out there was no such basis in fact and the real concern was over stress elsewhere in the system leading to premature failure.  We were chasing the wrong issue and had been for some time.

The next step is to agree on what solutions address the issues or requirements defined in the first step.  In my case, we came up with a couple of design approaches to address this particular requirement.  The next step is key.  The team needs to agree on how to validate or evaluate the various solutions.  This means they need to decide on what data must be collected and in some cases how it will be obtained to gather facts necessary to evaluate the solutions.  The final step is to use the data to evaluate the solution(s). In my case we evaluated just the first solution and since it worked we moved on for the sake of efficiency.  If you need to evaluate relative performance than, you must collect data on all solutions.  In either case it is crucial that you stick to objectively evaluating the data and do not allow emotion or allegations to drive decisions.  It's OK to allow the team to cycle back to collect more data if required, but do not let them get into analysis paralysis.  If the new data requested will not fill in a key missed step or is the result of new learnings, think twice about going back to collect more data.

We all have our rational and irrational fears.  The best way to deal with these fears is with facts.  Help your team to get past these fears by taking them head on and leading them through a fact based decision process. No mater how nasty the problem, if you stick to a rigorous fact based decision making process you will ensure the best outcome.