Track 1: Process Encoding

Process encoding is the work of taking how your best people actually do something — the spec they write, the code review they run, the customer interview they conduct, the design critique they lead — and capturing it in a form that an AI agent can follow. Not a description of the process. An encoding of it.

This is the highest-leverage place to start, for three reasons. The work is visible — you can read the artifact and tell whether it’s any good. The payoff is fast — within weeks, more than one person on the team is producing more consistent output. And the practice teaches the team how to think about every other track in this Playbook.

What encoding is, and is not

Documentation describes a process for a human to read and interpret. Encoding creates a structure that an agent can execute against. The distinction is not academic.

Documentation says: “Consider performance implications of new database access patterns.”

Encoding says: “When introducing a new database access pattern, evaluate the query plan; flag any plan that requires a full table scan; check whether an index exists for the access pattern; if not, propose the index in the same change set.”

The first asks the reader — human or model — to apply judgment they may not have. The second tells them what to do, in what order, with what evidence. The first is a comforting platitude. The second is a procedure that produces consistent output regardless of who runs it.

Almost every wiki page in your company is on the documentation end of that spectrum. Almost none of your existing process documents are encoded. That’s the gap.

What an encoded process looks like

A good encoded process — call it a skill, a rule, a recipe, whatever your tooling calls it — has five components.

Trigger. When does this process apply? Be specific. “When reviewing a pull request that touches the billing module” is a useful trigger. “When doing code review” is not.

Inputs. What does the process need to start? The PR diff, the linked ticket, the relevant design doc, the prior review comments. List them concretely.

Steps. What does the process actually do, in order? Each step should be small enough that a person reading it could not misinterpret it. If a step requires judgment, name the judgment (“does this match the conventions of the existing module?”) and provide the criteria.

Outputs. What does the process produce? A review with these specific sections, a spec in this specific shape, a memo with this specific structure.

Failure modes. What does the process get wrong, and what should the operator (or reviewer) check before accepting the output?

A skill written this way is short — usually one or two pages. It is not a manual. It is a tight specification of how the work happens, written so that running it twice produces work product of similar shape and quality.

Where to start

Pick one process. Pick the one where inconsistency is most expensive.

For most product organizations, that’s the product spec. Specs vary wildly in shape, depth, and rigor depending on who writes them. The downstream cost of an inconsistent spec is enormous — engineers misinterpret, designers re-scope, customers get something different than was promised. A tightly encoded spec process turns this from a personality-dependent variable into a managed one.

For most engineering organizations, it’s code review. Different reviewers catch different things. The bar moves with whoever is on call. An encoded review skill — what to look for, in what order, with what depth — produces reviews that are consistently thorough regardless of reviewer.

For most support or success organizations, it’s the customer-issue triage process. Triage drives every downstream cost. An encoded triage skill that asks the right questions in the right order, captures the right metadata, and routes to the right owner saves hundreds of hours a quarter.

The right “first process” is whichever workflow your team is running with the most variance per operator. If you’re not sure, ask: “If we ran this workflow ten times with our ten best people, how different would the outputs look?” The workflow with the most variance is the workflow with the most opportunity.

How to capture it

Sit with the person who runs the process best. Watch them do it once. Then ask them to do it again, narrating what they’re doing and why. The narration is where the gold is — it’s the judgment that doesn’t make it into any wiki page.

Pay particular attention to:

• What they look at first, and why. Order matters more than people realize.
• What they skip, and why. Skipping is judgment too.
• What they check that nobody told them to check. This is institutional knowledge in its raw form.
• What “good” looks like to them. This is the implicit acceptance criteria.
• What “not done yet” looks like. This is the implicit definition of done.

Take notes. Draft the skill. Send it back to the practitioner. Iterate until they read it and say “yes, that’s actually what I do.” That moment — when the person whose tacit knowledge you’re capturing endorses the explicit version — is when you have an encoded process worth deploying.

How to deploy it

Get one other person to use it on a real piece of work. Compare the output to what the originator would have produced. Refine. Get a third person to use it. Refine again.

Resist the temptation to roll it out broadly before it has been used in anger by two or three people who are not the original author. The first version of an encoded process is always too dependent on context that lives in the originator’s head. The second and third uses will surface what’s missing. Roll out the version you got after that surfacing — not the version you wrote.

Once it’s deployed, do not assume it stays good. Every encoded process needs an owner whose job includes keeping it current. Without an owner, encoded processes drift from reality faster than they were created — usually within a quarter. With an owner, they keep paying back for years. (More on this in Chapter 5: Governance.)

What success looks like in 30 days

Thirty days from now, if process encoding is going well:

• One workflow has a documented, encoded skill that more than one person uses.
• The output of that workflow is visibly more consistent than it was a month ago.
• At least one piece of feedback from a downstream consumer has been captured and folded back into the skill.
• A second workflow has been picked, and someone is starting the same exercise on it.

That’s it. One process, encoded, used, refined, owned. That is the move from Level 1 to Level 2 on the most important workflow in your team. Repeat it on the next-most-important, then the next, and within a quarter you have a fundamentally different organization.

The next chapter — Track 2 — is about the structure that makes those encoded processes fit together. Encoded processes tell agents how to do things. Knowledge architecture tells them what things exist, and how those things relate to each other. Without it, every encoded process is an island. With it, the islands start to compound.