Introduction
Over my years in software engineering, I’ve seen countless developers get frustrated trying to push technical improvements onto the roadmap. You hit tech debt or inefficient workarounds every single day, you raise the issue in retro, and… yeah, nothing happens. Or worse, you get that classic response: "We'll put it in the backlog."
It doesn't just feel frustrating; it feels like your experience isn't being taken seriously. Which sucks.
I used to hit this exact wall early in my career. It took me a while to realize what was actually happening: I was describing the technical mechanics of the issue, while management was making decisions based on risk, outcome and delivery timelines.
They weren't ignoring the issue out of malice; they simply couldn't assess its priority because I hadn't translated code health into outcomes. Which is totally fine, because their only job is to deliver the best possible outcomes for the end user while managing the budget efficiently.
Their job isn't to open the codebase and audit technical health - that’s our domain. When you approach a manager saying "The code architecture is getting really messy; we really need to refactor it," their brain translates that directly to: "Low-priority dev refactor complaint with zero measurable delivery value."
It feels insulting, but it isn't malicious.
Try to see it like a protocol mismatch instead 🙂. If you pass the wrong data type to an API, the request fails. Management has a clearly defined interface. So if you change your input format, you change the output 🙂.
Pitch Outcomes, Not Code
Don't pitch technical refactoring - pitch what the refactoring unlocks.
If you translate a technical issue into its operational impact, the time saved, and the risk removed, decision-makers don't care how you solve it technically. And the most beautiful side-effect: You get complete freedom over the implementation details because you owned the outcome.
Your easy 4 step framework for pitching ideas
There's a simple 4-step framework I rely on that makes the difference between a good idea and one that actually gets approved:
Problem - Impact - Approach - Outcome
Problem: Start with the problem, not your idea. State the operational blocker directly without deep technical jargon.
(e.g., "Our deployment pipeline is failing 30% of builds, stalling feature releases.")
Make them care before you make a request.Impact: Define the stakes if ignored versus the value if fixed.
(e.g., "We are losing roughly 12 engineering hours a week re-running failed jobs.")
Now they know the stakes. It’s all about consequences, not features.Approach: Outline your high-level strategy concisely.
(e.g., "Isolate the flaky integration tests and run them in parallel containers.")Outcome: Finish with a concrete result and timeline.
(e.g., "This cuts build times in half and recovers ~10 hours of dev time per week, taking 3 days to implement.")
You close with certainty and a timeline. That's how executives think.
Takeaway
When you present technical issues using this structure, you switch from asking for permission to proposing a clear trade-off.
It keeps managers out of your implementation details (less micromanaging), they won’t care how you do your job. Instead it gives you full ownership over how you write and structure your code.
