Stop Trying To Protect Your Tech Debt Time

If you've worked in technology long enough, you've heard some version of the idea that software development teams need to "protect" or "reserve" some percentage of their capacity for technical debt and infrastructure work. For those leaders who are responsible for their organization’s technical strategy, it's a common and widely adopted approach: teams negotiate to "hold back" a fixed amount of their time for technical investments while dedicating the rest to business priorities. In fact, some people reading this believe it to be an incontrovertible truth.

And while this may feel like a reasonable compromise on the surface, I have come to believe it's fundamentally flawed and creates more problems over time than it solves. I've seen firsthand how this capacity-splitting approach can undermine the very collaborations needed to build sustainable products.

The 70/30 Split

The 70/30 split (or whatever ratio gets negotiated) perpetuates this harmful idea that business priorities and technical priorities exist in separate worlds. This artificial division creates several significant issues:

1. It fosters an adversarial "us versus them" dynamic

When software development teams have to "defend" their technical investment time against product or business demands, it positions technology and business as opposing forces rather than partners. Engineers start seeing product managers and business stakeholders as people who "steal" their technical investment time, while business stakeholders view engineers as resistant to delivering customer value.

2. It incentivizes lazy thinking

Separate allocation buckets means we don't have to do the hard work of truly integrating our technical and business strategies. We avoid the difficult conversations about how specific technical investments directly enable business outcomes or how business priorities might need to adapt to technical realities. Or, conversely, acknowledge how certain technical investments we want to prioritize may simply not move the needle enough relative to other priorities.

3. It masks technical consequences of business decisions

When technical investment is separated, business leaders don't fully understand the downstream implications of their decisions because the conversations aren't forced to happen. Short-term solutions rushed to production to meet an urgent deadline might seem like a win today, but without clear visibility into its technical consequences, the larger team lacks the context to make informed decisions about when and how to pay down the resulting debt.

What Strategic Technology Leadership Looks Like

The alternative, of course, is not abandoning technical investment. It's creating a technology strategy and execution model that unifies business objectives and technical investment — which takes creativity, strategic thinking, influence, and ownership of the business outcomes.

To accomplish this, it takes several intentional shifts in thinking and decision-making:

1. Make technical debt visible and intentional

All debt ultimately comes down to borrowing from the future to pay yourself today. Consider that every technology solution has multiple dimensions: knowns, unknowns, assumptions, shelf-life, total cost of ownership, and others. Therefore, technical shortcuts aren’t inherently bad; they’re just intentionally shifting this equation in favor of speed at the expense of longevity, cost, or other variables.

And when these decisions are intentionally made, it takes similar intentionality and foresight to know how and when to pay that debt down. 

To know how and when to incorporate this into the roadmap:

• Document what you're borrowing against
• Set exit criteria, not just timelines: "We'll refactor when [future event happens]" and have that business justification conversation with your stakeholders
• Frame investments as capabilities, not just technical improvements
• Quantify the costs of debt to help with prioritization
• Schedule regular "debt portfolio reviews" (more on this below)

Technical debt exists for a reason and the company is reliant on it. Strategic leadership is about ensuring the organization makes intentional tradeoffs with clear visibility into costs and benefits across different time horizons.

2. Translate technical needs into business language

Technology powers the business, and therefore technology strategy is business strategy. Technology leaders have the responsibility to make the "under the hood" work not only understandable and meaningful — but also to choose the work that actually has the biggest impact.

For example, one could argue the need to "refactor the authentication service" because of its complexity, security issues, and maintenance cost. However, a more compelling justification would be the drop in customer support tickets and the increased development velocity in that area of the product ahead of what's coming next in the roadmap.

Companies with mature technology practices understand that technical excellence isn’t an engineering indulgence — it’s a business multiplier that enables speed, quality, and innovation.

3. Build a single, integrated roadmap

What this all ultimately comes down to is that there are not separate technical and product/business roadmaps; there is one roadmap that includes all of the investments necessary to deliver sustainable business value.

This means technical investments are prioritized alongside or baked into the business initiatives using the same framework, whether that's ROI, strategic alignment, or customer impact. Some technical investments might even outrank certain feature work because their business impact or strategic value is higher.

Implementing a Unified Technical Strategy

So how do you evolve from "capacity splitting" to truly integrating a technology and business strategy?

1. Establish a "North Star" architecture

Be opinionated about what you want your ideal state to look like and maintain a reference "North Star" architecture that details it. This serves as your measuring stick between where you are and where you want to be and becomes the foundation for evaluating technical decisions and investments.

From there, examine your system for:

• Divergence: how far it is off from your north star
• Friction: how much it's slowing you down
• Business gaps: what it's preventing you from delivering

This technical strategy should have clear connections to short, medium, and long-term business objectives. This allows the team to proactively propose the right technical investments at the right time, rather than reactively asking for capacity to address accumulated debt.

2. Create a technical debt portfolio approach

