Elevate Winter Summit has been announced (Fri, Dec 11th).

🔥


Don't have an account? 

Overcoming an Analysis Paralysis on Your Team

Team processes
Company Culture

30 October, 2020

Bhavin Surela, Director of Engineering at Twilio, describes his efforts to end an “analysis paralysis” on his team by introducing processes that encouraged their bias to action.

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.

Related stories

Building a Team of Mixed Seniorities
29 November

Sameer Kalburgi, VP of Engineering at Fieldwire, discusses how his team evolved from hiring junior engineers to building a team of -- and balancing -- mixed seniorities.

Building a Team
Company Culture
Sameer Kalburgi

Sameer Kalburgi

VP of Engineering at Fieldwire

Preserving the Startup Mentality After an Acquisition
26 November

Raghavendra Iyer, Head of Engineering at ReachStack, tells of his efforts to preserve the startup mentality of his team following the acquisition by a large company.

Company Culture
Personal growth
Raghavendra Iyer

Raghavendra Iyer

Head of Engineering at ReachStack

When Hype Doesn’t Deliver Value
26 November

Matt Pillar, VP of Engineering at OneSignal, shares how he had to abandon a technology investment his team was pursuing that neglected the real customer problems and instead focused on the brilliance of the solution alone.

Team processes
Product
Dev Processes
Matt Pillar

Matt Pillar

VP Engineering at OneSignal

A Company Merger: Two Locations and Multiple Challenges
26 November

Matt Pillar, VP of Engineering at OneSignal, recalls how he helped merge two engineering teams at two different locations and how legal and cultural context made all the difference.

Company Culture
Cultural differences
Team processes
Team reaction
Remote
Matt Pillar

Matt Pillar

VP Engineering at OneSignal

An Egalitarian Approach to a Disportionate Workload
16 November

Nimrod Perez, CTO and VP of Engineering at Wobi LTD., explains how he solved a long-troubling problem of disproportionate workload by his simple and egalitarian approach.

Team processes
Ethics
Ownership
Nimrod Perez

Nimrod Perez

CTO and VP of Engineering at Wobi LTD.

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.