Decision Feedback Delay

An engineer writing code learns whether they were right in minutes: the test fails, the deploy goes red, the profile shows the hot path. An architect choosing a data model, a service boundary or a build-versus-buy learns in a year or three, usually after reorganisations have moved the people involved. That gap is the defining difficulty of the job.

The consequence is not merely slow learning. It is that nothing forces learning at all. A decision that quietly costs a quarter of rework in 2027 produces no event that points back at 2025, so the same reasoning gets applied again with undiminished confidence. Ten years of this produces experience without calibration: strong opinions, no error bars.

Why it matters

Architectural seniority is largely a claim about judgement, and judgement is a claim about a track record. Without a closed loop, the track record is a memory, and memory selects for the decisions that turned out well. This is why the interview question "tell me about a decision you got wrong" is so discriminating: it tests whether a loop exists, not whether the candidate is humble.

The organisational consequence is worse than the personal one. A company where decisions are never revisited accumulates architecture whose justifications have expired: a service split made for a team structure that no longer exists, a datastore chosen for a scale that never arrived, a cache added for a query that was deleted.

Implementation patterns

• Write the falsifying signal into the decision record. Not "we assume moderate growth" but "we assume peak writes stay under 2,000 per second; at 5,000 a single primary stops being sufficient and this decision should be revisited". A number makes the record checkable by anyone with a dashboard.
• Record confidence per assumption. "80% confident, and here is what would move it" turns the record into something a future reader can grade, and grading it is the only way to discover whether you are systematically over- or under-confident.
• Schedule the revisit. A calendar entry or a recurring review item at the horizon where the assumption should have resolved — 6, 12, 18 months — attached to a rota rather than a person, because the person will have moved.
• Tie the record to a dashboard. The assumption's number should be a metric with an alert, so the revisit is triggered by the system rather than by diligence.
• Keep a personal decision log. A page per significant decision with the constraints, the choice, the confidence and the expected consequence, reviewed twice a year. It is the only way an individual accumulates calibration when their employer will not.
• Shorten the loop where the design allows it. Prefer a decision whose first consequence arrives in weeks: a slice in production, a canary, a load test at 3x, a spike deliberately taken to the failure point. Choosing the design that produces evidence sooner is worth real money.

Industry example

The practice that most directly targets this is the architecture decision record, popularised from about 2011 onwards, and the reason mature versions of it include context and consequences sections is precisely the delay: the author is writing for a reader who will arrive without the context and with the consequences in hand. Teams that keep decision records and go back to annotate outcomes are unusual, and they are the ones able to say why a boundary exists.

The counter-example is visible in every large legacy estate: a component everyone routes around, whose original justification nobody can state, kept because the cost of finding out is unknown and the cost of leaving it is diffuse.

Failure scenarios

• Confident repetition. The same architect makes the same class of choice across three employers, having never seen the third year of any of them.
• Cargo-culted boundaries. A service split preserved long after the team structure that motivated it, because the reasoning was never recorded.
• Blame landing on the wrong decision. An incident in year two is attributed to whatever changed last week, because the decision that made it possible is invisible.
• Expired justifications. A design defended by a requirement that was dropped, which nobody can challenge because nobody can find the requirement.
• Survivorship in war stories. A team's shared narrative contains the successes with mechanisms and the failures as bad luck.

Trade-offs

Closing the loop costs writing that feels bureaucratic at the time it is cheapest to do. A decision record with assumptions, confidences and triggers takes an hour; most of those hours are spent on decisions that turn out not to matter. The payoff is concentrated in the few decisions that do, and you cannot tell which in advance, which is the same argument as for tests.

The alternative worth naming is deliberately reducing the delay rather than instrumenting it: build the slice, run the load test, take the spike to failure. That costs delivery time now and buys evidence instead of a record, and where it is available it is the better trade.

When not to use it

Do not instrument decisions that are cheap to reverse. A choice affecting one service that can be undone in a fortnight should be made quickly and tried, and writing a record with triggers for it is ceremony. Reserve the practice for decisions with a long shadow: data models, external contracts, retention, security boundaries, anything other teams will couple to. The test is the reversal cost, not the seniority of the person deciding.

Interview question

Q: How do you know whether your architectural judgement is improving? Be concrete about the mechanism, not the attitude.

What a strong answer covers: naming the delay as the structural problem, 12 to 36 months with people moving; the mechanisms that close the loop — assumptions with numbers and confidences in the record, a scheduled revisit owned by a rota, the assumption wired to a metric; a personal decision log because employers rarely provide one; and the stronger move of preferring designs whose consequences arrive in weeks, with an example of a decision the candidate deliberately structured to produce early evidence.

Quick check

Quiz: Why does an architect's error rate not self-correct the way a programmer's does? Because the consequence arrives 12 to 36 months later, often to a different team, so no event points back at the decision.

Flashcard: What single line makes a decision record re-evaluable? — The assumption stated as a number with the threshold that falsifies it, ideally wired to a metric, so a future reader can check it against a dashboard.