Monday morning, email arrives: “Can you send over an NDA? I need it today.” You find the latest template, make a few tweaks, and send it out. A few days later it comes back marked up. Someone reviews the changes, the business follows up, and nothing about this is unusual. It’s how legal work gets done.
But it raises a question I don’t often hear. What if none of this is the work we should be optimising? The goal isn’t to draft and negotiate an NDA. The goal is to make sure confidential information is protected. Those are not quite the same thing: the NDA is simply the means to an end.
The thinking that limits transformation
That distinction is where most legal transformation efforts stop. We map what the team does today, analyse what’s working and what isn’t, and prioritise the pain points. This matters, because in legal it’s the everyday friction that shapes how the business sees the function.
But look closely at the pain points. Almost every request is a moment where the business could have made the decision and didn’t. The template was on the intranet. The policy answered the question. The playbook covered the scenario.
These aren’t process problems. They’re decision problems. Either the business doesn’t feel equipped to decide, or it won’t carry the accountability for getting it wrong. So every question ends up with legal, including the ones that don’t need a lawyer.
So starting with current state is a good place to begin. It’s an increasingly bad place to stop. If you only optimise what exists today, you risk making a fundamentally inefficient model slightly more efficient. The problem isn’t volume, it’s that every workflow assumes a human must start it, run it and finish it. That’s a design problem.
From documents to decisions
So start from the other end. Not from today’s workflows, but from a blank page. What do you actually need to achieve? What does “good” look like in practice? What decisions need to be made, and by whom? What can go wrong, and how can you prevent it? When you ask those questions, the focus shifts. You stop organising the work around documents, templates and processes, and you start organising it around decisions.
Take the NDA example. The process today starts when someone emails Legal, but the real starting point is earlier, when someone decides to share confidential information with a counterparty. The trick is to catch that decision in a system, not in someone’s head. That trigger could be a sales opportunity moving to a stage where pricing or roadmap is shared, or a procurement intake form opened for a new vendor evaluation. Each is a structured event in an existing tool, and each can be configured to set the NDA workflow in motion: generate the template, route it for signature, and only involve Legal where the counterparty pushes back.
The shift is from “the business knows to ask Legal” to “the business does its job, and the system asks for them”. The document still exists. It’s no longer the centre of gravity, and the human is no longer the trigger.
Where the model really matters: compliance
NDAs are the simplest version of this. Compliance is where the model is stretched. Today, compliance is still largely built on the assumption that if people know the rules, they will follow them. So we write policies, run training, ask for attestations, and audit afterwards. The real moments of risk look very different. An employee is about to send customer data to a partner. A sales team offers a discount in a sensitive market. Someone logs a gift or expense that feels borderline. In those moments, no one goes looking for a policy. They make a decision. That’s where compliance actually happens, or fails.
Now imagine designing for that. Instead of relying on people to remember rules, you embed the rules into the flow of work. Here’s a case I worked on. A business needed the employees of each new service provider to sign a confidentiality undertaking before they got access to company systems. Checking those signatures ended up with Legal. The solution was to embed the requirement in the form the business already had to use to onboard the contractor and request the IT account. No signed undertaking, no email address, no system access. The trigger sat with the business, in the workflow they were going to use anyway. Signatures arrived faster, Legal didn’t need to get involved, and the audit trail was already built in.
Gifts can work the same way. A gift is logged through an expense tool, which already knows the value, the recipient and the country. The system applies the thresholds: below a certain level, allowed; above it, requires approval; in higher-risk scenarios, escalated automatically. When something isn’t compliant, the system doesn’t just block it, it guides. Reduce the amount, provide more context, follow a different route. All recorded and documented automatically.
The same pattern works in other situations. Data protection impact assessments are usually done at launch and then drift as use cases change. The fix is to trigger the DPIA at the point where new use-cases are conceived. Perhaps it’s the product backlog, a marketing campaign plan or a quarterly strategy review. Any work item touching personal data, profiling, biometrics, or automated decisions auto-opens a DPIA task. Development can’t move past that triage step until it’s complete. The privacy check sits inside the team’s own delivery process, not something an individual has to remember to do.
The shift is the same in each case. You move from “read the policy and apply it” to “make the decision, and the system helps you get it right”.
For a GC running a lean team, transformation stops being about doing the same work faster. It becomes about enabling the basics to happen without manual input, so the team can focus on different work altogether.
Three ways to get started
You don’t need a full transformation programme to shift the focus; you just need to look differently at what you already do.
- Identify the decision-heavy workflows. Where does your team deal with the same issue again and again? NDAs, vendor contracts, compliance questions, data-use assessments. These aren’t document problems, they’re decision problems.
- Capture the hidden playbook. Your team already knows what’s always acceptable, what’s never acceptable, and what depends on context. The challenge is that this knowledge lives in people, not in the system. Making it explicit is the first step to scaling it.
- Rethink the trigger point. Most legal workflows start when someone asks Legal for help, which is already too late. Look upstream: the CRM, the procurement tool, the product pipeline. That’s where the real decisions begin.
Where this usually stalls
So why isn’t everyone doing this? The objections I hear most often are cost and technology capabilities.
On cost, the usual response is “we don’t have the budget for a transformation programme”. You don’t need one. Identifying the decision-heavy workflows and writing down the hidden playbook is something the team can do in an afternoon. The trigger-point work, the bit where the system does the asking, happens as part of whatever system upgrade or implementation is already on the roadmap. The cost is whether Legal turns up to those conversations, not whether you fund a separate project.
The technology concern is “our systems can’t do that”. In practice they almost always can. The block isn’t the technology, it’s that nobody has written down what “good” looks like clearly enough for anyone to configure it.
A design problem, not a capacity problem
You don’t need to replace everything overnight. You need to question whether the way legal work is structured today is the only way it can be done. Most legal teams don’t have a capacity problem. They have a design problem. Legal doesn’t scale by working faster. It scales by working differently. Explore working differently.
