Last updated: June 29, 2026
The Hallway-Decision Problem: Why Engineering Priorities Have to Live in Writing
By Kris Drouet, Engineering Executive, in partnership with KORE1
Engineering priorities have to live in writing because a decision made in a hallway reaches maybe four people, changes without a trace, and leaves every engineer who missed it building toward a target that quietly moved. That is the hallway-decision problem, and it is the second layer of the Clarity Stack. It is also the most fixable. You do not need a new tool or a reorg. You need the discipline to make every priority findable in one place before anyone leaves the room.
Twenty-five years building and leading engineering teams, almost all of it in fintech and mortgage technology, and I can tell you the most expensive decisions I have ever watched get made were not the ones in the architecture review. They were the ones made in the hallway. Two minutes between meetings. A quick nod. “Yeah, hold the rate-lock work, get loan pricing out first.” Done. Except it was not written anywhere, and forty people were about to spend a sprint proving it.
I wrote the full diagnosis in The Clarity Stack, the three-layer model for why engineering velocity stalls when the code is fine. This piece is about one layer. Layer 2. Priorities that live in people’s heads and side conversations instead of somewhere the whole team can see them. And unlike the other two layers, this one has a fix you can start on Monday.
When I join a struggling org, the first thing I look at is not the codebase. It is the gap between what leadership believes it decided and what the team can actually point to. That gap is almost never a technology problem. It is a writing problem. Somebody made the call and nobody wrote it down where it counts.
Why Smart Leaders Keep Deciding in Hallways
The hallway decision is not a character flaw. It is the path of least resistance, and your most senior people take it for the same reason water runs downhill. Proximity. Speed. The small hit of having settled something. You are standing next to the one person who can say yes, you have ninety seconds before the next meeting starts, you ask, they nod, and you both walk away feeling like something just got handled when really it just got buried.
It feels efficient. That is the trap. The cost is invisible at the moment you make the call and brutal three weeks later, when the work that nobody updated collides with the work that nobody knew was cancelled.
And the relay itself is not free. When a priority gets handed down in a side conversation, somebody has to carry it back to the team, explain it, defend it, and absorb the questions it raises. Dr. Gloria Mark’s research at the University of California, Irvine clocked the average return to focused work after a single interruption at 23 minutes and 15 seconds. Now count how many times your unwritten priority gets relayed, questioned, and re-explained because it never landed anywhere people could just read it.
Twenty-three minutes. Per interruption. The undocumented priority is an interruption machine, and you built it yourself with a nod in a corridor.
Look under the hood of almost any org that swears it just moves fast, and you find the same engine running underneath. Decisions getting made constantly, by good people, and disappearing the second the conversation ends.
A Decision Is Not Real Until It Is Written Where the Team Looks
A priority lives in writing when any engineer can open one known place, read it, and get the same answer their manager would give and the same answer the CEO would give if you stopped her in the parking lot and asked cold. Not three places. One. If the answer changes depending on who you ask, that is not a priority. That is a mood.
Made, written, findable. Those are three different achievements, and most teams quietly mistake the first one for all three. A decision got reached in a room, everyone nodded, and that felt like the finish line. The good ones go a step further and write it down somewhere. Almost nobody reaches findable, which is a shame, because findable is the only one of the three that changes what an engineer actually does on a Tuesday morning when the person who made the call is buried in back-to-back meetings and cannot be pulled out to settle it.
Two decades ago, Bain partners Paul Rogers and Marcia Blenko published a Harvard Business Review piece called “Who Has the D?” about exactly this. Their argument held up: most decisions stall not because the answer is hard but because nobody can say who owned the call. Writing a priority down forces the question the hallway lets you dodge. Who decided this? Based on what? When? A doc with no name attached is a rumor with better formatting.
What a Written Priority Actually Has to Contain
A priority is not “the list of stuff we want.” I have read plenty of priority docs that were really just wish lists with timestamps. A real one answers the questions that otherwise get asked in a hallway. Five fields. Miss any one of them and you can usually predict exactly which argument is going to keep crawling back into your week until you give up and put it in writing.
- The one thing. Not the top ten. The single most important outcome this sprint or this quarter, written in a sentence a tired engineer can repeat back without scrolling.
- Who owns the call. Put a name next to it. “We decided” has to become “Priya decided, on the 12th, after pricing flagged the deadline.” Borrow Rogers and Blenko’s RAPID model if you want the formal version. A name and a date carry most of the value.
- What it is not. This is the most underrated field, and the one I have watched change a team fastest. At one mortgage-tech shop, every priority doc listed what was in. None listed what was out. So every stakeholder assumed their pet project was merely unlisted, not killed, and kept lobbying for it through side channels. We added one line per item, “explicitly not this quarter,” and roughly half the hallway traffic dried up inside two weeks.
- The date it changed. Priorities move. Fine. Priorities that move silently are the problem. A two-line changelog beats a pristine doc that lies about its own history.
- Where it lives. One link. Pinned. Everyone knows it cold.
How to Get Layer 2 Out of the Hallway
You install this. You do not announce it. Announcing a new process and changing how decisions actually get made are different things, and engineers can tell which one is happening by Wednesday.
Start with the tool, and then stop thinking about the tool. Linear, Jira, a Notion page, a whiteboard you photograph every Friday. I do not care which. It is commodity. This is a build vs buy call and the answer is buy, because the tool is the least important decision you will make in this whole effort.
The move that does the real work is a rule, not a tool. Every meeting that changes a priority ends with the change typed into the one place, out loud, in front of the room, before anyone stands up. No “I’ll update it later.” Later is where priorities go to die in a corridor.
Then comes the hard part, which is not the doc at all. It is what you do when the CEO pings you a new priority in a Slack DM at 9 p.m. You do not argue. You say “great, putting it on the board now,” and then you actually do it, and you make sure the whole team can see that the late-night DM turned into a line on the board with a name and a date attached to it. Three times and the org learns the board is real. Ignore it three times and the org learns the board is theater, and theater is what you had before.
If any of this still sounds like overhead, the research disagrees. Show me the data and it points one direction. Google’s DORA program found that documentation quality drives the implementation of every single technical practice they studied, and that the performance lift from those practices is significantly amplified on teams whose documentation is above average. Writing it down is not the cost. It is the thing that pays for itself by the second sprint. I made the broader case for defending this kind of unglamorous work in operational discipline is not bureaucracy, if you need ammunition for the budget meeting.
| Where priorities tend to hide | What it costs you | Where the priority has to live instead |
|---|---|---|
| A hallway nod between two leaders | Reaches four people, changes with no trace | One pinned doc, updated before the meeting ends |
| The leader’s head | The leader becomes the single point of failure | A sentence with an owner and a date attached |
| A Slack thread from three Tuesdays ago | Technically written, functionally lost | The board the thread links out to |
| Five competing tools, none authoritative | Every source disagrees, so none is trusted | One tool, the other four switched off |
The Objections, and Why They Usually Fall Apart
“We move too fast to document.” You move too fast because you do not document, then you redo the work twice and call the second pass a learning. The fast teams I have run were the ones that spent ten minutes writing the call down so they never had to have it again.
“Slack is our source of truth.” Slack is a river. A source of truth is a lake. The latest message winning is not a priority system. It is a popularity contest with timestamps.
“We are agile, we embrace change.” Agile teams write things down constantly. The backlog is writing. The point of the whole approach is to change the writing on purpose and in the open, in front of everyone, not to quietly pretend the priority never moved and then let the team discover at the demo that the goalposts had walked off the field two weeks earlier.
The Hiring Reality Sitting Underneath All of This
Here is the part KORE1 pays me to be straight about, so I will be. A written priority system only holds if you have enough senior engineers who run it without a manager hovering. Capturing the decision, naming the owner, updating the doc before they leave the room, that is a seniority behavior. Juniors need it modeled for a year. Seniors do it on reflex. And they get quietly annoyed when leadership does not. Watch for that annoyance. It is a signal worth more than most engagement surveys.
When a team is missing that bench, the doc rots inside a month, because nobody owns keeping it honest. Then the hallway decisions creep back in to fill the vacuum. That is a hiring gap wearing a process failure as a disguise.
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 figure is the one that matters here. Think about who actually installs a clarity discipline and then keeps defending it when some impatient executive wants to cut it for speed. That is your senior bench. Lose one of them at the nine-month mark and you do not just lose a headcount. You lose the one person who still remembered why the system existed, you lose the reason the discipline held, and you watch the hallway decisions come flooding right back in to fill the space they left. If your senior bench is thin, KORE1’s engineering staffing and software engineer staffing teams place that level of talent, usually on a direct hire basis. We benefit when you cannot staff that bench on your own. Worth saying out loud.
The Bottom Line for VPs and CTOs
A priority you only said out loud is not a priority. It is a preference with good intentions. Engineers cannot ship a preference. They can ship a sentence in a doc that has a name and a date on it, which is the entire difference between a team that moves and a team that mills around waiting to be told what changed.
If your priorities live in your head and your hallways, you are not leading the team. You are the single point of failure it has learned to route around. Fix that one thing and you will be surprised how much of what you thought was a velocity problem was a writing problem all along.
If you want to pressure-test where your team’s priorities actually live, connect with me on LinkedIn. And if the real gap is the senior bench that keeps the discipline honest, KORE1’s engineering hiring team can help you start the search.
Questions Leaders Ask Me About Writing Priorities Down
Isn’t documenting priorities just process for the sake of process?
No. Documenting a priority removes a guess. It does not add a gate. The test is whether writing it down stops two engineers from building toward different finish lines. If it does, it earned its keep.
Process for its own sake protects whoever owns the process. Writing priorities down protects the people doing the work, which is the opposite thing even though they can look identical on an org chart. If a step exists so someone can prove they were consulted, cut it. If it exists so the next engineer knows what to do without asking you, keep it and stop apologizing for it.
What is the smallest version of this that actually works?
One link, one owner, one sentence. A single pinned doc that names this quarter’s top outcome and the person who owns changes to it. Everything past that is refinement you add only when the lack of it starts to hurt.
Teams overbuild this constantly. They stand up a whole prioritization framework before they have proven they can keep one sentence current. Start embarrassingly small. Get the habit of updating the doc in the room before you ever worry about templates, tiers, or tooling. The discipline is the asset. The structure is just where you hang it.
Slack is where our decisions happen. Doesn’t that count as written down?
Written, yes. Findable, no. A decision buried in a thread from three Tuesdays ago is technically text and functionally gone. The real question is not whether it was typed. It is whether anyone can find it without asking you.
Chat is where decisions get made, and that is fine. The failure is treating the chat log as the record. Nobody scrolls back three weeks to reconstruct what was agreed. They ask the nearest person who might remember, and now you are back in the hallway. Make the rule that any decision worth keeping gets copied out of the thread and into the board the same day, with a link back if you want the context.
Executives keep setting priorities in hallway conversations. How do I get them to stop?
You do not stop the conversations. You capture them. Every hallway decision gets typed onto the board, visibly, within the hour, until the executive starts going to the board first because it is faster than repeating themselves to six people.
Fighting the behavior head-on loses. Senior people decide in motion. That is part of why they are senior. What you can change is what happens in the next sixty minutes. Become the person who reliably turns their hallway call into a written, attributed line everyone can see. Do it enough and two things happen. The team stops getting whiplash, and the executive starts to trust the board as the faster channel. You are not policing them. You are giving their decisions a place to land.
Is a priority doc just a roadmap by another name?
A roadmap is where you are going. A priority doc is what you are doing this week and what you have explicitly agreed not to do. Roadmaps inspire the board. Priority docs prevent the arguments that eat your sprints.
I have watched teams point at a beautiful annual roadmap as proof they had their priorities straight, while the actual week-to-week work was decided by whoever caught the VP between meetings. The roadmap was real and useless at the same time, because it operated at a quarter’s altitude and the hallway decisions operated at a Tuesday’s. You need both. Just do not let the existence of the roadmap convince you the Layer 2 problem is solved. It almost never is.