When I first started working in law as a paralegal, a large part of my job was not related to giving advice but ensuring that the procedural steps throughout the matter were executed correctly. This work was given at the direction of the partner or senior associate. I learned a lot about what good advice looks like but also how to deliver it.
The procedural work looked like:
- completing tax forms
- preparing first drafts
- preparing client bundles accurately
- checking documents were executed correctly
- formatting (oh my god the formatting)
It wasn’t all on me either, secretaries picked up dictation; the post team sealed, stamped and tracked outgoing mail; deeds clerks made sure document were stored and records updated. Looking back, everything worked.
Nostalgia is a helluva drug.
In the first decade of my career, we aggressively dismantled the machine. Emails took over from post so lawyers typed their own (largely because they couldn’t figure out delegate permissions in Outlook). Some documents could be digitally signed, or worse, signed-scanned-and-emailed back (yuck). The impact of email meant the cadence of inbound mail, review then reply got shorter and shorter. Client expectations rose too.
Then came instant messaging followed by client portals (most of which sucked). But the expectations went higher as everyone moved online. FinTech got a lot of this right with cleaner KYC processes, superior mobile apps and dashboards that mattered. Maybe the incentives helped there too with banks and others driving down costs and benefiting from speed - the same incentives don’t always sit well with law firms (we’ll come back to this). My own frustrations were boiling over.
About 10 years ago I made a conscious choice to pivot into legal engineering. It wasn’t very well defined then but there were pockets of enthusiasm, curiosity and a growing number of stubborn souls who wanted to try. I started going to events where developers hung out both in real life and online to understand how machines are built in a digital world. Between coding on my lunchbreaks and setting up my own document automation instances, I got excited enough to write about Why Lawyers Should Make Good Developers in 2018.
A little while later I landed my first role as a legal engineer and continued building. It was slightly “undefined” work (which is where the inspiration for my github tag line came from) but it was impactful. I worked with some brilliant lawyers and marketers and built websites, pipelines and dealt with a lot of system integration work - I learned how to make things work.
I learned how to make things work.
Requirements
One of the best things I did then was take a course in Requirements Engineering. It taught me how to build process maps, model relationships, define schemas and scope work well. It gave structure to things we do intuitively, which is valuable because it then allowed me to layer the correct language and terminology onto what I need to ask to keep moving. Most problems have been encountered before and have patterns you can re-use to solve them. It’s never been more apparent with vibe-coding / agentic engineering that knowing what to ask is the key differentiator between ideas that live or die.
So what do Legal Engineers actually do?
Legal Engineers translate policies into processes and engineer processes into systems.
Policy
Intent, duties and risk expressed as an organisational position.
Process
Steps, roles, decisions and fallbacks that turn intent into repeatable work.
System
Tools, data and controls that make the process usable, observable and scalable.
Policies are how lawyers codify and articulate legislation or internal positions into something actionable that enables the business, anchors compliance and manages risk.
Processes are procedural steps for what should happen in order to follow the policy (the TO-BE Happy Path) and should compare to the current state (AS-IS) and account for deviations, errors and graceful fallbacks.
Systems are where the steps are taken and are, more often than not, multiple systems. There is often an element of novelty, or rather, adaptation to your company’s tech stack. Being able to design systems integrations and allow interoperability between platforms is engineering work and where the policies break out of being a human, read-only document.
It helps significantly to have a solid understanding of law in order to translate the policies. Better still, good process design should feed back into the policy itself so they converge on something pragmatic. Many legal engineers start as lawyers who learn the engineering principles, but increasingly engineers are turning to law as there is a huge amount of innovation, promise and hope to fulfil.