Approaching Tech Debt

We talked about Debt, now lets discuss one of the approaches to address tech debt.

Before you take on the tech debt management for your company/BU/product/team

• Ensure there is alignment with your leadership on the outcomes and impact.
• Ensure there is support for tackling debt as it can be expensive in the short run ( 2–8 quarters)

Key assumptions ( illustration)

. There are documented goals, that have metrics like revenue, margins, ARR, NRR, GRR, CSAT, SUS scores and other. They are not meeting the expectations, and we have identified that it is a tech issue (not product, not GTM, not a demand side problem).

· Tech debt is leading to the unfulfillment of the goals. Removing tech debt will help us beat and raise our objectives.

· If done well, we expect a 30–50% lift in engineering productivity (need to pick a metric).

· This will be a 6–8 quarter effort and then with judicious planning and resource allocation we will keep KTLO (keep the lights on) efforts under 25%.

What would good look/feel like ( illustration)

• Tech debt management is a core part of developer experience and other parts include tooling, platforms, feedback, roles and rubric, rituals and governance and escalations.
• If we manage tech debt we can expect an improvement in our operational metrics like incidents, time to recover/restore, quality, user satisfaction, improved product performance.
• If we manage tech debt, we can expect better ROI from R&D. We will start to see more innovation, more feature launches, easier to integrate acquisitions.
• If we manage tech debt well, we can expect better team dynamics leading to well architected systems (Conway’s law)
• Better tech debt management leads to better hiring practices as we would have addressed people and process debt thereby clearly identifying the new areas of investment based on companywide priorities.

Holistic Approach to Engineering

Any business function has four constituents, what we do (input), what we produce (output), how it behaves (outcomes), how it helps us win (impact). To make a function effective, one needs to look all four aspects to uncover the constraints and remediate the root cause.

In order to make any project successfull, one needs to look at all four aspects. For software tech debt management, following are the areas that you may want to consider —

• Input — planning, coding, architecture
• Output — service, library, function
• Outcome –operational excellence
• Impact — adoption, ARR, NPS

Operationalize Tech Debt management

• Use the 12 types of debts ontology (mentioned below) and can modify it based on our needs).
• Establish key metrics for each type and where do we expect the teams to be.
• Evangelize those metrics with the teams.
• Nominate a staff/EM/PE to own them for their respective services
• Let the teams publish where are they are on the tech debt journey and what is their plan to address the tech debt to get to a good state.
• Cross their plans with the company level priorities and see if we need to provide additional funding/support to certain teams to accelerate them.
• Build automation to capture as many metrics as possible and report them on a regular cadence.
• Have the nominated leader’s setup weekly rituals to go over the rituals.
• Setup monthly rituals ( MBR) with the CTO and staff to ensure we are making progress.
• CTO reports these to the CEO and his staff on monthly basis to highlight the progress and the impact on outcomes.
• This becomes part of the quarterly ritual where we assess the progress and assess the efficacy of the CTO and his staff.

Do I have the right people to address the issues?

Business is a team sport. If you want to be successful one needs to focus on building the best teams and give them the tools and framework to help them, be successful and then hold them accountable. This leads to a high trust organization that is always pushing the bar because the teams own the mission. One needs to identify a programmatic way to discover, attribute, remedy and then remediate tech debt. We also need to ensure it is structured and objective to remove any bias or blind spots.

Following graph guides on weather we need to focus on talent or process more.

E.g. If there is a lot of reckless and inadvertent debt then you may have to assess the teams.

Approaching tech debt.

Marin fowler1, Alves Et al.2 have published great work on how to approach tech debt, so one is able to classify, designate priority and quantify the impact and then build a plan to be deliberate and prudent about the tech investments. The main reason we want be aligned and committed to the right plan is because if addressed in out of order they could backfire and make the problem worse. A great example of this was the microservices adoption, some tech companies embraced microservices without fixing the core (clear domains, decoupled databases, missing aspects, testing framework, dependency management to name a few) that led to slower innovation, higher latency, worse reliability and very high cost to operate (infra, tooling spend, people).

1 Martin Fowler — tech debt

2 Alve Et. Al — Ontology of tech debt

Let’s go over the ontology of tech debt and touch on the symptoms (how can we identify if we have those issues) and key metrics (how will we quantity). This will help us stay away from gravitating towards inactionable feedback like “our tech debt levels are more moderate than initially assumed” to “we need to make architectural changes to reduce the dependency which is estimated to take 6 months that will lead to a 20% lift in our productivity”