The Technical Leader’s Real Job: Make Decisions Legible

Written in a personal capacity. Views are the author’s own.

Senior technical leaders are often pulled in when a consequential decision is stuck. The platform team wants to standardize. Product wants to ship. Security wants more evidence. Finance sees a commitment that will be expensive to unwind. Everyone asks for “the answer.”

Giving the answer can feel like leadership. It is usually the smaller part of the job.

The harder job is to create a system in which people can see how a decision should be made: what context matters, which options are real, where the trade-offs sit, who has authority, what can be reversed, and what happens after the meeting. I call this decision legibility.

A decision is legible when someone who was not in the room can reconstruct why it was made and act without another round of interpretation. Executive, product, and engineering groups rarely disagree only about technology. They carry different time horizons and definitions of risk.

The senior leader’s role is not to erase those differences. It is to make them usable.

Most “alignment problems” are information-shape problems

Consider a company deciding whether to buy a managed retrieval platform for an AI product or build the capability internally. The executive sponsor hears “six months faster.” Product hears “less control over the roadmap.” Engineering hears “proprietary data model and migration cost.” Security hears “a new processor in the data path.”

Put those statements into four separate meetings and the organization appears political. Put them into one decision frame and the disagreement becomes tractable. The groups are answering different questions.

Weak decision systems rely on social proximity. People who attended the meeting understand the choice; everyone else receives a conclusion stripped of its conditions. Three months later, “use the managed platform for the first release, provided we can export the index and meet the regional data requirement” has decayed into “architecture mandated Vendor X.” Teams either comply blindly or reopen the whole argument.

This is why documentation is not clerical residue. DORA’s research has found that high-quality documentation amplifies the effect of technical capabilities on organizational performance.¹ For a technical leader, the relevant point is sharper: documentation carries decision context farther than personal authority can.

Use two artifacts, not one giant process

I use a short decision brief before a consequential choice and a durable record after it. They solve different problems.

The brief exists to improve the decision. It should fit on one page whenever possible and state:

• the decision in one sentence, including the deadline;
• the context and constraints that materially narrow the choice;
• the viable options, including “do nothing” when it is genuinely viable;
• the trade-offs in business, product, delivery, operational, and security terms;
• the recommendation and the evidence behind it;
• the named decider, contributors, and people accountable for execution;
• whether the choice is reversible, the cost of reversal, and the review trigger;
• unresolved dissent.

This is a forcing function, not a template for producing prose. If the team cannot name the decider, it does not have a decision. If it cannot describe reversal cost, it does not understand the bet. Options consisting of “our recommendation” and two straw men are consultation theatre.

After the choice, an Architecture Decision Record or a concise RFC preserves the decision in the place future practitioners will look. Michael Nygard’s original ADR formulation is deliberately small: context, decision, status, and consequences, with superseded decisions retained rather than erased.² That history matters. A current architecture is a stack of prior trade-offs, not a collection of timeless truths.

The brief may be written for an executive and product audience; the ADR or RFC may sit with the code and contain implementation consequences. Link them. Do not force one artifact to serve every reader.

Put authority where the information is

“Empower the teams” is incomplete advice. Teams need explicit decision rights and explicit boundaries.

A useful model has one decider, not a committee. Other people contribute evidence, surface consequences, or own execution. The decider should sit as close as possible to the relevant information, while the level of authority rises with the blast radius.

A product team can choose how to rank search results within agreed outcome and safety guardrails. A group that owns a shared data contract decides changes that impose migration work on several teams. A decision that creates a regulated data exposure, a long-term commercial commitment, or an enterprise-wide operating constraint belongs at a different level.

Team Topologies makes a related point through explicit team boundaries and interaction modes, each with a different purpose and cost.³ Decision rights should be equally concrete. “Architecture should be consulted” is vague. “The identity platform owner decides token format; consuming teams can object on interoperability or regulatory grounds; the CTO resolves cross-domain risk by Friday” is operational.

Escalation is part of that design. It should trigger when objectives conflict, authority is unclear, or the downside crosses an agreed threshold. It should not trigger because a senior person has a preference.

