In five weeks I turned them into a system that makes decisions with my judgment in 8 out of 10 cases on the first attempt.
A note: in this case I am both the expert and the architect. I publish it because it demonstrates the complete process, including what broke along the way. Not because it's the best proof of Encode. The best proof will be your case, where I'm only the architect.
And a reading instruction: I was what your company calls the top performer. The one who solves what nobody else can solve, and can't explain how. Read this case with the face of your best salesperson, your head of operations, or the technician with fifteen years in. The story is the same. Only the name changes.
I sold enterprise technology for 20 years. Vodafone, Factorial, Personio, Typeform. Five- and six-figure deals where every judgment call moved the outcome.
Over those years I built three methods of my own:
For decoding what a client is thinking when they say "let me think about it." Four dimensions: what they say, what they want, what they fear, what they believe.
For assessing whether a deal is real or I'm wasting my time. No hope, only evidence.
For obtaining sensitive information without asking direct questions that raise a client's defenses.
Each method worked on its own. The real value was in combining them. The decision to "switch from qualification to mental analysis right now, because the client just said something that reveals a fear" wasn't written anywhere. It lived in my head.
I could explain each method. What I couldn't explain was when to use which, or how to combine them.
I tried for years. Manuals that were never finished. Training where people understood the theory but didn't apply it the way I did. A ChatGPT trained on my materials that sounded like me but didn't think like me.
From my own notes during the process:
"My biggest frustration was that I couldn't encode it. Whenever I put it on paper it came out incomplete. Some parts were left unfinished. Others I did communicate weren't understood correctly." That's the 70% Rule, in my own case.
If this happened to the expert trying to transmit himself, with every interest in succeeding, imagine what gets captured by the onboarding manual your company wrote about someone who, on top of that, has better things to do.
After years of failed manuals, I understood two things:
First: documenting and encoding are not the same. Documenting is writing down what you know. Encoding is writing down what you decide when something happens. "If the client says X, I do Y. If Z happens, I do the opposite. If something shows up that fits no rule, I stop and ask."
Second: my three methods weren't three files. They were a single system with parts that activated in sequence depending on what was happening in the conversation.
That second thing is what I had never been able to write down. Because I didn't know it consciously. I executed it.
The project that follows is what happened when I tried to extract it.
What follows is what happened in my own case. It is not the manual for how a Diagnosis, a Build, or an Expertise OS is done. That lives on another page. Here I tell what I learned when the method was applied to itself.
I started with the most uncomfortable question: when do I use each method, and why?
The specific difficulty of this case: when you're the expert and the architect at once, your confirmation bias is the biggest risk. You tend to document what you think you do, not what you do. That was the first evidence I had of why the manuals I'd written before came out incomplete.
The result of week 1 was a map. Not three separate files, but an architecture with seven connection points between methods and nine distinct situations where I activated one or another. Those numbers had never been written down. They were intuition.
That's what Diagnosis delivers today: the Critical Judgment Map. The part of your expert nobody has ever seen in writing, starting with them.
To force the decisions I made automatically, I needed scenarios that gave me no time to rationalize. The difference between asking:
"What do you do when a deal stalls?"
And putting this on the table:
"Your deal has been stuck for 3 weeks. Your internal contact isn't responding. The forecast review is Friday and your boss is asking whether to include it as committed."
The first produces a textbook answer. The second produces the real protocol.
In this case an outside collaborator ran it, not me. It was the only way to neutralize the bias. If I questioned myself, I knew the answers. With someone else applying the pressure, out came the decisions I actually make.
In your company, that outside witness is me. Your expert can't self-extract, and whoever works with them daily can't do it either: they know the textbook answers too well.
Out of that came nine complete protocols, and the seven connections between methods were documented for the first time.
Three layers:
The Decision Engine reads the situation and decides which protocol to activate. The user describes the case in plain language. The system chooses.
The Rules and Exception Matrix hold the detailed logic of each method and the cases where the normal rules don't apply. This is what separates your expert's way of working from any generic template in their industry.
The Operating Instructions explain how to use it. One page. Three steps. Written for the team, not for the expert.
I ran the system through ten real situations. The question wasn't "is this reasonable?" It was: is this what I would have done? Not similar. Identical.
Eight out of ten passed on the first attempt.
The two that failed are the ones I cover in the next section.
I expected more to fail. That only two out of ten needed correction surprised me. And it confirmed something I had never written down: the extraction process had captured more than I thought I had documented.
But those two matter more than the eight that passed.
A deal where two of my principles were in conflict: qualify aggressively to avoid wasting time, and keep the conversation open to avoid closing prematurely. The system didn't know which to prioritize. Live, I decide it without thinking. But the rule governing it wasn't written.
A situation where the client said something that triggered an information elicitation protocol, but the context called for pausing that protocol and switching to mental analysis. The transition wasn't encoded because, until then, even I didn't know I made it.
I corrected them. I retested them. They passed.
That's the kind of judgment that only comes out under pressure. You don't discover it writing documentation. You discover it when something breaks the rules.
So this case doesn't end up being just claims about what the system does, what follows is one of the eleven auditable rules of the Decision Engine, quoted exactly as it's written in the file.
MEDDICC tells you what information is missing to qualify a deal. But asking directly "who decides?" or "what's the budget?" puts the contact in interrogation mode and reduces future access.
For each MEDDICC element pending validation, the system selects the corresponding elicitation technique:
Exception: when rapport is established and the topic isn't sensitive (more than three interactions, an informal conversation in progress, or the contact has already shared delicate information), direct questions are acceptable. Elicitation is the primary method in early interactions, not a universal prohibition.
That specific rule, in my head, was an instant, unformulated decision. In the file, it's fourteen auditable lines any model can execute.
The difference between what I thought I did and what I do is exactly that. And that is what gets encoded.
Now think about your sales director's Rule 7. It exists. They apply it every week. It isn't written anywhere. Every expert carries 8 to 30 rules like this one. None of them are written down.
| Before | After |
|---|---|
| 45-60 minutes to diagnose a deal | Under 2 minutes |
| 3 isolated methods, each on its own | 1 integrated system |
| 0 documented protocols | 9 complete protocols |
| Connections between methods only in my head | 7 documented connections |
| Tacit, invisible rules | 11 auditable principles |
Three months of daily use: deal reviews in two minutes where I used to need forty-five. Meeting prep documented and reproducible. Stalled-deal diagnosis that proposes a concrete action based on the real blocker, not "follow up."
Is it perfect? No. There are situations where my human intuition adds something the system doesn't capture. But in eight out of ten cases, the result is the one I would have given. Those eight free my time to focus on the two that require live judgment.
And that's the arithmetic that matters in a company: the engine doesn't replace the expert. It takes the eight out of ten cases that don't need them off their plate, and makes their judgment available to whoever doesn't have it yet. The new salesperson doesn't wait 18 months to think like the veteran: they consult how the veteran decides from day one.
The first architecture was three methods, nine protocols, and seven connections. Today the engine is on version 4.1: five methods, eleven protocols, and nine connections.
After those five weeks I added two more methods. And this time they weren't mine: a teaching-based selling system and a complete objection-handling system, with its own sequence (prevent, qualify, triage, respond). Other authors' methodology, connected to my own.
Neither expansion required rebuilding anything. The new rules connected to the existing ones, the seven original connections remain intact, and the entire system was recalibrated against the full battery of test cases: 53 out of 53. Live proof of the third guarantee: the system recalibrates when something changes. Here, what changed was the judgment itself.
That's the difference between documenting and encoding, measured over time. A manual gets rewritten every time the judgment changes. An encoded system gets extended. And an engine that absorbs other people's methods without breaking can absorb your second key person's, and your third's.
In companies, that mechanism has a name: Expertise OS.
After this first architecture I applied the same process to four published bodies of work in the Spanish-speaking world: luxury, copywriting, B2B sales, and high-impact communication. I worked from the authors' published material, with no business contact with them. The goal was to audit whether the architecture held other people's judgment as cleanly as it held mine.
Every one passed the same threshold: eight out of ten decisions replicated correctly.
There is nothing special about an enterprise salesperson's judgment. It's judgment: conditional decisions made under pressure. Your head of operations', your technical lead's, or your best salesperson's can be extracted with the same mechanism.
That's why Encode now works with companies.