Tech Debt

Our technical debt doesn't slow down our work much.

What exactly is technical debt and why should engineering leaders care about it?

Technical debt refers to the "cost" of choosing expedient but suboptimal code solutions that will require rework later. Like financial debt, it accumulates interest over time in the form of increased maintenance costs, slower development, and reduced agility.

Engineering leaders should care about technical debt because:

1. It directly impacts developer productivity and morale
2. It can significantly slow delivery timelines
3. It increases operational costs and risks
4. It affects the ability to innovate and respond to market changes

Left unmanaged, technical debt becomes a hidden cost that gradually erodes team efficiency and satisfaction. Research shows that teams consistently dealing with significant technical debt report lower motivation and higher frustration levels.

How does technical debt impact developer experience and productivity?

Technical debt creates several negative effects on developer experience:

1. Increased cognitive load - Developers must keep workarounds and system quirks in mind
2. Frequent context switching - More time spent debugging unexpected issues
3. Reduced flow state opportunities - Interruptions from production issues related to tech debt
4. Diminished sense of craftsmanship - Forced to work with or add to suboptimal code
5. Increased onboarding friction - New team members struggle to understand complex or poorly documented systems

"This impacts coding quality because people don't remember the code they wrote previously, so they effectively write more code of lower quality, which translates into technical debt and affects both code quality and delivery time."

SVP People & Culture at Software Development Company

In productivity terms, technical debt:

• Extends development cycles as workarounds proliferate
• Increases bug rates and associated rework
• Makes testing more complex and time-consuming
• Reduces confidence in deployments
• Creates unpredictable timelines for seemingly simple changes

What are the most reliable ways to measure technical debt in an organization?

Measuring technical debt effectively requires a combination of approaches, with developer perception being the most reliable indicator:

Developer Experience surveys

Research from Google, referenced by multiple interviewees, found that developer perception is the most accurate measure of technical debt's impact:

"Google conducted extensive research on technical debt, correlating around 100 metrics with survey responses to a simple question: 'Our level of technical debt doesn't slow down our work much.' They found that no single data metric could predict the survey outcomes. Even more surprising, their model using all 100 metrics explained less than 1% of variance in survey responses. They ultimately concluded that the survey question about technical debt is their best leading indicator."

Technical Product Lead at Biopharmaceutical Company

Network Perspective DevEx Surveys provide a structured way to gather this feedback offering:

• Benchmarks against industry standards
• Team-level comparisons within your organization
• Qualitative comments to identify specific pain points
• Trend analysis over time

System log metrics

While developer perception is primary, these additional metrics can provide supporting data:

• Change failure rate - How often changes lead to failures
• Mean time to recover - How long it takes to restore service
• Bug remediation time - How long bugs remain unresolved
• Code churn - How often the same code is modified
• Module coupling - Dependencies between system components

Codebase analysis tools

Code quality platforms like SonarQube can help identify: - Test coverage gaps - Code complexity hotspots - Duplication - Potential security vulnerabilities

However, these tools should be used to support rather than replace developer feedback:

"For example, with technical debt, you can't really tell from passive metrics when there's too much or too little, because it's a matter of people's experiences. Does it slow me down? Is there too much code that isn't being updated?"

HR Director at Digital Media Group

How can engineering leaders effectively prioritize and manage technical debt reduction?

Effective technical debt management requires a strategic approach rather than ad-hoc fixes:

Make tech debt visible

You can't manage what you can't see. Create visibility through:

• Regular DevEx surveys to gauge impact
• Tech debt registers or backlogs
• Impact assessments for each debt item

Allocate dedicated time

Successful organizations build tech debt reduction into their regular workflow:

"What I do is allocate 20% of my team's capacity for addressing technical debt."

Director of Engineering at Software Development Company

Options include: - Dedicated sprints or iterations - Fixed percentage of each sprint (e.g., 20%) - Rotation of team members on debt reduction - Hackathons focused on specific debt areas

Prioritize strategically

Not all technical debt is equal. Consider:

• Pain frequency - How often does this debt cause problems?
• Impact severity - How bad are the consequences?
• Fix cost - How complex is the remediation?
• Risk - What could go wrong during remediation?
• Strategic alignment - Does fixing this debt support business goals?

Prevent new debt accumulation

While addressing existing debt, establish practices to prevent new debt:

• Robust code review processes
• Definition of Done that includes quality criteria
• Automated quality gates
• Regular architecture reviews
• Training on clean code practices

Communicate impact and progress

