“NEW SYSTEM MEANS NEW PROBLEMS”

John Gall

‍

This is the talk I, more or less, gave today to the UK Legal Tech Association.

‍

I started Radiant eleven years ago because I felt something was deeply wrong with how we were approaching  contracting, not helped by broken incentives at law firms. I'm not going to talk about the incentives problem - I've written plenty about that - but I do want to talk about what we've learned in the past eleven years about making contracting fly and where technology comes into this.

‍

I've been asked to talk about my book, “SIGN HERE: The Enterprise Guide to Closing Contracts Quickly”, but I also want to address the latest fashionable "silver bullet" in legal tech - contract lifecycle management (CLM) - and why I think it’s a step backwards. In making my case, I'm going to quote liberally from another book: “Systemantics” by John Gall. This book is a classic - it was first published in 1978 - but is not as well known in the legal tech world as it should be, perhaps because we are so focused on the new? All the same, it has plenty to teach us.

‍

Before I make the argument, let me cover my book’s basic ideas.

‍

I start by suggesting  that contracting matters, but is broken. I go into this at some length in the book, but let’s stipulate for now that there are plenty of business folks who are pulling their hair out over how long-winded and painful the contracting process is. They, I'm sure, have their own faults when it comes to contracting - it would be nice for some clear instructions, for example - but I basically agree with them. It's a mess, and it needs to be improved.

‍

So I spell out an approach to improving contracting that fundamentally comes down to a philosophy and a three-step plan.

‍

The philosophy is RADICAL contracting, that is: contracting should be built on Reasonable terms, smart Automation, be Data-driven, Incrementally improved, Collaborative, and Accelerated with a focus on creating Long-term relationships. The key is reasonable. We stand, at Radiant, for taking the middle road, for getting rid of unnecessary negotiations, and for contracts to be short, clear, relevant, and reasonable.

‍

I'll come back to this, but let me say now that you will have more impact fixing your standard terms than can be offered by any technology out there, and I give an example to illustrate this.

‍

The philosophy that we espouse is also hostile to the very concept of a silver bullet. We believe that Radiant is not in the contracting business, rather the relationship-creation business. And relationships are fundamentally between humans, which means that they will inevitably be messy. We can't create great relationships by wrapping everything in a beautiful UI, or a slick UX. We need to engage with each other, and make sure that what we are promising both meets needs and is achievable. The complexity of contracting means that there is simply no possible single fix.

‍

So much for the philosophy, let's talk about the three-step plan. Simpler than AA, but not quite as straightforward as it might appear. The three steps are:

‍

• Repeatable: get the basics in place, such as those short, clear, reasonable, and relevant templates, playbooks, and processes for intake, signing and collecting finalised agreements.
• Robots: Then we add some technology, not CLMs, but we put in place some basic tools. For example an intake form, document automation, Word extensions, esignatures, and a place for contracts to live. These may sound like just a feature list of a CLM, but I suggest you keep them separate for reasons that I will explain.
• Refinement: What I mean by this is continuous improvement, a never-ending process of pursuing perfection through incremental experimenting and tweaks.

Now, if you’re a student of lean, you will notice that there is something fundamentally wrong with the sequence I've spelt out. You don't start with the answer and then introduce continuous improvement, quite the opposite! What you have to do is put in place a culture of continuous improvement and then you figure out the answer.

‍

But I had reasons, two in particular:

‍

• The first is that I couldn't go and tell an audience of lawyers that the first step is to climb a cultural-change mountain before they can do anything practical. This is just not considered a reasonable proposition in our industry and no-one wants to hear it.
• The second is that we already know the answer to the initial steps of fixing contracting. It's not as if your problems are so different from the person sitting virtually next door to you. You can't automate contracts without having a template. You can't automate signing, without knowing who should be signing. And so on. So there is a logical sequence that we know because this is now at least semi-charted territory. There are maps, and one of them is in my book:

Radiant, however, didn’t start with a map. We had to create it. If you are one of the few people who have been following my online posts and tweets over the past eleven years, or even more crazily, coming to my talks, you will have watched as we figured this all out… we've been showing our workings along the way.

‍

We figured out the map by creating a culture of continuous improvement, and that is what I really want to focus on today. How does technology fit within a culture of continuous improvement? This matters because if you go Repeatable, Robots, Refinement, you need to make sure that the Robots stage doesn’t prevent you from doing the Refinement.

‍

