You can feel it when part of the system is wrong. The whole team feels it. Builds are slow, tests are unstable, and every new feature in that area becomes a grind. But when you try to put time on the roadmap to fix it, the conversation stalls. Your intuition about technical health doesn’t easily translate into a business argument, leaving you stuck making hard Technical Decisions with little support.
This is a classic misalignment.
We know that neglecting the foundation makes everything built on top more expensive and fragile, but that cost is usually invisible to the rest of the organization until something big breaks. Developer velocity slows down, morale drops, and constant firefighting means there’s no time left to innovate. Relying on “best practices” or gut feeling to justify major technical work simply doesn’t work when you’re competing for resources against new features with clear revenue projections.
From Gut Feeling to Quantifiable Impact
To get support, we need to reframe the conversation. Instead of talking only about the technical side, we need to talk about measurable business outcomes. That means directly connecting our proposed technical initiatives to the things stakeholders care about: speed, reliability, cost, and risk.
This isn’t just about reporting numbers from a dashboard. It’s about building a persuasive, data-backed argument. Even before you start, it helps to anticipate the questions you’ll get.
- “How much faster will we ship features?”
“What’s the risk if we do nothing?”
“How will this impact the customer experience?”
Having data-backed answers ready changes the entire dynamic.
How Not to Mislead Yourself with Metrics
Choosing the right metrics is extremely important, and it’s easy to get this wrong. The most common mistake is focusing on vanity metrics or simple outputs instead of outcomes. For example, tracking lines of code or number of commits shows that people are busy, but it doesn’t say whether they’re being effective.
Instead of using isolated metrics to jump to quick conclusions, focus on metrics that actually indicate the health of the system and the process. A drop in deployment frequency may point to issues in CI, tests, or excessive rework, not necessarily poor team performance. Similarly, an increase in MTTR may be tied to old architectural decisions, excessive coupling, or lack of observability, not just the team’s response.
These are the kinds of indicators that reveal real pain points, not just activity. Interpreting data out of context or cherry-picking statistics to support a preconceived idea quickly destroys trust, so it’s important to stay objective and transparent.
How to Justify Technical Decisions with Data
Securing resources for non-feature work requires a more deliberate approach. You need to define the problem, propose a solution, and forecast the impact using numbers that make sense to the business.
Step 1: Define the Problem and Establish a Baseline
You can’t show improvement without a clear reference point. Before proposing any change, turn perception into data: measure the current state of the system and document the bottlenecks.
If “the build is slow” doesn’t become a number, it doesn’t become a priority. Metrics like average build time, variance between pipelines, and impact on the delivery cycle create an objective starting point for the discussion.
For example, discovering that the main pipeline takes an average of 45 minutes, with peaks above an hour, completely changes the conversation: now there is a measurable problem to solve.
Identify the pain in terms of time, cost, or risk.
- Time: How many developer hours are lost per week due to slow local builds or unstable tests?
- Cost: How much do we spend on infrastructure for this inefficient service? How much does one hour of downtime cost during peak traffic?
- Risk: How many production incidents originated in this module last quarter? Are we at risk of violating an SLA?
This baseline becomes the benchmark against which you’ll measure the success of your project.
Step 2: Align the Right Metrics with Your Proposed Technical Decisions
Once you have a baseline, you need to choose the metrics your technical solution will directly influence. The metrics you choose depend entirely on the problem you’re trying to solve.
- For performance improvements: Focus on latency (P95, P99), throughput, and resource utilization (CPU, memory). The goal is to show that you can do more with less.
- For reliability initiatives: Track MTTR, error rate (for example, percentage of 5xx responses), uptime, and incident frequency. The goal is to demonstrate a more stable and resilient system.
- For developer experience initiatives:
when you decide to invest in Developer Experience, track metrics like deployment frequency, lead time, and PR cycle time. These indicators show where friction is happening, whether in code review bottlenecks or pipeline limitations, and help prioritize improvements with real impact. - For cost-efficiency projects: Connect your work to infrastructure spend per feature, operational overhead in person-hours, or cost per transaction.
Select metrics that your stakeholders will understand and value. A product manager will immediately grasp the value of improving deployment frequency, while someone in finance will care about reducing operational costs. Make sure what you choose can be tracked automatically. If you have to spend hours collecting data manually, your measurement system won’t scale.
Step 3: Build a Narrative with the Data
With your baseline and target metrics, you can now build a compelling story. This isn’t about manipulating numbers, but about presenting them in a way that clearly illustrates return on investment.
Start by projecting the expected improvements. For example: “By migrating our CI jobs to faster runners and parallelizing the test suite, we project a 60% reduction in average build time, from 45 minutes to 18 minutes. That would save roughly 25 hours per week for a 10-person team, enabling us to ship one additional feature per month.”
You should also present the trade-offs. Most technical work involves some level of risk or short-term disruption. Be transparent about it. For example: “This database migration will require a 2-hour maintenance window overnight, but it will eliminate a class of deadlocks that caused two P1 incidents last quarter.” Transparency builds credibility.
Step 4: Adapt the Story to Your Audience
One presentation rarely works for everyone. You need to tailor your narrative to who’s in the room.
- For engineering peers: You can go deep into technical details. They’ll care about how the change reduces rework, simplifies the architecture, and makes daily work less frustrating.
- For product managers: Frame the discussion around speed and customer impact. Connect the technical work to faster feature delivery, improved user experience (for example, faster load times), and greater product stability.
- For leadership: Keep it high-level and focused on business impact. Highlight ROI, risk mitigation, and how your proposal aligns with broader company goals, such as increasing efficiency or market responsiveness.
Closing the Loop: Monitoring and Reporting Results
Securing resources is only half the battle. To build long-term trust and make future justifications easier, you need to track and report the results of your work.
Implement the necessary monitoring to track your chosen metrics before the project starts, so you can show a clear before-and-after picture. When the work is complete, regularly report the real impact compared to your initial projections. Did you hit the targets? If not, why? Being accountable for results, good or bad, shows maturity and strengthens your case for future investments.
Finally, remember that quantitative data is powerful, but it’s even better when combined with qualitative insights. A chart showing reduced cycle time is great. A chart showing reduced cycle time alongside a quote from a developer survey saying, “I feel twice as productive since the build system was fixed” is unforgettable. These stories provide the context that gives meaning to the data and reinforces the message.
