Why your fastest reviewer might just have the easy queue

Sort your contract review dashboard by average turnaround time and whoever sits at the top looks like your best performer. They might just be the person who keeps getting handed the renewals that were always going to close in a day.

Turnaround time is popular because it's easy to calculate: days from intake to close, averaged per reviewer. But an average day count says nothing about what was inside those days. A reviewer who closes five straightforward order forms in three days and a reviewer who spends three days on one master agreement full of third-party paper and a dozen playbook deviations get the same score on a dashboard that only counts contracts closed per unit of time.

Queues don't get handed out at random

Files land with reviewers based on who is free, who owns the account relationship, or who has the seniority to take the ugly one. Ordinary staffing, not a fairness scheme. But the reviewer who consistently draws the hardest contracts, often your most experienced person, ends up with a slower average than whoever mostly clears NDAs and renewal paper. Read the dashboard at face value and you reward an easy queue while penalizing whoever keeps getting handed the deals nobody else wants.

The complexity signal is already sitting in your data

You don't have to guess at which contracts were harder. Umbrex's guide to measuring contract cycle time lists complexity attributes worth tracking alongside timestamps: business unit, deal value, third-party paper versus company paper, clause deviation count, and playbook or fallback usage. Its interpretation guidance is direct about the effect: third-party paper, high deviation counts, and external counsel involvement typically increase cycle time, and if they don't, that's worth checking rather than celebrating. That's the piece missing from most turnaround dashboards. They capture the clock, not whose paper it was or how many things about it needed a second look.

Borrow the fix from a team that hit this first

Software engineering hit a nearly identical problem once AI coding tools let some developers ship far more code than others. Larridin's write-up on the shift is blunt about the failure: a developer who scaffolds five hundred lines of routine code in twenty minutes and a developer who spends three days fixing a race condition in fifty lines look wildly different on a commit dashboard, and the dashboard picks the wrong winner. Their fix, complexity-adjusted velocity, weights output by difficulty instead of counting it raw, so people working the hardest problems stop looking underproductive next to people doing simple, repetitive work. Swap lines of code for contracts closed and code difficulty for deviation count and paper ownership, and the same fix transfers well enough.

Build the bucket before you build the ranking

Sort every contract into a rough complexity tier before anyone reads it, using two signals you likely already have if you're running an AI first pass: whose paper it is, and how many clauses depart from your playbook. Something like this works as a start: low complexity is your own paper with zero or one deviation, medium is your paper with several deviations or clean third-party paper, high is third-party paper carrying multiple deviations or anything that triggers escalation.

Then measure turnaround inside each tier separately. A reviewer's average time on low-complexity files tells you almost nothing interesting. Their average time on high-complexity files, tracked over months, tells you whether they're getting faster at the hard stuff or stuck. Comparing two reviewers only makes sense once you know their tier mix looked similar for the stretch you're comparing.

Pulling paper ownership and a deviation count off every inbound contract is the same pre-read described in how to triage a contract intake queue, and once that data exists at intake, sorting contracts into a tier is a small extra step, not a new tracking project. It's a fair question to put to any AI contract review workflow: can it hand you the deviation count and paper type on a file, not just a pass or fail flag.

Don't turn the fix into a leaderboard

One caution worth keeping from the engineering version of this idea. Larridin's own guidance on the metric warns against using it to rank individuals, noting the value is in spotting patterns, like someone whose raw output looks low because they're handling the hardest work, and that it should drive a coaching conversation, not a stack ranking. The contract version holds just as well. A complexity-adjusted turnaround number is useful for noticing that someone's high-tier turnaround is creeping up, or that your team runs slower on third-party paper than it used to. It's a poor basis for deciding bonuses, and using it that way will just teach reviewers to fight over the easy tier.

None of this replaces looking at what actually happened on a slow file. A high-complexity contract that took two weeks might have simply been that hard. The tiering gives you a place to start looking instead of a number that ends the conversation before it starts.

Try goHeather free if you want to see what a first pass already pulls off your inbound contracts, deviation count and paper ownership included, before you build a tier system on top of it.

This is legal information, not legal advice; consult a lawyer for legal advice.