Mindset Is the Variable
Four moments across legal tech projects where tech doesn't determine success
👋 Hey there, I’m Hadassah. Each month, I share my take on how legal tech can support in-house teams — enabling the business, managing risk, and freeing up time for the work that actually matters. Grounded in real-world experiences from across legal teams, I cover what works, what doesn’t, and the patterns that show up again and again.
Before we dive in, a quick note: in this post, I discuss just a couple of examples of how legal teams solve operational bottlenecks. There are plenty of ways to approach these kinds of problems, and the right approach will always depend on your specific needs and context. My goal is to give you some food for thought as you define what this might look like for your team.
When a legal tech project doesn’t land the way it was supposed to, there’s a fairly predictable list of explanations that tends to surface: the vendor over-promised, the timing was off, stakeholders weren’t sufficiently aligned, the budget ran out before the project found its footing, etc. These things happen, and they’re not always wrong as explanations. But they’re rarely the full story.
Across the in-house teams I engage with through QuikWins, one pattern comes up consistently: the technology itself is almost never the decisive factor in whether a project succeeds. What tends to matter more is mindset. Not as a vague cultural concept, but as something specific and observable, that shows up at four distinct moments across the lifecycle of any legal tech initiative.
What’s worth paying attention to is that these moments are easy to miss precisely because they don’t look like mindset problems on the surface. They look like timing problems, communication problems, adoption problems. The underlying variable, more often than not, is the same.
Here’s what those four moments look like in practice.
#1 Before you start: Readiness is a cultural question—but it’s also a structural one
When in-house legal teams begin thinking about a new technology initiative, the conversation usually starts with evaluation. Which tools are on the market, what they cost, what similar teams are using. That’s a natural place to begin, and those questions matter. But they have a tendency to skip over something more fundamental, a question that doesn’t get asked nearly as often as it should: is the team actually ready to adopt anything new right now?
Readiness has several dimensions that are worth examining explicitly before going to market. Is the underlying process stable and documented, or is the expectation that the software will create discipline that doesn’t yet exist? Does leadership understand the problem well enough to visibly model the new behaviour, or have they simply approved a budget line? Is there any internal proof—even from a small manual pilot—to ground the ask, or is the team requesting investment in something that has never been tested in their environment?
But there’s a layer underneath all of this that tends to get even less attention: technical infrastructure doesn’t just shape what’s possible, it also shapes how teams think and behave.
In an earlier piece—Why Legal Tech Tools Shouldn’t Be Evaluated in Isolation—I wrote about the concept of stack gravity: the idea that over time, every team develops a natural centre of gravity within their existing tools. It’s where work instinctively begins, where documents actually live, where conversations happen, where people turn when something needs to get done under time pressure. And crucially, it isn’t just technically embedded, it’s cognitively embedded too. It defines habits, expectations, and what “normal” feels like across the business.
This matters for readiness because a new tool doesn’t enter a neutral environment. It enters one that already has a shape—a layered system of infrastructure, productivity tools, communication systems, and workflows that determine how work flows and where friction sits. Teams that evaluate new tools without a clear view of their own stack often find themselves several months post-implementation wondering why adoption never followed. The teams that tend to handle this well don’t just ask whether a tool will work, they ask where it will sit relative to where work is already happening, and whether that’s close enough to the centre of gravity for adoption to feel natural rather than forced.
Readiness, then, is both cultural and structural. It requires understanding your process, your people, and the environment those people are already operating within. That’s the foundation that everything else depends on.
#2 Getting the yes: Buy-in is a translation problem
The second moment where mindset tends to be decisive is when the team goes to make the case for investment.
Legal teams are usually thorough at this stage. The business case covers capacity constraints, manual process risk, compliance exposure, time spent on low-value work. It’s detailed and, more often than not, accurate. And yet it frequently doesn’t land in the way it was intended to—not because the argument is wrong, but because it’s being made in the wrong language for the audience in the room.
Legal teams tends to think in terms of capacity and risk. On the flipside of the coin, CFOs think in cost, CEOs think in revenue and growth, and Sales thinks in speed. The same tool, the same underlying need, presented in the language of whoever needs to approve it, can produce a completely different result. “Legal is overwhelmed with contract volume” is a legal problem. “Reducing contract turnaround time removes a documented delay from the sales cycle” is a business problem. Both can be true at the same time, but only one tends to land in a budget conversation with the relevant decision-makers.
A quick example of this in practice
The legal team at a large transportation company had no real visibility into what they were spending on outside counsel. Invoices were scattered across departments, costs were being misclassified, and bills were getting buried in inboxes. The team knew they needed a dedicated platform to bring it under control.
The first business case was rejected. Not because the problem wasn’t real, but because the timing was off—a new GC had recently joined, the organisation was still adjusting post-pandemic, and the proposal read, on the surface, like a back-office accounting project. The framing wasn’t helping: “legal spend management” signalled cost tracking, not strategy, and it didn’t land with the people in the room who needed to say yes.
On the second attempt, the team reframed the initiative as “outside counsel management.” The scope hadn’t changed. The tool hadn’t changed. But the frame had—and this time it signalled something strategic rather than administrative. They also ran a proof of concept with a small set of low-risk invoices ahead of the formal ask, giving leadership something concrete to evaluate rather than a projection. It got funded.
That’s not spin, it’s translation. And it requires a shift that doesn’t come naturally to legal professionals trained to be rigorous and precise: moving from making the strongest argument to making the right argument for the specific person who needs to say yes.
Sequencing plays into this too. Teams that approach leadership with a large ask before there’s any internal proof tend to struggle—not because leadership doesn’t understand the problem, but because they’ve seen tool rollouts fail before. That hesitation isn’t irrational, it’s pattern recognition built from experience. The most reliable counter to it isn’t a more detailed slide deck, it’s evidence from within your own environment: a manual version of the process, a no-code prototype, a pilot on one narrow use case. Something that demonstrates the approach actually works before the ask is made to scale it. Requesting investment for something that doesn’t yet exist is a request for trust. Requesting investment to formalise something that already works is a different conversation entirely, and it tends to produce different outcomes.
#3 After go-live: Adoption is not a project deliverable
Of the four moments, this one may be the most common and the least planned for.
A legal tech project reaches go-live. The announcement goes out, training sessions are scheduled, and there’s a genuine sense of progress. And then, gradually, it becomes clear that not much has actually changed. Lawyers log in once, click around, and quietly return to their existing habits. Business users email the lawyer they’ve always emailed rather than going through the newly shaped intake process. Invoice approvals sit untouched because nobody is quite sure it falls within their role to action them.
What’s easy to miss here is that this isn’t a technology problem. It’s a change management problem—specifically, the failure to distinguish between implementation and adoption. Implementation is a project: it has a start date, an end date, a scope, and a budget. Adoption is a behaviour change, and it has none of those things.
Building on the previous example…
The same legal team implemented their Brightflag as their chosen platform in just 32 days—a genuinely fast rollout, made possible by giving the project team day-to-day decision authority and looping in IT and Procurement early to clear compliance and security hurdles ahead of time.
Go-live, however, was only the beginning. Despite the initial buy-in, many lawyers logged in once, clicked around, and stepped back. Some didn’t see invoice review as part of their role. Others found the system’s behaviour unpredictable at first and quietly disengaged rather than raising questions. Group training sessions fell flat—the problem wasn’t information, it was familiarity.
What eventually moved the needle was a dedicated team member spending six months doing one-to-one coaching, walking individual lawyers through real invoice approvals until the process felt natural. Progress was uneven throughout the first year, but by the end, usage was steady, approvals were happening in a single click, and the data had become reliable enough to inform decisions. Their takeaway was direct: fast implementation does not mean fast adoption, and the two require different kinds of planning and execution.
The teams that handle adoption well share a few things: they plan for it before go-live rather than treating it as a post-launch problem; they design solutions that meet users in their existing environment rather than asking them to step outside it; and they set realistic timelines—in most of these examples, full adoption took six months to a year, not weeks.
If you’re scoping a legal tech project, add an adoption phase that’s at least as long as your implementation phase. Budget for it, assign ownership, and measure it separately from go-live. A tool that’s live and unused is not a success; it’s a more expensive version of the problem you started with.
#4 Building forward: The 80% mindset
The fourth moment is the one most deeply rooted in legal culture, and in some ways the hardest to shift.
Legal professionals are trained to be precise—to work through every edge case, to ensure something is right before it goes out. That instinct serves the practice of law well. When dealing with legal operations, however, it has a tendency to work against progress in a specific way: it can make teams reluctant to launch anything until it’s fully resolved, which means projects stall in planning while the operational problem they were meant to solve continues unchanged.
Another example to put this into context
The legal ops team at a large retail business was dealing with a volume problem that had no obvious fix. Their business relied heavily on external IT specialists for project work that couldn’t be filled internally. Every engagement required a compliance check under national labour law, to ensure freelancers weren’t being treated as employees. Legal and Procurement handled this manually, case by case. At least one new request came in every working day. Each took between 30 and 60 minutes of focused review, plus back-and-forth for missing information. Similar cases sometimes produced different outcomes depending on who reviewed them.
The legal team’s insight was that even though each case varied in context, the underlying legal criteria never changed. So they translated those criteria into a weighted scoring system—delivered through a yes/no questionnaire built in Microsoft Excel. Conditional formatting calculated a result: compliant or non-compliant, based on a predetermined threshold. Procurement could triage straightforward cases themselves; only edge cases escalated to Legal.
They didn’t wait until it was perfect. They launched it, watched how people used it, and found that friction wasn’t in the logic—it was in the language. Requesters were misreading the questions. So the team rewrote them, with input from the people who hired external consultants most often. Once the first version proved itself, they rebuilt the workflow using Power Automate and SharePoint—no IT involvement, learned through tutorials, staying within the governance constraints of the Microsoft environment already in place.
The harder shift, in the team’s own words, was cultural. Lawyers had to move from perfectionism to an 80%-first mindset. But once that shift happened, the workflow matured faster than it would have if they’d waited. Early adopters began proposing their own automation ideas. What started as a single compliance tool became the beginning of a legal function capable of building scalable operational systems—all from tools the organisation was already paying for.
That pattern shows up consistently across the teams that build most effectively. They launch something functional, gather feedback from real usage, and improve it from there. They look for what they can start with—using what they already have—rather than waiting for all questions to be answered and all conditions to be right.
The 80% mindset isn’t about lowering standards, it’s about recognising that learning happens in production. A workflow that’s live and imperfect generates real data. A workflow that’s perfect on paper generates nothing.
The pattern, made explicit
What these four moments share is that none of them are fundamentally about technology. They’re about how teams approach the work around the technology—how they prepare for it, make the case for it, sustain it after launch, and build on it over time.
Readiness before you start. Translation when you make the ask. Sustained change management after go-live. The willingness to ship before it’s perfect and learn from what follows.
The question worth sitting with: at which of these four moments do your projects most often stall?
Many thanks to the in-house professionals who shared their experiences and helped ground this piece in the practical reality of navigating the legal tech space in-house. Each edition of QuikWins is grounded in real conversations with in-house legal professionals. If your team has navigated a technology change—smoothly or otherwise—I’d love to hear about it. Reach out to me on Substack, or find me on LinkedIn.