Mining Technical Debt for Fun and Profit

Building and improving an application stack or business is managing a series of past decisions. Some good, some merely expedient. We promise ourselves that given enough time and resources, we’ll go back- refactor the code, re-architect infrastructure, draft better documentation.  But for now, that will have to do. If it works well enough, leave it be and we’ll solve more pressing problems- the new features, some custom requirements for the Big Customer(tm) and bug fixes.

Rinse, repeat. That old tech debt gets a hard crust of “don’t go there” and after a while only a few people understand how it actually works. Those few people know the system well enough to develop workarounds to meet new requirements, so you don’t get a mandate to replace it. 

Sometimes that’s a valid approach.

It works well enough and it’ll be expensive to change, so why change it? Many times, that’s a valid strategy. Like some old cars I’ve owned, it doesn’t matter if the seat doesn’t move any more, since I’m the only one driving it. The modifications and non-original parts are OK, because I know what’s there.  

Until it comes time to sell it. Or let someone else fix it.  Or work with a company you just merged with. Or secure it. 

It’s hard to know the costs unless you know where to look.

Once I was the system administrator trying to make “our” backup infrastructure work with “their” file and database servers. Of course, we learned that all the cool workarounds they did on their end made it almost impossible to work with our relatively stock backup system. Our custom identity management application wouldn’t talk to their Active Directory.

And we all had to explain to our new, merged management that the IT cost savings their consultants expected weren’t going to happen.  

We weren’t very popular that week.

Looking back, we should have done some preparation for this. We needed to know what to clean up before looking to merge with someone else.  

This is a solvable problem, though.  A quick review of your infrastructure and governance will let you know where your weak points are before you’re taking to a potential buyer. This allows you to set aside money, resources and attention to prepare for the work.

The calculus of knowing your flaws:

For the seller, there’s a common belief that before a sale, it’s better to not know of a problem, since knowing requires disclosure. Failing to disclose a known issue is a litigation risk.

But not knowing costs more. If you sound quite incurious about your own company to the buyer’s due diligence people, it’s a bad look. They’ll doubt you on the things you _do_ know. When they’re done, the holdback is going to be a lot larger than you might like.

It’s better to know your flaws and have a remediation plan ready to go. That makes you seem more proactive. It also allows the buyer to better understand the costs and reduce the holdback and avoid deal friction. One fewer thing to worry about when working the fine points of the deal.

Finding the hidden flaws:

For the buyer, the value in finding the flaws in an acquisition is more straightforward. Every issue found can be used to offset the offering price. Also, you may find that behind the tech debt are possible undiscovered breaches or privacy issues that will require a holdback until claims are settled.

For the reviews we’ve done, we’ve saved the buyers a multiple of our fee. For firms looking to get acquired, a maturity assessment can convince buyers that you’ll be able to grow the size and number of your customers.