The gap
Spending on legal technology is rising sharply, and adoption of generative tools across large firms is now near-universal; and yet the clients paying the bills are not seeing the benefit, and they have begun to say so plainly. Thomson Reuters’ 2026 State of the Legal Market calls the result a “client value squeeze”: corporate legal departments have been running these same tools since 2022, they have developed their own sense of what a given task ought to take, and they are increasingly writing that expectation into their outside counsel guidelines. CLOC’s 2026 State of the Industry Report puts a number to the consequence — only 37% of legal departments expect their outside counsel spend to rise this year, down from 58% the year before.
The usual explanation is that adoption is simply lagging, and that with better tools, better training, and a few well-placed champions the returns will arrive in due course. That explanation strikes me as second-order at best. The tools largely work. What has not happened is the redesign of the work around them, and that failure, in my experience, has a particular and repeatable shape.
The friction lives between teams
In any professional services organization the expensive friction is rarely found inside a team. Teams optimize themselves; they have been doing so for years, generally without being asked, and they are usually quite good at it. The expensive friction sits instead in the seams between them — in handoffs, in the timing of notifications, in the gap between the moment one group learns something and the moment another group needs it.
That friction is, by its nature, invisible. Each team on either side of a seam experiences it not as a problem but as a condition: an upstream group that is slow, a downstream group that is unreasonable, a cost line that is simply what it is. Nobody experiences it as something solvable, because no one team can see both ends of it.
This is why intake fails, and why it fails so consistently. Most innovation functions run on requests — a form, a committee, a queue — and a request can only ever surface a problem that a team already knows it has, which excludes the interstitial ones categorically. A well-run intake process will fill a two-year roadmap with real, worthwhile, individually defensible improvements and never once touch the largest source of drag in the organization.
The organization chart will tell you who reports to whom; it will not tell you how work moves.
That second thing has to be discovered, and then maintained, because it decays.
Why the functions that already exist cannot do this
I want to be careful here, because the easy version of this argument is that the people currently doing this work are not good at it, and that is not what I mean at all. It is a charter problem.
A program management office is chartered against scope that somebody else defined, and it is measured on delivering that scope on time and on budget. The discovery work described below is unscoped by definition; it produces no deliverable for sixty or ninety days, and its most valuable output — a connection that nobody requested and, more to the point, nobody could have requested — cannot be forecast, committed to, or reported against. An office that spent a quarter on it would appear, by every metric it is judged on, to be doing nothing whatsoever, and would be cut long before the work paid out. A practice innovation or knowledge function, meanwhile, generates use cases but rarely controls the delivery capacity to act on them, and an information technology organization delivers what it is asked for, competently, against tickets and projects. Each of these is doing its job correctly. The seam between them is itself an instance of the problem.
There is a staffing pattern underneath all of this that is rarely named. Program offices tend to grow by depth: a manager is assigned to a large multi-year program, and when a second program arrives a second manager is hired to take it. The arrangement produces excellent single-program delivery and almost no lateral visibility, since nobody is ever inside two groups at the same time.
The office I work in grew both ways — the founding positions were depth assignments against major multi-year programs, while the roles added later ran several concurrent engagements across different sections and units — and everything in this paper came out of that second pattern. Breadth is what makes a seam visible, and breadth is almost never how these offices are staffed.
Discovery as capital
The proposition, then, is that an innovation office’s durable product is not its portfolio of projects but a living model of how the firm actually operates: who talks to whom, what is shared and what is siloed, where work waits and why. Projects are how that model is acquired, and how it is eventually spent. The distinction matters because it changes what the function is measured on and how it ought to be staffed. You are not funding a delivery shop; you are funding an asset that appreciates, and the projects are both the cost of acquiring it and the yield on it.
The method itself is unglamorous, and I would not claim any of it is novel.
I meet leadership individually, before there is a project to discuss, and I am explicit about the terms. I will not pretend to understand the nuances of your team’s work product — that is your expertise and I intend to rely on it entirely. What I do know is how systems, processes, and organizations fail at their boundaries. From there I want three things: how work moves through your group, what slows it down, and who I should talk to next.
I then meet the people those leaders name, which are generally the individuals with real control over a system or a process rather than the ones with the title suggesting it. I model their workstreams as products, I qualify what I hear against what I have seen elsewhere, and I build the map on the organization chart as a foundation and then draw the real edges over the top of it.
The findings get sorted by what it would cost to fix them, not by who asked.
Everything after that is ordinary delivery. Charters with purpose, scope in and out, milestones, risks, named personnel, and executive sign-off; a weekly internal cadence and a monthly report to stakeholders and leadership; regular contact with sponsors, and a standing request for feedback. None of this is new, and it is not supposed to be. Whatever novelty exists lies upstream, in what got selected.
What this looks like when it works
The point of the story is the sequence.
The map existed before anyone knew what it was for.
No requirements session with the discovery team would have surfaced this, for the simple reason that the answer was not in their building; and the mapping work was never funded on its own merits, having been a free byproduct of a delivery engagement that a conventional program office would have closed out and archived.
What it costs and what it returns
A candid version of the first year.
Leadership and practitioner interviews, the operating model map, and a qualified inventory of friction. What comes out of it is the map, a backlog sorted by tier, and two or three proposed starting portfolios for leadership to choose between. Visible output is thin by design, and this is the phase that requires a sponsor who understands what is being bought.
The first-tier items ship, and there should be a great many of them, alongside one chartered second-tier initiative. The purpose of the first tier is to buy credibility and to demonstrate that the map is real. Hours returned get measured, and so does where they land — capacity for fee earners is not the same thing as cost taken out of business services, and leadership should never have to ask which one moved.
One third-tier build, and at least one interstitial bridge that nobody requested. The second of those is the actual test of the function.
The standard should be anything whose measured return fails to materialize within a reporting cycle of the projection, and anything the sponsoring group has quietly stopped using. Every automation is a dependency the function then owns, and that maintenance load is a real budget line; a function that only accretes obligations will eventually lose the capacity to discover anything at all.
The measure of an innovation office is not how many initiatives it launched. It is whether firm leadership can now see how the firm works, and whether that visibility has been converted into capacity, cost, or client-facing value that someone can name and quantify.
What I have not solved
The candid version of section 5 is that the map survived because I carried it. It lived in my head and in scattered engagement documentation rather than in the function itself, and while that worked, it is precisely the fragility this paper is about. Had I rolled off the contract, the map would have gone with me and the storage problem would still be a storage problem.
Fixing it takes two moves, and the order matters considerably more than either move on its own.
The order is not negotiable, and I would rather say so plainly than be found out later. Point a model at a repository of charters, requirements, and status reports and what you get is a better search box; those artifacts record what was decided, not how work moves. Run it against the case in section 5 and it returns a case management replacement and a storage cost complaint as two unrelated projects, because that is what the documents say. It would not have found the bridge.
Nor, to be equally clear, has anyone yet built the version described here: the capture change is unimplemented, and the tooling exists only as small-scale prototypes.
Principal of Jackson, Morin & Co. He works on stalled programs, operating-model discovery, and the systems and data infrastructure that come out of it — across federal litigating components and privately held operators.
The seams are findable. Ask.
The first conversation is scoped, not exploratory. Bring a place where work reliably waits — a handoff, a cost line nobody can move, an initiative that has been funded twice. We will tell you honestly whether discovery would find anything, and what the first ninety days would produce.