Author’s note: on rereading this, it seems like I’m calling for dev/ops integration via the product model which is hardly revolutionary. Old news, right? And yet … why is there still SO MUCH TECHNICAL DEBT? 

=======================

Product management and technical debt are top of mind for many digital and IT organizations, but people are unclear on the relationship between them. Did you know that one is a solution for the other? Let me explain.

How Does Tech Debt Arise?

The economic cause I see over and over again: It emerges “in the cracks,” between projects funded to achieve new, innovative things and technical operations constantly pressured for efficiency. Neither side has clear accountability for the problem, and so mitigating technical debt becomes highly politicized, with much kicking the can down the road — which only makes matters worse:

 

The above illustration is how traditional “dev” vs. “ops” teams might perceive it. But both are essentially powerless, because funding doesn’t happen there.

At the org level, it looks like this:

 

The leaders fight over who has to pay for technical debt in the aggregate. The development leader may be “closer to the business,” which controls the money overall, but “the business” is historically uninterested in paying down the debt. In theory, “the business” owns both sides of the problem but in reality tends to focus on new functionality and be much less interested when, for example, a required update to end-of-life (EoL) technology requires millions of dollars of migration costs — essentially to maintain the status quo. So the infrastructure group is told to take it out of constrained operational budgets.

Notice also that many of the projects on the left are now handcuffed because the technical debt has started to also slow down project delivery and operations is increasingly fighting fires.

In the past, leaders might advocate large-scale “IT transformations” and try to direct some of that funding to paying off technical debt, but such transformations are notorious for failing. Forrester also has heard that such transformations have difficulty making an ROI case for large-scale technical debt paydowns. Forrester does not recommend ROI as a criteria for deciding to rectify technical debt, which should be seen more as essential maintenance spend.

Many of us are familiar with these dynamics in traditional plan/build/run IT organizations. Many are also pursuing product model IT transformations, but I haven’t seen much discussion of the impact of the product model on technical debt. What’s becoming clear is that product is potentially a game-changer.

Marty Cagan of the Silicon Valley Product Group (one of the leading product thinkers I follow) states that “most companies with a good handle on tech debt will tell you that they work on tech debt every day, with about 10–30% of the engineering capacity.” But how? How can this level of investment be sustained when spending is so politicized and fragmented?

Exactly How Does The Product Model Solve For Tech Debt?

In the product model, the product team owns both new features and ongoing delivery of value. As my recent blog from the TBM Council conference pointed out, increasingly, product management is a “business within the business,” which means that it owns both development and operational concerns. If the product team is dependent on a major piece of software approaching EoL, it needs to budget for the software’s replacement (and associated migration costs) if the product wants to remain “in business.” In a simple “two in a box” model, we have, for example, a close partnership between a product lead and an engineering lead.

Here’s the interesting aspect: A fixed percentage of funding is protected and dedicated to technical debt. Note that the tech debt paydown is controlled by the engineering lead. This is based on a number of conversations I’ve had: Product leads may still have a tendency to focus on the shiny and new, so the engineering lead takes point on prioritizing the tech debt paydown. Devolution of the authority means that decisions are taken closer to the information, a key agile/DevOps value. Ideally there’s a unified funnel ala Mik Kersten’s Flow Framework: all work is either features, defects, debts, or risks.

 

Higher in the org, note that the protected capacity for tech debt is established and sponsored at the executive level. This of course takes the product lead and CTO presenting a united front that the budget *must* work that way. Ideally, the product model means no more idea of “IT” versus “the business” but many organizations are still working through those nuances. Topic for another day.

 

Another supportive, product-related development is platform engineering, which reduces the occurrence of technical debt (in part) by streamlining the infrastructure portfolio and reducing variation. Yes, this comes at the cost of some developer independence, but the days when that was a dominant priority are done. There’s growing consensus that too much developer autonomy to choose “flavor of the month” tech results in fragmented and decaying tech stacks that are toxic to innovation and agility. Organizations can’t get a handle on tech debt with so-called “full-stack” teams selecting whatever tech strikes their fancy in a given week. This is why platform engineering has become a major trend, as it replaces bureaucratic architecture processes and drives infrastructure teams toward empathy with their internal customers.

Summary Recommendations

  • Integrating dev and ops at the product team level
  • Protecting a “tech debt paydown” stream as an ongoing budgetary priority
  • Investing in platform engineering to reduce sprawl

Are you working on a product operating model, tech debt, platform engineering, or the intersections between them? If so, drop me a line.