Make tech debt reduction visible to stakeholders:

• Quantify the cost of debt in terms business understands
• Demonstrate productivity gains after debt reduction
• Share before/after metrics on developer satisfaction
• Celebrate wins to reinforce the value

"Technical debt is always that embarrassing secret of technology teams that nobody at the top wants to hear about. It's always a hidden cost that's best kept swept under the rug if possible."

Head of Technology at Mobile Games Developer and Publisher

What are the common patterns of technical debt that most organizations face?

Recognizing common debt patterns helps teams identify and address them more effectively:

Legacy system burden

Many organizations struggle with maintaining legacy systems while developing new ones:

"Part of our challenge is the classic case of maintaining a legacy system in production while trying to replace it with a new one. The more work we have to do on the legacy system, the less time we have to build the new system. We can't deploy the new system while simultaneously making significant progress on it."

Engineering Manager at Digital Client Engagement Platform

Inadequate test coverage

Insufficient testing forces teams to rely on manual verification and reduces refactoring confidence.

Monolithic architecture constraints

Overly coupled systems make changes risky and time-consuming:

"Even when you have good measurements, you still often encounter legacy systems and components that are difficult to change. This forces you to develop custom approaches to deal with issues like a massive codebase that's become the organization's biggest monolith."

Engineering Manager at Software Development Company

Documentation gaps

Poor or missing documentation increases onboarding time and knowledge silos.

"We're significantly lacking in the creation of durable documentation - internal guides, troubleshooting resources, and reference materials. Developers need a central place where they can search and quickly find answers about how to use frameworks, how to get started with new tools, and who to contact when they encounter issues. Without this, knowledge remains trapped in silos."

Engineering Manager at Software Development Company

Dependency hell

Outdated or conflicting dependencies create security vulnerabilities and compatibility issues.

Process debt

Inefficient processes can contribute to technical debt:

"The second challenge is that people are reluctant to get involved with refining, defining, and making processes more efficient. It's messy work that many avoid. I use this analogy because while it's easy to introduce new tools and processes, it's much harder to make your entire value chain efficient."

DevSecOps Centre of Excellence at Banking Group

How does technical debt affect onboarding and team culture?

Technical debt has significant impacts beyond just code quality, affecting how teams work together and grow:

Onboarding challenges

• Extended ramp-up time - New developers take longer to become productive
• Tribal knowledge dependency - Reliance on undocumented workarounds known only to veterans
• Confusing mental models - Systems that don't follow logical patterns are harder to learn
• Confidence issues - New team members may hesitate to make changes

Cultural impact

• Learned helplessness - Teams accept debt as inevitable and stop pushing for improvements
• Blame culture - Finger-pointing when debt-related issues arise
• Reduced pride of ownership - Developers disconnect emotionally from codebase impacting sense of ownership
• Higher turnover - Experienced developers leave rather than maintain problematic code

Positive cultural opportunities

Proactively managing tech debt can create positive cultural shifts:

• Empowerment - Teams feel agency when given time to address debt
• Craftsmanship - Reduced debt allows focus on quality
• Knowledge sharing - Debt reduction activities spread understanding across the team
• Alignment - Clear strategies for managing debt build team cohesion

"One of the realizations that took me time to internalize as an engineering manager is that I truly run and own this team. I have the authority to make a difference. I can decide that we're going to spend 20% of our time improving our developer experience - that's a decision within my power to make."

Software Development Manager

What's the relationship between technical debt and delivery speed?

The relationship between tech debt and delivery speed is complex and often counterintuitive:

Short-term speed vs. long-term drag

• In the short term, taking on technical debt can accelerate delivery
• Over time, accumulated debt creates a drag effect that significantly slows teams down

"We identified several pain points and managed to reduce their impact by 40-50% in some dimensions. In the engineering area specifically, our analysis revealed problems with test environments, weak engineering practices, and inconsistent contracts across environments."

Development Director at Banking Group

The speed paradox

• Teams under pressure to deliver quickly often accumulate more debt
• This debt slows them down further, creating pressure to take even more shortcuts
• Breaking this cycle requires intentional intervention

Recovery patterns

Organizations that successfully recover delivery speed typically:

1. Create breathing room - Temporarily reduce feature commitments
2. Focus on fundamentals - Address core infrastructure issues first
3. Build momentum - Start with small wins that visibly improve velocity
4. Measure and communicate - Track improvements to justify continued investment

"One of our conclusions was that there was a lack of understanding. I'm responsible for that, so we clearly defined responsibilities, improved the repository structure to make it properly packageable. We're still in the process of migrating things over."

