Decision Ownership: The Single Diagram That Stops Hallway Decisions

Last updated: July 24, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

A staff engineer on one of my teams once had to decide, at 6 p.m. on a Thursday, whether to roll back a payments deploy that was throwing errors for about two percent of loan submissions. The rollback was clean. Reversible. Low blast radius. Exactly the kind of call he was hired to make. He did not make it. He spent forty minutes trying to reach me, then his manager, then me again, while the error rate sat there, because somewhere along the way the team had absorbed the idea that anything touching payments went up the chain first.

It was not his fault. Nobody had ever told him that call was his. Nobody had told him it was not, either. The ownership just sat in a fog, and in a fog people freeze or they guess. That night he froze. Two weeks earlier, a different engineer on the same team had guessed, shipped a schema change to a shared Kafka topic that four other services read from, and broke three of them before lunch. Same fog. Opposite reaction. Neither one had a map.

I wrote about getting priorities out of the hallway and into writing in why engineering priorities have to live in writing. That piece is about where a decision goes once it has been made. This one is about the question that comes first, the one almost nobody assigns on purpose. Who was allowed to make the call at all? It is the deepest layer of the Clarity Stack, and it is why KORE1 keeps running into the same pattern across their engineering staffing work. The teams are not short on talent. They are short on a line that says who decides what.

Two Ways a Decision Ends Up in a Hallway

When decision ownership is undefined, decisions do not stop happening. They cannot. Work still has to move, so the calls still get made anyway, leaking out through the two weakest points in any org that never bothered to name an owner, which are the person standing nearest the problem and the person sitting highest above it. I have watched both drain more velocity than any framework, any refactor, or any heroic weekend ever gave back.

The first is the grab. Someone with proximity and enough seniority to sound convincing makes a call that has a bigger blast radius than their authority. They are not being reckless. They are filling a vacuum, and the vacuum feels like theirs to fill because nobody said otherwise. The Kafka engineer grabbed. He had the keys, he had a fix, and no one had drawn a line around the shared topic that would have made him pause and pull in the three teams downstream. The keys were his. The judgment call was not.

The second is the freeze. A decision that clearly belongs low in the org rolls all the way up because nobody at the bottom was ever told it was theirs to make. So it lands on the leader. Then the next one lands on the leader. And the leader, who thinks they are being helpful and available, has quietly become the bottleneck their whole team routes around. My staff engineer froze. The rollback that should have taken ninety seconds took the better part of an hour, and the only thing standing between the customer and the fix was a permission slip nobody had bothered to pre-sign.

Grab and freeze look like opposite problems. A manager tries to cure the grab with more control and the freeze with more empowerment, tightens and loosens the same team in the same month, and cannot work out why neither knob does anything. Same problem. The line was never drawn. There is a McKinsey number I keep throwing at executives who tell me this is soft stuff. Sixty-one percent of them admit that at least half the time they spend making decisions is wasted. Sit with that. Most of that waste is not the hard calls, the genuinely irreversible ones that deserve a long meeting and a nervous stomach. It is two-way doors, easy ones, stuck for days in the wrong set of hands because nobody could say whose hands they were.

The Single Diagram: A Decision-Rights Map

The whole framework fits in one diagram with two axes. How reversible is the decision, and how far does it reach? Answer those two questions and the owner is no longer a matter of who happened to be standing in the hallway. It is already decided.

The reversibility axis is not mine. I borrowed it from Jeff Bezos, who in his 2015 letter to Amazon shareholders split decisions into two kinds. Type 1 decisions are one-way doors. You walk through, and you cannot walk back. Type 2 decisions are two-way doors. If you do not like what you find, you turn around and try something else, and the whole cost of being wrong was the walk. Most engineering decisions are two-way doors. Leaders treat them like one-way doors, run every one through a heavyweight approval, and wonder why the team feels slow.

The second axis is blast radius. Does this decision stay inside one service and one team, or does it reach across teams, into shared contracts, or out to a paying customer? A reversible call with a wide blast radius is not the same animal as a reversible call that lives and dies inside one repo. So you plot both. Here is the map I draw on the whiteboard, every time, for every team that tells me they have a velocity problem.

