Modernization: Old != Bad; New != Good

December 3rd, 2025
Reviewing the old as a means of realizing the new – such a person can be considered a teacher.” — Confucius

I have been a part of many modernization efforts. It’s a necessary step in the evolution of a product, of a team and of an organization. I’ve seen it done well, and I’ve seen it done poorly.

I shudder to recall one project I worked on… I joined the team late, and was asked to help them get back on track from a timeline perspective. When I asked about the project objectives, everyone was in agreement on what those were – to rewrite the system. They were taken aback at my perplexed face, and confused by my response.

“Sure… but why? What are we trying to accomplish?” Their response? “We were asked to rewrite the system. Management said to rewrite it.” The business team, the technical team – they all stated this as their goal. No one had stopped to articulate what problems the rewrite was meant to solve.

It took some work to track down the real (and valid) objectives. The current process was a conglomeration of systems integrated through manual steps, with significant data duplication and inefficiencies. The purpose of the “system rewrite” was to reduce manual effort associated with the use of multiple systems and reconciling across data sources.

When these objectives were surfaced and discussed (and we stopped just talking about modernization) other options became available. Where before massive effort was being planned to rewrite entire systems, now we started having discussions about relatively minor integrations between systems that achieved the efficiency goals with much less overhead.

Modernization is tempting. It promises speed, clarity, and efficiency. But executed poorly it becomes waste, churn, and self-inflicted wounds. Here are some of the common modernization traps – and how to avoid them.

Traps

  • Newer is Better – Do not fall into the trap of considering everything old as bad and everything new as good. In both systems and organizations, the current state usually exists for a reason – whether it was intentionally designed that way or evolved through a series of practical constraints. It is appropriate and necessary to question whether that reason is still valid, and to challenge it – but it is also important to understand it, so that you are not reintroducing problems that have already been solved.
  • Oooh, Shiny! – Whether it is new technologies, new execution techniques or new management frameworks, it is easy to jump on a bandwagon with a lot of buzz. Perhaps the team wants it as a resume-builder. Perhaps management believes it is a silver bullet to solve the toughest problems. Before chasing something shiny make sure you have clear and realistic expectations about what concrete benefits you expect to realize. If, after testing a change, it is clear that these benefits won’t be realized, quickly abandon or adapt the modernization effort.
  • Blank Slate Fantasy – It is tempting to imagine that starting over will wash away accumulated complexity. But complexity has a way of returning. Systems accrete rules for reasons. People and processes do, too. Starting fresh without understanding why complexities were introduced often means re-learning old lessons at full price. A blank-slate approach can reduce complexity, but only if you understand what problems that complexity once solved, and design simpler solutions for those same problems.
  • Metric Myopia – Modernization efforts often focus on a single metric: performance, cost, velocity, security, “cloudiness”, “newness”, or whatever is currently fashionable. The trap is assuming that improving this one axis will improve the entire system. Monocultures are fragile: focus too tightly on one measure, and you may erode resilience elsewhere. Modernization is ecological – it touches many metrics at once. Measure it appropriately.
  • Stagnation – Avoiding modernization because change is hard, or you can’t prioritize time to invest in the future, leads to stagnation. In a product, this may mean falling behind your competitors or failing to leverage changes in technology. In a team or organization this may mean failing to grow your skills or adapt to change. Don’t let the presence of the other modernization traps scare you into falling into this one.

Guidelines

  • Why Before How – Before discussing tools, architectures, processes, or roadmaps, make the underlying problems explicit. What pain are you relieving? What capabilities are you unlocking? What risks are you reducing? Modernization is only meaningful as a response to something real.
    • Will you be able to improve customer response times? Say that.
    • Will you be more efficient (able to do at least the same amount of work with less effort)? Say that.
    • Will you be closing important security vulnerabilities? Say that.

    Start with the “why,” and the “how” becomes far more grounded – and often much simpler. Labeling something simply as “Modernization” invites people to step squarely into the “newer is better” trap.

  • Right-Size the Change – Not every modernization requires revolution. Sometimes the smallest viable improvement delivers the greatest return. If your goals can be met by pruning rather than replanting, prune. Measure modernization by outcomes, not by the volume of change.

  • Carry Forward the Good – Every system, no matter how tangled, contains something that works well: an efficient process honed over the years, a dependable component that never has to be touched, or a bit of institutional knowledge that holds the whole thing together. Modernization is not demolition; it’s renovation. Identify what is valuable and bring it forward deliberately. Preserving proven strengths is as important as improving weaknesses.

  • Test and Learn – As you’re exploring your modernization with clear objectives in mind, be mindful of what works and what doesn’t work. Don’t be afraid to redirect what you’re modernizing and how. The last thing you want is to expend significant effort to modernize only to achieve no benefits (or in some cases, actually make things worse).

As a product manager or a leader of a team or organization you want to avoid stagnation, complacency and mediocrity. Modernization could be your way forward – if you avoid the traps, learn from your history and define clear objectives for your future.

Modernization is a choice, not a reflex. Make it deliberately.

Interested in help planning or executing a modernization effort?  Feel free to reach out at al@melecoaching.com and let’s chat.

Tell Me More (Additional Reading)

  • The Innovation Delusion (Vinsel, Russell)
  • Accelerate (Forsgren, Humble and Kim)
  • Corporate Innovation in the Fifth Era (Merle, Davis)