The thinking-to-typing ratio

I've been watching how solo GCs and lawyers on scrappy, lean legal teams work for the better part of a year now. My explanation for why they're perceived as slow is simple. They have a very high amount of effort per unit of output. In plainer terms, a very high thinking-to-typing ratio.

Let me explain it through one email. A GC gets a message from HR: a key hire is negotiating the non-compete clause and wants it removed, can we do that? The response the GC drafts will be 200 to 500 words at most. But what goes into drafting it is a complex dance of four distinct retrieval modes. Each one draws on different information. Each one degrades differently over time. And each one fails in ways that are invisible to the person waiting for the answer.

Retrieval Mode 1: Informed Retrieval

The GC reads the email and something fires. Not a fully formed memory, more of a directional signal. I think we've done this before. There was an employee, maybe last year, maybe the year before, who asked for something similar. I think we gave them the exception.

This is informed retrieval: a vague associative recall that tells the GC where to start looking. It doesn't give them the answer. It gives them a hypothesis about where the answer might live. And then the search begins.

The GC opens Gmail. What do they search for? They don't have the employee's name. They don't remember the exact timeframe. They try "non-compete exception" and get too many results. They try the name of the hiring manager they vaguely associate with the negotiation and get nothing relevant. They scroll a folder of executed contracts, scanning file names, trying to jog loose the memory that started all of this.

This is the most fragile of the four modes, because it depends entirely on one person's associative memory. The hypothesis might be correct. There really was an exception. But the path from hypothesis to artifact is unstructured, unsupported, and entirely manual. It's the GC brute-forcing their own memory through trial-and-error queries.

And here's what makes it consequential. The GC knows the precedent exists. They know there's a contract somewhere in the workspace that would ground their response. But they can't find it. After thirty minutes of searching, they face a choice: keep looking, or move on and draft from judgment alone. Most of the time, they move on. Not because they're lazy, but because there are nine more emails behind this one.

The failure mode of informed retrieval isn't that the GC forgets. It's that they remember just enough to know they're giving an inferior answer by not finding it, and not enough to actually locate it. That's a uniquely frustrating kind of failure!

And when this GC leaves, informed retrieval doesn't just degrade. It vanishes. The next GC reads the same email, has no associative signal at all, and doesn't even know there's a precedent to look for. They treat it as a novel question. The institutional knowledge isn't lost in the dramatic sense of a database being deleted. It's lost in the quiet sense of nobody knowing it was there.

Retrieval Mode 2: Precedent Retrieval

Precedent retrieval is different. It's not "I think we did this before," it's "what is our position on this?" The GC isn't hunting for a specific past event. They're looking for an organizational stance.

Do we, as a company, enforce non-competes aggressively? Do we grant exceptions regularly? Is there a standard clause we use, and how much flexibility do we allow around it?

In a well-documented legal function, this lives in a clause library, a contract playbook, or a policy memo. In most lean legal teams, it lives nowhere explicitly. It's implicit, distributed across the last twenty employment contracts, each one a slightly different data point on the company's actual position.

So the GC reconstructs the position inductively. They pull up recent contracts and check the non-compete clause in each. Are they identical? Mostly, but two of them have modifications. Were those intentional policy shifts, or one-off accommodations? To know, you'd need the email thread behind the redline. Which puts you right back to searching Gmail with imprecise queries.

Precedent retrieval fails differently from informed retrieval. It doesn't fail because of memory. It fails because the precedent was never consolidated. Each contract is a standalone artifact. The pattern across twenty of them, the actual position, has never been extracted and stated anywhere. It exists only as a statistical regularity across documents nobody has read side by side.

This is the failure mode that produces inconsistency. When the GC can't efficiently survey the full set of precedents, they work from a biased sample: the three or four contracts they happen to remember or can find quickly. If those happen to be the exceptions rather than the standard, the GC might characterize the company's stance as more flexible than it really is. Two GCs looking at different subsets of the same contracts could reach genuinely different conclusions about what the company's position even is.

