Technical decision making that doesn't stall the team

The real problem is rarely the decision

Technical decision making fails in organizations far more often than technical judgment does. In years of leading architecture teams and owning technical direction for enterprise accounts, I can count on one hand the disasters caused by a genuinely wrong technical call made with full information. I cannot count the ones caused by decisions nobody made, decisions everybody relitigated, decisions made by the loudest person in a meeting nobody documented, and decisions whose reasoning evaporated the day their author changed jobs.

So this article is not about how to be right. It’s about the machinery around decisions — who makes them, how disagreement is processed, what gets written down — because that machinery, not raw intelligence, is what separates teams that compound from teams that thrash.

Sort every decision by the cost of being wrong

The first move in any decision is deciding how much process it deserves. Jeff Bezos’s framing in Amazon’s 2016 shareholder letter is the best one-liner in the field: some decisions are one-way doors and some are two-way doors, and treating them the same is fatal in both directions.

	Two-way door (reversible)	One-way door (hard to reverse)
Examples	Library choice, internal tooling, service boundaries you control, most refactors	Data platform, public API contracts, auth architecture, vendor lock-in, compliance boundaries
Who decides	The team doing the work	Senior owner, with review
Speed	Days. Bias to action	Weeks. Bias to evidence
Documentation	Lightweight ADR	Full ADR + review record
Wrong call costs	A sprint of rework	Years, or a migration program

Most organizations get this exactly backwards: heavyweight governance smeared uniformly over everything, which slows the two-way doors to a crawl while the actual one-way doors — often disguised as small choices, like “we’ll just store that in the vendor’s proprietary format for now” — slip through unexamined because they didn’t look big enough for the process.

The highest-leverage question I teach architects to ask is not “what’s the best option?” but “what would reversing this cost in eighteen months?” That one question sorts 90% of decisions correctly, and it’s also how I keep review boards scoped to decisions that deserve them.

Write decision records, but for the right reason

An architecture decision record is a page or less: context, options considered, decision, consequences. The format matters far less than the habit. What matters is why you keep them, because teams that adopt ADRs for the wrong reason abandon them in a quarter.

The wrong reason is compliance — producing artifacts because governance asked. The right reasons:

1. ADRs kill relitigation. The most expensive meeting in engineering is the one deciding, for the third time, something already decided. With a record, the conversation changes from “I think we should reconsider” to “which assumption in ADR-014 has changed?” If none has, there’s no meeting. If one has, that’s a legitimate reopening — on evidence.
2. ADRs preserve reasoning across turnover. Every long-lived system is full of choices that look wrong out of context. The record is how the next architect learns which oddities are load-bearing tradeoffs and which are accidents safe to fix. On the accounts I led, where systems outlive any individual’s tenure by a decade, this was not a nice-to-have.
3. Writing exposes weak reasoning before it ships. A decision that sounds solid in a meeting frequently falls apart when you must write the “options considered” section honestly and discover you considered one.

Keep them in the repository next to the code, numbered, immutable once accepted (superseded, never edited). Two paragraphs is a fine ADR. Ten pages is not an ADR; it’s a document nobody will read.

Disagree and commit, done honestly

Every consequential decision leaves someone in the room unconvinced, and what happens next determines whether your organization can decide at all. The failure modes are symmetric: consensus cultures where any dissenter holds a pocket veto and decisions take quarters, and authority cultures where dissent is career-limiting and the leader’s blind spots ship straight to production.

Disagree-and-commit is the narrow path between them, but only when all three parts are real:

• The disagreement gets a full hearing first. Not a token agenda slot — a genuine one, where the dissenter can change the outcome. I ask dissenters to argue their case in writing in the ADR’s options section, which both sharpens the argument and permanently records that it was heard. Half the time, being demonstrably heard is most of what the dissenter needed.
• The commit is total. After the call, executing at 70% enthusiasm while waiting to be proven right is sabotage with plausible deniability. I say this explicitly to teams: you may reopen the decision when its recorded assumptions break; you may not slow-roll it in the meantime.
• The leader commits to their side too. When I overrule an architect and the decision goes wrong, the accountability is mine — publicly. Disagree-and-commit collapses instantly if the deciders quietly reassign blame downward when their calls fail. This is servant leadership applied to decisions: authority and accountability travel together.

And the precondition for all of it: it must be explicit who decides. Most decision paralysis I encounter isn’t disagreement at all — it’s that nobody in the room knows whether they’re advising or deciding. Name the decision-maker before the debate starts, not after it deadlocks.

Review boards that help instead of perform

I chaired a solution review board at DXC, and I inherited the skepticism most engineers have about them, because most deserve it. The degenerate form is familiar: a weekly gate where delivery teams present finished designs to people with no context, collect nitpicks about diagram formatting, receive a rubber stamp, and leave having lost a week. Everyone’s incentive is to get through it, so teams present late — when changes are impossible — and the board reviews theater, not architecture.

What I changed, and what I’d tell anyone building one:

• Narrow the charter to one-way doors. The board reviews decisions that are expensive to reverse: security boundaries, data architecture, external contracts, major vendor commitments. Everything else is explicitly not the board’s business. This single change removed most of the queue and most of the resentment.
• Review early, when it’s cheap to be wrong. The valuable review happens at the “two options on a whiteboard” stage, not the “deck is finished” stage. We invited teams to bring problems, not just answers — and the sessions where a team brought a genuine open question were the ones that produced measurably better designs.
• Materials in advance, questions in writing, meeting for argument only. The anti-pattern is a live read-through. We required the design doc 48 hours ahead and written questions back before the session, so the meeting itself spent its time on the two or three points of real contention.
• The board’s output is an ADR, not a verdict. “Approved” is a useless artifact. “Approved, having considered X and rejected it because Y, with consequence Z accepted” is an asset the account keeps forever.
• Measure the board by designs it improved. If presenters never leave saying “that was worth it,” the board is a tax, and taxed teams route around governance — which is precisely how one-way doors end up unreviewed.

The honest tradeoff: a good board still costs time, and adding one to an organization that hasn’t sorted decisions by reversibility just builds a better-run bottleneck. Sort first, then gate the small set that deserves gating.

What this looks like in practice

The whole system compresses to four sentences. Sort every decision by the cost of reversing it, and push the reversible ones down to the people closest to the work. Name the decider before the debate. Record the reasoning in an ADR — especially the options you rejected. Hear dissent fully, then commit fully, and reopen only on evidence.

None of it requires tooling, budget, or reorganization — which is exactly why it’s a fair test of leadership rather than resources. It’s also the foundation the rest of the job builds on: at account scale, where I owned technical direction for clients’ businesses, the decisions got bigger but the machinery stayed the same. It still does. Tools and titles have changed around this system; the sorting question hasn’t.