Juralio

Graeme Johnston / 2 February 2022

Something that’s crept up on me over the years is my frustration with the typical format of contracts, the process for dealing with them and the difficulty of doing much about it in a practical way.

Contracts have never been my core business, but I’ve drafted them, negotiated them, read them, managed them, tried to understand their risks, and on occasion litigated or arbitrated them. And the frustrations have built over time.

There is plenty of great material out there on how to make better use of technology, data, process and design in relation to contracts.

This article discusses something different: some thoughts on an appropriate way of organising for better contracting within a modestly sized business.

It’s still work in progress and I’d appreciate comments and suggestions for how to do it better.

But first, some background.

Plain language

I originally trained as a lawyer. When I did my basic legal education in England in the early 1990s, there was some emphasis at the postgraduate diploma stage on ‘plain English’ drafting. As contrasted with the mystical terminology and syntax of old-school legal documents. It seemed clearly right. 

I think it’s fair to say that the principle is widely accepted in the UK legal world nowadays, though there is still considerable mismatch between words and action. Plain language doesn’t just happen: it takes effort and often just isn’t a priority. And the interpretation of ‘plain’ can vary. And I do still meet some cynics even in today’s legal world who admit to protectionist motives in keeping things jargony.

But still. There has been progress over the last thirty years, even though unevenly distributed:

• Language in most commercial agreements of UK origin that I see isn’t obscure in the way that I still see quite often in contracts originating in, umm… certain other places. 
• Much good work has also been done in recent decades in making UK consumer contracts easier to read. I’ve done some work in that area myself at points over the last quarter century.
• The plain English movement also extended in the UK beyond contracts into other lawyer-dominated fields such as regulation and litigation.

Remaining problems

But some other contractual format problems weren’t talked about so much in the English legal world of the 1990s – at least not extensively enough to filter down to me. Problems such as disproportionate length, cost, delay, over-complication, excessively bespoke language, lack of open standards, underuse of structured data and how to manage a contract through its lifecycle. 

There was some acknowledgement of the importance of document layout and fonts, but that was, at best, outsourced to publication specialists once the lawyers had done their thing. And modern concepts of interaction design and flows weren’t really a thing yet, in those early days of the web.

Despite the progress on plain language, I would say that the overall problem has worsened under two main types of pressure:

• Technological imbalance. The almost universal adoption of late twentieth century technologies for generating, sending, revising and commenting on the written word. This has contributed to the growth of the problem faster than twenty-first technologies can yet address. And they’ll never be able to do so on their own: it’s a really complex problem.

• Legal and regulatory depth, impact and breadth. One clear trend of recent decades: ever more law, more regulation and more risk of falling afoul of them in ways with serious consequences. Also, more countries have detailed laws affecting business, and they interact in complicated ways. All of this imposes complicating pressures on contracts.

To the extent that contracts can be standardised in ways that are widely accepted, a clear route to solving some issues can at least be envisaged, though it’s not trivial to execute effectively. 

For negotiated contracts, the problems are exacerbated by the fact that different organisations may well have conflicting attitudes to doing things differently. It’s a really tough problem.

Organisational implications

There’s plenty to be said about technology, data, process, design and standardisation. Lots of interesting things are happening and I’ve tried to do something to contribute and encourage some endeavours which I find promising in those areas.

But the specific topic I want to talk about here is something that we’re currently thinking about in our company:

• Being clear as to what our and our stakeholders’ real needs are in relation to contracts
• Organising in a way that’s capable of meeting those needs long term, in a balanced way

Advantages we have include

• We’re not committed to a particular approach for scaling things up yet.
• I and some of my colleagues have been around long enough to see how things can go wrong in this area.
• We have a good range of skills in the company, including legal, finance, operations, design, engineering and data.
• We’re used to working cross-functionally in a product context and already have systems, roles and processes in place to stay on top of that sort of process and continuously improve.

A disadvantage is that we’re constrained in the resources we can apply to this topic. But that has some advantages as well.

Established approaches

Over the years, I’ve done a lot of work with large companies who handle contract preparation and negotiation primarily via their legal departments. I’ve also dealt with those who put another department (e.g. procurement) in control of certain types of contract (though with some level of legal department input in the background). The two approaches play out differently in their details, but I think either carries a real risk of ending up with overlapping problems such as these –

1. Over-complication and excessive length – because a group focused on a highly specific domain (e.g. legal issues, procurement) doesn’t itself bear the true cost and risk of this.  
2. A tendency to fixate on certain risks and contractual solutions – while missing other risks or solutions.
3. Unreasonable or inflexible stances which show they’ve done their job (if questioned) but damage relationships and risk deals
4. Cost and delay resulting from the above – and from other sources
5. Conflicts of interest and agency problems, including ‘staying relevant’
6. Contracts which are hard to digest and manage for humans and machines alike

There are more subtle problems as well. I can’t prove it, but I suspect that a mindset of ’my job is to manage risks’ may be harmful in a relational context by creating an illusion of safety in the form of highly complicated contracts, whereas a less detailed ones may paradoxically keep people more conscious of the need to look after the relationship. If an analogy helps with this point, I offer Hans Moderman and traffic design. Of course, it requires a lot of judgement to strike the right balance.

I don’t want this to come across as somehow anti-lawyer. As well as technical legal input, a really good lawyer brings a conceptual and linguistic clarity, and other good things, which can be hard to find elsewhere. It’s just a question of bringing other perspectives effectively into play as well.

