This page is about the order I work in, and why I won't work out of order.
Most ops implementations don't stick because they started in the wrong place. Someone — usually someone reasonable, usually someone under pressure — decided the fastest path to results was to pick a tool, pick a framework, or pick a process and start rolling.
What actually got built was a system that treats symptoms, skips the humans, and starts eroding the day it ships. Six months later, half the team's working around it and the other half has stopped using it entirely.
I don't sustain before I build. Every engagement follows this arc. Skipping any phase is how you end up back where you started.
Before anything gets built, I need to understand where you are. Not just operationally — ethically, emotionally, practically. What you're comfortable with. What you're not. Where the line is for your people, your customers, and your values.
This is where the AI policy gets established, and it's the first concrete output of any engagement. Everything downstream depends on getting this right.
Goal first. Then process. Then gap. In that order.
Most mapping exercises start with "walk me through how it works now" — and that's exactly why they produce maps nobody uses. Starting with the goal and then asking about the process almost always produces a moment where the client sees their own misalignment. I don't have to point it out. They arrive there themselves.
That moment is the whole reason the sequence matters.
Find where the human is most constricted. Relieve that pressure first.
A person who's drowning can't think well, collaborate well, or absorb change well. The quick win isn't a morale play — it's a physiological unlock. You clear the most painful thing, and suddenly the team has enough oxygen to actually engage with the larger build. Skip this, and everything after lands on people who don't have the capacity to receive it.
Systems people can run without me.
Documentation is freedom, not a leash. The swim lane is a diagnostic tool as much as a deliverable — you can't map what nobody understands, so the mapping itself forces the clarity.
While I'm building, I'm also finding the internal operator: the person inside the organization who already thinks like an ops person, whether or not that's in their title. They're the reason the system lives after I leave. If I haven't found them, I haven't finished.
Done isn't a deliverable. It's a feeling, plus a feedback loop.
I won't hand off a system I haven't watched run in real conditions. The review cycle is built in from the start, and it's built in as a permission structure: you have the authority to change what we made together.
The system is yours, not mine. That has to be true in practice, not just in theory, or it won't hold.
Not handed to you. Drawn out of you.
Before I touch a single process, I establish an AI policy with the client. What the policy defines: where you currently are with AI, what you're comfortable using it for, where your lines are, and how much AI I'll use while building your systems. We write it down before we start. It gets revisited as we go.
Why this comes first: it defines everything downstream. And it's the clearest signal I can send that I'm not here to sell you on AI. I'm here to figure out what's actually right for you and build accordingly.
Customer complaints had been climbing on a high-volume loan portfolio. The instinct in the room was to fix the customer service script or retrain the team.
The sessions started tense — senior people who felt the customers were being unreasonable, a team that felt unsupported, everybody tired. We mapped the refund process end to end. On the wall, visually, in front of them. It took about an hour.
By the end of the hour, the same executives who'd walked in frustrated with customers were the ones arguing most strongly on the customers' behalf. Nobody had told them to. They could just see it — the twelve-month refund cycle, the bank account structure that made it that way, the investor agreement language that had been silently shaping the whole experience.
The complaints weren't a customer service problem. They were a cash flow architecture problem, and once everyone could see it, the fix became obvious. We rebuilt the cash flow structure with legal and our banking partner.
That's Align and Map doing their job. The solution was almost ordinary. The shift in the room was not.
Because Unblock has to happen before Build, I don't take engagements where the ask is to skip straight to systems work.
It's not a preference. It's the reason any of this works.
If you're looking for someone to come in and document what already exists, I'm probably not the right fit. If you want to understand what's actually happening — and build from there — that's the work.
If this is the order you want to work in, reach out.