The reading room · Digna Legi
Why Engineers Should Invest in Decision Making Skills Early
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. Evidence is sampled with gaps, so completeness and full argumentative quality cannot be fully assessed.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Why read this
Technical debates turn brittle when engineers skip goals and criteria, leaving hidden priorities to masquerade as solution preferences.
AI brief · Checked against source text
The main idea
The piece argues that engineers overtrained in execution often rush from incident or discomfort straight to technical solutions. That shortcut makes debates personal and brittle because participants optimize for different hidden goals. Its proposed “water-shedding” model separates the upstream work of defining the problem, goal, principles, and decision criteria from solution exploration, risk mitigation, decision documentation, communication, and later realignment.
Go a little deeper
The root problem is premature solutioning
The author’s core distinction is not technical versus strategic work; it is sequencing. Engineers may be solving a real pain, such as midnight escalations, while still framing the decision badly. If the goal is unclear, “fix paging,” “reduce false positives,” “modernize old technology,” and “speed buy-in” can all masquerade as the same problem while demanding different solutions and stakeholders.
Criteria reduce both bias and argument
Decision criteria turn a contest of preferred solutions into a shared evaluation method. The piece compares this to hiring: without explicit criteria, people default to liking, disliking, status, and persuasive force. Useful criteria can include time, resources, stakeholder impact, maintainability, observability, reversibility, and whether the choice unlocks future options. The important move is agreeing what matters before defending a favorite answer.
Divergence is disciplined, not endless
The framework asks teams to generate multiple realistic options before choosing, but it also insists on convergence. Evaluation means testing risky assumptions, mapping tradeoffs, and deciding when enough is known. That matters because teams can get trapped in binary debates, chase fashionable technologies, or delay decisions out of fear; the remedy is not more discussion, but better staged discussion.
Communication is part of the decision
A technically sound choice can still fail if affected teams do not understand the reasoning, timing, or consequences. The WhatsApp/Facebook migration example treats alignment as engineering work: a small meeting could prevent months of wasted work, while slow replies from dependent teams still created major side events. Documentation and stakeholder mapping preserve why a decision was made, not just what was chosen.
A case from the article
Zippi’s billing architecture decision
Zippi had to choose how to build credit-card operations around flexible billing cycles. The team first named criteria: business impact, future customization, a six-month/four-engineer development bound, and reversibility. They compared building everything, outsourcing authorization and billing, or using a processor for real-time authorization while keeping billing in-house. The third option was operationally scarier but created a customizable asset that later matched independent workers’ income patterns better than a fixed weekly system.
How the case is made
The case is made through practitioner observation, a decision taxonomy, diagnostic patterns, and named engineering examples from Zippi and WhatsApp/Facebook security work.
Where the idea has limits
The framework is strongest for consequential technical choices involving multiple stakeholders; the piece does not argue that every small engineering choice deserves a full formal process.
A question to take away · from Digna Legi
Where are your team’s current technical debates actually disagreements about criteria rather than solutions?
What the original adds
The source includes a fuller catalogue of criteria, off-track diagnostic labels, stakeholder communication advice, and two practitioner narratives with tradeoffs around migration and financial-product architecture.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.