Technical Decisions

The core skill of senior engineering is not knowing the right answer. It is making a good call when there is no right answer — only trade-offs. Junior engineers ask "which is correct?"; senior engineers ask "which trade-off are we choosing, and who is it for?"

Most consequential technical decisions have no clean winner. Postgres or DynamoDB, monolith or services, build or buy — each option is better on some axis and worse on another. The value a senior adds is rarely the choice itself. It is naming the trade-off explicitly so the team is deciding on purpose rather than drifting into a default nobody examined.

Judgment Under Uncertainty

You will almost never have complete information. Waiting for it is itself a decision — usually a bad one, because the cost of delay compounds while the information rarely arrives.

• Decide with the information you have, and write down what would change your mind. A decision you can revisit when an assumption breaks is far stronger than one made in false certainty.
• Separate the reversible from the expensive-to-reverse. Most of the agony goes into decisions that didn't deserve it.
• A made decision beats a perfect decision made too late. The team can move; you can correct course. A team stalled on a fork moves on nothing.

The discomfort of deciding without certainty never goes away. Getting comfortable being uncomfortable is the job.

Reversible vs Irreversible

Bezos's framing: some decisions are one-way doors (hard or impossible to walk back), most are two-way doors (cheap to reverse if wrong). Match the speed and rigor of the decision to which kind it is.

The common mistake is treating reversible decisions as if they were irreversible — three weeks of debate over a logging library you could swap in an afternoon. The rarer but worse mistake is the reverse: shipping a public API or a schema in a day because "we can change it later," when you can't.

Bias to action on the two-way doors. They are the majority. Speed there buys you the time and credibility to be careful on the few that matter.

Who Decides

Decision-by-committee is how reversible decisions become irreversibly slow. Every decision needs a single owner — a single-threaded owner who is accountable for the call and for living with it. Consultation is wide; the decision is not.

Two frameworks worth knowing:

• DACI — Driver (runs the process), Approver (the one who decides), Contributors (consulted for expertise), Informed (told after). One Approver. If there are two, there is no Approver.
• RAPID — Recommend, Agree, Perform, Input, Decide. Same idea, different letters; the D is singular.

The mechanic that makes this work socially is disagree and commit. People are consulted, they argue their case, the owner decides — and then everyone, including the dissenters, executes as if it were their own call. Re-litigating a decided question in the hallway is corrosive. You get one venue to disagree; after the decision, you commit or you escalate, you don't undermine.

A team where every decision needs consensus doesn't get safety. It gets paralysis dressed up as inclusion.

A Practical Evaluation Approach

When a decision is big enough to warrant structure, the same sequence works almost every time:

1. State the decision and the constraints. One sentence: "We need to pick a queue for X, must handle Y throughput, team knows Z, deadline is W." Vague decisions produce vague debate.
2. Enumerate the real options — including do-nothing. Three to five genuine candidates. "Keep what we have" is always on the list; often it wins. Two options is usually a false binary hiding a third.
3. Define the criteria and weight them. Operational cost, time-to-ship, team familiarity, failure blast radius, lock-in. Weight them before you score, or you'll weight them to justify the answer you already wanted.
4. Name the assumptions. "This assumes traffic stays under 10k rps" and "this assumes we still own this service in two years." Assumptions are where decisions rot — make them visible.
5. Pick, and write down why. The reasoning matters more than the choice. A documented "we chose B over A because we valued operational simplicity over raw throughput, given our scale" lets future-you re-evaluate when the scale changes.

The structure is not bureaucracy. It is the difference between a decision and a vibe.

Build vs Buy vs Adopt Open Source

The most expensive errors here come from comparing the wrong numbers. Engineers compare a license fee to "free, we'll just build it." The license fee is almost never the real cost.

• Build — you own it forever. Every dependency it grows, every on-call page it generates, every engineer-month it diverts from your actual product is the cost. Build when it is core differentiation, not when it is undifferentiated plumbing.
• Buy — you pay money to not own a problem. The real questions are lock-in, the cost of integrating and operating it, and what happens to your data if the vendor dies. The sticker price is the cheap part.
• Adopt open source — "free" as in puppy. You inherit maintenance, upgrades, CVEs, and the bus factor of a project that may go dormant. Sometimes excellent; never costless.

Frame all three against maintenance and opportunity cost, not the line item. The right question is "what is the most valuable thing the team is not building because it's building this?"

Translating Decisions Into Business Impact

A technical decision that the people funding the work don't understand is a decision you will lose. Senior engineers translate. The skill is restating an engineering concern in the terms of the person across the table — cost, risk, time-to-market, revenue.

You are not dumbing it down. You are stating the consequence in the currency the decision-maker is accountable for. The same translation works upward to executives and outward to product — speak the language of the people who fund the work, and you get to keep making the calls.

This is also where decisions connect to cost discipline — see FinOps — and to the longer arc of where the system is going, in Technical Strategy.

Record the Decision and the Reasoning

Decisions rot. Six months on, the context that made a choice obvious has evaporated, and someone — often future-you — finds a "weird" decision and is one step from reverting it without knowing why it was made.

The fix is cheap: write it down. Capture the context, the options considered, the choice, and the reasoning and assumptions behind it.

• For decisions of record, use an ADR — short, immutable, kept in the repo next to the code it governs.
• For the deeper exploration before a big call, an RFC or design doc carries the analysis and the consultation.

The thing future-you needs is not what you decided — that's visible in the code. It's why, and what you would have needed to be true for it to still hold.

Failure Modes

• Analysis paralysis. Endless evaluation of a two-way door. The cost of deciding wrong is lower than the cost of not deciding; pick and move.
• Bikeshedding. The team spends more energy on the trivial-and-familiar (tabs vs spaces, the logging library) than on the load-bearing-and-hard, because everyone has an opinion on the easy thing.
• HiPPO decisions. Highest-Paid Person's Opinion wins regardless of merit. Corrosive when the HiPPO is furthest from the work and nobody surfaces the trade-off.
• Reversible treated as irreversible. Weeks of ceremony for a thing you could change in an hour.
• Irreversible treated as reversible. Shipping a public contract or a shared schema fast because "we'll fix it later" — and you can't.
• Deciding too early. Locking in before you have the cheap information that's arriving next week, when waiting costs nothing.
• Refusing to decide. Letting the decision make itself by default or attrition, then disowning the outcome. Not deciding is deciding — own it.

Pre-Commit Question

Before you commit to a technical decision:

Can you state the trade-off you're choosing, who inherits it, and what would make you reverse it?

If yes, you've made a decision. If no, you've made a guess wearing a decision's clothes.