It's Monday morning. Your product manager, visibly excited, announces a "simple new feature", max 1 week of work. You open the codebase, stare at the tangled mess of legacy code, and realise it'll actually take two months.

If you're lucky.

Two months of digging through the code that would make even AI Agent quit its job. You feel a sudden urge to drop all of this and start raising geese in some remote mountains. Instead, you grit your teeth and make yourself another coffee. You're going to need it.

It's not the first time. The legacy code gives you a headache for a long time already. But the last three times you brought up "refactoring", you watched your manager's eyes glaze over before he changed the subject to "more pressing priorities".

I've been there. Many times.

And I was angry and frustrated. Why don't they understand how bad things are? Why don't they understand that we need to fix it? Are they stupid?

They were not. Obviously. It was my fault. I did not know how to talk to them.

I eventually learned how to do this. How to pitch an idea to the leadership and convince them to invest in it. I learned it the hard way, making many mistakes along the way. Now, I want to share this knowledge with you, telling you what I wish someone had told me many years ago.

Story Time: Pitching Location System Rewrite

Back in the day, I was working as a Head of Engineering in the Real Estate Marketplace.

As you can expect from the Real Estate business, location search and related functionalities were at the very centre of our interest. We had big plans!

Unfortunately, the location system we used did not know about those plans. It was an old, legacy mess that my engineering team was struggling to keep afloat. They did not even want to think about building advanced features on top of it. But the leadership was pushing for more, business critical features.

We needed to do something.

We sat down and drafted a new location system. Better, simpler, flexible, easy to extend with new features. But implementing it and replacing the legacy one was not a trivial task - it required time and resources. We needed to convince the upper leadership to allocate a team to that project and modify the planned product roadmap. Not easy, given the tight timeline and competitive market.

I needed to pitch our idea to the leadership and get them on our side. I've prepared a PitchDoc.

First, I reviewed the planned product roadmap for the locations to check what engineering work is needed to implement it.

Next, I described the issues with the legacy system, focusing exclusively on how those issues would prevent us from implementing the roadmap and achieving our business goals. Not a single word about technical debt or "ugly code".

I focused entirely on missing abilities, incompatible data and a compromised roadmap and user experience. I also highlighted how, due to the inherent complexity of the old system, the implementation time would be significantly higher for any work touching it.

Finally, I described possible solutions.

One option was to invest in the legacy system, modernise it and remove flaws that were blocking us.

The second was to implement a new location system from scratch, based on modernised assumptions and new tech.

Both plans were backed up by a high-level project plan, required resources, a migration plan and an estimated timeline.

I shared the PitchDoc with the leadership and scheduled a meeting to discuss the details. In the meeting I went through the key highlights of the proposal, stating that my recommendation, based on the research I did, was to implement a new system.

They asked a few questions, especially about the project plan, and after the discussion, they gave me a green light to proceed with the project and prioritise it as our main point of focus for the next few months.

Great success! 🎉

Notice that in this story, I never once said anything about technical debt or refactoring. All the discussion was about what we need to do to achieve the company's strategic goals. What we, as an engineering team, have to do to deliver our product roadmap as efficiently as possible.

Looking back, that success wasn't luck. I'd stumbled onto a formula that actually works. I started using the same approach for every technical pitch, and it kept working. Turns out there's a specific pattern to getting leadership buy-in, and I've refined it into a framework I want to share with you.

How to Pitch Your Idea to the Leadership

This experience taught me a simple but powerful approach. Every successful technical pitch I've made since, follows the same three-part framework:

• Why - The business problem I'm solving
• What - The solution I propose
• How - High-level execution plan

Pitching is a lot like selling. Good sellers create demand by solving problems their stakeholders have. To do that, you need to understand them.

Step 1: Know Your Audience

The first and most important realisation was that previous failures to prioritise the technical debt were my fault. I did not communicate it properly. I was talking to senior leadership like I was talking to my peers, fellow engineers. No surprise that I failed to convince them!

The first rule of good communication is "understand your audience!" But it took me many failed attempts to understand that engineers and executives are wired completely differently.

We think about code quality, technical elegance, and long-term system health. They think about quarterly targets, customer retention, revenue, and what they'll report to the board next month.

This isn't because they don't care about quality - they're simply playing a different game.

Usually, the more senior the leadership, the less they care about technical details. They don't care what version of React you use. Sadly.

Terms like "reducing technical debt" are too vague for them. A successful pitch demonstrates how your technical issues relate to their business challenges and how it helps them solve it.

In short:

What makes executives say yes - Clear ROI, reduced business risk, competitive advantage, and solutions to problems that keep them awake at night.

What makes them tune out - Abstract concepts, technical jargon, and requests without a clear business impact.

Step 2: Align with Company Goals

Company strategy is like a complex, collaborative puzzle. When pitching your idea, be the person who says, "I found the missing piece you need!", not the one dumping pieces from a different puzzle onto the table.

When I pitch an idea, I draw a clear connection between the company's goals and my proposal. I explain how this project will help the company achieve its goals faster and better.

Pitch your ideas as something that will help your leadership solve their problems, and it will be much easier to sway them to your side.

Step 3: Build Your Pitch Using Why, What, How

