When Best Practices Fail

Not all problems are the same kind of problem.

Some have clear cause and effect. You can write a checklist, follow it, and get the result. Deploying to production. Setting up a CI pipeline. Onboarding a new developer. Best practices shine here — the relationship between action and outcome is predictable enough to standardize.

Other problems require expertise and analysis, but the right answer still exists. Tuning a slow query. Debugging a memory leak. Designing a caching strategy. There's a correct approach even if finding it takes skilled work. Best practices still apply — they just require judgment to apply them well.

Then there are problems where cause and effect only become clear in hindsight. Building a feature users haven't asked for yet. Scaling a system you've never scaled before. Entering a market you don't fully understand. No amount of planning reveals the answer upfront — the terrain only becomes visible as you move through it.

This is where best practices break down. Rigid roadmaps and detailed upfront planning keep failing not because of poor execution, but because the tool doesn't fit the problem. A checklist assumes the path is known. Here, finding the path is the work.

The trap isn't reaching the wrong solution. It's misdiagnosing the problem type — treating the third kind like the second. Thinking you need a better plan when what you actually need is contact with reality.