The partner who says no is usually right about something

Every legal innovation project has one. The partner who sits at the end of the table during the demo, arms folded, and says some version of “I don’t see us using this.” In the innovation team’s retrospective, they become a character: the blocker, the dinosaur, the cultural resistance that held things back. I’ve been in plenty of rooms where that partner was discussed as a problem to be managed around. Over the years I’ve come to a less comfortable view. The partner who says no is very rarely right about everything. But they are almost always right about something, and the projects that succeed are the ones that bother to find out what.

The blocker is a caricature

The story innovation teams tell about sceptical partners is flattering to the innovation team. It goes like this: the technology is good, the business case is clear, and the only thing standing in the way is an older lawyer’s reluctance to change. Adoption becomes a question of persuasion, or patience, or waiting for retirement.

It’s a convenient story because it puts all the error on one side. If the partner is simply resistant, nothing about the project needs to change. But that story is usually wrong in a specific way. Senior lawyers didn’t get senior by refusing everything new. They got there by being good at spotting where things go wrong, and that skill doesn’t switch off when the thing in front of them is software.

”No” is compressed experience

When a partner says no to a tool, they’re rarely giving you their full reasoning. They’re giving you a conclusion, compressed from years of watching things fail. They’ve seen the last three tools the firm bought sit unused. They remember the time a junior relied on a search result that turned out to be out of date. They know which client would be furious to discover a machine had touched their file.

None of that arrives as a structured objection. It arrives as “I don’t think this is for us”, which sounds like stubbornness and is often closer to a risk assessment delivered without the working. The job is to unpack it. That means asking the second and third question rather than countering the first answer. “What would worry you if an associate used this on one of your matters?” will get you further in ten minutes than any number of slides about efficiency gains.

Decoding the objection

Once you start unpacking, the objections tend to fall into a few recognisable kinds, and each one points at something real.

The risk objection - “what happens when it’s wrong?” - is a design requirement in disguise. It’s asking how errors become visible, how output gets checked and who is accountable. If you don’t have a good answer, the partner has found a genuine gap.

The economics objection - “this just means fewer hours” - is a pricing question nobody at the firm has properly answered. The partner is right that efficiency without a change in how the work is charged can make a team less profitable. That’s not resistance. It’s arithmetic.

The client objection - “my clients won’t accept this” - is a testable claim. Sometimes it’s true. Often nobody has asked the client. Either way, it deserves an answer rather than a sigh.

The workflow objection - “that’s not how we do it” - is, in my experience, the one most likely to be completely correct. Tools designed from outside routinely misunderstand how a particular team actually runs a matter. A partner who says the tool doesn’t fit is often telling you exactly where the tool needs to change.

Where they’re wrong

To be fair to the innovation team, the sceptical partner is not an oracle. They’re right about something, not everything, and their errors are predictable too.

They tend to generalise from one bad tool to a whole category. They weigh the risk of a new tool’s mistakes heavily while treating the existing process’s mistakes as normal, as if the tired associate doing it by hand at midnight never misses anything. And they often underrate the cost of doing nothing, because the cost of the status quo is spread thinly across hundreds of hours they never personally see. Taking the objection seriously doesn’t mean accepting the conclusion. It means separating the real insight from the overreach.

How to work with them

The practical move is to bring the sceptic in early and give them a real role. Ask them to choose the hardest test case: the matter where they’d expect the tool to fail. Let them define what failure would look like before you run it. If the tool survives their test, you have the most credible endorsement in the building. If it doesn’t, you’ve learned something important cheaply, before the rollout rather than after it.

Some of the strongest advocates I’ve seen for a tool started as its loudest critics, precisely because their concerns were heard and visibly addressed. A partner who helped shape the guardrails trusts the result in a way that a partner who was simply persuaded never will.

So the next time someone at the end of the table says no, resist the urge to write them into the retrospective as the villain. Treat the objection as data. Somewhere inside it is a requirement you missed, a risk you underweighted or a workflow you misunderstood. Find that, fix it, and you’ll often find the partner who said no becomes the one who makes everyone else say yes.