I often see engineers having a difficulty communicating the value and necessity of investing resources into system improvements in the form of refactors and redesigns.

With this difficulty comes a lot of frustration, even some distrust for the decision-making of the product. This is bad, multiplied. On one hand, the system isn’t getting any better, because the proposals keep getting rejected. On the other hand, the company isn’t moving forward either, as the distrust and the resentment grow. A lose-lose situation.

However, I have seen quite a lot of purely technical improvements getting the utmost support from the product. As always, I observe the talented people around me and try to absorb as much as I can. These are my thoughts on how the most effective engineers navigate though these challenges.

---

A well-written technical document is valuable, but when pitching to product, it needs to tell a story beyond the changes. And the story must be compelling enough to be well-received and supported.

Highly effective engineers, instead of focusing solely on the technical improvements, would have framed the proposal in terms of business impact—how this change reduces risk, unlocks new opportunities, or aligns with strategic longer-term goals.

Rather than assuming the work should be prioritised, they would have first assessed its place in the bigger picture. How does this stack up against other initiatives? What trade-offs does it introduce? Time spent here is time not spent elsewhere, and high-impact engineers make sure they’re advocating for the most valuable improvements at the right time.

---

The winning strategy

Top engineers know that the most effective way to push a large or risky system improvement is to align it with core business objectives—also known as north star drivers. This is a business-first mindset, and that’s exactly why it works.

Every improvement must create tangible value, and value often comes in the form of money. The key is to clearly articulate how the proposed change contributes to the bottom line. Below are a few universal business drivers that are hard to ignore:

• Reduced costs – Cutting storage, compute, or infrastructure expenses leads to direct savings.
  Example: This change will reduce storage needs by 30%, saving ~$3K/month.

• Improved performance – Better performing systems drive user engagement, satisfaction, and retention.
  Example: This will reduce peak traffic lag by 15%, addressing a top-5 churn factor.

• Reduced manual intervention – Less human effort means lower costs and higher efficiency.
  Example: This will cut customer support requests by 25%, reducing support staff needs by ~10%.

While these are strong general drivers, top engineers tailor them to their company’s specific priorities. The more precise, the more relevant, the more persuasive.

At the end of the day, the bottom line is the priority—because what else would be?

Piggy-backing

They sometimes reach for another strategy - attaching it to a new feature the product team is already invested in. When a new feature is being discussed, it comes with attention, pre-allocated resources, and momentum—valuable assets that can be leveraged to drive meaningful technical upgrades.

During system analysis, engineers identify areas that could be improved to better support the upcoming feature. This creates an opportunity for a local redesign, making the system more robust while seamlessly integrating the new functionality. And the best part is that the investment in system improvements immediately starts paying off, as it enhances the very feature it was tied to. As it should, system improvements should always have tangible results.

Of course, not every new feature requires foundational improvements. The trick is having a good judgment on whether something is well-aligned, or we’re coupling apples and pears. Hard data will be the best source of knowledge in deciding whether the effort is justified or if the feature can stand on its own without deeper changes. Top engineers are clever in driving changes, but they never lie or mislead.

Detached Effort

Finally, the most difficult way to get the green light for system changes is when they are detached from the bottom line. It’s a strategy, nevertheless. Unlike the changes we make to enable other features or the changes we make to directly earn profit, we could propose detached improvements paying off over time.

The difficulty with allocating resources to them is often the fact they are longer-term investments in the system or things difficult to measure. How challenging is it to measure the fact team members are onboarding twice as fast and being more productive due to a key system refactor? Or the fact that a series of good system investments resulted in avoiding scaling issues?

You can make up as many of these as you’d like. And although there are certainly some numbers we could measure, they’d mostly be standing on shaky grounds. If we had good numbers, we’d simply attach them to a North Star Driver and go forward with it. But we don’t. So we make-do with what we got and try our best to gauge the right call.

---

Impactful engineers don’t just write good code—they make good decisions. They focus on the highest-leverage work, communicate with the right language for their audience, and understand that the best way to move fast is to minimise friction. They don’t just push for technical improvements; they push for the right improvements, at the right time, with the right framing.