Analysis Paralysis in Software Engineering

A few years ago when I started my jorney as Eng Manager, I was trying to figure out a better way to measure development velocity for my team when I came across a situation that later on I learn as to be called analysis paralysis.

Before, some context:

We estimated Jira issues complexity with fibonacci, backed by a complexity matrix, which was a ritual introduced by the previous manager on that team. Adding a field to an existing API endpoint was low complexity. A brand new endpoint was medium, because now you are designing the data structure, handling migrations, and thinking about traffic and database load. An endpoint touching PII in a multi-tenant architecture was high, because the security layer adds real work.

The matrix was useful. The paralysis started when I tried to turn it into a north star metric. One project sat blocked for two sprints waiting on another team. Should those sprints count against velocity? An item scored as high complexity turned out to be easy. Do we re-score it? Every adjustment to the model raised two new questions, and the metric never shipped.

I see the same movie playing today with AI. Companies want to measure AI adoption, and token usage is the number everyone can pull. But does a team burning more tokens mean higher productivity, or just sloppier prompts? Do you normalize by team size? By type of work? Leaders keep refining the model while quarters go by and nobody learns anything.

That is analysis paralysis, and it is very much a leadership problem, not just an engineering one.

Why leaders fall into it

The more senior you get, the easier it is. Experience teaches you how a bad metric distorts behavior. You have seen teams game story points, and you can already picture engineers padding token usage to look busy. So you keep refining, because publishing a flawed metric feels riskier than publishing none.

There is also a quiet career angle. A metric with your name on it can be wrong. An analysis that is “still in progress” cannot. Analysis becomes a hiding place.

The two-way door test

Jeff Bezos talks about one-way doors and two-way doors. A one-way door decision is hard to reverse. A two-way door can be undone if it turns out to be wrong.

Publishing the first version of a metric is a two-way door. If token usage turns out to be a poor signal, you change what you count next quarter. Most measurement decisions are like this, yet we deliberate as if they were irreversible. So ask: if this is wrong, what does it cost to change? If the answer is “an awkward conversation and a dashboard update,” the analysis should not take a quarter.

Breaking out of it

Three things have worked for me. Put a deadline on the decision itself, not just the project: we decide by Friday with whatever we know by Friday. Make one person the owner, because committees stall. The RAPID model exists exactly for this. And say the quiet part out loud: version one is allowed to be imperfect, and nobody gets punished for a reversible call.

Deciding is also information

One thing the OODA Loop taught me is that acting is not the opposite of learning. It is often the fastest way to learn.

I eventually published a simple version of that velocity metric and let it be imperfect. Within one quarter, the conversations it started taught me more about where the teams were struggling than weeks of refining the model ever did.

Perfect information never arrives. Decide with what you have, watch what happens, and adjust. That is not recklessness. That is the job.

I hope this was useful for you, Rodolfo