What is common between technical debt (a programming concept) and private equity M&A?
As a non-technical founder of a software product the learning curve is both steep and fun. When you are surrounded by engineers, you cannot escape the technical jargons from their world (as a tax advisor, I can relate to my engineering colleague’ love of jargons).
Amongst the many I have picked up, one particular software development concept has stuck with me and made me think. I think this is because it sums up the motivation behind what we are building here at DealsPlus. The term is ‘technical debt’. Wikipedia defines it as the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that may take longer. The most common form of technical debt is when software is built in a rush and corners are cut. As with any debt, technical debt comes at a cost which includes the time and money incurred down the line when you have to repay it (rework the software).
I think there is an analogy between technical debt and private equity M&A processes. Having been involved in the private equity M&A for 15 years, I can summarise the technical debt private equity managers take on as follows:
- lack of standardisation in deal closing processes; and,
- lack of a Single Source of Truth across a Manager’ portfolio holdings
The interest for on this debt accrues over the life of an investment and is paid through higher costs, both in terms of time and ultimately returns.
Debt is good, but not all debt is good. And this one is best avoided. That’s exactly what we here at DealsPlus help private equity managers do. We think there is a lot of value in this.