Let's start with a study by a team of academics who were trying to figure out the role of automation in car manufacturing. The team dug into the sequence that was followed in the US versus the Japanese car industries. In the US,  when automation first became available, the manufacturers  piled right in. They started putting machines wherever they could find a space for them. But the Japanese took a very different approach. They worked manually and figured out the process first, simplified everything they could, and then they slowly introduced simple automation. They didn't want to put a complex machine in and then get stuck. And the results? Well, you know where this is going. The Americans got remarkably little productivity improvements out of their new machines, while the Japanese got plenty. And the American car companies eventually ended up with a new business strategy of going bust and having to be bailed out.

‍

So what if we started by taking continuous improvement seriously? What if we said that culture mattered most? I mean these things get said, but rarely done. So how do you even create a culture?

‍

Let me show you a picture - my summary of the approach taken in lean and then codified in the Shingo model:

Basically, you need to start with principles (such as taking scientific-thinking seriously and pursuing perfection) and use them to design systems, by which I mean people, processes, and tools, working together with an aim. These systems together with your organisational purpose (and your team’s individual purpose - so get the right people) will drive the actual behaviours of your team, and those behaviours will drive your organisational results. If you focus on getting those components right, you can build a culture of continuous improvement - and so deliver the faster contracting and the other results that you are looking for.

‍

This culture of continuous improvement is what we continue to work towards at Radiant, where we are already turning over 85% of contracts in half a day (top quartile inhouse teams average 11.5 days), helping our clients (in their words) “treble” their through-put of deals, and rewriting contracts so that they are indeed short, clear, relevant, and reasonable.

‍

Meanwhile, this is what I keep seeing happening elsewhere - the model, being pushed hard by sales teams and jumped on by at least some GCs:

It's so simple, isn't it? Why bother with culture, if we can just force through change by putting in an IT system, and getting everyone to use it? If we do this, then surely everything will work as it should? We will have data and dashboards, and we will finally look good in front of our finance colleagues by being able to show pie charts in many colours. And we may even, eventually, know how many contracts we are supporting.

‍

But there is a very big difference between an IT system - and I’m talking about CLMs here - and a system in the sense of systems-thinking.

‍

The concepts are not completely different though. If you take an IT tool and make it big and hairy and complex enough then it becomes a system in the sense that it has side effects and emergent properties. You can find yourself with gnarliness quite by accident.

‍

So what is a CLM? Well, think of it this way. Here are the main categories of legal technology associated with contracting:

Obviously, this picture is completely wrong because the only two technologies used for most contracting are Word and Outlook, but moving past that problem, these are the tools/features that would normally be called Contract Legal Tech.

‍

In this context, CLM can fundamentally be understood as a marketing term created by the companies behind contract management databases as they moved left to add the additional features to try to provide an "end-to-end" solution.

‍

Another way of looking at it is that if legal technology is fundamentally made up of four types of tech: databases, document manipulation, search (including posh search aka AI) and workflow, then the defining feature of CLM that I am so concerned about is the workflow - the attempt to glue all of the parts together into one integrated and unified system.

‍

Now tight integration has apparent advantages: no one wants to rekey or throw away data. But there are costs that come from this unified approach because it introduces those pesky side-effects and emergent properties.

‍

And so we come to the book Systemantics, a Lovecraftian-study into all the things that go wrong with complex IT systems. With its words of wisdom echoing from a previous generation, that tend to come in ALL CAPS, the first lesson of Systemantics is that:

‍

NEW SYSTEM MEANS NEW PROBLEMS

‍

The first of these problems will be adoption. How are you actually going to get your team to use the new CLM system?

‍

