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.

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.

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.

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:

Invisible Decision | Documented Decision

Where it lives | Code comment, developer memory | Accepted spec, ticket update, test case

Who can see it | The person who made it | The whole team

When it surfaces | At customer demo, production incident | During review, sprint planning

Who's accountable | Individually (the person who should have raised it) | Collectively (the team that approved it)

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.

The honest part

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.

What you saw in this lesson

Two features have now been delivered incorrectly or incompletely. One was built against the wrong concept because the concept was never defined together. One shipped with a critical business rule decided alone, in a code comment, under time pressure.

The team is working harder than before. The problems are the same.

In the next lesson, a third consequence surfaces, one that will make the cost of these invisible decisions concrete in a way nobody on the team anticipated.