- Published on
Engineering Leadership: Decision-Making
- Authors
In Part 1 of this series, we introduced the core responsibilities of engineering leadership - from team mentorship to stakeholder management. This second part focuses on one of the most defining aspects of the role: decision-making.
Engineering leaders make decisions constantly. Some are small and reversible - which library to use, how to structure a module. Others are high-stakes and difficult to undo - choosing a cloud provider, restructuring a team, or deciding whether to rewrite a system. What separates effective leaders from the rest is not the ability to always make the right decision, but the ability to make good enough decisions at the right time, with the right people, and with the right level of transparency.
We'll explore the types of decisions leaders face, practical frameworks for navigating them, and how to communicate decisions in a way that builds trust and alignment.
Table of Contents
- Types of Engineering Decisions
- Navigating Ambiguity
- Balancing Speed and Quality
- Decision-Making Frameworks
- Communicating Decisions
- Common Pitfalls
- Conclusion
- Appendix: Recommended Resources
Types of Engineering Decisions
Not all decisions carry the same weight. One of the first skills an engineering leader develops is recognising which decisions need deep deliberation and which just need momentum. The table below breaks down the two key dimensions.
Reversible vs Irreversible Decisions
Jeff Bezos famously distinguished between "one-way door" and "two-way door" decisions. This mental model is incredibly useful for engineering leaders.
| Decision Type | Characteristics | Examples | Approach |
|---|---|---|---|
| Reversible (Two-Way Door) | Low cost to undo, limited blast radius, can be iterated on | Choosing a testing framework, API response format, feature flag scope | Decide quickly, delegate where possible, iterate |
| Irreversible (One-Way Door) | High cost to reverse, affects architecture or team structure long-term, often involves external commitments or contracts | Cloud provider migration, major rewrite, team restructuring | Invest time in analysis, consult broadly, document clearly |
Examples:
- A Tech Lead identifies that a library choice for a new service is a two-way door decision and empowers a senior developer to make the call, saving the team days of deliberation.
- An Engineering Manager recognises that migrating from a monolith to microservices is a one-way door and initiates a cross-team RFC process before committing.
Some decisions are consequential and irreversible - these are one-way doors. But most decisions aren't like that. They are changeable, reversible - they're two-way doors. - Jeff Bezos
Technical vs Organisational Decisions
Engineering leaders straddle both technical and organisational domains. Knowing which hat to wear - and when - matters.
| Domain | Key Decisions | Common Stakeholders |
|---|---|---|
| Technical | Architecture choices, build vs buy, technology selection, API design, data modelling | Tech Lead, Solution Architect, Senior Engineers |
| Organisational | Team topology, hiring priorities, process changes, on-call rotations, cross-team collaboration models | Engineering Manager, Team Lead, VP Engineering |
| Hybrid | Platform investments, technical debt prioritisation, build vs buy with budget implications, migration timelines | All leadership roles |
The hybrid decisions are often the hardest because they require both technical depth and organisational awareness. A decision to prioritise paying down technical debt, for example, is as much a business case as it is a technical one.
Navigating Ambiguity
One of the most uncomfortable realities of engineering leadership is that you rarely have all the information you need. Requirements are unclear, timelines shift, and the market doesn't wait for your analysis to finish.
Effective leaders develop a tolerance for ambiguity and a set of practices to navigate it:
Timebox your analysis: Set a deadline for the decision. If you don't have 100% clarity by then, decide with what you have. Waiting for perfect information is itself a decision - and often the wrong one.
Separate the decision from the outcome: A good decision can still lead to a bad outcome. What matters is whether you followed a sound process with the information available at the time.
Seek diverse input, not consensus: Consensus-driven decisions often produce watered-down results. Instead, gather diverse perspectives, listen carefully, and then make the call. Not everyone needs to agree - but everyone needs to feel heard.
Examples:
- A Solution Architect is asked to choose between two competing database technologies for a new product. Neither is a clear winner. Rather than analysing indefinitely, they run a two-week spike with two small teams, compare results, and make a decision based on real data rather than speculation.
- A Team Lead is uncertain whether to adopt a new deployment strategy mid-sprint. They consult the team, timebox the discussion to one hour, and commit to a trial run with a rollback plan if it doesn't work.
In the face of ambiguity, refuse the temptation to guess - but also refuse the temptation to wait forever. - Will Larson, Author of An Elegant Puzzle
Decision Confidence vs Time Cost of Gathering Information
The chart above illustrates a pattern most leaders recognise intuitively: the marginal gain in confidence diminishes rapidly beyond about 60-70% of available information, while the time cost of gathering more data continues to climb. The sweet spot for most decisions sits somewhere around that threshold - enough information to be directionally correct, without paralysis.
Balancing Speed and Quality
This is perhaps the most persistent tension in software engineering. Ship fast and accumulate debt? Build carefully and risk missing the window? The answer, as with most things in leadership, is it depends - but there are principles that help.
| Context | Lean Toward Speed | Lean Toward Quality |
|---|---|---|
| Early-stage product | Validate assumptions quickly, expect to throw code away | Invest in core data models and APIs that are hard to change later |
| Mature product | Feature flags and incremental rollouts allow fast iteration with lower risk | Core infrastructure changes need thorough review and testing |
| Regulatory environment | - | Compliance requirements (GDPR, HIPAA, PCI-DSS) demand quality-first |
| Team experience | Experienced teams can move fast without cutting dangerous corners | Junior teams benefit from guardrails, code review, and deliberate pace |
| Customer-facing vs internal | Internal tools can tolerate more rough edges | Customer-facing systems demand polish and reliability |
Examples:
- A Tech Lead at a startup pushes the team to ship an MVP with known limitations, documenting the technical debt explicitly in the backlog so it doesn't become invisible.
- An Engineering Manager at a fintech company insists on a full security review before launching a payments feature, even though it delays the release by two weeks. The cost of getting it wrong far outweighs the cost of being late.
Move fast and break things is great advice - until you're the one responsible for fixing what broke at 2am on a Saturday. - Charity Majors, Co-founder of Honeycomb
Short-Term Velocity vs Long-Term Maintainability
Decision-Making Frameworks
Frameworks don't make decisions for you, but they bring structure to what can otherwise feel chaotic. Two frameworks stand out as particularly useful in engineering organisations.
DACI: Driver, Approver, Contributor, Informed
DACI is a decision-making framework that clarifies roles and prevents the "too many cooks" problem.
| Role | Responsibility | Example |
|---|---|---|
| Driver | Owns the process, gathers input, proposes a recommendation | Tech Lead drafting a proposal for a new CI/CD pipeline |
| Approver | Has final authority, signs off on the decision | Engineering Manager approving the proposal after review |
| Contributor | Provides input, expertise, and feedback - but does not have a vote | Senior engineers, DevOps, QA leads offering technical input |
| Informed | Notified of the decision after it's made, does not participate in the process | Product managers, other teams affected by the change |
The power of DACI is that it separates input from authority. Contributors don't need to agree - they need to be heard. The Approver doesn't need to do the analysis - they need to trust the process and the Driver.
RFCs and ADRs: Documenting Decisions
For significant decisions, written documentation creates accountability, enables asynchronous input, and serves as institutional memory.
- RFCs (Requests for Comments): A proposal document circulated before a decision is made. Team members can comment, question, and suggest alternatives. Works well for architecture decisions, major refactors, or process changes.
- ADRs (Architecture Decision Records): A lightweight record of what was decided, why, and what alternatives were considered. ADRs are invaluable when a new team member asks "why did we build it this way?" six months later.
Examples:
- A Solution Architect writes an RFC proposing a migration from REST to GraphQL for a specific service. The document includes trade-offs, migration cost estimates, and a rollback plan. After a week of asynchronous comments, the team aligns on a phased approach.
- A Tech Lead creates an ADR after the team decides to use PostgreSQL over MongoDB for a new service, documenting the reasoning (relational data model, ACID compliance needs) so future engineers understand the context.
The best time to document an architectural decision is when you make it. The second best time is now. - Michael Nygard, Creator of the ADR format
Communicating Decisions
A decision that isn't communicated well might as well not have been made. Engineering leaders spend as much time explaining and selling decisions as they do making them.
Key principles for communicating decisions effectively:
- State the decision clearly: Don't bury it in context. Lead with the outcome.
- Explain the "why": People can disagree with a decision but still commit to it - if they understand the reasoning.
- Acknowledge trade-offs: Pretending there are no downsides erodes trust. Be honest about what you're giving up.
- Define what "disagree and commit" means: Borrowing from Amazon's leadership principle, it's okay for people to disagree - but once a decision is made, the team moves forward together.
- Follow up: Revisit decisions after a reasonable period. Did the expected outcomes materialise? What would you do differently?
Examples:
- An Engineering Manager sends a concise Slack message after a decision is finalised: "We've decided to go with Approach B for the auth migration. Here's the ADR with full context and rationale. We considered Approaches A and C - the ADR covers why we didn't go with them. Questions welcome, but we're committing to this direction as of Monday."
- A VP of Engineering presents a quarterly review to leadership, showing that a decision to delay a feature launch by one sprint led to a 40% reduction in post-launch bugs, reinforcing the value of quality-focused trade-offs.
Common Pitfalls
Even experienced leaders fall into decision-making traps. Awareness is the first step toward avoiding them.
| Pitfall | Description | How to Avoid |
|---|---|---|
| Analysis Paralysis | Over-analysing to the point of inaction, often driven by fear of making the wrong call | Timebox decisions, accept "good enough," use the reversibility test |
| HiPPO Effect | The Highest Paid Person's Opinion dominates, regardless of merit | Use structured frameworks (DACI), encourage dissent, weight arguments over authority |
| Sunk Cost Fallacy | Continuing with a failing approach because of already-invested resources | Regularly reassess, make it safe to change direction, celebrate "smart pivots" |
| Consensus Trap | Seeking universal agreement leads to slow, diluted decisions | Aim for alignment, not consensus; be clear about who the Approver is |
| Decision Fatigue | Too many decisions degrade quality; leaders who decide everything burn out | Delegate reversible decisions, empower senior engineers, establish defaults and conventions |
| Invisible Decisions | Decisions made without documentation or communication, leading to confusion and inconsistency | Document with ADRs, communicate proactively, create a decision log |
The biggest risk is not taking any risk. In a world that is changing really quickly, the only strategy that is guaranteed to fail is not taking risks. - Mark Zuckerberg
Conclusion
Decision-making is the thread that runs through every responsibility we explored in Part 1. Whether you're mentoring a junior developer, setting a technical direction, or negotiating with stakeholders, the quality of your decisions - and how you make them - defines your effectiveness as a leader.
The key takeaways:
- Classify decisions by reversibility and domain before investing effort.
- Embrace ambiguity - waiting for perfect information is often more costly than acting on good-enough information.
- Use frameworks like DACI and ADRs to bring structure and transparency.
- Communicate clearly - a well-made decision poorly communicated is a poorly made decision.
- Avoid common traps - awareness of pitfalls like analysis paralysis and the HiPPO effect goes a long way.
In the next post, we'll explore communication and influence - how engineering leaders build alignment across teams, manage up effectively, and navigate difficult conversations.
Appendix: Recommended Resources
Books:
- An Elegant Puzzle: Systems of Engineering Management by Will Larson - Practical advice on engineering management, including decision-making at scale.
- Thinking in Bets by Annie Duke - A framework for making better decisions under uncertainty, drawn from professional poker.
- The Hard Thing About Hard Things by Ben Horowitz - Real-world stories of making tough calls in high-pressure environments.
- Turn the Ship Around! by L. David Marquet - On pushing decision-making authority to the people closest to the information.
Articles:
- "Documenting Architecture Decisions" by Michael Nygard - The original ADR proposal.
- "Speed as a Habit" by Dave Girouard - On making speed a core value without sacrificing quality.
- "How to Make Decisions" by Farnam Street - A collection of mental models for better decision-making.
Videos:
- Decision Making for Leaders - A talk on structured approaches to leadership decisions.
- Jeff Bezos on One-Way and Two-Way Doors - Bezos explaining his decision-making framework in his own words.