Standup starts at 9, every day, on time. The board has swim lanes and WIP limits. Retro happens every other Friday, and people actually show up with real feedback instead of staring at their laptops. On paper, this team runs process better than most orgs I've worked with.
Six months in, the thing that actually matters still hasn't shipped.
Same Trap, Different Costume
Last week I told you not to throw a tool at a problem you hadn't defined yet. This week: same warning, different target. Scrum, Agile, OKRs, whatever's currently fashionable — reaching for any of them before you've done the diagnostic work is the same reflex wearing a different costume.
"Defined" was never code for "has a process." It meant someone did the actual thinking — what's broken, why, who's supposed to own the answer. A canned process can get bolted on without any of that thinking happening, which makes it exactly as hollow as automating undefined work. Different bandage, same untreated wound.
Process doesn't automatically create ownership. It just makes the absence of it more organized.
The Fix That Missed the Diagnosis
I took on a short engagement a while back with a founder who wanted to build a specific tool. He had a very particular idea of what the UX should look like — a way of working that made sense to him and, as far as I could tell, to nobody else. My job was to help him define it well enough to actually build. That meant asking why: why this flow, why this interaction, who's it for, what happens if they don't get it the way he's picturing it.
He didn't want that. He wanted it built the way he saw it, verbatim. When I kept pushing on the reframe instead of just executing his vision, he got frustrated — not with the work, with me, for not just doing what he'd asked.
His fix was to bring in someone else to "drive" the effort. That person's main contribution was OKRs.
Not diagnosis. Not user validation. Not a hard look at whether the vision anyone had signed off on actually resonated with real users. OKRs — as if the thing standing between this team and a shipped product was a lack of clarity on quarterly goals. Nothing says "we heard the feedback" like a spreadsheet with targets on it.
The OKRs didn't touch the actual gap. The vision was still unexamined. The team still didn't have a shared, validated picture of what they were building or for whom. They just had it now with better goal formatting.
I was let go not long after. I wasn't sad about it. As far as I know, they never got the tool built.
Process Isn't Self-Enforcing
None of this is an argument against process. I've seen the opposite problem plenty of times too — a process so minimal it's hard to call it process at all. One small piece of traceability, added to something the team was already doing dozens of times a week. Barely an ask.
Developers resisted it anyway.
The process wasn't the problem. It's about as targeted and low-overhead as a process gets. What was missing was leadership actually willing to hold the line the first few times someone pushed back — to spend a bit of social capital enforcing something inconvenient instead of letting it slide. Once leadership signaled they meant it, the resistance stopped being a fight.
A process is never self-enforcing. Somebody has to own whether it sticks — and be willing to spend the capital to enforce it when it's inconvenient.
That's a different failure mode than the OKR story above, and it's worth telling apart. One is a process substituted for diagnosis. The other is a correct process with no one backing it. Both end the same way — ceremonies happening, nothing landing — but the fix isn't the same, and "just add more process" doesn't touch either one.
When Process Actually Works
I've also watched the opposite happen — a process that stuck without anyone chasing it. Ten minutes, once a week: the three things that mattered most, the one goal being moved, what changed since last time. No deck. No 40-slide investor narrative translated down to the team. Just a rhythm, tied to real priorities, run by someone who actually owned the outcome.
Nobody had to enforce that one. It kept running because it was answering a question people actually had — not filling a slot on a maturity checklist.
That's the tell. Process that's standing in for a decision nobody made needs constant chasing. Process that's carrying real weight barely needs asking twice.
The Question Before the Ceremony
Before your next Scrum training, before you write your next quarter's OKRs, before you adopt whatever framework the last consultant swore by — ask what accountability gap this is actually supposed to fill. If you can't answer that in one sentence, you're not ready to add it yet. And if you can answer it, ask the harder follow-up: who's going to enforce this when it's inconvenient, and do they know that's their job?
Whoever that is — the one holding the line when the ceremony gets inconvenient — is doing Operator Seat work, whether your org has a name for it or not.
I'm not going to hand you a framework for answering that — that's not a template problem, and pretending it is would just be one more ceremony standing in for the actual thinking. What I'll say is that the question is doing more work than any methodology you're about to adopt.