A story from early in my business, before I built the operational systems I use today.
I placed an admin with a client of mine, an attorney with a growing practice. She needed real-time, high-touch support: last-minute requests, fast turnarounds, the kind of role where things come in fast and need to be handled exactly the way she’s used to, not close enough.
The admin came with a strong resume and a solid referral. On paper, another easy placement.
At first, I ran it the way I ran most placements back then: verbal direction. I told her how my client liked things handled, walked her through a few scenarios, and trusted that would be enough.
It wasn’t. Requests came back done, but not done right. Not wrong exactly. Different. Her way, not my client’s way.
So I did what I now tell other founders to do. I documented it. Wrote out the actual workflow: what happens when a request comes in, how fast it needs to move, what my client’s specific preferences are, what ‘done’ actually looks like.
And it still didn’t work. She had the document. She’d read it. And she still did it her way.
| A documented process only works if someone intends to follow it. I didn’t have a documentation problem. I had an intention problem, and I mistook the first for the second. |
I want to say I have a good excuse. I don’t, not really. It wasn’t a communication problem in the end. It was much closer to a preference. When requests came back different from what I’d documented, I’d ask if she’d seen the workflow for this. She had. She just believed her way was better, or easier, or that the client wouldn’t really mind.
The client minded. My client had built her practice on a specific way of doing things, tone, timing, format, exactly how she wanted materials to look. When the work started coming back close enough instead of exact, she noticed immediately, and she said something to me directly, not to the admin. I fielded it, recalibrated, thought we’d course corrected.
It kept happening. Same drift. Same “I thought this way worked better.”
I let her go. Not because she was incapable. Because a documented process nobody intends to follow isn’t a process. It’s a suggestion with extra steps.
Why Writing It Down Isn’t the Same as Getting It Followed
Operational Clarity™ is where most founders start: seeing where the business depends on them. But once you can see the gaps, it’s tempting to think the fix is just writing it down. Document the process, hand it over, problem solved.
It doesn’t work like that. Documentation answers “what should happen.” It doesn’t answer “why would someone choose to do it this way instead of their own.” Those are two different problems, and Operational Foundation™ is where you learn the difference.
| A Gartner survey found 77% of employees experienced situations in the past year where they rationalized ignoring a process they knew was the right one to follow, more common than acting out of malice (40%). A documented workflow doesn’t make that reasoning disappear. It just gives people something specific to talk themselves out of. Source: Gartner, “Gartner Survey Shows a Strong Ethical Culture Isn’t Enough to Stop Noncompliance,” April 17, 2024 |
What Actually Went Wrong
Not a lack of documentation, eventually. Not a lack of skill either, she was clearly capable.
What was missing:
- No defined consequence for drifting from the process. There was no answer to “what happens if you do it your way instead,” so there was no real reason not to.
- No check on whether the workflow was actually being used, not just written. I confirmed she’d read it. I never confirmed she was using it on live requests until my client flagged it.
- No conversation about why the documented way mattered. I told her what to do. I never explained why my client needed it done that specific way (just that she did), so “close enough” felt reasonable to her, even though it wasn’t to my client. Some individuals need to know why.
What This Stage Actually Requires
Operational Foundation™ isn’t finished the moment something gets written down. It’s finished when the written version is the version that actually gets used.
1. Explain the why, not just the what.
A workflow that only says what to do invites someone to substitute their own judgment for the parts that seem optional. Explain why each part matters, and it stops looking optional.
2. Check the work against the document, not just against “did it get done.”
“Done” and “done correctly” are different questions. Compare early outputs to the documented standard directly, not just to whether the client complained.
3. Name what happens when the process isn’t followed.
If there’s no real consequence for drifting, drift is free. Decide in advance what happens the first time, the second time, and the third time someone does it “their way” instead.
4. Confirm the workflow is being used, not just that it exists.
Reading a document and following it are two different behaviors. Verify the second one. Don’t assume it from the first.
Where This Isn’t You
This stage isn’t about every business, every hire, or every version of “someone didn’t do it my way.”
If you don’t have anything documented yet, workflows still living entirely in your head, that’s Operational Clarity™, or the early side of Operational Foundation™, not this. Start there first. A conversation about compliance has nothing to hold onto without a real document underneath it.
And if the drift you’re seeing is a one-time miscommunication, not a pattern, that’s not a stage problem. That’s just a normal correction. This is about what happens when documentation exists, is understood, and still doesn’t change behavior.
The Bottom Line
A workflow tells someone what “right” looks like. It doesn’t make them choose it. That choice is a separate thing you have to build for, it isn’t something documentation does automatically.
| I didn’t need a better document. I needed a reason for her to trust the one I already had. That’s not a writing problem. That’s a leadership one. |
Frequently Asked Questions
What is Operational Foundation™?
Operational Foundation™ is the second stage of the Operations Ascension Ladder™. It’s where documented workflows, roles, and standards start replacing verbal direction and memory, so the business runs the same way twice.
Why doesn’t a documented process guarantee it gets followed?
Because documentation answers what should happen, not why someone should choose to do it that way instead of their own. Without a reason to trust the process, and a consequence for skipping it, a written workflow is easy to treat as optional.
What’s the difference between Operational Clarity™ and Operational Foundation™?
Operational Clarity™ is about seeing where work and decisions depend too much on the founder. Operational Foundation™ is about building the documented structure, roles, workflows, standards, that lets the business run without the founder explaining everything from memory each time.
How do I know if a hire is ignoring the process or just wasn’t trained on it?
Check the work against the documented standard directly, not just against whether the end result seemed fine. If they’ve read the document, understand it, and still deviate consistently, that’s not a training gap. That’s a compliance gap, and it needs a different fix.
| Which stage is your business actually in? Take the Operations Ascension Ladder™ Assessment, a two minute questionnaire that tells you exactly where you stand and what to build next, before the next hire tests it for you. Take the Assessment. done4u.vip |
Done4U™ – We architect operational maturity.™
Operational Clarity™ | Operational Foundation™ | Operational Leadership™ | Director of Operations™