Where we are, where we’re going

We’ve already made some investment in

• designing some of our key contract templates in ways that are much more usable than standard legal documents
• making an effort to keep them simple
• tracking key points

But we’re now at a stage where we are going to need to make some decisions in the near future as to how to scale up our contract handling.

I thought it might be of interest to share some high level thoughts about this difficult topic. These fall into two major categories –

Category 1: what are our needs?

As a starting point, we’re determined to keep in mind the real needs, both

• positive – clear benefits to our business, team and stakeholders
• negative – managing the risk of things that might go wrong.

‘Positive’ things include

• Concluding and managing contracts as quickly, efficiently and – for the individuals involved – as unstressfully as we can.
• Covering the commercially important points effectively.
• Supporting relationships, rather than being tiresome artifacts that most people stay well away from.
• Making them as clear, simple and usable as we can for their primary users – business counterparties, team members and technical experts in our case, i.e. the people who will implement them.

This involves challenging ourselves about additional detail – does it help, what does it cost – now, and down the line – what risks may it carry. It therefore involves actively simplifying, in a world where the tendency is towards ‘feature creep.’

I think it’s clear that the design, process and data aspects of this are just as important as the legal ones. No single perspective should dominate.

The two big ‘negative’ issues to manage are, we think:

• Mitigating specific ways that a particular contract could go wrong – but applying some really careful, joined-up thought as to risk likelihood and magnitude, the costs of addressing risks disproportionately, and different options (not just contractual terms) for addressing risks.
• Guarding against the agency problems and other conflicts of interest which we all have. Lawyers, sales, procurement, engineers, managers. Everyone. And not just guarding against them in the ‘design by committee’ way that makes things more complicated. Instead taking a ‘product owner’ approach to contracts that looks at them from the perspective of our organisation’s needs plus the needs of those we work with, internally and in other organisations. With a willingness to say ‘no’ to things on the ground of over-complication and risk/cost/benefit.

Another ‘negative’ issue that was emphasised when I worked as a lawyer was ‘privilege.’ For anyone not familiar with this concept, it’s a sort of immunity (going well beyond ordinary commercial confidentiality) from being forced by a court or investigator to produce evidence if it contains certain types of advice or assistance from a lawyer. Sometimes it’s used as an argument for getting lawyers to do things than could be done by other people. Frankly, not a relevant consideration for us at the moment, and to the extent it becomes an issue in future we’ll be taking external legal advice anyway. It’s a ‘tail’ which shouldn’t be allowed to wag the dog.

Category 2: what type of organisation can best meet those needs?

We’ve come to the conclusion that, in our company, to allow contracts to be led by a group with a traditionally-defined mission (e.g. ‘legal’ or ‘procurement’ or ‘HR’) is likely to lead to problems sooner or later. Not because people are ill-intentioned, but because there’s a lack of balance. 

I’m not quite sure exactly how this is going to evolve in our organisation. But we’re pretty convinced that 

1. Contracts are important and difficult enough that they’re best treated as a separate thing, organisationally, drawing on various types of input (legal, design, engineering etc) and serving various functions (sales, HR, operations etc).
2. It follows that they shouldn’t be a sub-thing of a legal function (if and when we have such a thing). That will likely throw off the balance we need to strike between input from perspectives such as business, finance, operations, design, sales, people/HR, engineering/data, process, niche regulatory expertise, and others. None inherently more important than the other.
3. Initially, as we’re still quite small, these inputs will largely come in on a part-time basis from people who have another ‘day job’ and we’ll continue to source some significant elements from outside the company.
4. I don’t think there is a single ‘core’ background that people will need to have to do well in this area. Success may involve starting off with some traditional knowledge/training in one of the areas I’ve mentioned, but combining it with a willingness to learn more about the other areas and perhaps unlearn some of the original domain ‘knowledge’ (or custom). It will definitely involve think effectively about relevant people’s needs and collaborating well with the other perspectives. We already work cross-functionally in our business so I think culturally we can do that in contract work as well, as we grow.
5. We’ll need a product owner-type role to ensure that an overall balance is achieved. Also a process coach (scrum master) or similar to get the continuous improvement thing really going.
6. We should seek to learn from what others have done and are doing, and there won’t be a clear end state – we’ll continue to evolve the thinking and approach on this. See what works and what doesn’t.

As the topic still seems very siloed in the world at large, I thought it might just help someone somewhere if I share the drift of my thinking on this.  I’d also welcome suggestions of what to consider further as we continue our journey as a business.

Acknowledgements

These thoughts have been forming for a while. Years, really. But I was prompted to articulate them in writing by some short pieces which I’ve come across randomly this week. Worth a look.

1. This short article by Alex Hamilton – his book about contracting (mentioned in the article) is also fantastically helpful. 
2. This piece by Richard Tromans on ‘contract operations’ – a more specialist ‘big company’ role, I think, than the sort of thing I’m envisaging for us in the near future, but certainly in the same general zone.
3. This short post by Joel Roy challenging the assumption that legal departments necessarily have a leading role in relation to contracts. 

Needless to say, none of them has any responsibility for the route down which this article has gone.

—

Photo: shared space in Groningen by Jannick Nijholt on Unsplash. If the relevance isn’t immediately apparent, see the Hans Moderman reference above!