In a complex legacy environment, internal motivations like improving developer experience or modernizing technology often fail to gain traction. The initiatives that successfully navigate the process are those that can clearly articulate and deliver tangible value to the end customer.

Related Insights

A significant maturity gap in large organizations is that internal platform PMs don't treat their users (e.g., developers, finance) as customers. Applying customer-centric practices like problem framing and journey mapping to these stakeholders can dramatically improve outcomes.

A platform's immediate user is the developer. However, to demonstrate true value, you must also understand and solve for the developer's end customer. This "two-hop" thinking is essential for connecting platform work to tangible business outcomes, not just internal technical improvements.

Instead of a full rewrite, identify the specific pain points of a legacy system (e.g., a command-line UX) and solve them with minimal development. This delivers immediate value, reduces risk, and validates the market need for a larger investment later, preventing a costly failure.

What developers dismiss as obscure 'edge cases' in legacy systems are often core, everyday functionalities for certain customer segments. Overlooking these during a rewrite can lead to disaster, as the old code was often built entirely around handling these complexities.

To get buy-in for developer experience initiatives, don't use generic metrics. First, identify leadership's primary concerns—be it market share, profit margin, or velocity. Then, frame your measurements and impact using that specific language to ensure your work resonates.

To get product management buy-in for technical initiatives like refactoring or scaling, engineering leadership is responsible for translating the work into clear business or customer value. Instead of just stating the technical need, explain how it enables faster feature development or access to a larger customer base.

To prevent engineers from focusing internally on technical purity (e.g., unnecessary refactoring), leaders must consistently frame all work in terms of its value to the customer. Even tech debt should be justified by its external impact, such as improving security or enabling future features.

To successfully advocate for a working legacy system against modernization pressure, you must be deeply aligned with its profit and loss. If someone else controls the P&L, your customer-centric arguments will be overruled by financial or political motivations, making your position untenable.

Product teams focus on technical metrics like scalability, but customer-facing teams see success differently: it's when a client says they "couldn't run their business" without the product. The goal is to merge these two definitions by translating technical achievements into tangible customer outcomes.

Even if legacy code is stable and functional, it should be replaced when the user experience it provides becomes obsolete. When user expectations (e.g., mobile access, modern UI) have fundamentally shifted, the old system becomes a liability regardless of its technical stability.