VP of Engineering at Software Development Company

How much time should teams allocate to technical debt reduction?

Allocating the right amount of time to technical debt reduction requires balancing competing priorities:

Industry patterns

Successful organizations typically allocate between 10-30% of development capacity to technical debt reduction:

"One of my biggest fears is that when something breaks, the cost of fixing it becomes exponential. As a technical leader, it's our duty to set the right expectations. That's why I allocate 20% of my team's capacity for addressing technical debt."

Director of Engineering at Software Development Company

This allocation can take several forms: - Dedicated time - Specific days or sprints focused on debt reduction - Percentage approach - Fixed portion of each sprint - Opportunistic fixes - Addressing debt when working in related areas - Rotating focus - Different team members focused on debt each iteration

Situational factors

The optimal allocation depends on:

• Debt severity - Higher allocation needed for severely impacted teams
• Business context - Critical market windows may temporarily reduce allocation
• Team maturity - More experienced teams can often tackle debt alongside features
• System stability - Unstable systems may require higher allocation

Avoiding All-or-Nothing approaches

Neither extreme is effective: - Zero allocation leads to crippling accumulation of debt - Too much allocation can starve feature development

The key is consistency rather than sporadic large efforts.

What role does the development process play in managing technical debt?

Development processes significantly influence how technical debt accumulates and gets addressed:

Process contributions to debt

Ineffective processes can increase technical debt through:

• Excessive context switching - Reduces deep work time needed for quality solutions
• Unrealistic deadlines - Force shortcuts and workarounds
• Poor requirements - Lead to rework and band-aid solutions
• Siloed teams - Create integration debt between components

Process improvements

Effective processes help manage debt through:

• Regular refactoring - Built into development workflow
• Code reviews - Prevent debt introduction
• Definition of Done - Includes quality criteria
• Technical spikes - Explore options before committing to solutions
• Continuous integration - Catches issues early

Team autonomy

Giving teams ownership of their processes improves debt management:

"For our teams at least, each one owns their own process and manages their planning as they see fit based on what's realistic for them. They generate simple reports on their progress, and while the system isn't extremely mature, it works for us."

Engineering Manager at Global Operator of Digital Exchanges and Data Services

How can engineering leaders communicate the business impact of technical debt to non-technical stakeholders?

Communicating effectively about technical debt is crucial for securing the time and resources to address it:

Translating technical concepts

Avoid jargon and focus on business impacts:

• Opportunity cost - "This debt means we can only deliver X features instead of Y"
• Risk exposure - "This increases our vulnerability to outages costing $Z per hour"
• Competitive disadvantage - "Our competitors can release twice as often because they've addressed similar issues"
• Team velocity - "After addressing this debt, we expect to increase delivery speed by 30%"

Quantifying impact

Use metrics that resonate with business leaders:

• Time spent on maintenance vs. new features
• Customer-impacting incidents and their costs
• Developer turnover related to technical frustrations
• Delivery predictability improvements after debt reduction

"Our quality is significantly low. We experience an average of 60 micro incidents per week. Approximately 40 of these incidents impact revenue, and 70% of those revenue-impacting incidents are directly attributable to poor code quality."

Head at Online Casino Games and iGaming Platform]

Building allies

Develop relationships with business stakeholders who can advocate for technical investments:

• Product managers who understand how debt affects their roadmaps
• Operations leaders who see support costs from technical issues
• Finance teams who can quantify long-term costs vs. short-term gains

Visual storytelling

Use visuals to make abstract concepts concrete:

• Trend lines showing incident rates or development velocity
• Comparative dashboards between teams with different debt levels
• Before/after demonstrations of developer experience improvements

Conclusion

Technical debt is a universal challenge that significantly impacts developer experience and productivity. The most important insights for engineering leaders are:

• Developer perception is the most reliable measure of whether technical debt is problematic, more so than any automated metrics.

• Regular surveying through tools like Network Perspective DevEx Surveys provides the clearest picture of how technical debt is affecting your teams.

• Consistent investment in debt reduction (typically 10-30% of capacity) yields better results than sporadic large efforts.

• Technical debt affects more than just code - it impacts team culture, onboarding, delivery predictability, and overall developer satisfaction.

• Effective communication about debt's business impact is essential for securing time and resources to address it.

By approaching technical debt management strategically and consistently measuring its impact through developer feedback, organizations can maintain higher productivity, better developer experience, and more sustainable delivery patterns.