It is important to regularly revisit the state of the liabilities you are carrying in your tech stack as business priorities may shift the urgency to invest in certain areas over others. Fortunately, a simple 2x2 matrix can help to prioritize this.

For the entire inventory of technical debt/liabilities, consider Impact and Effort:

• Impact: This takes into account the impact on the technology team (such as the ability to maintain the code and systems) and the impact on the business (such as the reduced speed to market or customer impact due to downtime)
• Effort: This takes into account everything needed to remediate the issues from the fix itself to the downstream impacts such as testing, validation, and other coordination that might be necessary.

This visualization creates a natural alignment between technical investments and business needs and provides a framework to identify which initiatives will be most strategically advantageous to pursue.

3. Embed technical investments within business initiatives

Look for opportunities to incorporate technical improvements directly into business-driven work by continually referencing the “debt portfolio.”

For example, if a high-priority business initiative is going to touch a particularly problematic area of the codebase, use that as an opportunity to address underlying technical debt simultaneously. Rather than saying "we need two separate weeks to refactor this area," expand the scope of the business initiative to include the necessary improvements.

This approach:

• Aligns technical investment with business value as a matter of practice
• Creates natural opportunities to improve areas that are actively being developed
• Builds a pattern of continuous improvement rather than periodic "technical debt sprints"
• Allows engineers to work in a more sustainable way by addressing issues as they encounter them

Of course sometimes the business timeline won't accommodate the full technical investment needed. In these cases, you can still make incremental improvements while documenting what remains to be addressed in future iterations. The key is thinking of technical investments as integrated elements of business initiatives rather than competing priorities.

4. Build cross-functional empathy and shared understanding

Perhaps the most overlooked aspect of unifying technical and business priorities is the human element. Technical and business teams often speak different languages, operate with different time horizons, and are incentivized by different metrics.

Breaking down these barriers requires intentional relationship building:

• Create regular cross-functional learning sessions where technical and business teams teach each other about their domains. For example, have engineers explain architecture decisions while product managers share customer insights and business constraints.
• Involve technical leads in customer research and business strategy discussions from the beginning, not just when implementation is being planned.
• Include business stakeholders in technical design reviews to give them visibility into the considerations and tradeoffs being made.
• Use shared metrics that matter to both technical and business teams, like user-facing performance, reliability, or time-to-market for new capabilities.

The goal isn't just knowledge transfer but building genuine relationships that foster trust. When business leaders understand the technical implications of their decisions and engineering leaders understand business constraints, the artificial boundaries between "business work" and "technical work" begin to dissolve naturally.

5. Integrate prioritization processes

Ensure both business and technical stakeholders can articulate how their priorities create value. Non-technical teams should understand concepts like "reduced time to recovery" or "decreased deployment risk," while technical teams should understand key business drivers like "customer acquisition cost" or "lifetime value."

This allows for a single prioritization framework for all work, whether it's a customer-facing feature or an infrastructure improvement. This forces the organization to make explicit tradeoffs based on impact rather than protecting artificial capacity allocations.

Addressing Common Concerns

As I mentioned at the beginning, many technology leaders hold the "protected allocation" methodology to be the only viable model. And with understandable objections that I'd like to address:

"Without protected time, technical work never happens"

This concern is valid, but the solution isn't to wall off capacity, it's to better articulate the business value of technical investments. When technical investments are proposed with a clear understanding of their business impact, many will win prioritization on their own merits. For those that don't, this transparency helps the organization understand the real costs of deferring the work.

Additionally, by embedding technical improvements within business initiatives as I described earlier, you create ongoing opportunities to address technical debt without having to fight for separate capacity.

"Business stakeholders don't understand technical needs"

This is a symptom of insufficient communication and empathy, not a fixed reality that requires separate capacity allocation. Technical leaders need to translate complexity into business consequences. This is probably the hardest part of the job, but building relationships and trust across organizational boundaries makes these conversations easier over time.

"If we don't upgrade the database, we'll face increased operational costs of $X per month, growing risks of outages that cost us $Y per hour, and the inability to implement the personalization features planned for Q3."

"The 70/30 model is simple and easy to understand and implement"

While capacity splitting might seem straightforward, it actually introduces several forms of hidden complexity. It creates duplicate planning processes, artificial boundaries between "business work" and "technical work," and discourages opportunistic improvements that engineers could make while working on business features.

The model also fails to adapt when business needs change rapidly, creating either too much or too little capacity for technical work at different times. Engineers experience productivity loss from constantly switching contexts, and valuable learning opportunities are missed when technical and business conversations remain separate.

Resetting the Model

Moving away from this "reserved allocation" model doesn't happen overnight. It requires building trust between software development teams and the business stakeholders, developing shared understanding, and creating new processes for prioritization and planning. But the payoff is substantial: faster delivery, more sustainable systems, better alignment, and ultimately, greater business impact.

The moment you stop thinking about technical investment as something separate from business investment is the moment you start making much better decisions about both.