You inherit a legacy web app. The backend is an unsupported version of Ruby on Rails, the frontend is Ember.js held together by monkey patches, and your GitHub dashboard is a wall of critical security alerts. Upgrading the frameworks is impossible because the dependencies are mutually incompatible.
You and your team are sick of it. You pull your engineering manager and the product lead into a room. You tell them the codebase is a mess, no one understands the event wiring, and you want to spend the next six weeks rewriting it in a modern stack because the current one is dead and you are falling behind industry standards.
The product lead stares at you and says, "The developers who wrote that 'mess' built the product that pays your salary. If you don't understand the codebase, maybe we hired the wrong person. And you want to freeze feature development for a month and a half so you can use a trendier framework?"
Your pitch failed because you pitched a developer comfort problem. Management does not care about your developer experience. They care about risk and revenue.
If you want approval for a massive structural change, you have to map the technical rot directly to business metrics.
Don't say the code is hard to read. Say it took the team three weeks to add the PayPal integration because the billing module lacks tests. Explain that if you extract the payment gateway into a separate service, you can add Apple Pay and Stripe in four days each. Now you are pitching faster time-to-market.
Don't say you have technical debt. Say the team spends two days every sprint manually resolving stuck database locks. Explain that if you rebuild the data layer, you reclaim that engineering time for new features. Now you are pitching resource optimization.
Don't say the framework is deprecated. Say the current version of Rails stops receiving security patches next month. If a vulnerability is exploited, the company fails the upcoming SOC2 audit and loses the enterprise contract currently in negotiation. Now you are pitching risk mitigation.
Never pitch an open-ended timeline. "A few weeks" sounds to management like six months of zero output. Bring a phased plan. Show exactly what you will cut and what you will keep running. Propose rewriting the highest-churn service first, putting it behind a reverse proxy, and routing 5% of traffic to it. This proves to management that you can deliver value incrementally without betting the entire company on a single, massive cutover.
A rewrite is a massive financial investment. If you walk into the room sounding like a developer who just wants to play with a new tool, the answer will always be no. Frame the technical cleanup as a business enabler, prove the financial return with historical sprint data, and you won't have to beg the product lead for permission to fix the wall of security alerts.
We cover stakeholder communication, negotiating for engineering time, and the other non-technical skills that determine whether you advance as an engineer, in our course The Tech Career Playbook — 7 Rules Beyond Code.
Author Quote
“Management buys speed, not frameworks”