Three of those four quadrants belong to the engineer or the tech lead. Count them. That is the point of drawing it. When you actually plot your decisions instead of reacting to them one at a time, you find that the overwhelming majority are two-way doors with a local blast radius, and you have been sending them all uphill out of habit. The map does not empower anyone. It just stops you from accidentally hoarding decisions that were never yours to hold.

What the Map Looks Like Filled In

The two-by-two is the idea. A team needs the idea turned into examples, because the argument is always at the edges. Is a feature-flag rollout a local call or a wide one? Depends on the flag. Internal beta, local. A slice of live loan traffic, not even close. So you sit down for one hour, you list the decisions that actually come up on this specific team rather than some tidy imaginary one, and you place every last one of them on the grid even when the placement kicks off a fight about where the line really sits. RACI, DACI, and RAPID are the formal versions of this exercise, and if your org loves a framework, use one of them. I find they collapse under their own weight on a fast team. Four roles times forty decision types is a spreadsheet nobody opens twice. One page, four quadrants, real examples. That is what people keep on the wall.

Notice the escalation column. It is not a list of hoops. It is a short list of the specific conditions under which a decision changes owners, written down so the engineer knows the exact edge of their authority. Most permission-seeking happens because people cannot see that edge, so they assume it is closer than it is and check in to be safe. Show them the edge and the checking-in stops. You did not give a speech about trust. You drew a line they could actually see.

How to Install It Without a Reorg

You do not announce this. You install it, the same way you install any real change to how a team works, by changing what happens in the next ten decisions rather than sending a memo about the next hundred. A memo tells people the rule. The next ten decisions, each one handled in front of them with the owner named out loud before anyone is allowed to argue the substance, are the only thing that ever teaches a team where the lines actually sit and that you intend to hold them. The move is small and almost annoyingly repetitive. Every time a decision shows up, before anyone debates the decision itself, you ask one question out loud. Whose door is this?

Say it enough and the team starts asking it without you. That is the whole win. The map lives in their heads, they place the decision in a quadrant in about three seconds, and the owner just decides. I have run teams where a new engineer would ask permission for a local reversible call in week one and be quietly annoyed at anyone who asked permission for the same class of call by week ten, because by then the norm had set. This is the culture I keep trying to describe to executives who think it is about hiring nicer people. It is not. It is about drawing the doors.

So here is the version I have said out loud enough times that it is basically my whole position on the matter. I am just going to let it sit here and not dress it up.

The highest-performing teams I have led were the ones where engineers felt empowered to make decisions at their level without escalating everything upward. That kind of culture does not happen by accident. It comes from clearly defining decision ownership, building trust, and then staying out of the way when people take responsibility for the decisions that belong to them.

The hard part of that sentence is the last clause. Staying out of the way. Drawing the map is a one-hour exercise. Honoring it when your instinct is screaming to grab the reversible, local call back because you would have done it slightly differently, that is the discipline, and it is the part most leaders quietly skip. If you take back a decision you assigned, you did not delegate it. You lent it. Everyone can tell the difference, and they adjust their effort accordingly.

The Hiring Reality Underneath the Map

Here is the part KORE1 pays me to say plainly, so I will. A decision-rights map only holds if the people below you can actually be trusted with the calls you are assigning down. If your bench is thin on senior engineers, everything genuinely does need to escalate, not because the map is wrong but because there is nobody standing in the lower quadrants ready to own the door when it opens. The map does not fix that. It exposes it. Which is worth knowing, and also not remotely what you were hoping a tidy little diagram would do for you on the day you drew it.

This is why I stopped treating decision ownership as purely a leadership habit and started treating it as partly a staffing question. You cannot delegate a one-way door to someone who has never walked through one. KORE1 has placed engineers across more than 30 U.S. metros for two decades, with a 17-day average time-to-hire for IT roles and a 92 percent twelve-month retention rate on those placements. The retention number is the one I care about here. The senior engineer who can be trusted with a wide, reversible call is exactly the person who is hardest to replace and easiest to lose to a competitor who lets them decide things. If your lower quadrants are empty, KORE1’s software engineer staffing team places that level of talent, usually on a direct hire basis. We do better when you cannot staff that bench yourself. Fair to say so out loud.