And the playbook doesn't solve this. A playbook captures the position as of the day it was written. Three months and four exceptions later, the playbook says one thing and the actual body of contracts says something subtly different. Now you have two sources of truth that disagree, and the GC has to decide which to trust, which means they're back to reading contracts anyway.

Retrieval Mode 3: Contextual Reasoning

This is the mode that makes legal work fundamentally human, and fundamentally hard to systematize. The GC has read the email. They know a key hire is negotiating the non-compete. But the response doesn't depend only on the legal merits or the company's precedent. It depends on context that lives entirely outside the legal function.

How key is this hire? Is this someone the CEO personally recruited? Has the company been trying to fill this role for nine months? Did three other candidates turn it down? Is losing this person over a non-compete going to create a real problem, not a legal problem but a business problem?

This isn't legal analysis. It's organizational intelligence. And the GC either has it or doesn't, depending on how plugged in they are to the company's priorities. A GC who's been here three years and sits in on leadership meetings knows the CEO has been obsessing over this hire for months and will be furious to lose the candidate over a clause the company barely enforces. A GC who joined six weeks ago sees an employee negotiating a contract term and applies the standard position.

Both might be excellent lawyers. They'll give meaningfully different advice, not because of legal skill but because of information asymmetry about what the business actually cares about.

Contextual reasoning degrades with organizational distance. The more removed the GC is from operations, the fewer meetings they sit in, the less visibility they have into what leadership is prioritizing, the more their responses default to pure legal analysis. And pure legal analysis is correct but often useless. Telling HR "our standard position is to enforce non-competes" is legally sound and practically worthless if the CEO already promised the candidate flexibility over dinner.

The information that fuels contextual reasoning lives in Slack threads, in offhand comments during all-hands, in a text message between the CEO and the head of HR. It's the least structured, least retrievable, least durable form of organizational knowledge. And yet it's often the single biggest factor in what the GC actually recommends.

Retrieval Mode 4: Risk Calibration

The GC has now gathered their associative memories, surveyed the company's precedent (or their best reconstruction of it), and factored in the business context. The last step is risk calibration: mapping all of it against the actual legal landscape.

California doesn't enforce non-competes. If this employee is based there, the clause is unenforceable no matter what we've done historically. If they're in New York, it's enforceable but only within specific parameters. If they're in Colorado, recent legislation restricts non-competes for employees below a certain salary threshold.

This is where deep legal expertise meets jurisdictional specificity. And it's where the failure mode is most dangerous, because getting it wrong doesn't just produce an inconsistent answer, it produces a legally incorrect one.

For a GC managing employees across multiple states or countries, this step requires a current mental map of rapidly evolving law. Non-compete legislation alone has shifted in over a dozen US states in the past few years. The GC either stays current, through CLEs, legal newsletters, and peer networks, or operates on an outdated model of the regulatory environment.

The knowledge debt here is especially sharp. There's no internal memo saying "non-competes are unenforceable in California." Why would there be? The GC knows it. It's obvious to them. But when a new attorney joins, or when HR in a satellite office drafts an offer letter from a standard template that includes a non-compete for a California-based hire, that undocumented gap surfaces as a real legal risk. The company now has an unenforceable clause in a signed contract, one that may have influenced the employee's behavior under false pretenses.

Risk calibration is the one mode where external information matters as much as internal. The other three are about finding what the organization already knows. This one is about ensuring the organization's knowledge is still accurate against a shifting outside reality. It degrades not through information loss but through information staleness. The world changes and the workspace doesn't reflect it.

Knowledge Debt

These four modes, informed, precedent, contextual, and risk, combine to produce the thinking behind a 200-word email. The effort is invisible to the person waiting. HR sees a six-hour turnaround on what felt like a yes-or-no question and concludes legal is slow.

But the real problem isn't speed. It's that every one of these retrieval steps is accumulating debt.

