A workflow that won't stay fixed is usually encoding a decision that was never actually made. What a real decision looks like, and how the deciding gets done.
Decision-Making
The Question I Ask First
When I come across a workflow that's broken and won't stay fixed, the question I ask is not "what's wrong with the workflow." It's "what decision is this workflow trying to encode, and was that decision actually made." Often it wasn't. Or it was made, but never clearly communicated, so the team has been filling in the blanks. Or two versions of it are operating in parallel, and the friction between them is exactly what's breaking the workflow.
What Counts as a Decision
The workflow is a system, and every system is downstream of a decision. If the decision underneath was never actually made, no version of the system will hold. You can rebuild the workflow as many times as you want. You're encoding the same unresolved question.
A decision, in this context, isn't the meeting where everyone nodded along. It's whether the team is actually operating from it afterward. That's the real bar, not documentation.
What I look for:
The team behaves as if the decision is settled. When the situation comes up, nobody pauses to relitigate.
People can articulate what was decided, and just as importantly, what wasn't. The boundary is clear.
The decision was made deliberately. Not arrived at by default, not inherited from a previous tool, not assumed.
The right people had a voice in it. Some got a vote. Some got consulted. Whoever held the final call held it explicitly.
How the Deciding Gets Done
The piece most teams skip is how the deciding actually gets done. Decision rights usually get framed as "who has the authority." That framing is top-down, it doesn't create buy-in, and it makes the whole exercise feel worse than it needs to.
However, the version that holds is based on process: who gets a vote, who gets consulted, and how the call gets made, whether that's consensus, a smaller group, or a single decider with input. Without that, decisions don't get made, stay murky, or don't address the problem they were meant to solve. None of this happens in bad faith. The decision-making parameters just never got built.
The work, before you build any system, looks something like this:
Surface the unmade decision.
Weigh the tradeoffs with the people who'll be affected: whoever gets a vote, whoever gets consulted, whoever holds the final call.
Move between the day-to-day detail and the broader strategy so you can see how the decision plays out at both levels.
Build the system that encodes it.
Then tell the team, name who owns it, and say plainly that it might need to change as the business does.
In my experience, the deciding does the work the building gets credit for. The building still matters, because someone has to turn the decision into something the team can use every day. But when the decision underneath is solid, almost any reasonable system can carry it. When it isn't, even the best-built one won't.
The deciding does the work the building gets credit for.
The Workflow Was Never the Problem
If the same workflow keeps breaking no matter how many times it gets rebuilt, the workflow was never the problem. There's a decision underneath it that hasn't been made, and finding it is most of the fix.