Let me tell you another story: one company I know introduced a new contracts management system (that's just the database part, no real workflow) because the head of procurement was fed up that no one could ever tell them when contracts in a particular category were up for renewal. They chose a large solution that had lots of bells and whistles and was correspondingly expensive. It cost millions of dollars for the system and the extraction of the data, so in order to justify the cost for the project (which let us note was being introduced to solve a problem that could have also been done by a spreadsheet), they decided that it was important to track not only renewal dates but also a large number (as in approaching 50) other fields. The problem, of course, was that no one wanted to answer 50-odd mandatory questions about any contract that they uploaded, so they actively avoided adding  new contracts to the system. And so the system became untrusted as incomplete, and people continued doing what they used to do, which is rummaging around in emails whenever a question was asked.

‍

But a CLM has got even bigger adoption problems than a mere contracts database, because its scope is all-encompassing. You are dealing with lawyers who, as others have observed, are the kind of people who will look at a broken twig on a tree and declare the tree to be broken. You need to get all the different parts of your complex system to be beyond great to win them over, but Systemantics tells us that:

‍

SYSTEMS IN GENERAL WORK POORLY OR NOT AT ALL

‍

So adoption is going to be hard. Very hard. This is one of the reasons why most IT system projects fail.

‍

But it gets worse because when you try to put a large system in you are effectively trying to model (as well as steer) reality and again Systemantics has an observation:

‍

REALITY IS MORE COMPLEX THAN IT SEEMS

‍

Even if you follow my advice and document and tame your processes before you start thinking about automation, the reality is that you won't really understand the reality that exists in your environment, and to try to represent that poorly-understood reality in a workflow tool is a recipe for disaster.

‍

You also have a flexibility problem.  What used to be easy to change (even if it was in fact chaos) is now hard to change because:

‍

THE SYSTEM ALWAYS KICKS BACK

‍

When you make changes going forwards, you are going to have to try to understand the side effects of any change. And even if you get on top of those, you are going to be constrained in your changes because they will need to be done by rare and limited resources. Programmers whether internal or external are generally expensive, and so your department will have limited access to them  and you will never stop having to fight for a budget.

‍

Oh, I hear you say, what about “no code”?  Well sure that’s an aspiration of some of the contenders, but even if it lives up to the sale’s promises, your system will quickly get to the stage where it is too complex to be tweaked by anyone other than a few brave souls in your team and guess what - they have poor availability too, and sometimes people leave.

‍

Meanwhile, you think you have lots of new data about what is happening, but can you really trust what is coming out of the system? On one level you can because:

‍

IF THE SYSTEM SAYS IT HAPPENED, IT HAPPENED

‍

It's cute as long as you don't care about what is really going on, but this then raises the next problem which is whether the shiny dashboard that you have been promised will actually help.

‍

One of the observations I make in the book is that the information you get from your dashboard may be initially enlightening but as you identify new issues in your process, in the spirit of continuous improvement, the dashboard will likely be less and less enlightening. And Systemantics, of course, has observations about this problem too:

‍

THE INFORMATION YOU HAVE IS NOT THE INFORMATION YOU WANT

THE INFORMATION YOU WANT IS NOT THE INFORMATION YOU NEED

THE INFORMATION YOU NEED IS NOT THE INFORMATION YOU CAN OBTAIN

‍

Because guess what has happened? You've just locked yourself into an inflexible system that may be pretty but which you can't pull any data out of that wasn’t envisaged by the developers… who don’t understand your particular evolving needs.

‍

Meanwhile, as a corollary of our earlier rule (if the system says it happened, it happened) there is:

‍

TO THOSE WITHIN A SYSTEM THE OUTSIDE REALITY TENDS TO PALE AND DISAPPEAR

‍

This might be problematic if you are, for example, trying to create human relationships with the other party but your team has now retrenched into an environment that just fires out electronic demands.

‍

And then we come to this fundamental rule:

‍

A COMPLEX SYSTEM THAT WORKS IS INVARIABLY FOUND TO HAVE EVOLVED FROM A SIMPLE SYSTEM THAT WORKS

‍

How can a “complete out of the box” system meet this?

‍

This explains why we at Radiant have created our own system painstakingly over the years that has a team of developers slowly adding features based on what we actually need in practice, and where the scope is limited and unambitious because we are so damned uncertain about what we will think in the future is a better way of working.

‍

But if you still want a CLM, think about this derivation from the previous rule:

‍

A COMPLEX SYSTEM DESIGNED FROM SCRATCH NEVER WORKS AND CAN NOT BE MADE TO WORK. YOU HAVE TO START OVER, BEGINNING WITH A WORKING SIMPLER SYSTEM.

‍

This is why I encourage you to focus on simple tools like base document automation (go have a look at Docassemble) rather than starting with a pre-glued uber system. As Brooks (of Brooks Law) observed:

‍

PLAN TO SCRAP THE FIRST SYSTEM. YOU WILL ANYWAY.

‍

I should note here that this talk was inspired by a post on LinkedIn from someone helping a team roll-out their fourth CLM.

‍

And so we come to the meat of the advice from Systemantics:

‍

DO IT WITHOUT A NEW SYSTEM IF YOU CAN.

DO IT WITH AN EXISTING SYSTEM IF YOU CAN.

DO IT WITH A LITTLE SYSTEM IF YOU CAN.

‍

and remember:

‍

ALMOST ANYTHING IS EASIER TO GET INTO THAN OUT OF.

‍

Does this mean that I am fundamentally anti-technology? Not at all, I can't bear the idea of our team wasting time doing manually that which could be done faster and more accurately using automation. But I urge you to think long and hard before you try to solve all your problems with one masterstroke.

‍

Try instead some simpler tools:

That way you will have a fighting chance of getting somewhere in the Refinement stage.

‍

Thanks to Professor Norman Faull for the story about the car industry.

‍