Pay Down Your Technical Debt In 4 Steps

By Ken Clubok, Principal Consultant and Solution Architecture Lead at Navigator

You have an IT department filled with smart, competent employees.  And yet, they have a hard time getting projects done in a timely manner.  You try to find out why, and discover that the problem is twofold: They are spending so much time just keeping the lights on — handling routine day-to-day tasks and putting out fires — that they have little time left over for doing project work.  In addition, even small changes invariably seem to create new defects, which are time-consuming to track down and fix.

If some or all of the above seems all too familiar to you, then your organization probably has a problem with technical debt.  This is a term originally coined 25 years ago by writer, blogger, and software developer Ward Cunningham, and specifically applied to programming.  But the concept works just as well when considering a broader IT infrastructure.

Technical debt is the accumulated result of suboptimal or outdated decisions made in the course of project implementation.  It may be taken on knowingly (I have to take some shortcuts in order to meet an important deadline) or unknowingly (If I had known then what I know now, I would have designed this differently).  

Technical debt is like financial debt in that simply having it creates costs.  Just as financial debt bears interest, so does technical debt — in the form of increased total cost of ownership.  You end up paying the “interest” cost in day-to-day operations, with an additional surcharge on projects.  And just as too much financial debt can strangle your financial cash flow, so too can excessive technical debt strangle your IT team’s workflow.

It is nearly impossible to avoid generating some new debt with every project, although it is possible to minimize new debt by following good practices, and to offset new debt by paying off old debt.  Following a handful of simple guidelines can go a long way towards achieving this:

1.    Identify and prioritize the pain points.

It’s surprising how many discussions about technical debt ignore this obvious and important point.  With financial debt, you usually want to pay off the debts with the highest interest rates first.  The same is of course true with technical debt.  A poorly-written piece of code may be an eyesore, but if it’s stable, and it never needs to be touched, then you likely have bigger fish to fry elsewhere.  In contrast, a module that always seems to break whenever you touch something else is a ripe candidate for refactoring and/or automated regression tests.

A number of approaches may help to determine your biggest pain points.  For example, tracking trouble tickets, time spent on daily activities, and regressions can all provide useful data, as can interviewing IT team members.

2.    Make time.

This is perhaps the simplest piece of advice here, and simultaneously the hardest to follow.  When there are more business-centric demands on the IT team than can be fulfilled, it can be difficult to set aside time for an initiative that provides little or no direct benefit for the end users.  Of course, by freeing up IT capacity, it may provide indirect benefit, but it may take a while to see a return on that investment.  Occasionally, a proposed project will simultaneously benefit the business while also removing technical debt, such as replacing an outdated system that is a pain to use and maintain.  But relying on such projects is unlikely to be sufficient.

Recognize that most technical debt accumulation is the result of time pressure.  Much of it is incurred in order to meet ambitious project timelines, and nearly all of it is retained because time is never set aside to fix it.

The solution needs to start with IT estimates.  At the work unit level, make sure that the estimated time is not only sufficient to get the job done, but sufficient to get the job done right.  At the project level, build in some time for every project that touches existing systems to pay down at least some of the debt in those systems, so that the overall project can be debt-neutral or better.

If you have already reached the point where IT productivity is seriously hampered by technical debt, then the time problem is simultaneously more difficult and more urgent.  Entire projects may need to be executed with the primary purpose of paying down debt, so that IT resources can be freed up to help the business again.  IT leaders will need to compile and present a compelling case to business leaders to justify such projects.

3.    Create (and enforce) project execution standards.

Standards can go a long way toward minimizing the amount of debt accrued by projects.  For example, when systems are well coded, properly documented, and have sensible automated regression tests, they are significantly easier to maintain.  But take care to create standards that actually help the problem.  Good standards should meet the following three criteria:
  • They can reasonably be followed.  Overly cumbersome requirements will likely end up being ignored, or implemented in a half-hearted, non-value-added way.
  • They can reasonably be enforced.  Another name for standards that are not enforced is “suggestions.”
  • They add more value than they cost.  For example, when determining documentation standards, consider how the documentation will be used in the future, and also how brittle it will be.  The worst case scenario is documentation that nobody finds useful, but is difficult to maintain.  That exacerbates the problem of technical debt.
In general, I try to avoid making absolute statements, but here is one:  Programming standards should always be enforced by code review.  Period.  Studies have shown that effective code reviews not only improve adherence to standards, but they also significantly reduce the number of defects in the delivered product, and they reduce project time and cost.  The last is because they reduce the number of costly test cycles necessary.  This is one of those rare cases in which avoiding technical debt saves time up front, so there is really no reason not to do it.

4.    Create (and follow) an enterprise architecture plan.

Organically grown food is usually more costly, and in the long run so is unplanned organically grown IT infrastructure, only without the health benefits.  Without an overall architecture plan, It is easy to end up with a hodgepodge of systems built on different technologies, and depending on different protocols for data integration, authentication, authorization, and so on.  Such a hodgepodge delivers a double whammy to your IT team’s productivity, as they must work harder to make the different systems work well together, and they must maintain skills in many technologies.  

A well thought-out architecture plan will provide guidance for all projects, so that new systems will not add to the chaos.  Old systems that do not conform to the plan should be evaluated and prioritized for possible replacement. Of course, it may not be possible or desirable to replace every old COBOL system with a new Java or .NET system, and certainly not overnight.  But such considerations should at least play a role in project selection and prioritization.


The astute reader will have noticed that the burden of implementing the suggestions above falls largely on IT directors and project managers, rather than developers and system engineers.  Although the developers and engineers may do the actual work of paying down the debt, they must be given the tools and support to do so, including a consistent architectural vision, sensible and consistently enforced standards, and most importantly, the time to address the most pressing pain points.

Navigator Management Partners can help.  Our experts in architecture, project management, and requirements analysis can help you identify and implement the best opportunities for preventing and reducing your technical debt, so you can go back to focusing on what is truly important:  the needs of the business.