by Drew Winlaw
A few weeks ago the very excellent Stuart Barr posted an article entitled “the rise of the legal engineer”. It struck a chord with us here at Wavelength HQ.
I started my working life Down Under using technology, data, ‘lean’ process methods and teamwork to help troubleshoot problems and increase efficiency in the manufacturing sector. By a circuitous route I landed in the UK and trained and then practised as a commercial technology lawyer. But I hadn’t lost my allergy to over-engineered, inefficient processes. Unsurprisingly, the processes I found inside law firms and legal teams horrified me, but the big opportunity for me was that I was armed with a basket of skills to fix many of them.
Identifying myself as a legal engineer was something of an epiphany. I recognised many of the new law firm roles predicted by Richard Susskind in his book The End of Lawyers?. In time I gravitated away from practising as a lawyer towards troubleshooting and fixing processes for legal teams and the teams that support them. That transition started with basics like teaching someone how to extract data from a legal practice management system in the right format to reduce their downstream administrative effort. That was the tip of the iceberg, and after that a lot of my work started with the question “Why can’t we do that?”.
I am now using technology, data, ‘lean’ process methods and teamwork to troubleshoot problems in the commercial contracting process. A lot of my work involves designing and implementing systems that reduce duplication and use sensible automation in the right part of the process. Systems need to interact with humans in a ‘polite’ manner and help them achieve something more quickly or accurately with the system than without. Understanding data reliability, data cleansing and visualisations that mean something are all really important factors in great system design.
But that’s just me. I’ve been thinking more broadly about what makes a legal engineer and there are certainly different variants within the breed. For instance, some legal engineers have a deep focus on a particular technology or are especially adept at, say, low code platforms. Nevertheless, there are common threads. I reckon that if you have some combination of the following, then you may well be a legal engineer (and, until now you may not have even known it!):
- Legal training of some sort is a necessity but that doesn’t mean you need to be a qualified lawyer.
- Empathy is very important. Legal engineers straddle two different worlds, we need to talk to technologists and lawyers to help each understand the other and work together positively.
- Impatience is useful. You probably have a dissatisfaction with the status quo and find yourself asking “can we do this legal process faster, smarter, and who needs to be involved?”
- Bravery to start a pilot and experiment, together with energy to bring along others with that experiment.
- Imagination to evaluate a legal technology and project where it could be most useful, including how associated technologies may fit around it.
- Pragmatism. Legal engineers don’t always chase the newest tech. Sometimes it’s a matter of re-implementing existing tools, cleaning data sets and perhaps making clean data in old systems available to newer systems with enhanced capabilities.
- Inspired about how data can be transformed, curated and presented to help people digest information and/or make decisions quickly and with more confidence.
Fundamentally, a legal engineer probably has a constant nagging feeling that there must be a better way…
Does any of this sound like you? Here at Wavelength, we’ve decided that we want to be a honeypot for Legal Engineers. So, if you’ve had your Legal Engineering epiphany – please get in touch (but be warned, it might lead to an enthusiastic chat over coffee/lunch/beer with me!)