What is Technical Debt?
Technical debt is a term whose origin is from the software industry. All of us have had the experience with Microsoft or Apple spinning out a new version of an operating system or software platform which we are compelled to download only to find out there are bugs. This bugs us to no end (pardon the pun).
For software firms there is a tradeoff between speed and perfection. If time were taken to make things perfect, no software would be produced. No amount of testing will examine every use case, so these choices must be faced. Judgments must be made regarding whether to do it perfect the first time or rather to produce a usable product and fix it later. It’s a matter of prioritizing speedy delivery over perfect software coding.
That’s Software. But how About Legal Tech?
With legal tech there is a technical debt of sorts which law firms and legal departments should seriously consider. And we’re not talking here about software bugs. The accelerating pace of change right now for digital transformation is extraordinary. To survive and thrive that transformation must be done with excellence.
Legal tech is on the move, but false starts are frequent and costly. As legal tech has been added, one point solution after another, obsolete workflows and reorganization of legacy systems tend to be initially overlooked. Internal processes cannot be kept the same if you want the full value of digitization. Information infrastructure may likewise have weaknesses that are more time consuming and costly to deal with down the road if not addressed at the outset.
“Procrastination is like a credit card: it’s a lot of fun until you get the bill.” – Christopher Parker
There are many challenges faced with interoperability of multiple legal tech platforms added one after another in law firms and legal departments. Firms are coming to realize they need to have their data house in order, and their information infrastructure tuned up, in order to leverage the combined horsepower of all the available legal tech tools.
In the world of software most systems contain cruft (leftover, superseded, unnecessary, or just poorly written source code that is then uselessly and harmfully compiled into object code) which accumulates. This can make adding new features or modifying existing ones more difficult and time consuming. Now, setting aside this software coding example, can you imagine this happening in a similar fashion when legal tech systems are incrementally added to your information infrastructure over a span of time?
Consider a “Technical Debt,” not at the software coding level, but at the business systems level. Consider not just the technology systems, but also the internal legal organization work processes, which had previously been fashioned to be congruent with manual execution, and legal professionals who are typically resistant to adoption of new tools to boost effectiveness.
These and other things comprise an accumulation of a type of technical debt that sooner or later must be paid off. What is a good legal tech debt? What is a bad legal tech debt? What can be wisely put off for addressing later, and what must be tackled up front to avoid costly implementation failures and do-overs.
How Does It Come About?
Technical debt as it pertains to legal tech can occur many different ways. One way to categorize it is to consider the specific context and the intent.
- Was the overall strategy for change deliberate or inadvertent?
- Was the approach prudent, carefully thought out and evaluated, or was it uncritical or, in the extreme, reckless.
Considering the above two parameters, Martin Fowler, a British software developer, author and international public speaker, proposed a Technical Debt Quadrant which can be easily adapted to business leadership decision making for digital transformation in law firms and corporate legal departments that have embarked on the legal tech transformational journey. See the table below:
Technical Debt Quadrant
|We don’t have time for prioritizing our technology choices based on business value.
|Based on our thorough reasoned analysis we must do this urgent high-value, high-impact thing right now and optimize it later.
|User acceptance and buy-in??? They will just have to use it!
|Got it done! But now we know better, and how we should have done it.
Technical Debt Ledger
Consider the example of data governance. This governance is required for legal tech to produce ongoing value. Who owns the investment stack of your corporate data is foundational knowledge for digital transformation to be successful.
Volumes in your technology infrastructure are data containers. Volumes can be online, offline, restricted, or shut down. Knowing who has rights to which storage volumes and having a protocol for granting rights and changing the records for this should be thoroughly documented.
Should there be a security breach, being able to narrow the list of persons who have access will shorten the time for problem solving. This list, this overview, is a fundamental for security for legal tech integration and high technology infrastructure readiness. That’s one example where a technical debt can be accumulated. Below is an example technical debt ledger that lists some other examples.
Technical Debt Ledger
|Delayed reorg of legacy systems to harvest latent legal tech efficiencies
|Postponed deletion of obsolete workflows
|Lack of organization-wide KPIs for tech adoption
|Change management system not implemented
|Silo’ed data repositories not ready for legal tech data intake and interoperability
|Internal legal tech data analytics capacities lacking
|Business recovery plan absent
Think About It
Where are you in the digital transformation journey? Would you want to optimize your approach and apply best practices to assure avoidance of legal tech failures? Do you want to be, and to stay, reasonably DEBT FREE?