Someone comes back from a conference and opens the meeting with a direct, confident position and states: “We need Legal Ops.”
One person (with their camera off) hears intake, panel management, spend, knowledge, metrics and a reliable way for the business to get help. Anotherwho has just re-connected their sound again hears policies trapped in prose, decisions made manually and a pressing need to turn legal logic into a working product. A third missed everything becuase they just dropped a “BRB” in the chat.
As they all process the statement, they begin drawing the same problem from opposite ends of the Miro board (if we still use Miro).
This is usually where the argument about job titles starts. Is this Legal Operations? Is it Legal Engineering? Does it matter if the outcome is good?
I think it matters just enough. The disciplines overlap and the best teams let them overlap. Understanding where each one begins helps you put the right shape of team around a problem and makes it harder for a new tool to masquerade as transformation.
Legal Ops makes the legal function work. Legal Engineering makes the legal rules work.
Start with the thing being changed
Legal Ops looks at the legal function as an operating system. Work arrives from somewhere. Somebody has to triage it, assign it, complete it and show what happened. There are budgets, suppliers, projects, knowledge, people, risks and a business whose patience is not infinite.
The unit of change is the function: how demand moves, how work is organised and how the service improves.
Legal Engineering starts closer to the rule itself. What does the policy mean at the moment somebody has to act? Which facts change the answer? What data do we need? What should happen automatically, what requires legal judgement and what happens when the happy path breaks?
The unit of change is the legal logic: how it becomes a usable, testable part of a system.
Legal Ops
Designs and runs the legal function: demand, delivery, knowledge, suppliers, data, change and continuous improvement.
Legal Engineering
Translates legal intent into requirements, decision logic, data, interfaces, integrations and controls.
The seam
Where workflow, requirements, adoption and feedback meet. Most worthwhile problems live here.
That diagram is deliberately untidy around the edges. A Legal Ops team may have project managers, knowledge managers and automation specialists. A Legal Engineering team may bring together a lawyer, a business analyst and a software engineer. In a smaller organisation, one curious person may wear several of those hats before breakfast.
The mythical lawyer-developer-business-analyst hybrid appears in a surprising number of job descriptions. In practice, the work needs those ways of thinking to come together, usually across several people. Legal meaning needs delivery craft if it is going to become useful; software needs domain judgement if it is going to automate the right thing.
Follow one piece of work
Imagine the business wants a faster route through a common contract request.
Legal Ops begins by looking at demand. Who is asking? How often? What is genuinely standard? Where does work wait? Who owns the service? How will requests be prioritised, escalated and measured? What training and change will make the new route stick?
Legal Engineering opens the playbook. Which questions actually determine the route? Can the answers be expressed as structured data? Which clauses can be selected safely? When must a lawyer intervene? What needs to be written back to the contract repository, CRM or reporting layer? How will we test the result and recognise failure?
In practice, I have found that each view needs the other.
A team focused on the engineering may build an elegant contract tool that sits outside the way work really enters the department. A team focused on the operation may install a polished front door which still leads to an inbox and a manual legal decision. I have seen versions of both, and they rarely get us very far.
Together, they can create a service: a clear route in, legal logic that behaves predictably, data that travels with the matter, sensible fallbacks and evidence for the next improvement.
The work between the tools
The original sketch behind this article had Google, Slack, Wordsmith and Notion across the top, with automations moving work between them. That is a believable modern work surface: requests arrive in messages and forms; documents are drafted; knowledge is stored; automations carry information from one place to another.
A line between two boxes is a useful start. The service emerges when we work out what actually travels along it.
You still have to decide which event starts the workflow, what the source of truth is, whose approval matters, which data may leave a system and how somebody recovers when an integration fails. This is where Legal Ops and Legal Engineering become a particularly useful pair: one keeps sight of the service; the other makes the behaviour explicit.
The logos will change. But good intake, clear requirements, safe data movement, ownership and feedback tend to be evergreen. I would rather teach somebody to model a process and interrogate a rule, because those skills remain useful long after the button has moved in this year’s platform.
Then AI shortened the distance
AI has made this boundary much more interesting. A domain expert can now prototype a workflow, interrogate a policy, generate interface code or connect tools without waiting for a conventional development cycle to begin. That is definitely exciting!
It also makes it easier to produce something plausible before the problem is understood.
A prompt can get you surprisingly far. Production brings a longer list of questions: detailed requirements (both functional and non-fucntional if have your your requirements gathering chops), evaluation, permissions, data handling, review, fallbacks and the points where judgement must remain visible. A convincing answer is one part of that picture but it wont stand up to scrutiny from your executive team if it isn’t support by the whole canvas.
This is why I like AI training that reaches beyond collections of clever prompts. Remote’s free (like seriously do this training it’s A+) AI for Actual Work course moves from foundations and tool selection through workflows, agents and production. Anthropic’s prompt engineering guide is also useful because it begins with success criteria and testing. The words come later.
AI gives Legal Ops more ways to redesign the service and Legal Engineers more ways to build it. Knowing which job you are doing remains rather important.
A practical learning path
There are more courses here than anyone needs to complete. I would pick the resource closest to the problem in front of you and begin there.
If you need to make your everyday work better, start with applied AI and the systems your organisation already uses. If you want to understand why software behaves as it does, learn a little computer science and practise expressing instructions precisely. If you have a real workflow in mind, build the smallest safe version and observe where it breaks.
AI for actual work
Begin with outcomes, evaluation and the tools already close to legal work.
Learn how software thinks
Use these to practise decomposition, logic and feedback in a structured way.
Build with tools
Choose a small, real problem; protect the data; keep a human-visible fallback.
Which one do you need?
If the pain is fragmented demand, unclear ownership, uncontrolled spend, invisible work or poor adoption, lead with Legal Ops.
If the pain is a policy that cannot be executed consistently, a decision trapped in somebody’s head, data that cannot move safely or a legal process that needs to become a product, lead with Legal Engineering.
If the problem is important, you will probably need both.
The most interesting work happens along the line between the disciplines: operations shaping the requirements, engineering exposing what the policy really means, users showing where both were wrong and the system getting better each time around. The hand-off never quite becomes a hand-off, which is probably a good thing.
Start with the system you are trying to change. The title can wait.
Legal Ops and Legal Engineering are different jobs. They are also part of the same promise: legal work that is easier to access, safer to deliver and capable of learning from itself.