The quiet cost of optimizing what’s already workingThere’s a particular kind of ambition that gets rewarded in business: the drive to improve things. Streamline this. Automate that. Rebuild it from scratch with modern tooling. It’s energetic, it sounds forward-thinking, and it gets people promoted.But there’s a question that doesn’t get asked often enough before the consultants are hired and the project kickoff meeting is scheduled: Is this process actually causing a problem?
The Allure of “Optimization”
When a new leader joins a team, or a company adopts a new methodology, or a vendor pitches a platform upgrade, the instinct is to look for things to change. Change signals competence. Change is visible. Standing pat is harder to defend in a strategy deck.But this bias toward action creates real costs — costs that are easy to overlook because they don’t show up immediately, and because the damage is hard to attribute to the decision that caused it.
What You Risk When You Fix What Isn’t Broken
You disrupt institutional knowledge. Processes that have been running for years carry embedded wisdom. The quirky workaround your team uses isn’t arbitrary — someone built it in response to a real constraint, even if no one remembers the original reason. Replacing it without understanding it can mean quietly removing something that was quietly doing a lot of work.
You drain capacity. Any change initiative — even a well-managed one — costs time and focus. People need to be trained, workflows need to be tested, and edge cases need to be ironed out. When the old process was functional, that’s capacity spent not on growth, but on returning to a baseline you already had.You introduce new failure modes. Every new system has bugs, gaps, and unexpected interactions with other systems. An old process that’s been battle-tested has already had most of those found and fixed. A replacement, however theoretically superior, starts from zero.You erode trust and morale. Teams that are repeatedly asked to change how they work — without a compelling reason why — start to feel like they’re being managed by whim. The implicit message is that their judgment about what works can’t be trusted.
The Right Questions to Ask First
Before touching a process that’s running without obvious problems, it’s worth sitting with a few honest questions:What specific outcome are we trying to improve? If you can’t name a concrete metric or pain point, that’s a signal.
Who is experiencing friction, and how often? Anecdote is not the same as pattern.What’s the opportunity cost? What else could this team do with the time and energy a change initiative will consume?What could break? Mapping the risks of change is just as important as mapping the risks of staying put.Are we solving a real problem, or pursuing novelty? This one is uncomfortable to ask, but worth asking.
When Change Is the Right Call
None of this is an argument for ossification. Processes absolutely should be changed when they’re creating genuine friction, when they can’t scale, when they’re exposing the business to risk, or when a substantially better alternative exists and the transition costs are manageable.The point isn’t that change is bad. It’s that change has a cost, and that cost needs to be weighed against a real benefit — not a theoretical one.
A More Honest Standard
The phrase “best practice” is often used to justify change without doing the harder work of justifying it for your specific situation. What works brilliantly at a different company, in a different context, with different people, may not translate. And a process that already works in your context is evidence — actual evidence, not a pitch deck — that it belongs there.”If it ain’t broke, don’t fix it” isn’t a philosophy of complacency. It’s a philosophy of proportionality. It asks you to reserve your energy, your team’s capacity, and your organization’s risk tolerance for problems that are actually worth solving.
Sometimes the most sophisticated thing a leader can do is look at something that’s running well, and leave it alone.Have a business process question or a story about a “fix” that made things worse? The comments are open.