Managing Technical Debt Plays Benefits Against Risks
November 09, 2021

Charles Caldwell
Logi Analytics

Share this

Everyone laments technical debt like it were a high-interest credit card. But just like how your CFO uses debt as capital for the business, the intelligent Product Manager knows that technical debt can help finance your path to market if you know how to manage it well.

Product managers who choose when and where it's acceptable to take on technical debt to overcome limited budget, constrained resources or critical deadlines, and budget their resources to resolve that debt at reasonable points in the future, avoid those nightmare scenarios. They recognize that taking on some debt can deliver real benefits so long as it's managed.

Finding the sweet spot between avoiding all technical debt and leveraging the right amount to get to market on a timeline that matters is a key skill for successful product teams.

Don't Build Too Little … or Too Much

Speed to market is a constant driver for product teams, with a high focus on feature delivery that can lead to an anemic architectural ramp. This is the source of technical debt that most teams are used to seeing. All the velocity is on features, and architecture "just happens" (or doesn't). Features are delivered that are not fully fleshed out, and the foundation they are built on won't support the actual feature requirements. While this is fine for an initial feature release to get feedback, repeated iterations result in a brittle product.

While a lot of technical debt comes from investing too little in supporting architecture, we see too many teams swing the other way and build far too much "infrastructure" upfront. Trying to anticipate everything a feature will ever need to do and build out the most beautifully architected backend for high-scale perfection before a single feature ships.

If the team is building too much enabling architecture at the onset, it's setting itself up for technical debt resulting from a change in requirements. Failing to get features out the door, the team doesn't get feedback until a lot of code is built. If you've got it wrong, you end up with a ton of technical debt in the form of an architecture that will never result in value to the customer.

There are, of course, feature sets that require a large amount of enabling technology. Features that have significant, complex components across multiple application tiers often resist iterative, MVP-style implementation. There are times when the MVP requires a lot of backend capability just to get the most basic version of the feature out the door. These are great cases for a buy/partner/open-source approach. Yes, you may accept some technical debt in the form of integration or "someone else's code," but if there is any risk around feature requirements, technical debt will pay dividends in the short term as you validate the feature. Place finite resources, including talent, toward solutions that could be resolved more efficiently by third-party options instead is another way technical debt mounts.

In the simplest term, reasonable technical debt is a trade-off. It's the result of identifying what's acceptable now that's worth addressing later. That's wholly manageable. What's unforeseen or overlooked that demands attention later is technical debt that every product manager wants to avoid.

To solve this and other varieties of technical debt, choose off-the-shelf options, either at the project's beginning or when they're needed. As noted above, embedded analytics allows managers to place solutions right into the development pipeline and move on. Time and talent spent focusing on other areas of the project offset the costs of buying a solution.

Debt Equilibrium

Technical debt is acceptable and even desired in some instances. When creating a genuinely trendsetting product, getting it to market as soon as feasible is the best way to obtain crucial user feedback. Addressing every possible way the new product will be used may be impossible to predict. So, creating an operational framework with simple, adaptable features that can be reliably built out into a compelling business solution for the client is a terrific way to identify and accept technical debt and leverage it for a project's benefit.

Identify technical debt and prepare for it to eliminate unpleasant surprises. Avoid it where possible and accept it where the benefits outweigh its drawbacks.

Manage and pay down debt by planning for it, choosing where and when it serves project purposes. This will ensure team momentum, the efficient delivery of products with state-of-the-art functionality, and expand the number of viable solutions to consider for addressing technical debt on projects in the future.

Charles Caldwell is VP of Product Management at Logi Analytics
Share this

The Latest

January 26, 2023

As enterprises work to implement or improve their observability practices, tool sprawl is a very real phenomenon ... Tool sprawl can and does happen all across the organization. In this post, though, we'll focus specifically on how and why observability efforts often result in tool sprawl, some of the possible negative consequences of that sprawl, and we'll offer some advice on how to reduce or even avoid sprawl ...

January 25, 2023

As companies generate more data across their network footprints, they need network observability tools to help find meaning in that data for better decision-making and problem solving. It seems many companies believe that adding more tools leads to better and faster insights ... And yet, observability tools aren't meeting many companies' needs. In fact, adding more tools introduces new challenges ...

January 24, 2023

Driven by the need to create scalable, faster, and more agile systems, businesses are adopting cloud native approaches. But cloud native environments also come with an explosion of data and complexity that makes it harder for businesses to detect and remediate issues before everything comes to a screeching halt. Observability, if done right, can make it easier to mitigate these challenges and remediate incidents before they become major customer-impacting problems ...

January 23, 2023

The spiraling cost of energy is forcing public cloud providers to raise their prices significantly. A recent report by Canalys predicted that public cloud prices will jump by around 20% in the US and more than 30% in Europe in 2023. These steep price increases will test the conventional wisdom that moving to the cloud is a cheap computing alternative ...

January 19, 2023

Despite strong interest over the past decade, the actual investment in DX has been recent. While 100% of enterprises are now engaged with DX in some way, most (77%) have begun their DX journey within the past two years. And most are early stage, with a fourth (24%) at the discussion stage and half (49%) currently transforming. Only 27% say they have finished their DX efforts ...

January 18, 2023

While most thought that distraction and motivation would be the main contributors to low productivity in a work-from-home environment, many organizations discovered that it was gaps in their IT systems that created some of the most significant challenges ...

January 17, 2023
The US aviation sector was struggling to return to normal following a nationwide ground stop imposed by Federal Aviation Administration (FAA) early Wednesday over a computer issue ...
January 13, 2023

APMdigest and leading IT research firm Enterprise Management Associates (EMA) are teaming up on the EMA-APMdigest Podcast, a new podcast focused on the latest technologies impacting IT Operations. In Episode 1, Dan Twing, President and COO of EMA, discusses Observability and Automation with Will Schoeppner, Research Director covering Application Performance Management and Business Intelligence at EMA ...

January 12, 2023

APMdigest is following up our list of 2023 Application Performance Management Predictions with predictions from industry experts about how the cloud will evolve in 2023 ...

January 11, 2023

As demand for digital services increases and distributed systems become more complex, organizations must collect and process a growing amount of observability data (logs, metrics, and traces). Site reliability engineers (SREs), developers, and security engineers use observability data to learn how their applications and environments are performing so they can successfully respond to issues and mitigate risk ...