tjbresearch.com
Monday, December 16th, 2019
technical debt

I am always on the lookout for new concepts to use in the analysis of organizations.  Often they originate in other disciplines, but can be applied or adapted for use in my consulting work and training sessions (such as my due diligence workshops, the next of which was just announcedtjb research | This one will have some new wrinkles.).

In the case of “technical debt,” much of the work was done for me by Mawer Investment Management.  A November podcastMawer Investment Management | The podcast page has a link to the transcript of it, as well as others to related blog postings. from the firm explores technical debt and its implications for both the investment and operating decisions of asset management firms.  In this posting, I also link it more broadly to other kinds of organizations in the investment world.

To start, here’s a graphic from CIO New Zealand:CIO New Zealand | It appeared in this posting.

techdebt

Ignore for a minute the words inside the grid.  In evaluating an organization (whether from the inside or the outside), a basic goal is to identify the things that add and subtract value, knowing that some are easy to see and some are hidden.

The term “technical debt” comes from the realm of software development.  Simplistically, it is the gap between the optimal state of a program or system and where it is now.  (A tidy overview of what it is and its history comes from Agile Alliance.Agile Alliance | Ward Cunningham came up with the term.)  Appropriately, the Mawer podcast starts with a discussion with Dwight Pratt, who works in its business technology group.

Pratt provides an overview and then talks about three kinds of technical debt:  deliberate (such as when corners are cut to bring a software release to market, in expectation of improving it later), accidental, and “bit rot,” the complexity that results from lots of incremental changes, often made without an understanding of the big picture.  Whatever the source, as with financial debt, if it becomes overwhelming, technical debt can pose significant operational and cultural challenges to an organization.

The second part of the podcast features Karan Phadke, an equity analyst at Mawer, who discusses the implications for analyzing companies and provides examples of how technical debt left unaddressed can result in significant financial impact down the road.  He discusses the various metrics and investigative methods Mawer uses to try to estimate the technical debt of companies it evaluates.

There are also references to “The Lab,” an internal Mawer team that helps investment decision makers try to come up with new tools and techniques to aid the analytical process.  That is a good example of how the notion of technical debt relates to something that you might call analytical debt.  Time doesn’t stop and the investment markets are always grinding away at what works; getting better for tomorrow means assessing the interconnected technical and analytical debts and addressing them today.

When evaluating an organization, I find that its technical structure can give important clues about how information flows and where potential problems might be.  The notion of technical debt adds another layer (and another line of questioning) to that.  A few examples where it can come into play:

~ Information platforms (pick your favorite provider) all have technical debts to one degree or another.  The problem is that by relying on them, you inherit that debt.  In cases where it gets extreme, you may be forced to play catch-up, involving elevated expenses, operational problems, and even missed investment opportunities.

~ The concept of technical debt applies across the board, regardless of firm size.  On the one end of the spectrum, small firms often don’t have the resources to solve the problems that they face, causing them to cobble together solutions.  Big firms can easily be hamstrung by legacy systems (and there’s plenty of cobbling away on spreadsheets within them too), and they are often susceptible to budget freezes that cause the problems to grow further.

~ A perennial issue for investment firms is that when they create systems, they usually lock down today’s world in their analytical and reporting schemes.  Yet strategy and categorization changes are part of the evolution of the market, and systems can become out of date quickly.  (Here’s an old posting — from 2008! — about that.the research puzzle | It was titled, “where we draw the lines.”)

~ Knowledge management systems should be the heart of any investment organization’s process.  Ashby Monk has writtenGoogle | A search provides examples of his work. about the need for asset owners to improve on the knowledge management front; the same goes for asset managers, advisory firms, consultants, etc.  There are large gaps in this area.

~ An article on TABB ForumTABB Forum | The site requires free registration to view the article. addresses the production of sell-side research, which is stuck in time.  Granted, the author is in the business of proposing new ways of providing it, but the assessment is spot on.  Both research providers and the asset management firms that consume their research ought to be preparing for a much different future ahead.  There are changes happening at the margin already; you can think of it as technical-debt-in-waiting (with significant implications for the research process).

~ Among many other firms in other parts of the investment ecosystem, advisory businesses are facing significant changes in how they operate.  The Schwab/TD Ameritrade merger and the RIA roll-ups are upping the stakes for others, making the gaps for many firms on both the operating/practice management front and the investment front more acute.  Many involve technical debt.

If you run a firm, you ought to have a clear focus on your technical debts (deliberate, accidental, and bit-rot), which are often hidden even from insiders.  If you are on the other side of the table, trying to understand the situation as an outsider, you need to adapt your questions and tactics to be able to identify those very real liabilities.  One suggestion, in reference to the image above:  Start in the upper right by learning about the architecture of the organization; you’ll be surprised at what you stumble upon.