The C-Suite Guide to Managing Technical Debt

Image not Found

The topic of technical debt is no longer dubious. However, given that there is no set way to go about it, getting to know where to start with managing it can be quite hectic. As a C-suite executive, you may be having many concerns on the cost of ignoring it.

“Are we not making the tech investments our competitors are?”

“Is our current tech infrastructure optimized for maximum efficiency?”

After looking closely at the varying perspectives that exist around this topic, we thought of consolidating all those insights into a list of refined tips for debt management that you can implement starting today.

Recap: The true nature of technical debt

In our previous blog post, we explored the critical role of technical debt in your company’s strategy. We also discussed whether it was possible to create debt strategically or recklessly as well.

If we choose to look at tech debt like this, we are arriving at a more empathetic, healthy approach to understanding its precursors and also finding better ways to manage it — ways that don’t involve pointing fingers of blame at engineers or product managers. As previously reiterated, we need to make trade-offs that we can live with.

Let’s set a few facts straight before we get into how to tackle tech debt.

  • Tech debt is inevitable. Andrea Goulet compared paying down technical debt to remodelling a house, stating that no matter how well a house is built, parts eventually need to be replaced. This applies to codebases and team processes, as implementations may become outdated or inefficient over time.
  • There is no company advantage as such. Resolving tech debt is a challenging task for companies of all sizes due to financial constraints and operational complexity.
  • It’s not just the debt itself. It’s when the debt turns toxic and hampers day-to-day operations, eventually raising red flags for your stakeholders.
  • This debt cannot be “fixed”. Just because your modernization efforts are being realised does not mean you will have zero tech debt. It is a continuous and iterative process to manage it.

As a leader, your natural instinct may be to seek a tech-related magic fix. However, it is crucial to maintain a strategic approach and consider the big picture. We’ve established that we need to create a bit of debt to keep our tech products alive. But how do we keep things from turning “toxic”?

A framework for managing your technical debt

  1. Managing people, processes, and culture within the team
  2. Making it a strategic priority at C-level decision-making

People, processes and culture.

Shape your developer culture.

Your engineering teams are the lifeblood of your product portfolio. The need to reduce technical debt is likely to receive support from engineers themselves. Those who have been in the field for some time have already seen the impact of toxic debt on the application ecosystem. However, for practical changes in process and workflow to materialise, adjustments must be made on the ground in highly tangible ways.

Industry leaders propose the following strategies to shape the perspectives and approaches to technical debt within engineering teams.

Get the vote of your engineers first. Before you pitch the idea of addressing TD to stakeholders and other departments, you need to make sure that the team of engineers is in alignment with its importance. They need to be hands-on if a new project is created around addressing tech debt items; otherwise, you have a culture problem on your hands. Their support of the outcomes goes a long way once you get sign-off from stakeholders and the rest. Refactoring may not be a delight for everyone, but there are always a couple of “menders” on every team who see it as a welcome challenge.

Make “investment work” and “fixing work” their top priorities. Some devs are more inclined towards feature work and others towards refactoring or mending work. Identify these “makers” and “menders”. Assembling a team with individuals who like doing both contributes to a more effective process of tech debt management. Your product managers can plan for technical debt and technical investments with the same vigour and attention to detail that goes into developing a product strategy or roadmap, knowing that certain people on a team like cleanup. Additionally, by coordinating strategic and technical investments on a monthly, quarterly, or semi-annual basis, you can connect such investments to the company’s more high-level initiatives.

Address tech debt as a daily mantra. Taking it a step further, this method becomes the status quo when technical debt management is implemented on a daily (or at the very least, weekly or sprint) basis.

“The notion that 100 percent of my engineering team’s time or every engineer’s time is going to go to feature development is where your problems start. None of us is perfect the first time we write something. We all know as soon as we put something out there, there’s going to be a problem and we’re going to have to go fix that problem. You need to allocate out a budget in a way that says some percentage of this is always dedicated to maintenance, clean up and bug fixing.” - Rob Zuber, CTO of CircleCI

  • Reframe the term technical debt. There has been a lot of talk around semantics and how it can dramatically impact team attitudes. One of the ideas is that we reframe tech debt as a part of your modernization efforts. As you may well know already, companies and products never win by having little to no tech debt. The opportunity cost of rework in exchange for efficiency implies that a certain amount of debt is needed to keep our products alive and running. Therefore, it may boost team morale to reframe it as modernization, or intiative in favour of “continuous product health,” as CTO Yvette Pasqua prefers. You might like to think of this as self-care for the dev team, since we are referring to what they do day in day out. The folks over at Reforge have a similar perspective, only they view technical debt as a “strategic lever” for business success over time.

Establish quality standards.

5 stars

Quality-oriented coding practices: Encourage a culture of quality through the enforcement of coding practices that prioritise clarity and maintainability. Embrace coding standards and best practices, coupled with regular code reviews, to catch potential issues at an early stage.

Automated QA: Elevate code quality with automated tools designed to conduct rigorous checks. These tools not only identify potential issues but also enforce coding standards consistently. This way, you establish a proactive approach to maintaining a high standard of code throughout the project lifecycle.

