Sit a founder down and ask them to write out how their business actually works, and you will get a document that is accurate and useless in equal measure. It will name the steps and miss the thing that makes the steps work. It will say "review the schedule" but not "spot the row that looks fine and isn't", because the person who wrote it has no idea they do that. It isn't a process to them. It's Tuesday.
That is the central problem with trying to industrialise a craft business. The value is locked inside people who cannot hand it over. Not because they're withholding it, but because they can't see it. Expertise feels like recognition. You just know a design code won't allow that, or that a creator is wrong for this brand. You can't ask someone to write down what they know, because what they know is mostly judgement, and judgement doesn't transcribe.
So stop asking. Watch what the expert does, and capture four things: their method, their judgement, their questions, and their red lines.
Start with the part the expert can describe: the sequence. Every craft business already has one, even if it's never been written down. An architect takes a brief, pulls house types from a library, checks them against the design code, generates options, and the client picks. A talent manager gathers a brief, finds the right creators, prices the deal, drafts the offer, and sends it.
That sequence becomes the workflow. In the engine it's a definition of steps, each with a name, a typed input, a typed output, and a number: how many minutes that step takes a human today. That number matters more than it sounds, because it is the baseline against which everything else is measured. You cannot claim a system saves time until you've frozen how long the work takes now. And the expert's own operating procedure, not a guess, is where that number comes from.
A real one: Pollard Thomas Edwards, an architecture practice, already automates its Schedule of Accommodation, a Revit-to-Excel table of every room and area in a building. The step they still do by hand is reconciliation: dropping the spreadsheet, checking it against the brief and the design code, and working out what doesn't add up. That manual judgement became a workflow of five steps: gather, read, validate, draft a "what doesn't add up" report, sign off. The legwork is the machine's. The sign-off is still theirs.
Now the part the expert can't describe. The sequence isn't the value. The judgement along the sequence is. So every point where a human would stop and make a call becomes an approval gate: the machine does the work, then stops and waits.
Notice what this does to the "will it replace me" fear. It inverts it. The expert doesn't hand over their judgement. They get promoted to the person who reviews it. A step only sheds its gate once it has earned it, by passing a scenario batch of a hundred cases and a replay corpus of thirty-plus approved decisions, then holding a spot-check floor. The gate is earned off, never switched off.
In practice this is where a professional-service business finally relaxes. The compliance check on a building runs through the regulations, flags the non-compliant clauses, and cites the exact text each finding came from. But the Principal Designer still signs off. In architecture that sign-off is legally load-bearing, post-Grenfell. "The sign-off stays human" isn't a limitation you apologise for. It's the reason a partner trusts the system at all.
Here's the part nobody writes down because it feels too obvious: the questions the expert always asks before they start. Which design code applies? What's the budget band? Which regulations? What's the goal of the offer?
Those questions are the expert's judgement made visible. In the engine they become a typed schema, the requirements the operator must supply before a run starts, not a free-text brief for the model to interpret. In the architecture example: client choices, the design code URL, the regulations to parse. In the talent example: the target, the goal, the pricing notes.
This is load-bearing for a simple reason. If you capture only the answers, the answers go stale. The expert who "just knows" what to ask is the one whose departure should frighten you most. Turning their questions into a schema is how you find out what they actually look at, because a requirement you can't turn into a field is a judgement you haven't understood yet.
The last thing to capture is negative knowledge: the things the expert would never let out of the door. Not "do a good job". The specific failures. A schedule that matches the brief perfectly must not produce invented discrepancies. A compliant design must not be flagged as non-compliant. A clean spreadsheet must not crash because a cell is empty.
Each of those becomes a scenario: an input with a known-good outcome, run against the step, with a failure threshold. The expert doesn't write down their standards. They write down what wrong looks like, and the system refuses to ship output that trips it. This is where craft gets genuinely preserved, because it's where the expert's instinct, "that feels off", becomes a checkable assertion.
You can't ask an expert to write down what they know. You can ask them what they'd never let go wrong, and watch what they do. And that's enough.
This isn't a way to get rid of expensive people. It's a way to stop being held hostage by them, including, if you're honest, the version of you that is the expert.
The founder reading this is usually that expert. You built the business on judgement you can't articulate, which is why it doesn't scale and why you can't step back. The point of the whole exercise is to turn what you do into something that runs when you're not in the room, with your judgement still holding the gates.
The whole point: you don't replace the expert, you industrialise them. The method becomes the templates, the judgement becomes the gates, the questions become the schema, and the red lines become the tests. Everything else, the drafting, the checking, the reconciliation, was never the craft. It was the tax on it.