Why do these decisions stall in partner meetings?
Because of what gets tabled. The typical paper asks the partnership to endorse an approach to AI, or to agree a budget for exploring it, or to appoint someone to look into it and report back. None of those is a decision. They are all invitations to have an opinion, and in a partnership everyone accepts that invitation.
Watch what happens next. One partner has used a chat assistant and thinks the whole thing is nearly free. Another read something about a negligence claim and wants counsel's view first. A third supports it in principle but not this year, because the office move and the new hires are already in flight. A fourth says nothing, then raises three objections in the corridor. The item is deferred, gently, and nobody has said no.
This is not partners being difficult. It is the predictable result of asking a group of equals to agree on something abstract, expensive-sounding and open-ended. The fix is not better persuasion. It is putting a different question on the table.
What are they actually disagreeing about?
Rarely the technology. Under the surface there are usually four separate arguments happening at once, and they get confused with each other.
- Money. Not the amount so much as the shape of it. Partners have been burned by engagements that started small and grew, and by licences bought for everyone and used by nobody.
- Risk. What goes to a client, who signs it off, what the insurer thinks, what happens to client data. These are legitimate and answerable, but they need answering rather than absorbing.
- Distraction. The honest objection that the firm's capacity to absorb change is already spoken for. Partners have watched systems land half-adopted before.
- Identity. The quietest one. If the write-up, the draft and the first-pass review are the work junior people learn on, what does the firm become? That deserves its own conversation, and we take it up in what changes for junior staff.
Separate these before the meeting and the discussion becomes manageable. Leave them tangled and every answer you give lands as an answer to the wrong question.
What does a decidable proposal look like?
One process. One fee, fixed in writing. One date it is live. That is the whole paper.
Naming the process is the hardest and most important part, because it converts an argument about AI into an argument about a job the partners recognise. Not "adopt AI in the disputes team" but "the attendance note and follow-up email after a client meeting". Not "improve reporting" but "the monthly client update that goes out of the management team". Everyone around the table knows what those jobs cost them, and they can picture the version where the job takes minutes.
Then put the current cost next to it, worked out from the firm's own numbers rather than anyone else's. Hours lost per fee earner per week, multiplied by the number of fee earners doing that job, multiplied by the charge-out rate, multiplied by forty-six working weeks. The guide to calculating unbillable hours sets out the method, and the unbillable hours calculator does the arithmetic. Show every assumption. A partner who disputes the charge-out rate can change it in front of the group, and that argument is far more productive than a general one about whether AI works.
The fee shape matters as much as the number. A fixed fee agreed before work starts removes the scope creep objection completely, which is why it is worth insisting on. We set out the difference it makes in fixed fee or day rates.
How do you answer the objections in the room?
Have the answers ready and short.
We tried this and nothing happened. Correct, and the reason is usually that a licence was bought instead of a job being rebuilt. A tool is not a process makes that case. Ask what actually changed about how the job was done. Normally, nothing.
The risk is unacceptable. State the review rule out loud: a named person reviews and signs off anything that goes to a client. AI drafts, people approve. That is the same control the firm already applies to a trainee's first draft. Pair it with a written position on data, and with a note to the insurer if that is the firm's practice, which we cover in AI and your PI insurer.
We have no capacity for a change programme. Agree, and then point out that this is not one. One process, the people who already do that job, four weeks. If it is bigger than that, it should be refused.
Let us wait and see. Waiting is a decision with a cost, and it is worth pricing it the same way you priced the process. Doing nothing versus acting now sets out what accumulates in the meantime. So does the fact that people are already using these tools quietly, without a policy, which is the argument in shadow AI.
Who should sponsor it?
A partner who loses hours to the process personally. Not the most technically curious partner, not the managing partner by default, and not the IT manager. Sponsorship by someone who feels the pain gives the proposal credibility no business case can manufacture, and it makes adoption likely, because the sponsor's own team benefits first.
Avoid the committee. Committees are good at collecting facts and bad at choosing between options, and an AI committee in a firm of this size tends to produce a document rather than a working process. Let a small group spend a fortnight counting and shortlisting, then hand one recommendation to the sponsor. The process priority scorer is a reasonable way to force a shortlist into an order.
What is the smallest first decision you can put to a vote?
Approve one process, at a fixed fee, live by a named date, in one team, with a review at the partners' meeting after go-live. That is reversible, cheap to be wrong about, and specific enough that a sceptical partner can agree without endorsing anything broader.
Define what success looks like before the vote, or the review will be a matter of opinion. Pick two or three measures: the time the job takes from start to sign-off, the proportion of drafts approved without substantial rewriting, and whether the team is still using it eight weeks later. Measuring return on AI sets out how to hold that line. Most failed rollouts fail for reasons that were visible at the decision stage, which is the pattern in why AI rollouts fail.
If you do not yet know which process to name, that is the gap to close first. Deciding well is mostly a matter of choosing the right job, and what to automate first and the audit both exist to answer that question with the firm's own numbers. Walk into the meeting with the job named, the cost of the current way of working shown, and one date. The vote takes ten minutes.