The legal function is always under pressure, and the artifact of that pressure is a compounding knowledge debt. There's no memo about non-competes in California. There's no consolidated view of which exceptions were granted and why. There's no record of which hires the CEO considers critical. The cost of formalizing and encoding knowledge is high compared to the immediate perceived benefit, so the GC answers the email and moves on. The encoding never happens.

Meanwhile the workspace keeps getting informationally richer. New contracts arrive, each redlined, and the reasoning for each redline is buried in someone's chat or email thread. Every decision made without documentation is deposited into the debt. The GC who once had a one-hour turnaround is now taking a full day. Not because they got slower, but because the search space exploded while the indexing stayed the same: crude self-organization at best, one person's memory at worst.

So it's time to write a playbook. The GC spends a day and a half writing one on how to respond to an employee negotiating a contract. Three months later, twelve people were hired, four exceptions were made, and HR comes back with the same question. The playbook says one thing. The last four contracts say another. A playbook is, after all, a static snapshot of a dynamic, ever-evolving system.

Why Legal Is Structurally Different

As a software engineer, I also have a high thinking-to-typing ratio. But my retrieval is fundamentally different. I break large blocks of code into smaller, comprehensible modules. I optimize for readability and drop inline comments that help me retrieve the reasoning later. My work product is designed for future retrieval. Not as an afterthought, but as a core engineering practice.

Legal is different because its retrieval sources are the final steps in the lifecycle of other departments. Contracts are the output of sales, procurement, or HR, not reference documents. Email threads are communication, not knowledge bases. A lawyer doesn't have the luxury of splitting a sixty-page contract into well-indexed modules, or of structuring it for retrieval the way I structure code. The information architecture of legal work is accidental, never intentional.

The contract is the output. The email thread negotiating it is where the reasoning lives: why a clause was softened, what the business justification was, what risk was accepted. But email is the worst possible medium for institutional knowledge. It's siloed to its participants, unsearchable by concept, and it decays as people leave. The most valuable knowledge in the legal function lives in the worst possible container.

The Double Curve

At 20 employees, the GC knows every relationship personally. At 100, they remember the important ones. At 300, they're mostly running on fragments and gut feel. But here's the part nobody talks about. Query volume scales with headcount too. More employees means more employment questions, more vendor contracts, more compliance surface. So you get a double curve. Retrieval cost per query rises while query volume rises alongside it. Plot those two mentally and you can see why legal teams hit a wall at such a predictable stage of company growth.

The Workspace as Playbook

The entire concept of the playbook was a workaround for poor retrieval. The workspace already contains the knowledge: the signed contract with the softened clause, the email thread explaining why, the redline exchange with outside counsel. It's not missing. It's scattered.

What legal teams need isn't a better playbook. It's a workspace where the playbook is an emergent property of the work itself, continuously derived from the actual artifacts of legal decisions rather than a separate document someone has to write and maintain. Not a static snapshot, but a living, queryable representation of every position taken, every exception granted, every reasoning chain, updated not by deliberate effort but as a natural consequence of doing the work.

Confidence Breeds Opinionatedness

When retrieval surfaces the actual precedent, the specific contract where the exception was granted, the email thread with the reasoning, the output shifts from hedged ("you may want to consider…") to decisive ("we've granted this exception twice before under similar circumstances; here's my recommendation"). This holds whether it's a human GC or an AI system drafting the response. Weak retrieval produces cautious, generic advice. Strong retrieval produces advice that takes a position. And taking a position is what the stakeholder actually needed.

Consistency becomes automatic rather than effortful. Right now, staying consistent across legal positions is a memory task. The GC has to remember what they said last time. With strong retrieval, consistency becomes a byproduct. The system surfaces the last three times this question was answered, and deviation from precedent becomes a conscious choice rather than an accidental drift. The GC stops quietly contradicting themselves across a twelve-month span.

That's the whole shift. Not a faster lawyer, but a workspace that remembers, so the thinking-to-typing ratio finally starts to fall.