Define the Why

What problem are you solving? Why is it important? Why should stakeholders care? Try to be as concrete as possible.

Treat stakeholders as investors - explain why they should invest in your idea.

Bring Some Numbers

Stakeholders really like numbers. If you back up your pitch with concrete numbers, you'll have a much easier time convincing them it's a worthy investment.

For example: "This service causes 20% of our production incidents and generates 15 customer complaints monthly. Fixing it eliminates both." - Now you have their attention!

Other examples:

• "Features in this legacy system take 40% longer to build, slowing our delivery speed."
• "Modernising this system will cut the infrastructure costs by 30% and maintenance tickets by 60%."

Now you're clearly describing return on investment, not talking in vague terms.

Be smart and use numbers that match your leadership's goals and priorities. A rapidly growing company fighting for market share won't care much about infrastructure cost. But they'll care about team efficiency and delivery times.

Define the What

What solution do you propose?

Focus on the outcome, not the technology: Instead of "We'll migrate to microservices," say "We'll build a system that can scale individual components, and will allow our teams to deploy their changes independently, improving their delivery times."

Present alternatives: Don't just pitch one solution. "We have three options: patch the existing system (cheap but temporary), rebuild with modern architecture (expensive but future-proof), or a hybrid approach (balanced risk/reward)."

Explain your recommendation: "Based on our timeline and resources, I recommend the rebuild approach because..."

Keep scope flexible: "The core deliverable is X, but we can add Y and Z if we have extra capacity."

Example of good vs bad:

• Bad: "We need to refactor our API to use GraphQL and implement a microservices architecture."
• Good: "We'll rebuild our data layer to support real-time updates and reduce page load times by 60%. This will enable the requested personalisation features on our roadmap and handle 10x traffic growth."

Define the How

It's much easier to get a green light when stakeholders know exactly what they're agreeing to. Prepare at least a rough execution plan. Try to include the following details:

Timeline with key milestones: Break it into phases with specific deliverables. "Phase 1: Data migration (3 weeks), Phase 2: API replacement (4 weeks), Phase 3: Frontend integration (2 weeks)."

Resource requirements: Be specific about who you need and when. "2 senior engineers for 8 weeks, plus 1 week of DevOps support for deployment."

Success metrics: How will you know you've succeeded? "Page load times improve by 50%, deployment frequency increases from weekly to daily, customer support tickets for this area drop by 60%."

Risk mitigation: What could go wrong and how you'll handle it. Do you have a backup plan? "We'll run both systems in parallel for 2 weeks to ensure zero downtime. If needed, we can roll back changes."

Dependencies: What do you need from other teams? "Marketing needs to coordinate the customer communication, and Legal needs to review the new data processing approach."

The plan doesn't have to be very details. Things will change along the way. But it shows you've thought it through and can actually deliver on your promises.

Step 4: Avoid These Common Mistakes

Even with a solid framework, I've seen many engineering leaders make some common mistakes:

Being Greedy. Don't try to fix everything at once. Pick one specific problem that really hurts. It's better to solve one problem than not solve 5 at once.

Too technical. Even when one of the executives asks technical questions, resist the urge to dive deep. Keep answers brief and business-focused.

Blame game. Never frame it as "we should have done this years ago" or blame past decisions. Especially if you were not around when those were made. Focus on moving forward and keep the blameless approach.

Step 5: Handle Objections Like a Pro

No matter how good your pitch, you can face pushback. You might get challenged. Think about possible questions and concerns you may receive. Prepare good answers upfront. Be smart, you don't want to argue with people who are several levels above you. Don't reject their concerns, address them and show them how your project can help.

"We don't have time for this right now"
"Yes, we're all stretched thin. That's exactly why this matters. Right now, every feature in this area takes 3x longer than it should. We're choosing between 2 weeks now or 6 extra weeks spread across the next quarter."

"It's not a priority compared to new features"
"Yes, we need new features. This work makes those features possible. Without fixing this, Feature X will take 8 weeks instead of 3, and Feature Y might not be possible at all."

"Can't we just patch it for now?"
"We've been patching it for the last 2 years, and each patch makes the next one harder. We're at the point where patches are not sufficient anymore and cost more than fixing it properly."

When Things Don't Go as Planned

This framework usually allowed me to successfully get the green light for my projects.

But not always.

Sometimes I failed. And that's ok. It's always frustrating to get rejected after all this work, but don't let the negativity get to you. Stay positive and plan your next steps.

Sometimes you need to rethink your idea. Did you choose a good problem to solve? Is it the problem that stakeholders care about? Did your solution address the problem properly?

Rethink your idea, replan your proposal and try again.

Sometimes, timing is the issue. The company might be in a tough place with no bandwidth for improvements. Wait for better times and build allies who'll support your plan.

Finally, don't be afraid to adjust. You rarely can get everything you want. Be prepared to reduce or adjust the scope of your project, plan with fewer resources than initially requested, and cut the scope to the very core.

If you manage to deliver a critical improvement to the core system, it's still a great success, even if you hoped for more. And after you prove that you can deliver and your work has a positive impact, it will be much easier to get approval for another project.

Good luck! 🤞