Technology and process support: the rise of the lawyer-engineers

In this chapter, Dean Nash, General Counsel, Monzo, explores how hypergrowth companies do lawtech. The views in this article are the author's own, and do not represent the views of Juro nor those of CLOC.

Successful, mature, established, large corporations often handle their legal technology and process support a certain way. They know that legal is often seen as a cost base, so they set out to block that narrative. Hire a legal operations manager (or an external consultancy); map out all your existing processes, end-users and silos; spot pain points, bottlenecks and inefficiencies and see if you can disaggregate the work. Buy or build technology solutions that capture as many stakeholder requirements as possible to turbo-charge your efficiency gains, and for the discrete processes you want to get rid of, push them out to an alternative legal services provider (or indeed build and hire a lower-cost service hub internally).

White-hot growth is the only driver that matters, and it’s our job to move any legal issue that might distract from that growth out of its way

This is a tried and tested approach to technology and legal operations that succeeds at corporate legal departments all around the world. It can involve tough decisions, change management and long-term thinking on how legal and the business will align three years, or even five years, from now.

Here’s why we don’t do that.

Monzo grew to more than 350 employees and 850,000 customers in less than three years, gaining a full UK banking licence along the way. The early stages of hyper-growth at a startup bring fierce challenges, where the legal function’s focus cannot stray from growth and existential survival. We aren’t trying to build the legal team of the future; as the first lawyer, hiring the second lawyer took 30-40% of my time, and that’s an inefficient way to keep up with business demand. The time costs are just too great.

But that doesn’t mean we can get away with a legal function that isn’t optimised. White-hot growth is the only driver that matters, and it’s our job to move any legal issue that might distract from that growth out of its way. This is the same driver that fuels our product’s growth - and so it makes sense to align our way of working with the product engineers behind our success. They work in small teams, conducting small-scale tests, iterating, prototyping, picking winners and quickly discarding what doesn’t work. Development cycles of one to two months are the norm. To support, enable and react to what they create, we need to work in the same way. Here are two practical examples of how we use technology to do it.

Optimised contract management

It’s probably a fact of life that any company, at some point, has some duplicated or underperforming contracts. But going out to procure a contract lifecycle management solution isn’t something we have the bandwidth to do - more importantly, it might not be what we need right now, and what we need right now might not be what we need six months from now. Just like product, first we need a minimal viable proposition (MVP), to drive at least some value and help people to understand what the solution should do. Even a contract management spreadsheet would be better than nothing. So that’s exactly what we did at first; we used a google sheet to collect our documents, which let us see where our duplication points were. Just from that starting point, we reduced a significant chunk of unnecessary spend. The next step was to build in our service level agreements and review dates, iterating and testing to build on that MVP. We continue in that vein until we reach the edge of our internal capability; but by taking this approach we explicitly mark out our requirements for if we decide to procure a solution further down the line.

Build your own triage

Our outsourcing policy is simple and clear enough from a legal point of view. But the natural meaning of outsourcing is distinct from its regulatory meaning, which can be hard for non-legal colleagues to understand - creating the potential for confusion when they need help with procurement contracts. Instead of diving into documents, we do what our product engineering colleagues would do: start from the UX perspective, and build something. An employee has a problem, and they need help. So we built a visual resource in our internal knowledge hub, using natural language questions to lead the user: who are you partnering with? Is it a company? Is it a consultant? This leads them through a flow diagram that holds their attention, and narrows their request until it’s specific enough to be acted upon. We pin the weblink to that resource in our #contracts Slack channel, and run through an all-hands to show them the process. Within the channel they can request bespoke contracts or flag relevant queries, and we have sight of the whole process - without committing to a solution that might be superseded by our needs six months from now.

Legal design in action

Too much of the legacy software that powers huge chunks of the legal industry still falls down when it comes to being user-friendly

This way of working doesn’t come easily to everyone, and it doesn’t fit neatly with the change management approach that’s often needed at mature companies. Legal design is a concept that’s become more mainstream, thanks to pioneering work at places like Google and at Stanford University, but it’s still the exception rather than the rule. In all honesty, I haven’t seen very many well-designed legal products - too much of the legacy software that powers huge chunks of the industry still falls down when it comes to being user-friendly.

To work this way at Monzo, we need lawyers who are comfortable with technology, can handle agile working, and are user-friendly - meaning, as with so many things, hiring fantastic people is a big part of the battle. As time goes on, lawyers joining the workforce will be even less tolerant of bad UX, impenetrable resources and clunky systems. But hiring lawyers who can work like engineers helps us to do what our company expects us to do: keep our projects discrete, remove the distractions, and if anything impedes growth, find the best way to move it out of the way - fast. Through this approach to technology and process support, we can deliver a legal UX that’s as friendly as the product the company aims to deliver.