A developer I worked with was handing over a project she’d spent the best part of two years building.
Gigabytes of code. Thousands of files. All of it working.
She pointed at one file, a few kilobytes of plain text, and told me that was the valuable part.
The README.
She wasn’t being modest. The code told you what existed. The README told you why it was like that: what had been tried and abandoned, which bit looked stupid but was load-bearing, where the thing would bite you if you touched it.
Anyone competent could rebuild the gigabytes. Nobody could rebuild the kilobytes.
Why this is worth actual money
Years ago I wrote and subedited for Alluxi Consulting, an independent business productivity consultancy. It was effectively my apprenticeship in business, because you cannot write for a knowledgeable audience on an expert’s behalf without properly understanding the thing first.
One principle from that work stuck harder than the rest.
A business should be staff-turnover agnostic, and independent of its critical person. Usually the founder.
It’s what an acquirer is checking for, and an investor too. They aren’t buying your people, because people resign. They aren’t backing your judgement, because judgement goes home at six and might not come back.
So the value has to move off the human touch and into documented procedure, charted territory, decision trees. The things that survive a resignation.
The warehouse test
I worked with Wholefood Earth, and the thing I keep returning to is how deterministic the operation had to be.
An order lands on the online store. From that moment there is a chain with no ambiguity anywhere in it. Which shelf the product sits on. Who on the warehouse floor owns that aisle. When it gets picked, how long packing takes, which parcel van is due and at what time, and how the stock count travels back to the front end of the store so the next customer sees the truth.
And upstream of all of it, replenishment. When to reorder each line, pre-empting both the sell-out and the use-by date, because with food both directions cost you money.
Every step prescriptive. Human action and data flow, both documented, both predictable.
Which meant we could forecast staffing and measure efficiency across the whole business. Not because anyone was clever on the day, but because the thing had been defined.
I look at most marketing companies and I don’t see anything close to that rigour.
Some of that is fair. Marketing carries real probabilistic variables: outside factors, immeasurables, things that can be sensed but never documented. Which angle will land. What the market will care about in March. You don’t put a decision tree on taste, and pretending otherwise produces worse work, not better. I’ve written about that failure mode at length as the McNamara Fallacy: what happens when measuring the measurable quietly replaces understanding the meaningful.
So the test is whether the task has a right answer. Budget pacing does. Campaign QA does. Which story earns attention does not. Automate the first. Protect the second. Know which one you’re looking at.
Get that boundary wrong and you don’t merely waste the effort. Systematise the probabilistic half and the system will dutifully optimise a proxy while the thing you actually wanted gets worse, which is the Cobra Effect and which is a great deal more common than anyone admits in a board update.
But a great deal of what agencies do daily is business as usual. Reporting, pacing, QA, publishing, briefing, onboarding. Determinate work, with right answers, done the same way every time.
And it is routinely run by extremely talented, extremely expensive multidisciplinary autodidacts. Not because the work needs them, but because nobody ever wrote it down beyond the critical person.
That’s the real cost of not documenting, and it isn’t untidiness. It’s your most expensive people executing procedure that someone earlier in their career could run to the same standard, while the judgement work only they can do sits waiting.
And the same mistake is now being made in software.
An LLM is a probabilistic process. That’s the whole point of it, and it’s why it can attempt work with no single right answer. But it is a generalist, and generalism costs. Every run burns tokens, and it can be confidently wrong about things that have a correct answer.
A deterministic process costs almost nothing by comparison. Ordinary processing power, no tokens, and the same answer every time.
I once built a tool that checks copy against a client’s own accumulated feedback. It runs on regular expressions. Putting a language model behind it would have meant paying per check to do a worse job of matching a pattern, and that cost would have compounded quietly for as long as anyone used it.
So the expensive multidisciplinary autodidact and the expensive probabilistic machine are the same problem in different clothes. Hand determinate work to either and you’re paying a premium for flexibility you don’t need. In both cases the fix is upstream: define the work, and something cheap and boring can do it.
AI doesn’t fix ambiguity. It launders it.
A vague brief used to produce a visibly vague output. Someone would frown at it and go back for a better question. The friction was doing useful work.
Now it produces something confident, fluent and well-formatted in eleven seconds. Same ambiguity, beautifully typeset. Nobody frowns. It goes out.
Which is why the firms getting real value from this aren’t the ones with the best tools. They’re the ones who already knew what good looked like, precisely enough to tell when they hadn’t got it.
That shift has an outward face too, which I’ve written about separately: whether your firm gets found and credited at all once machines are the ones answering the questions. This is the inward face of the same problem.
Most transformations start at the gigabytes
They buy the platform. They map the integrations. They book the workshop about the platform. Then around week six somebody sits down to configure it, has to answer “so what happens at this step?”, and four people give four different answers. All four are correct. That’s the problem.
They haven’t bought the wrong tool. They’ve bought a tool for something that doesn’t exist yet.
The order doesn’t bend. Define the thing, then it becomes repeatable, then it becomes worth tooling, and only then does it produce margin. Everyone wants to start at step three, because step three is the fun one and step one is a meeting.
What “not defined” actually looks like
It’s rarely as obvious as not knowing what you do. It shows up smaller.
You can’t write instructions for it. Try writing a how-to for “some brand work”. Not for lack of words. There’s no stable object to describe.
You can’t price it twice the same way. If two similar jobs get priced differently by two different people, you don’t have a process, you have a habit.
Nobody can improve it. The expensive one. You cannot optimise a shape that changes every time you look at it.
So the README isn’t the documentation. It’s the definition.
This is where the developer’s point stops being a metaphor.
Her README was worth more than her code because it held the reasoning: the thing that made the work continuable by somebody else. Not a record of what happened. A definition of what the thing was for.
That’s the artefact a transformation needs, and the one nobody schedules, because it doesn’t look like progress.
Two things make it happen anyway. Call it version zero: explicitly imperfect, dated, revised whenever reality changes, never an attempt at the definitive account. And make it an output, not an initiative, because documentation run as its own workstream competes with billable work and loses, permanently. The thing doesn’t ship without its README. That’s the whole policy.
For the determinate work, numbered steps are fine. Screen recording, list, done. For judgement work they’re a trap, because a step-by-step tells someone what you did and nothing about what you were weighing. So they can repeat the task and they cannot do the job.
Sixty-two steps make someone able to run this one. Knowing what was being weighed makes them able to run the next one.
Where to start
There’s a fair objection to all of this: what if the differentiator is the person, not the process? Documented method can reproduce the artefact without the judgement. You can’t argue past that, but you can test it. Have someone else run the process to the written standard and look honestly at what comes out. If it misses, you’ve learned exactly which part was the person.
Either way it starts in the same place, and it isn’t the tooling roadmap. It’s one sentence per thing you sell, specific enough that a competent stranger could tell whether a given piece of work sat inside it or outside it.
If you can’t write that sentence, you’ve found the real project. And you’ve found it before you spent the money, which is the cheapest time to find it.
The gigabytes were replaceable. The kilobytes weren’t.