Org Design Starts With Accountability: Who Actually Owns What
Org design gets treated as a structural exercise - new boxes, new lines, new titles. But structure is downstream of a simpler question: who owns what, and who is responsible for the outcome. Get that answer right, and the structure to support it becomes obvious. Get it wrong, and no amount of restructuring fixes it.
Accountability is simple to define and hard to build. Most organizations think they have it figured out because it's written into job descriptions and an org chart. In practice, very few do and the gap between the two is where most performance problems actually live.
The chart says who's responsible. It doesn't say who actually is. Two people quietly think they own the same step. A step has no owner at all. Someone is held accountable for a decision they don't have the standing or information to make well. None of that shows up in a job description, and none of it gets fixed by redrawing reporting lines - because the org chart was never built to answer the question "who really owns this" in the first place.
The first step in org design: the operational journey map
The best org design efforts share a common starting point: they begin with the work, not the chart. Before anyone touches a reporting line or rewrites a job description, the strongest teams build an operational journey map — a real, current-state picture of how work actually moves through the business, built directly with the people doing it.
That single step is what turns "who owns what" from a guess into a fact. A journey map forces you to trace the work itself:
Where does this process start, and what actually triggers it?
Who touches it, in what order, and how much of that is informal versus documented?
Where does it stall, loop back, or get done twice?
What information exists only in someone's head, not in any system?
Where are the handoffs, and what breaks at each one?
Answer those questions honestly, and ownership stops being an assumption. You can see exactly where accountability is clear, where it's duplicated, and where it's missing entirely.
What a good journey map actually captures
The best maps are built directly with the people doing the work — not from policy docs, which describe the process as designed, not as it runs. A useful map includes:
The trigger and the end state — what kicks the process off, and what "done" actually means downstream.
Every touchpoint, in sequence — each person, system, and decision point the work passes through, including the informal ones nobody put in the SOP.
Time and friction at each step — not just "this takes two days," but why: waiting on approval, waiting on data, waiting on a person who's the only one who knows how to do it.
Decision points, explicitly called out — where judgment gets applied, who has the authority to apply it, and what information they use that isn't written down anywhere.
Failure and rework loops — where things get kicked back, redone, or quietly fixed off to the side.
That fourth item is usually the most revealing. Decision points show you where real authority sits in practice — which is often not where the org chart says it sits. You can't find those gaps by looking at a process flow diagram or a RACI chart. You find them by mapping the journey with the people who actually make the calls.
From ownership to performance management
Once ownership is clear at each step, performance management gets easier to design honestly:
Metrics attach to the actual step, not the department. Instead of a generic team KPI, you can measure the specific handoff or decision point the map identified — and hold the right person accountable for the right thing.
Goals reflect real authority, not assumed authority. If someone is accountable for a decision but doesn't actually have the standing or information to make it well, the map surfaces that mismatch before it shows up as a missed target.
Incentives can reward fixing the friction, not just hitting volume. Once you can see where rework and delay live, you can build performance goals around reducing them — which is a very different, and more useful, conversation than a generic productivity metric.
This is the payoff of doing the mapping work first: accountability, performance metrics, and incentives all get designed off the same picture of reality, instead of three separate guesses that may not even agree with each other.
From ownership to structure
The same map answers the structural questions too, once ownership is clear:
Where is the actual bottleneck? Not "this team seems overloaded," but which specific step is slow, inconsistent, or dependent on one person.
Which roles need to be redesigned, not just relabeled? If a step is duplicated, skipped, or informally owned by someone outside their job description, the role built around that step needs to change to match reality.
Where does decision authority actually need to sit? The map shows exactly where decisions cross team or function boundaries — which is where reporting lines need to be tightened, and where they're already working fine.
Skip the mapping step, and every one of those answers is a guess dressed up as strategy. Do it first, and the redesign practically writes itself, because you're changing a process — and reassigning ownership — based on how things actually work, not how you assumed they did.
The tell that you got it right
If your journey map looks like a tidy flowchart with no loops, no informal steps, and no "it depends who's on shift," it isn't done yet. Real operations are messier than that. The map should feel a little uncomfortable — it should surface the workarounds and shadow ownership that never made it into any official documentation. That discomfort is the signal you're looking at how the work actually happens, and who's actually accountable for it. That's the only foundation solid enough to design an organization on top of — which is what org design was supposed to be about all along.
