The Decision Nobody Logged

Monday morning. The team regroups. They're embarrassed by the sprint review - not publicly, but you can feel it in how everyone talks a little faster than usual and avoids the word "urgency."

Priya rewrites the ticket. More detail, more acceptance criteria. She adds a row to the Jira description explaining the difference between urgency and priority.

Tom adds more unit tests around the filter logic - boundary conditions he hadn't covered before.

Maya builds an extended test matrix. Forty cases instead of twenty.

Nobody says what Alex said at the end of the review, so nobody asks the question it implied. Nobody schedules a conversation to answer: Do we all agree on what urgency actually means to the business?

That question would have taken twenty minutes. It doesn't get scheduled.

The fix that missed the problem

Two weeks later, Tom is building the revised urgency filter - the real one, with SLA-risk logic. Mid-Wednesday. Sprint ends Friday. He hits an edge case that wasn't in the spec: jobs with no SLA classification assigned. These are jobs that exist in the system but haven't been categorized yet - no SLA target, no urgency value possible.

The ticket says nothing about this. Priya is in back-to-back stakeholder calls until Thursday. Tom makes a call: treat unclassified jobs as low urgency. It's a reasonable default. He adds a comment in the code.

// Unclassified jobs default to LOW urgency - no SLA assigned
// TODO: discuss with Priya if this is the right business rule

He ships it.

Three weeks later, Priya demos a follow-up feature to a key customer. The customer asks: "Why are all our unclassified jobs marked low priority? Those are our most complex cases. We need them visible, not buried."

Priya didn't know Tom had made that decision. Tom didn't know it was the wrong one. The TODO comment was never discussed.

The edge case that couldn't wait

Two patterns showed up in this sprint, and they're worth naming precisely.

The first is the "work harder in your own lane" reaction - what teams do after a delivery failure when they can't identify the root cause. Priya wrote more detailed tickets. Tom wrote more tests. Maya built a more thorough test matrix. Each response is individually rational. If the problem were that the ticket was too sparse, Priya's response would have fixed it. If the problem were test coverage, Tom's response would have fixed it. The problem was neither. The problem was that three people never reached agreement on what the feature was supposed to do before any of them started working.

Working harder in your own lane when you're all on the wrong road doesn't help. It just gets you further down the wrong road faster.

The second pattern is the Invisible Decision: the moment a spec gap gets filled alone, under pressure, without anyone else knowing it happened.

Spec gaps don't stay empty. When implementation begins and the ticket doesn't cover a case, someone fills the gap. It's not carelessness; it's how development works. The code has to do something with an unclassified job. Tom couldn't ship undefined behavior. He made a call.

The problem isn't that he made the call. The problem is that the call became invisible the moment he made it.

What an invisible decision looks like in practice

A code comment is not shared understanding. It's a note in a file that nobody reads unless they already know to look. Tom intended to raise it with Priya, but intending to raise something is not the same as raising it. The sprint ended. The TODO stayed in the file. Three weeks passed. A customer found the wrong behavior.

Here's the practical difference between an invisible decision and a documented one:

When a decision is invisible, accountability is individual and the detection mechanism is luck. When a decision is visible, the team can evaluate it before it ships.

Tom's decision might even have been the right one. Maybe low urgency is the right default for unclassified jobs. There's a legitimate business argument for it. But nobody in the business knew it was being made, so nobody could confirm or correct it. It was a reasonable answer to a question no one agreed needed asking.

A structural failure, not a documentation failure

Tom did the right thing given his constraints. He was blocked. The sprint was ending Friday. Priya was unavailable. He made a reasonable assumption, he flagged it with a TODO, and he shipped clean code.

The problem isn't the decision; it's that nobody else ever saw it.

The twenty-minute conversation that would have surfaced the "unclassified jobs" question didn't happen before the sprint started. So it happened inside a code comment instead. A code comment is a private note. It sits in one file, visible only to whoever opens that file, and only if they already know to look. Tom's TODO was his intent. It was never anyone else's knowledge. That's not a documentation failure. That's a structural one: the decision was made in the only place that guaranteed nobody else would see it.

Working harder, writing more, testing more thoroughly - this addressed symptoms of a different problem. The failure wasn't in how much anyone wrote or tested. It was in what never got said before the work started. Invisible decisions don't get made because people are careless. They get made because the conversation that would have made them visible was never scheduled.

The spec gap that produced Tom's decision was always there. It was there on Monday when Priya rewrote the ticket. It was there on Tuesday when Tom estimated the story. It was there on Wednesday when Tom hit the edge case. Nobody saw it as a gap because nobody had looked for it together.

These two patterns aren't separate failures. They're connected.

The Invisible Decision that Tom made on Wednesday was downstream of the Semantic Gap that was never closed. When the concept of "urgency" was never agreed before the first sprint, the revised spec for the real urgency filter inherited the same ambiguity - just with more detail around it. The unclassified-jobs case was a gap that existed because nobody had ever asked, together, what the full behavior of urgency classification should be. The spec didn't cover it because the conversation that would have generated that coverage never happened.

This is the structural pattern: a Semantic Gap leaves ambiguity in the spec. The ambiguity produces a gap. The gap gets filled under pressure, alone, invisibly. The Invisible Decision is what happens when the Semantic Gap doesn't get closed in time.

The TODO comment is still in the file. Priya has never read it. The sprint ended on Friday, and on Monday the next sprint started, and the code went to production, and three weeks passed.

Nobody knows about the other implicit assumptions in the codebase. Nobody has thought to look.