Amelia Bedelia was a housekeeper who followed every instruction exactly as written.
She was asked to “put out the lights.” She took them outside.
She was asked to “dress the chicken.” She put it in an outfit.
She was not incompetent. She was literal.
And the instructions assumed a shared context that didn’t exist.
Most business processes are written by Amelia Bedelia’s employer. The instructions are clear to the person writing them. They assume everything the writer already knows. And they produce, faithfully and consistently, a wide variety of completely different outcomes.
The Instruction That Forgot to Define Peanut Butter
A founder once showed me their process documentation. Flowcharts for everything — sales, onboarding, customer handoffs. Color-coded. Organized. The kind of documentation that makes a leadership team feel operationally mature.
One step in the onboarding flow said: “Prepare the customer for onboarding.”
That sounded perfectly reasonable. It was right there between two other steps that were equally tidy and equally vague. A complete sentence. A checkbox. Nobody had questioned it in three years.
So we started asking people what they actually did when they reached that step.
Five people. Five completely different answers. One walked the customer through a checklist on a thirty-minute call. One sent a PDF and followed up if there were questions. One had an informal conversation that covered roughly the same ground in a different order depending on the client. One assumed someone else had already done it. One had developed their own version over two years and considered it an improvement on the original — which, to be fair, they had never actually seen.
One person had a jar of Jif. One had Skippy. One had chunky store brand. One was using a butter knife, one a spatula, and one was effectively using a sword.
Everyone believed they were following the documented process. Technically, they were.
“We had documented that peanut butter should go on the bread. Nobody had documented what peanut butter was.”
The process wasn’t wrong. It was too vague to produce consistent outcomes. Those are two different problems. Most organizations treat them as the same problem — which is why the same issues keep reappearing no matter how many times the flowchart gets updated.
This Is What Process Ambiguity Actually Costs
A vague process doesn’t fail dramatically. It fails quietly — in variation, in inconsistency, in customer experiences that differ depending on which employee handles the account. Leadership sees the variance in outcomes and diagnoses a people problem. Somebody isn’t following the process. Somebody needs more training. Somebody needs to be held accountable.
It is almost never a people problem. It is almost always an instruction problem — an assumption that shared context exists when it doesn’t, compounded across every person who has ever tried to follow the step. This is also how Shadow Systems™ form. When the official process is too vague to follow consistently, people build their own versions. Over time those versions become the real operating system — and leadership may not know it exists.
Fraggles, Doozers, and the Two Versions of Every Business
Every organization has two groups of people, and they know fundamentally different things about how the business works.
The Fraggles are leadership. They set direction, make decisions, and believe — reasonably — that they understand how the business operates. The view from the top of the org chart is real. It is also incomplete. Leadership sees outcomes, dashboards, and the version of the process that gets reported upward. They see what the business is supposed to do.
The Doozers are the operators. The people actually doing the work. They know things leadership doesn’t — not because anyone is hiding anything, but because the knowledge lives in the doing. You cannot learn from a dashboard what you can only learn from performing the job on a Tuesday when the system does something unexpected and you have to figure out what to do next.
Field Notes — Observed in the Wild
In Fraggle Rock, the Doozers spend their days constructing elaborate buildings that the Fraggles promptly eat without noticing.
The Doozers keep building. The Fraggles keep eating. Nobody compares notes.
This is a surprisingly accurate model of most organizational knowledge transfer.
The organizational problem is straightforward: most process documentation is written by Fraggles describing what they believe Doozers do. It is then handed back to the Doozers as instruction. The Doozers, who actually know how the work works, adapt it to reality and say nothing — because nobody asked, and because pointing out that the documentation doesn’t match reality has historically not been rewarded.
“The people doing the work know things the people directing the work don’t. Most organizations have never built a formal way to close that gap.”
A PBJ Session™ is that way.
What a PBJ Session™ Actually Is
Key Concept
A PBJ Session™ is a structured cross-functional conversation that asks the people doing the work to describe the work — in their own words, at the level of detail that actually matters. The goal is not evaluation. It is discovery. We are not assessing performance. We are reverse-engineering the process that is already running in production to find out what it actually is versus what it was designed to be.
It starts with leadership. Before we meet with operators we meet with the Fraggles — a kickoff and discovery session that establishes what leadership believes is true. What are the documented processes? What does the official workflow look like? What does leadership believe is working, and what do they suspect isn’t? This is the hypothesis. It is almost always partially wrong. That is not a failure — it is the starting point.
Then we meet with the operators. Separately. Without leadership in the room. We ask the Doozers to describe their processes in their own words — not what the documentation says, but what they actually do on a Tuesday morning. How they handle the edge cases. What they do when the official system doesn’t cover the situation. Where they go to find the real answer when the CRM doesn’t have it. These conversations are the data.
The gap between those two conversations is the diagnostic. Where leadership’s version and the operator’s version diverge — that is where the process ambiguity lives. That is where the Shadow Systems™ are forming. That is where the revenue problems that keep coming back are hiding.
Tell Me How to Make a Peanut Butter and Jelly Sandwich
The prompt sounds absurd. That is the point.
“Tell me how to make a peanut butter and jelly sandwich” is a classic software engineering exercise used to teach the importance of precise instruction. If you say “put the peanut butter on the bread,” a literal interpreter picks up the jar and places it on the loaf. Details matter. Sequence matters. The assumed context — the thing everyone knows without saying — is exactly what needs to be said out loud.
In the sessions, we ask operators to describe their processes the same way. Not what the documentation says. What they actually do, step by step, in the order they actually do it. The gaps, the workarounds, the “it depends on the customer” moments. All of it.
Why Scrum Gets This Right
In Scrum methodology — which we genuinely love — a user story documents intended behavior from the user’s perspective before anything is built: “As a [user], I want to [action] so that [outcome].” The discipline forces teams to make assumptions explicit, define acceptance criteria, and agree on what “done” means before work begins.
A PBJ Session™ borrows this discipline and applies it in reverse. The process already exists. It is already running in production. We are writing the user story after the fact — reverse-engineering the Epic from observed behavior — to discover what the process actually is versus what it was designed to be. We call it Reverse Epic Discovery. Scrum practitioners tend to recognize it immediately.
This is why the sessions ask operators to describe processes out loud rather than review documentation. Documentation describes what was intended. The verbal description — unfiltered, literal, following the actual sequence of Tuesday morning — reveals what actually happens. The difference between those two things is almost always the most instructive thing a leadership team can learn about their business.
Who Is in the Room
We Always Include
Leadership — for the kickoff session only, to establish the hypothesis.
Front-line operators — the people actually performing the process, not managing it.
Cross-functional representation — not just one department, because revenue moves through handoffs between teams.
At least one person who has been there long enough to remember how it used to work.
We Always Keep Separate
Leadership and operators are never in the same session. Operators describe processes differently when leadership is in the room. They describe the process as it was designed. We need the process as it runs.
Anyone whose presence changes what operators will say.
Anyone with a stake in the outcome being a specific answer.
The most important structural rule is the separation. Not because leadership is adversarial — they usually aren’t. Because the presence of a manager, however well-intentioned, changes what people say and how they say it. We need the unfiltered version. The one that includes the spreadsheet nobody told leadership about. The workaround that everyone uses and nobody has documented. The step that only works because one specific person knows how it works.
Watch For
The most revealing moment in almost every session is when an operator describes a step and then adds, unprompted: “but we don’t actually do it that way.” That sentence — and everything that follows it — is the real process. Write it down.
What a PBJ Session™ Produces
Not a meeting summary. Not a slide deck with a RAG status. Not a list of action items that will be reviewed once and filed somewhere reasonable.
A PBJ Session™ produces a more accurate map of how the business actually operates. Not the org chart. Not the flowchart. The real map — the one that reflects what people actually do, what systems they actually use, and where the handoffs actually break down.
What We Find
Steps that exist in documentation but not in practice — the process has drifted from its design.
What It Means
The documentation is a historical artifact, not an operating manual. It describes a business that no longer exists.
What We Find
Steps that exist in practice but not in documentation.
What It Means
A Shadow System™ is load-bearing. The business depends on it. Nobody officially owns it.
What We Find
The same step described completely differently by different operators.
What It Means
Process ambiguity is producing outcome variance. The customer experience differs depending on who handles the account.
What We Find
A process that only works because one person knows how it works.
What It Means
Key-person risk disguised as operational maturity. One departure away from a crisis nobody saw coming.
What the sessions do not produce: a blame map. The sessions are explicitly not performance reviews. We are observing organizational behavior the way a naturalist observes a habitat — with curiosity, not judgment. The dysfunction is almost never the fault of the people in the room. It is almost always the fault of the systems they inherited, the instructions that assumed context that didn’t exist, and the processes that were never precise enough to produce consistent outcomes.
“The goal is not to catch anyone doing something wrong. It is to discover that everyone has been faithfully executing a different version of the same instruction.”
Where PBJ Sessions™ Fit in the Revenue Health Diagnostic™
PBJ Sessions™ are part of the Revenue Health Diagnostic™ — the structured process by which we build an accurate picture of how revenue actually moves through a business across all five systems. They are not the whole diagnostic. But they are often the part that produces the most immediate recognition — the moment a leadership team sees, for the first time, the documented gap between what they believed was true and what is actually running.
The Gap Is the Diagnostic
The distance between what leadership believes the process is and what operators describe the process as — that gap is not a communication problem. It is a Visibility Debt™ problem. The organization has grown faster than its ability to see itself clearly. PBJ Sessions™ are how you start paying that debt down.
How the Sessions Run
No two engagements are identical. The sessions adapt to what they reveal. But the shape is consistent.
In the Twin Cities
Sessions run in person — half day or full day depending on the scope of systems being mapped. In-person sessions produce richer data. People draw on whiteboards. Someone always produces a spreadsheet nobody knew existed. The room has a different energy when people can point at things.
Everywhere Else
Sessions run as 45-minute Zoom calls — one team or function per session. Focused. Structured. Surprisingly effective for something that sounds like it requires a conference room. The separation of sessions matters more than the medium.
The typical sequence moves from hypothesis to discovery to documentation: a leadership kickoff establishes what is believed to be true, operator sessions reveal what is actually true, gap analysis maps where those two versions diverge, and the output — the Reverse Epics, the real process map — becomes the foundation for the Revenue Health Diagnostic™.
The Process That Nobody Has Ever Written Down
Every organization has processes that exist only because someone learned them from someone else, who learned them from someone else, who may or may not have been following the original intent. The knowledge is real. The documentation is not. The process works — until the person who knows how it works leaves, or gets promoted, or goes on vacation for two weeks and the whole system quietly stops functioning in ways nobody can immediately explain.
A PBJ Session™ is, at its core, a very simple act: asking the people who do the work to describe the work. Out loud. In detail. At the level of the peanut butter.
It sounds obvious. It is almost never done. And the gap between what gets described and what leadership believed was true is almost always the most useful thing a leadership team can learn about their business — and the most direct path to understanding why the same problems keep coming back no matter how many times they’ve been addressed.
- The most expensive processes are the ones nobody officially owns.
- Operational truth does not live in the org chart. It lives in the people doing the work.
- You cannot fix what you cannot see. You cannot see what you have never asked about.
- Most organizations are one key-person departure away from discovering how much of their operating system was living in one person’s head.