Architectural excellence: Cultivate a commitment to quality by designing systems with scalability and maintainability in focus. Prioritise good architectural practices to reduce the risk of accumulating technical debt. A well-thought-out architecture serves as a foundation for long-term success, fostering a culture where each team member contributes to building robust and scalable solutions.

Stability of infrastructure environment and sustainable practices: Uphold the stability and sustainability of the core infrastructure environment by implementing and adhering to best practices. Regularly monitor system health and performance to prevent the accumulation of technical debt.

Employ Effective Code Promotion

Code Promotion: This strategy is about maintaining a branch per environment and triggering deployments when a check-in is triggered against the branch.

Good code promotion practices, including code reviews, automated testing, documentation, and collaboration, contribute to maintaining code quality and addressing issues early in the development lifecycle. This, in turn, helps prevent the accumulation of technical debt and promotes a healthier and more sustainable software development process.

Each phase in the workflow contributes to maintaining code quality and can help reduce technical debt in various ways.

If you are a startup founder, you’ll have more insight into how your product managers may be doing. They may be really struggling to address tech debt and may be becoming overwhelmed. Advise them to:

  • Treat tech debt like financial debt. Advise them to pay it down bit by bit and integrate technical investments into their sprints instead of going hammer and tong once a year.
  • Sharpen the focus. Which debt should you tackle first, given your company’s roadmap and strategy? Those are the key areas. Is it architectural debt? Is it knowledge debt? Is it infrastructure or UX debt?
  • Evaluate the lifespan of products. The product life cycle itself is the primary factor to be taken into account while addressing technical debt. Performing a risk analysis is helpful for establishing and managing technical debt.

Technical debt as a strategic priority.

Conduct a technical debt audit.

This includes questions like “what is the extent of the debt?”, “who is accountable?”, “have we engaged decision makers?”, “what is creating tech debt?” and “what is the payment plan exactly?”

Comprehensive assessment: The first step in managing technical debt is to conduct a thorough assessment. This involves understanding the scope of the debt within your organisation. Identify areas that require immediate attention and categorise them based on their impact, cost, and time required to go back in and fix things. What are the organisational structures or processes hampering the company’s ability to address them? By performing this assessment, you gain a clearer picture of the debt landscape and can make informed decisions.

Get the stakeholder vote.

It makes sense why there are times when members of the larger organisation object to the thought of dedicating funds to pay off technical debt. They believe that releasing new features to users is a trade-off for paying off technical debt. When it comes to product health efforts, they often feel hesitant to support them if there isn’t an immediate tangible advantage. The secret is to shift the focus from the debt itself to topics that are important to these stakeholders.

Here are a few strategies to shift the focus from ongoing product health or success lever, however you choose to refer to TD.

Clearly communicate any trade-offs.

There are trade-offs with any product. The well-known “good, fast, or cheap” Venn diagram is a great illustration of this fact. Any one or two of those factors may be used to complete a project. However, using all three at once is not feasible.

An engineering leader must decide which debt is acceptable and when it may be paid off.

For instance, a team may choose to release the capability now and then devote more work to improving or stabilising it at a later date. Alternatively, they might take the extra time to stabilise it now and provide the feature to the market thereafter. There is a trade-off, and it is the duty of engineering — and in their best interest — to specify those trade-offs.

Calculate the opportunity cost of tech debt payment.

Typically, engineering executives are aware of the cost of technical debt in the codebase — the team’s inability to consistently produce products at full speed. However, many executives may see this as a waste of money when they learn that engineers must take on a significant restructuring project that will take months. Instead, they should be informed about the benefits that resolving technical debt would bring to the company.

Stories of technological debt are all too frequently anecdotal. The effectiveness of discussions with various stakeholders increases significantly when these issues can be measured using metrics and converted into monetary losses.

Recasting technical debt as an investment in future returns is possible by using models like the Technical Debt Ratio. It will be easier to make the case for strategically tackling technological debt if that type of data is available.

Highlight its importance to the whole company.

Few organisations have teams or people whose goal is to reduce technical debt, which is one of the reasons it accumulates in the first place. Building products, improving the customer experience, and increasing revenue are common goals. However, full ownership of technical debt is often put on the back burner.

Therefore, the next stage is to get support for engineering team TD pain point across the whole organisation from upper-level stakeholders who have given engineering leaders buy-in to address technical debt. Engineering teams may find it more difficult to commit time and resources to effective debt reduction without your high-level assistance, leaders.

Planning significant technical debt efforts concurrently with a company’s product strategy and roadmap is one approach to getting this kind of buy-in. Whether that’s done on a monthly, quarterly, or half-yearly basis, coordinating such activities together improves process efficiency for the organisation and raises awareness of the initiatives.

Conclusion

IT executives who effectively handle technical debt are in a considerably better position to improve organisational performance. Infrastructure and operations executives may achieve at least 50% quicker service delivery times to the company by aggressively managing and reducing technical debt, according to research and consultancy firm Gartner. By conscientiously addressing technical debt as a strategic initiative rather than a reactive measure, businesses can fortify their competitiveness and adaptability.

For further insights into our commitment to principles such as TD management, explore our official Engineering Manifesto and Engineering Playbook.

You May Also Like