Match the ceremony to reversibility

Organizations often apply the heaviest governance to the most visible decisions, not the least reversible ones. That is backwards.

The one-way-door/two-way-door distinction is useful because it connects decision speed to the cost of being wrong. Reversible choices deserve lightweight review, a bounded experiment, and fast feedback. Irreversible or expensive-to-reverse choices deserve more evidence, broader challenge, and explicit exit planning. Amazon’s 2016 shareholder letter describes this distinction and warns against using one process for both.⁴

Selecting an embedding model behind an internal abstraction, with offline evaluation and a shadow rollout, is usually reversible. Discarding source data or signing a multi-year minimum-spend contract is not. “AI platform strategy” is too coarse a label; each layer has a different reversal cost.

Technical leaders should ask teams to make reversible decisions actually reversible. A feature flag without a tested rollback path is theatre. A vendor exit clause without an export test is comfort, not optionality. The practical mechanisms are mundane: small batches, compatibility layers, migration rehearsals, spend caps, and dates at which the evidence will be reviewed.

DORA’s delivery research repeatedly finds that speed and stability are not opposing outcomes, and recommends smaller changes because they are easier to reason about and recover from.⁵ The same logic applies above the code level. Decision velocity comes from reducing the cost of correction, not from becoming more confident in forecasts.

Make dissent part of the record

Consensus is often confused with the absence of visible disagreement. That confusion creates polite meetings and brittle decisions.

A dissenting view should state the specific objection, the consequence if it is right, and what evidence would resolve it. The decider must address the objection, but does not have to accommodate every preference. RFC 7282, written about rough consensus in the IETF, draws this distinction well: technical issues must be considered and answered; unanimity is not required.⁶

Once that happens, “disagree and commit” can be healthy. Without a legible record, the phrase can become an instruction to stop talking. Commitment is earned when the objection is heard, the authority is clear, and the risk is monitored.

Some disputes should move up quickly. If product is rewarded for launch date while operations is accountable for reliability, another architecture workshop will not settle the conflict. The goals need an owner. A good escalation contains the decision brief, the unresolved issue, and the smallest decision the next level must make. It does not forward a month of meeting notes.

Run a cadence that closes the loop

A decision system needs a rhythm, or briefs and ADRs become an archive of good intentions.

A weekly decision review should discuss only choices that are blocked, approaching a deadline, or crossing a risk threshold. It is not a status meeting. Each item should end with a decision, a request for named evidence by a date, or an explicit escalation. Record the outcome while the context is fresh.

A monthly outcome review asks whether prior decisions produced the expected effects. Review the original assumptions, observed signals, execution gaps, and whether the choice should stand, adapt, or be superseded.

This is not a trial of who was “right.” Outcomes contain luck, execution quality, and facts that were unavailable at decision time. The review should improve the decision system. Did the brief omit an affected group? Was the supposed two-way door costly to reverse? Did the team define a metric but fail to instrument it? Did a valid dissent disappear from the final record?

Google SRE’s postmortem practice offers the right posture: document impact and contributing causes, assign preventive follow-through, and keep the inquiry blameless so people continue to surface bad news.⁷ Apply the same discipline to strategic and architectural decisions before they become incidents.

Track a few signals without turning them into quotas: decision time, records with an owner and review date, and follow-up actions closed. A superseded decision may show that the organization learned before the environment forced it to.

The leader should not be the memory of the system

Decision mechanisms can become bureaucracy. Long templates, standing approval boards, and mandatory RFCs for trivial changes will slow work and push real decisions into private channels. The test is whether the mechanism reduces repeated interpretation and shortens responsible action.

The best technical leaders still bring judgment. They notice hidden coupling, ask the question that changes the option set, and know when a technical concern is carrying a business consequence. But they do not make organizational coherence depend on their presence.

Their work is visible when an executive can see the technical constraint without a translation meeting; when a product leader can challenge an architecture choice in outcome terms; when an engineer can understand which decisions are theirs to make; and when a team can reverse course without rewriting history.

Being the smartest problem-solver in the room scales to the room. A legible decision system scales beyond it.

Sources