Contracts are broken. How do we fix them?

This blog post originally appeared on our founder’s consulting website potemkin.legal. We reprinted it here because it gives an early insight into the roots of Majoto and the problems it is designed to fix.

As a lawyer, I was always frustrated with how contracts work. I wanted to make a contribution to fixing it. That was one of the motivations for leaving the corporate world and embarking on a new adventure. I started with the belief that I needed to work outside of the prevailing system of legal tools and technologies and to search for a different paradigm.

To start, I thought about the ways in which contracts and contracting processes are broken, and what the future of contracts should look like. I shared these in some articles. 9 months down the line, I was listening to this excellent interview with Alex Hamilton of Radiant Law, and it reminded me that it’s worth revisiting the problem statement. I was relieved to see that my original statement still rang true. I figured I’d set it out again, refreshed and updated, before I share my own contribution to pulling down that wall.

Recap - why (and how) contracts are broken.

Reason 1 - bad language (= unclear, not human friendly).

The majority of contracts are (still) long-winded, full of archaisms and unclear and unnecessary language (as Ken Adams demonstrates over and over again). Which means that contracts are poor at the one thing they are meant to be good at. The legal community as a whole has yet to learn to apply good language discipline and modern best practice. There is change (mostly B2C contracts), but there’s a long way to go.

Reason 2 - all words (= a poor communication tool)

The business world thinks and communicates with diagrams, charts, stories and outcomes. Yet contracts and the lawyers who write them tend to be limited to words and risk - communicating narrowly and performing a narrow function. As Alex Hamilton puts it nicely, the “normal” is to expect and create car crashes. It’s no wonder that (most) contracts are not good instruments for securing business objectives, forging relationships and building trust.

Reason 3 - A4 Word (= not very functional)

A word processing application is at best an awkward tool for managing contracts. A contract is not a letter. It usually needs customisation, internal alignment and negotiation. It needs ongoing use because it records how a relationship should work. It often needs to be extended, amended or terminated during its life. The tech in this space is either adding functionality to Word or building workflow around a Word-style document. That does not make the document inherently more functional. In my view that’s a huge limitation to driving real change.

Reason 4 - negotiations are stupid (= bad process)

Most negotiations are still done by sending mark-ups (usually by email) in highly iterative adversarial cycles. Contracting tech takes this poor process and automates it. It may be faster, but automating a bad process only gives you a bad automated process. There are tools out there for real time collaborative negotiations. But unfortunately the day-to-day reality for most businesses is very backward.  

Reason 5 - unstructured (= no data, not machine-capable)

This is a new addition to my list. Most of the contracts out there (and legal content generally) is created in a highly unstructured form (word processed documents, email). This makes it difficult to pull useful information down the line - whether it’s data insights or risk assessments or a negotiation history. Machines can’t read it, at least not easily and not without a lot of manual effort. This is hugely limiting, not only because it makes it more difficult for machines, but because it puts many possibilities out of reach of existing capabilities.

So what about legal tech?  

My view: most of the contracting tech out there perpetuates old paradigms: (semi)automating and speeding up old processes but not transforming them. It's like automating a horse (more on that later). It can be impactful for sure - but perhaps because of how dismal the legacy processes are? The prevailing failure (to date) to build fundamental improvements to how things look, feel and work, is in my view the key barrier behind the key barriers to legal tech adoption.

Recap - how to fix it.

As Richard Susskind points out, clients don’t want lawyers, they want outcomes. Contracts in their current form are a product of process-centric and supplier-driven thinking, and the designers of the instrument(s) that will replace them will focus on outcomes, customers and different ways of working.  So here is a recap of my vision for “new generation” contracts.

Feature 1 - for people and purposes

A refocus towards outcomes and business users, rather than processes and legal suppliers. This impacts both form and content: better and simpler language, shorter contracts, more navigable structures, outcomes before risk, business efficacy before legal processes. A simple but excellent example is Lemonade’s insurance policy: it’s no frills but wonderfully put together and clearly focuses on two key outcomes: attracting users and making sure they understand what they’re signing up to. There is a great debate about “purpose” in the business community. We should have a good answer to the question “what is its purpose?” for The Contract as a tool, and for each individual contract.

Feature 2 - better communicators

There is fantastic work being done in the legal design and visualisation space (I would single out Stefania Passera and Anna Posthumus Meyjes and the community around the Legal Design Summit), but this approach has yet to make headway into B2B contracts, and contract automation is nowhere ready for it. A truly modern contract must be able to present information in ways that are helpful to users - and accommodate diverse preferences and aptitudes. This means being able to present information in visual and other ways and, ultimately, giving users a choice of how they see and interact with the information. It means providing useful interfaces for the business looking at the high level, and for the contract professionals working with the detail.

Feature 3 - dynamic

A contract should be able to simplify, not complicate, its own lifecycle. Contract automation helps to link lifecycle events and the documents involved, but it does nothing to reduce the complexity of those lifecycle events and the multitude of documents. To me, the future lies with a dynamic living instrument that allows lifecycle events to be viewed, created and manipulated - without having to rely on the underlying platform through which it was created. 

Feature 4 - functional

A contract should be able to do more than just record the final deal. Think of all the documents that a contract might spawn: internal and external emails, powerpoints, negotiation plans, term sheets, negotiated versions, risk assessments, playbooks, post-signature tracking etc. A truly modern contract instrument or system should be able to integrate all of these seamlessly or do away with the need altogether. Self-executable “smart” contracts might be part of the answer. More generally, contracts and contracting systems should be active instruments in the outcomes that they are built to drive, not just passive records of risk allocation. 

Feature 5 - more structured

Contracts need to move from “unstructured” to “structured”, to enable data insights, portability and, even more importantly, new ways of presenting and manipulating content. This Juro white paper is a good introduction. There are ways in which content can be deconstructed or structured from the get go, and it’s possible to start doing that now - even without AI or proprietary platforms. But rather than digitising poor content, I believe that contracts need to be designed and structured to make it easier for both machines and humans to work with. This will be a game-changer towards transforming, not just automating.  

Final word.

If all this sounds lofty or far fetched, hopefully I’ve indicated enough examples to suggest otherwise. And I’m sure you’ve seen many others. There is a growing handful of products and people out there building new paradigms to challenge the old. In my next post I will unveil my own contribution to that, which I hope starts to answer many of the unmet challenges I have posed.

- Denis, Founder, 24 September 2019