The Bottom Line for VPs and CTOs

Most of what leaders call a velocity problem is a decision-ownership problem wearing a costume. The work is not slow. The decisions about the work are stuck, either grabbed by the wrong hands or frozen waiting for yours. A one-page map that names who owns which door fixes more of that than a reorg, a new tool, or another sprint of overtime ever will.

Draw the two axes. Plot your real decisions. Hand three of the four quadrants to the people you already hired to make those exact calls, and then do the one genuinely difficult thing this whole framework asks of you, which is to leave them alone once you have, especially on the Thursday evening when your gut is begging you to reach back in and take the reversible little call yourself because you would have played it half a degree differently. If you want to pressure-test where the lines currently sit on your team, or argue with me about the quadrants, connect with me on LinkedIn. And if the real gap turns out to be an empty lower quadrant, KORE1’s engineering hiring team can help you start the search.

What Leaders Ask Me About Decision Ownership

Isn’t a decision-rights map just RACI with extra steps?

Other way around. RACI has the extra steps. A decision-rights map is one page with four quadrants, and RACI is a grid of four roles across every task you can think of. The map is what survives contact with a team that actually ships.

I am not against RACI, DACI, or RAPID. They are more rigorous, and in a large regulated program where an auditor will eventually ask who approved what, the rigor earns its keep. On a fast product team, the formal versions get built once, admired once, and never opened again. The test is not thoroughness. It is whether an engineer can glance at the thing and know, in three seconds, whether the call in front of them is theirs. Two axes clear that bar. A forty-row matrix does not.

Where exactly do I draw the line on what engineers can decide?

Start with reversibility and blast radius, and default generous. If a decision is reversible and stays inside one team, it belongs to the engineer, full stop, even if you would have chosen differently. You reserve your own approval for the one-way doors that reach across the org.

Most leaders draw the line far too high because they remember the one time a junior engineer made a mess and they never want to feel that again. So they pull a whole class of decisions upward to prevent a rare failure, and pay for it every single day in speed and in the message it sends. Draw the line by asking what the actual cost of being wrong is. If the answer is a revert and an apology, that is a two-way door. Let them open it.

What happens when someone owns a decision and gets it wrong?

If it was a two-way door, you reverse it and you leave the ownership exactly where it was. The failure was the point of putting the door there. If you claw the decision back the first time it goes sideways, you have taught the whole team that ownership evaporates under pressure.

The response to a bad call inside someone’s own quadrant is a conversation about the reasoning, not a repossession of the authority. Nine times out of ten the reasoning was sound and the outcome was variance, and you learn something. The tenth time is a coaching moment. What it is never is a reason to redraw the map so that call now comes to you. Do that a few times and you will have centralized every decision worth making, and a team that has stopped bringing you their judgment because they have learned it is not wanted.

How is this different from just writing our decisions down?

Writing a decision down records who decided. A decision-rights map decides who gets to decide, before the decision exists. They are consecutive problems, not the same one. You can have immaculate records of decisions that were all made by the wrong person.

Documentation is the layer above this one, and I made the full case for it in the piece on keeping priorities in writing. The two work together. Ownership tells the right person to make the call. Documentation makes sure the call does not evaporate the moment they make it. A team that writes everything down but never assigned ownership just produces beautifully archived hallway decisions. Fix the ownership first. Then the record is worth keeping.

My executives keep overriding the map. How do I handle that?

Do not fight the override. Log it. Every time a decision jumps its assigned owner, note who took it and why, without drama, and let the pattern speak. Three overrides in a month is a real conversation. One is just a Tuesday.

Senior people will occasionally reach into a quadrant that is not theirs, and sometimes they are right to. Context you do not have, a customer relationship on the line, a bet only they can authorize. The map is not a wall. What you are protecting against is the quiet, constant erosion where the map says the engineer owns it and reality says the loudest person in the room does. Make the gap visible. Most executives, shown that they are personally the reason their engineers stopped deciding, will move. The ones who will not have told you something you needed to know about the job.

Related reading: The Clarity Stack: 3 Reasons Engineering Velocity Stalls, Why Engineering Priorities Have to Live in Writing, and When You Are the Bottleneck: The Mirror Engineering Leaders Avoid.