Make the technical choice you can put your name behind

TL;DR

It is not just acceptable but right to make deliberate technology choices grounded in your own earned judgment — and to put your name on them. When two options would both realistically work, the honest tiebreaker is often “which one can I stand fully behind?” — and that’s a legitimate basis to decide on. The corollary is the hard part: you must be willing to resist pressure that isn’t about the merits — a vendor’s incentives, internal politics, someone’s personal stake, even a leader’s stated preference — because none of those are engineering reasons. Owning the call can cost you political capital in the moment. Spend it deliberately, on the decisions that matter and where you genuinely have the conviction, and over time being right repays it with interest.

Context

Most consequential technology decisions are not “the right answer vs. a wrong one.” They’re two (or more) options that would both basically work, and the choice comes down to judgment, fit, and what you can live with operating for years. That’s exactly the situation where non-merit pressure rushes in: a salesperson who benefits from one vendor, a relationship between someone pushing an option and someone with authority, the comfortable choice everyone already assumed, or simply “leadership prefers this.” These forces are real and they’re strong, and the cheap move is to let the close-enough option win because fighting it is uncomfortable.

But “close enough” and “I can put my name on it” are different things. Deep, relevant experience — years of actually running a thing, knowing its failure modes, its operational reality, its sharp edges — is real information, and it’s yours to weigh. When you have that and the other option is merely “fine,” choosing the one you can stand behind, and owning it openly, is the responsible call. Putting your name on a decision is what accountability looks like; it’s also what makes you trustworthy, because people know you’ll own the outcome either way.

Recommendation

On a close call, decide on the merits and your earned judgment — own it, and don’t let non-merit pressure win by default.

• Use conviction-from-experience as a legitimate tiebreaker. When the options are genuinely close, “which can I operate and stand behind, given what I actually know” is a real, defensible basis — not a cop-out. Deep hands-on experience is information.
• Name non-merit pressure for what it is. A vendor’s incentive, a colleague’s personal stake, a relationship, “the CEO likes X” — these are not engineering arguments. Don’t let them masquerade as the decision; separate them out and weigh the technical case on its own.
• Put your name on it — that’s the point. Owning the decision openly is the accountability that makes the call trustworthy. You’re not hiding behind consensus or a process; you’re saying “this one, and I’ll answer for it.”
• Spend political capital deliberately. This costs something, so save it for decisions that matter and where you truly have the conviction. Don’t burn it on trivia, and don’t confuse ego or stubbornness with earned judgment — that’s the failure mode on the other side.
• It requires real depth — without it, defer. This is not “trust your gut over the data” or “be contrarian.” If you don’t genuinely have the expertise on this specific call, the honest move is to defer to someone who does, or take the safe/standard option (ZFN-30Field Note · currentZFN-30 — Use the standard; don't reinvent the protocolWhen a standard exists for a common or complex problem, use it — don't reinvent the protocol. Standards encode huge adversarial expertise, especially in auth and crypto; a partial implementation beats rolling your own. You're not that special, and your problem isn't either.Open ZFN-30 →, ZFN-32Field Note · currentZFN-32 — Commit to one cloud, and go all-in nativeCloud-independence is a false benefit: portability is the least common denominator, costing you the native services that are the point. For end products you run: commit to one cloud, go all-in native. Libraries, software others run, LLM-embeddables, and edge code are exempt.Open ZFN-32 →). The licence to put your name on it is earned.
• Record the decision and the why (ZFN-1Field Note · currentZFN-1 — Keep engineering decision recordsRecord significant engineering decisions as short, versioned markdown files — context, decision, consequences. Write one for cross-team contracts, directional principles, hard-to-reverse choices, and conventions others must follow. Cite them instead of re-arguing.Open ZFN-1 →) so the reasoning survives and the call is auditable — “here’s why, on the merits” beats “because I said so,” and it protects you and everyone after you.
• Surface business overrides honestly, and make leadership own them. If leadership overrides your technical call for a business reason, that can be legitimate (ZFN-2Field Note · currentZFN-2 — Engineering priority orderingWhen concerns conflict, prioritize security > correctness > availability > performance — and never trade a higher-ranked concern for a lower one. The rule binds the moment you must choose. Cite it instead of re-arguing it.Open ZFN-2 →) — but make it an explicit, owned decision at that level, with the engineering tradeoff on the record, rather than quietly caving and pretending it was the technical choice.

Consequences

Easier:

• Better outcomes on the decisions that compound for years — you choose what you can actually run and stand behind, not the path of least resistance.
• You build real trust and credibility: people learn you’ll make the hard call on the merits and own it, which is worth far more long-term than the capital it costs short-term.
• You can live with your own systems, because you believed in them when it counted.

Harder:

• It costs political capital and creates friction with people pushing other agendas — sometimes friends, sometimes the boss. That’s uncomfortable and sometimes genuinely risky.
• The judgment to tell earned conviction from ego is the whole game, and getting it wrong — digging in on a close call you don’t actually have the depth for — is its own failure.
• The payback is delayed and not guaranteed; you put your name on it now and find out later. You have to be willing to be accountable in the meantime.

References

• ZFN-42Conviction · currentZFN-42 — My one cloud is AWSApplying the one-cloud principle (ZFN-32), my pick is AWS — 100%, a league of its own. Go native: skip Kubernetes, use ECS; lean into SQS, SNS, Kinesis, IAM, ALB, RDS. The one exception to native — provision with OpenTofu, not CloudFormation, now that LLMs write .tf so well.Open ZFN-42 → — a deliberate, conviction-based technology choice (AWS) made with deep platform knowledge, owned openly; ZFN-32Field Note · currentZFN-32 — Commit to one cloud, and go all-in nativeCloud-independence is a false benefit: portability is the least common denominator, costing you the native services that are the point. For end products you run: commit to one cloud, go all-in native. Libraries, software others run, LLM-embeddables, and edge code are exempt.Open ZFN-32 → is the durable principle underneath it.
• ZFN-26Field Note · currentZFN-26 — AI-assisted content needs no disclaimer, only a human who can back itUsing an LLM to draft engineering content — chat, commits, PRs, docs, comments — is fine and needs no disclaimer. The obligation is human co-signing: every word under your name is one you drove, reviewed, and can defend. Disclose when the ideas are the model's, not yours.Open ZFN-26 → — putting your name on something means you own every part of it; you can’t hide behind anything.
• ZFN-2Field Note · currentZFN-2 — Engineering priority orderingWhen concerns conflict, prioritize security > correctness > availability > performance — and never trade a higher-ranked concern for a lower one. The rule binds the moment you must choose. Cite it instead of re-arguing it.Open ZFN-2 → — business-level overrides belong at leadership level, explicit and owned, with the engineering tradeoff documented.
• ZFN-1Field Note · currentZFN-1 — Keep engineering decision recordsRecord significant engineering decisions as short, versioned markdown files — context, decision, consequences. Write one for cross-team contracts, directional principles, hard-to-reverse choices, and conventions others must follow. Cite them instead of re-arguing.Open ZFN-1 → — record the decision and the reasoning, so a close call rests on the merits and survives.
• ZFN-30Field Note · currentZFN-30 — Use the standard; don't reinvent the protocolWhen a standard exists for a common or complex problem, use it — don't reinvent the protocol. Standards encode huge adversarial expertise, especially in auth and crypto; a partial implementation beats rolling your own. You're not that special, and your problem isn't either.Open ZFN-30 → — the other side of the gate: where you lack the depth, defer or take the standard option.

Changelog

• 2026-06-12: First published as a Field Note.