Most growing practices don't lack ambition. They lack a partner who understands both how operations actually break, and how to get a real team to fix them for good.
In 2000, I was working as a retail manager, and part of the job was running what the industry calls a "floor reset" — rearranging store displays on a schedule, a known retail tactic for keeping the shopping experience feeling fresh and customers moving through the store longer. In theory, straightforward. In practice, chaos: a reset meant to refresh the floor was taking my team five full days, with no defined process, no sequence, and no clear ownership of who did what, when.
The cost was real and measurable. Staff burned out mid-reset and started calling out specifically on reset days, overloading whoever was left. With the floor in disarray for nearly a full work week at a time, my sales associates couldn't help customers navigate a store that was half-disassembled — and satisfaction dropped right along with it. By the time one reset finished, the next was nearly due to start.
That demanded a fix, not a workaround. I built a step-by-step task analysis that turned an undefined scramble into a defined, sequenced process. The result: a five-day reset became a 1.5-day reset. Sales increased. Call-outs dropped. Customer and employee satisfaction both rose, measurably.
That moment — taking a process quietly breaking everyone involved and rebuilding it into something fast, repeatable, and humane to execute — became the lens I've used in every engagement since. Twenty-six years across business ownership and operational leadership later, the work hasn't changed: find the chaos hiding inside a process everyone has learned to tolerate, and rebuild it into something that actually works.
I joined a fast-growing company whose technology had outpaced its own infrastructure — the kind of growth where headcount and complexity arrive faster than the operational backbone needed to support them. On paper, the systems looked modern enough. Underneath, the company was quietly bleeding money and sitting on serious risk, with no one positioned to see either clearly.
There was no centralized IT function, so there was no single source of truth for anything technical. Departments were paying for multiple individual software seats the company had already covered with enterprise-level licensing. Hardware — laptops, printers, peripherals — had no inventory tracking, so equipment routinely went missing, depreciation wasn't accounted for correctly, and nothing was reclaimed when an employee left. Security was worse: a shared, easily guessed password covered multiple systems. A breach wasn't a risk on the horizon. It was close to inevitable.
None of it was any one person's failure. It was the predictable cost of growth that outran its own infrastructure. So I built what was missing: a hardware asset management system to close the inventory gap, multi-factor authentication on every account, and onboarding and offboarding processes that finally accounted for hardware and software access on the way in — and reclaimed both on the way out.
The result was roughly $85,000 recovered in redundant software spend, a measurable drop in hardware shrinkage, and an offboarding process that finally held up across a multi-location organization. The lesson has held in every engagement since: the real danger is rarely one bad decision. It's the absence of a system — and once that gap is visible, it's almost always bigger than anyone expected.
A retail floor and a fast-growing company are different industries, different decades, different kinds of chaos — but the same lesson sits inside both. A five-day reset that breaks staff and customers, and a company hemorrhaging $85,000 to shadow IT on a password everyone could guess, aren't really different problems. They're the same problem: a gap nobody built a system to close, getting more expensive the longer it stayed invisible.
That's where most operational consulting fails. Practices bring in help, get a polished audit or a training initiative, and watch it fail to stick — not because the advice was wrong, but because it only solved half the problem. A workflow redesign without a plan for adoption is a binder on a shelf. A security policy nobody enforces is a document, not a fix. Training layered on a broken process just makes the broken process run more consistently.
Protocol exists to stop forcing that choice — bringing Lean Six Sigma's process rigor, OBM's adoption science, and hands-on systems and security engineering together in the same engagement, from the same team. It's both founding lessons, formalized: fix the sequence, fix the system people work inside of, and close the gaps nobody's tracking — all at once.
Protocol is built around two disciplines working as one practice: deep operational and behavioral systems leadership, paired with systems and automation engineering. Most growing practices can't yet justify a full-time VP of Operations and a systems architect on payroll. Protocol exists to be exactly that — without the year-long hiring search, and without the overhead of a full executive team.
Two disciplines, one practice — built so you get both halves of the fix, from people who've actually done the work, not delegated it.
Protocol works primarily with clinical and behavioral health practices — ABA, physical therapy, dental, mental health, and similar — because that's where our deepest operational experience lives, and because the stakes of getting it wrong are highest. We also work with small businesses more broadly, wherever the same underlying pattern shows up: a founder who's become the operational bottleneck, systems that worked at an earlier stage and are breaking now, and growth that feels heavier instead of lighter.
If that sounds like where you are, you're exactly who we built this practice for.