Overcoming an Analysis Paralysis on Your Team

Problem

Analysis paralysis or paralysis by analysis refers to a situation where overanalyzing can cause decision-making to become “paralyzed”. Engineers often find themselves stuck in the never-ending analysis without progressing and moving closer to the solution.
 

When I joined my previous company I inherited a team of highly technical back-end people. Their past manager was fired and they have been left without any leadership for a while. I was appointed to manage a very knowledgeable group of people who were striving for perfection and were spending time on corner case solutions that were nowhere near a priority. They were hardly making any progress and were stuck in their own quest for perfection.
 

Actions taken

I started dealing with the problem by setting more clear expectations. Somehow people on the team believed that they had to come up with perfect solutions and I would encourage them to prioritize progress over perfection. To achieve that I had to create a team culture that championed progress and embraced failures. I called for a team meeting where I explained to them why progress was important and how making mistakes was acceptable. The fact that previous managers were fired sent a signal that mistakes were not tolerated and much of their behavior was driven by those implicit assumptions.
 

Then a series of one-on-ones took place where they would ask me about specific tasks and if they should work on those. As I was fairly new to the team myself, I often didn’t have all the details but decided to move forward and show them by example what was the preferable model of behavior. Move forward and figure it out!
 

I decided to follow the processes that were used in our company, but not on our team. For example, the RAPID model was company-wide accepted as a decision-making tool (RAPID stands as an acronym for five roles within the decision-making process -- recommend, agree, perform, input, and decide). I explained to the team how to use the RAPID model and then have them observe the process when I would use it.
 

Another thing that also helped the team move forward and make progress was applying the Pareto principle or the 80/20 rule, which stipulates that 80 percent of the effects come from 20 percent of the causes.
 

I had noticed that the team started to slowly move forward applying these processes. However, to support their efforts I had to build a culture that would encourage people to do experiments and make mistakes. Also, I had to make sure that our leadership would be willing to forgive our first-time mistakes as we were learning new things and trying new approaches. At the same time, whilst first-time mistakes should be accepted recurring mistakes would undermine accountability and I had to set those expectations clear with the upper management.
 

Lessons learned

• All the processes I introduced were highly useful, but you have to know when and how to apply them. Oftentimes people would overuse them making them a goal in itself or would avoid using them because they were not familiar with them. -Nothing rivals one-on-ones where you can directly talk to your reports and set and clarify your expectations if/when needed.
• Most mistakes are reversible and making mistakes is acceptable. My role as a manager is to de-risk things and allow my engineers to make mistakes in a safe setting and learn from them.