The best argument against doing the imperfect thing in front of you is that it isn’t perfect. I have watched entire organizations lose years to this argument, and I want to talk about what that actually looks like from the inside, because from the inside it doesn’t feel like paralysis. It feels like rigor.
There is a name for what I’m describing. The nirvana fallacy, sometimes called the perfect solution fallacy, is the habit of measuring a real option against an ideal one that doesn’t exist and concluding that because the real option fails the comparison, you’re better off doing nothing. The name comes from the Buddhist concept of nirvana, the unattainable perfect state, which is a little ironic given that the whole point of Buddhism is to be okay with impermanence. But the fallacy has taken the word and run with it, and it is running through your industry right now at a pace that would impress you if it weren’t costing you so much.
Here is what it sounds like in practice. “We can’t implement this feedback process until we can guarantee anonymity.” “We can’t hire until we’ve built out the onboarding program completely.” “We can’t address the team dynamics issue until we understand the root cause.” “We can’t launch the empathy initiative until leadership is fully aligned.” What all of these sentences have in common is that they are using a real concern (incomplete anonymity, incomplete onboarding, incomplete understanding, incomplete alignment) as cover for something that is not a concern at all: the imaginary version of the thing, which would be perfect, and which will never arrive.
I spent enough years in infrastructure to know what this looks like when the stakes are concrete. A monitoring system that catches seventy percent of incidents is not a good monitoring system in the ideal sense. But it is infinitely better than the perfect monitoring system you are still designing. A p95 SLO that you actually measure beats a p99.9 SLO that lives in a slide deck by any metric that matters. The engineers who understand this viscerally, who have been woken up at 3am enough times to have a healthy relationship with imperfect observability, are not confused about whether to ship the imperfect thing. They ship it. They improve it. They do this because they have learned, through direct experience, that the absence of imperfect coverage is not the same as perfect coverage. It is the same as no coverage at all.
The fallacy gets harder to see when you move from infrastructure into people. And I think this is worth sitting with, because the domain shift is not incidental. With systems, you can measure the gap between what you have and what you want. With people, with culture, with the soft and unglamorous work of building an environment where people can actually do their best work, the gap is harder to quantify, which means the perfect imaginary solution is easier to construct and harder to argue against. You can always conjure a more complete version of the thing. You can always find a reason why this particular feedback mechanism isn’t quite right yet, why this particular conversation is better had after the next planning cycle, why the team health check feels premature while the roadmap is still unsettled.
What you are actually doing, in those moments, is comparing the cost of the imperfect action against the cost of nothing. And you are miscounting. The cost of nothing is not zero. The cost of nothing is everything that accumulates while you wait: the engineer who decides you don’t actually care because nobody asked, the team dynamic that calcifies because there was never a structured moment to name it, the trust that doesn’t get built because the conditions for trust never got created. The nirvana fallacy hides these costs because they don’t appear on any ledger. The imperfect solution you didn’t implement doesn’t generate a line item. It just generates a culture where people have learned not to expect much.
There is also a version of this problem where you are doing the imperfect thing, you have done the imperfect thing, and someone accuses you of not doing enough anyway. This happens more than people admit, and I want to address it directly because the nirvana fallacy does not only freeze leaders from the inside. It gets aimed at them from the outside too, and knowing how to hold your ground in that conversation is a different skill from knowing how to start the right project.
The single most useful question I know in that situation is: compared to what? Not as a deflection. As a genuine request for the comparison being made. When someone says “this isn’t enough,” there is always an imaginary “enough” hiding inside that sentence, and it is worth pulling it into the light, because about half the time it turns out to be incoherent, and the other half it is a real thing you can actually respond to. “Compared to what?” does not mean “what I’m doing is fine.” It means “show me the standard so we can evaluate it together, instead of against a feeling.”
The second thing that helps is making the imperfect action visible before the criticism arrives. This is partly about communication and partly about framing. If you implement an eighty-percent solution without naming it as such, the gap between it and one hundred percent looks like negligence. If you implement it while saying “here is what this does, here is what it doesn’t do yet, and here is when we revisit it,” the gap looks like a plan. The difference between those two things is not the action. It is whether the action has been given enough context to be evaluated honestly rather than just compared to an imaginary alternative.
The third thing, and the hardest, is to stop accepting the premise that imperfect action equals insufficient effort. This is the frame the nirvana fallacy needs to survive, and you do not have to grant it. Doing the sixty-percent version of the right thing is not evidence that you don’t care. It is often evidence that you are the only person in the room who is actually paying attention to what’s achievable. The people demanding the perfect version are not wrong to want it. But they are not the ones who have to answer to the ones on the outside watching you build it, which is a relevant asymmetry that sometimes needs to be named out loud.
I want to be clear that I am not arguing for thoughtless action. The answer to “this isn’t perfect” is not always “ship it anyway.” There are genuinely bad plans that should be improved before they go anywhere near a team. But there is a difference between a plan with real structural problems and a plan with the problem of being imperfect in a world where nothing is. Most of what I see stuck in organizational purgatory is the second kind. It is feedback mechanisms that would work at eighty percent. It is check-in cadences that aren’t perfectly designed but would be better than nothing. It is conversations that need to happen before someone is ready to have them flawlessly.
The one thing I keep coming back to, the thing that took me embarrassingly long to stop arguing against, is this: you are not choosing between the imperfect thing and the perfect thing. You are choosing between the imperfect thing and what exists right now. That reframe does not make every imperfect solution worth implementing. But it does make the question honest. And honest questions are the only ones that lead anywhere useful.
The perfect version of this post would have a cleaner ending.
This is the ending it has.
