Why Decision Making Is a Leadership Skill

Most engineering leaders have not thought deliberately about how they make decisions. They have a style - consultative, authoritative, consensus-seeking - that they apply without much examination across most situations. The style probably worked well enough to get them to their current role. That does not mean it is working well now.

The reason decision making is a leadership skill - not just a cognitive skill - is that every decision a leader makes sends a signal to the team about what kinds of decisions they are allowed to make themselves. Leaders who make many decisions teach their teams to escalate. Leaders who make few decisions create ambiguity that paralyses action. Leaders who make decisions in ways that exclude relevant people create resentment and poor implementation.

The cumulative effect of a decision-making style is the team's level of autonomy. Not the autonomy you intend or declare - the autonomy that actually exists in practice, measured by the decisions your team makes without you.

The Signal Problem

Engineers are pattern-matching machines. They observe what actually gets decided where, and they update their model accordingly. If a staff engineer proposes a solution and the engineering manager overrides it without explanation, the team learns that proposing solutions is a formality. If a technical decision goes to committee and comes back with different requirements than the team submitted, the team learns that the committee overrides technical judgement.

These patterns accumulate into an implicit decision-making culture that bears little resemblance to whatever is written in the team charter.

The question to ask is not "what is our decision-making process?" but "what does our team actually do when they need to make a decision?"

DACI

DACI is a decision-rights framework that makes explicit who plays which role in a given decision. It stands for Driver, Approver, Contributor, Informed.

• Driver - the person responsible for making sure the decision gets made. Not necessarily the decision-maker. They gather input, run the process, and ensure closure. There should be exactly one Driver.
• Approver - the person with final decision authority. There should be exactly one Approver. If there is more than one Approver, you do not have decision clarity - you have diffused accountability.
• Contributors - people whose input shapes the decision. They are consulted, but they do not have a veto. Being a Contributor means your perspective is sought and considered, not that you must agree with the outcome.
• Informed - people who need to know the outcome but are not shaping it. Keeping this list current prevents the surprise that undermines trust in the decision.

When It Helps

DACI is most useful for decisions that:

• Involve multiple stakeholders with competing interests
• Have a high cost of making the wrong choice
• Will be hard to change once made
• Have historically been unclear about who owns them

It is overkill for routine technical decisions. It is essential for decisions like: which cloud provider to use, how to structure team topologies, which architectural pattern to adopt as a standard, or whether to take on technical debt to meet a delivery milestone.

A Worked Example: Technical Architecture Decision

Decision: Whether to adopt an event-driven architecture for the new data pipeline or extend the existing REST-based approach.

The Driver schedules the conversations, not the Approver. The Approver is brought in when needed, not sitting in every discussion. The Contributors give input in defined sessions - they do not have an ongoing veto. The Informed receive a clear, timely communication of the outcome and the reasoning.

The Most Common DACI Failure

The most common failure is having multiple Approvers - usually as an attempt to be inclusive or to avoid accountability. "The leadership team will approve this" is not DACI. It is committee decision-making dressed in DACI language.

Every decision needs exactly one person who is accountable for the quality of the decision. If nobody owns it, everybody avoids it.

Reversible vs Irreversible

Jeff Bezos's two-door framework is one of the most practically useful ideas in decision-making: some decisions are one-way doors (irreversible or very costly to reverse), and some are two-way doors (easily reversible). The appropriate level of deliberation, time investment, and escalation is radically different for each.

One-Way Doors

These are decisions that are very hard to walk back. Major architectural changes. Vendor commitments. Organisational restructures. Public API design. Decisions that set the track for many subsequent decisions.

One-way doors deserve:

• More time for analysis
• Broader input
• Explicit consideration of what you would do if the decision turns out to be wrong
• Documentation of the reasoning, not just the conclusion

Two-Way Doors

The vast majority of technical decisions are two-way doors. The choice of a specific library, the implementation approach for a feature, the structure of an internal API, the format of a log message. These can be changed if they turn out to be wrong - often cheaply.

Two-way doors deserve:

• Enough analysis to make a reasonable choice
• A clear owner who makes the call
• Documentation that is proportionate to the decision
• Trust that the person making the decision can learn from it if it turns out to be wrong

The Asymmetry Problem

Most organisations treat most decisions as one-way doors. Leaders require sign-off for decisions that could be made and reversed in a week. Architects review choices that a competent engineer should own. Committees form to discuss things that should have been decided in an afternoon.

This is not diligence - it is risk aversion dressed as process. The cost is speed, autonomy, and the development of decision-making capability in the team.

The rule of thumb: Unless you can articulate specifically why this decision would be very hard to undo, treat it as a two-way door and make it fast. Reserve the heavyweight process for decisions that genuinely deserve it.

Delegating Decisions

Delegation is not the same as abdication. The distinction matters because many leaders who believe they are delegating decisions are actually either micromanaging the process or abandoning the person to make a hard call without adequate support.

What to Delegate and What Not To

Delegate decisions where:

• The person has better context than you do (they are closer to the problem)
• The decision is reversible and the cost of a wrong call is manageable
• Making the decision will build their capability
• The decision is time-sensitive and your involvement would slow it down

Do not delegate decisions where:

• The decision sets direction that will constrain many future choices
• It requires information or context the person does not have and cannot reasonably get
• The stakes of a wrong call are very high and you are better positioned to assess them
• The person is new to this type of decision and needs guidance, not independence

How to Delegate Without Abdicating

Good delegation has four components:

1. Context - why this decision matters, what constraints exist, what the successful outcome looks like
2. Authority - explicit clarity that the person is making this decision, not making a recommendation for you to approve
3. Support - what resources, input, or access they have
4. Feedback - when and how you will find out what they decided and how it is working

Without context, the person is guessing at the constraints. Without explicit authority, they will probably come back for approval anyway. Without support, it may be abandonment. Without feedback, there is no learning loop.

The Difference Between Delegating a Decision and Delegating a Problem

Delegating a decision: "You have the authority to decide which monitoring approach we use. Here's the context I'd want you to consider. Let me know what you decide."

Delegating a problem: "We need to sort out monitoring. Can you look into it?" - then expecting the person to make a recommendation that you approve, while nominally saying they own it.

The second is very common and is not delegation. It is work assignment with an extra approval step. The person learns to make recommendations, not to make decisions. This is not a trivial distinction - the cognitive and ownership shift between "I recommend" and "I decide" is significant.

Communicating Decisions

A decision that is poorly communicated is a source of confusion, resentment, and re-litigation. Most engineering leaders focus on making the decision; fewer focus on communicating it in a way that enables people to implement it well and to trust the process.

Decision vs Announcement

An announcement tells people what was decided. A decision communication tells people what was decided, why, what was considered and rejected, and what happens next.

The why matters more than most leaders think. Engineers who understand the reasoning behind a decision can apply that reasoning to the next related decision. Engineers who only know the conclusion cannot. Over time, sharing reasoning builds the team's decision-making capability. Sharing only conclusions builds compliance.

The "What We Considered" Component

Explicitly communicating what alternatives were considered and why they were rejected is one of the most underrated practices in decision communication. It prevents:

• People spending time proposing the alternatives that were already rejected
• The impression that the decision was made carelessly or without consideration of obvious options
• Re-litigation when someone comes along who does not know that the alternative was already thought through

It does not need to be long. "We considered X but rejected it because Y. We considered Z but it would require Q which we do not have" is usually enough.

Handling Disagreement After the Decision Is Made

Decisions are sometimes made over the objection of people who are affected by them. This is normal and necessary - some decisions cannot wait for consensus. But the way you handle post-decision disagreement has a significant effect on the team's trust in the process.

Disagree and commit is a legitimate mode. The person who disagreed gets acknowledged, their concern is on the record, and they commit to implementing the decision they disagreed with. This requires:

• The leader to have genuinely engaged with the concern, not dismissed it
• Explicit acknowledgement that the disagreement is noted
• An agreed point at which the decision will be reviewed if the concern proves founded

What does not work: Expecting people to act enthusiastic about decisions they openly disagreed with. Enthusiasm is not what you need. You need commitment to implementation and a willingness to surface evidence that the decision is not working if it emerges.

Decision Quality vs Decision Outcome

This is one of the most important and least practised distinctions in engineering leadership. A good decision can have a bad outcome. A bad decision can have a good outcome. Evaluating decisions by their outcomes teaches the wrong things.

Why This Matters

If good-outcome decisions are praised and bad-outcome decisions are criticised, regardless of the quality of the reasoning and process, the team learns:

• To make safe choices rather than well-reasoned ones
• To invest in outcome attribution rather than good thinking
• To distance themselves from decisions that might produce bad outcomes
• To avoid honest analysis that might lead to an uncomfortable conclusion

This is sometimes called "resulting" - judging decisions by their results rather than by the quality of the reasoning and process. Poker players talk about it. Financial investors talk about it. It is universal.

Evaluating Decision Quality

A decision is good if:

• It was made with the information available at the time (not in hindsight)
• The relevant inputs were considered
• The decision rights were clear and appropriate
• The reasoning was sound given the constraints
• The uncertainty was acknowledged and accounted for

A decision is bad if:

• It ignored information that was available at the time
• Key stakeholders were excluded from contributing
• The reasoning was flawed or incomplete
• The outcome was treated as more certain than it was

The test: If you made the same decision ten times in the same conditions, what proportion would you expect to turn out well? A good decision is one that you would expect to turn out well on average, given the information at the time. A bad outcome from a good decision is just variance.

Building a Culture That Does Not Punish Good-Process Bad-Luck

This is harder than it sounds because the instinct to find someone responsible when something goes wrong is deeply human. The alternative - examining the process and acknowledging that the outcome was partly chance - requires deliberate practice.

Specific practices:

• In post-mortems, explicitly separate "what could we have known at the time" from "what do we know now"
• When a decision turns out badly, ask "given what we knew when we made this, was the decision reasonable?" before asking "what should we have done differently?"
• When a decision turns out well through lucky variance, acknowledge the luck - do not attribute it entirely to good judgement

Common Failures

Decision by Committee

The group meets, everyone shares a view, nobody is willing to take a position that might be wrong in front of others, and the group converges on a lowest-common-denominator outcome that everyone can technically agree with. Nobody owns the decision because everyone was involved in making it.

This is particularly common in engineering organisations that value consensus and are uncomfortable with authority. The consequence is decisions that are slow, mediocre, and accountable to nobody.

The fix: Make the DACI explicit. One Approver. Full stop.

Fake Consultation

The decision has already been made - or the leader knows what they want - but a consultation process is run to create the impression of inclusion. Questions are asked, input is gathered, and the decision emerges in exactly the form it would have taken without the consultation.

The team learns this quickly. After the second or third experience of consultation that changes nothing, they understand that consultation is performative. They stop engaging, or they engage tactically.

The fix: If you have a strong view, say so. "I'm leaning toward X - I want to test whether I'm missing something before I confirm it." This is honest. The alternative is treating people as if their input matters when it does not, which is a specific and damaging form of disrespect.

Flip-Flopping Under Pressure

Making a decision and then changing it when people push back - not because of new information or better argument, but because of social pressure or persistence. This tells the team that the way to change decisions is not to provide better reasoning but to create enough discomfort.

The consequence is that every decision becomes a negotiation rather than a conclusion. People do not accept decisions - they manage them. This is exhausting and produces poor outcomes.

The distinction that matters: Changing a decision because of new information or a compelling argument is good decision-making. Changing a decision because someone expressed displeasure more forcefully is not. The test: "What did I learn that I did not know before?"

The Missing Record

Decisions made verbally in meetings, not documented anywhere. Two months later, nobody can agree on what was decided, who decided it, or why. The decision is re-made, often differently, with corresponding confusion in the team.

Documentation of decisions does not need to be formal. A brief note in Confluence, a Slack message, an email - enough to capture what was decided, who decided it, and the key reasoning. This is low-cost and high-value.

Connection to Your Operating Model

Decision-making patterns are the mechanism through which your organisational structure either enables or defeats autonomy.

You can design a team topology that gives teams ownership of a domain. You can write principles about empowered teams and distributed decision-making. But if the actual pattern of decisions shows leaders making calls that teams should own, teams escalating decisions that they should be making, and committees reviewing choices that individuals are better placed to make - then the structure and the principles are decorative.

The operating model this framework describes - high autonomy, clear accountability, teams that own their domains - depends on a decision-making culture where:

• Decision rights are explicit and respected
• Reversible decisions are made fast and locally
• Irreversible decisions get appropriate deliberation
• Delegation is real - with context, authority, and feedback
• Outcomes are communicated with reasoning, not just conclusions

If you want to know whether your operating model is real, look at the decisions being made. Where are they being made? By whom? How fast? With what level of context being shared?

The gap between the decisions you intend the team to make and the decisions they actually make is the measure of how much work remains.

Building a Decision-Making Culture

Culture does not change through aspiration. It changes through repeated experience of different norms. If you want a culture where decisions are made fast, locally, and with accountability - you have to create the conditions for that to happen and then defend those conditions when the organisation pushes back.

Making Decision Rights Visible

Most engineering organisations have implicit decision rights - everybody roughly knows who tends to decide what, but it has never been written down. This creates three problems: new team members have to learn the implicit rules (taking time they do not have), the implicit rules are often inconsistently applied, and the rules cannot be easily challenged or improved because they are not visible.

Making decision rights explicit does not require bureaucracy. A simple document that covers:

• What decisions this team makes independently
• What decisions this team makes in consultation with [other team/function]
• What decisions require escalation to [role]
• What decisions we explicitly do not own and refer to [role/team]

This takes an afternoon to draft. It takes a few months of real use to refine. The return is significant: faster decisions, clearer accountability, and a shared model of how the team operates.

Decision Velocity as a Health Metric

Teams can measure how quickly decisions get made - not as a performance metric to be gamed, but as a diagnostic. If a class of decision consistently takes longer than it should, the causes are worth examining:

• Is the decision right unclear? (Who is actually the Approver?)
• Is the information required hard to get? (What is blocking good analysis?)
• Is there social pressure to delay? (Is someone avoiding a hard call?)
• Is the process disproportionate to the decision size? (Is a two-way door being treated as a one-way door?)

Decision velocity is not an end in itself. Some decisions deserve to be slow. But systematic slowness across most decisions is a sign that something structural is wrong.

Creating Decision Review Cadences

For significant decisions - particularly architectural decisions, major process changes, and resource allocation choices - a lightweight review cadence creates two things: accountability for revisiting decisions that are not working, and a record of the reasoning that enables future teams to understand why things are the way they are.

A quarterly decision review for significant technical decisions is a low-overhead practice. The questions to ask:

• Is this decision still the right one given what we know now?
• What did we predict would happen, and what actually happened?
• If we were making this decision today, would we make the same one?

This is not about rehashing or undoing decisions without cause. It is about treating the decision as a hypothesis that benefits from evidence.

Worked Examples: Decision Anti-Patterns in Context

Abstract anti-patterns are harder to act on than concrete ones. The following are representative scenarios from engineering organisations.

Anti-Pattern 1: The Infinite Consultation

Scenario: The team needs to choose a new observability platform. The tech lead kicks off an evaluation. Three options are shortlisted. The team presents findings to the engineering manager, who says it is a great analysis but wants to check with the CTO. The CTO says it sounds sensible but suggests consulting the platform team. The platform team has concerns about one of the options. The evaluation restarts. Eight weeks later, the decision has not been made.

What went wrong: No single Approver was identified at the start. Every person consulted had implicit veto power. The Driver did not have the authority to close the decision.

The fix: Before starting any significant evaluation, make the Approver explicit. "At the end of this process, [name] makes the call. Everyone else is a Contributor or Informed." The evaluation can run exactly the same way - the difference is that when the evaluation is complete, there is a person with authority and accountability to decide.

Anti-Pattern 2: The Revisited Decision

Scenario: The team decides, after proper consultation, to deprecate a legacy API. The decision is communicated. Two weeks later, a stakeholder who was not in the Informed list objects. The engineering manager, faced with the objection, says "let's revisit." The team, which has already started the deprecation work, pauses. The decision is re-litigated. Morale drops. The final decision, reached after another two weeks, is roughly the same as the original.

What went wrong: The communication of the decision did not clearly mark it as a decision rather than a proposal. The Informed list was incomplete. The engineering manager capitulated to objection rather than distinguishing between new information and displeasure.

The fix: When a decision is made, communicate it explicitly as a decision, not a proposal. Include in the communication: what was decided, why, who decided it, and how to raise concerns (through whom, by when). If concerns are raised, test whether they represent new information. If yes, consider them. If no, explain the reasoning and hold the decision.

Anti-Pattern 3: The Undelegated Delegation

Scenario: An engineering manager tells a senior engineer: "You're responsible for the technical direction of the data layer. You own it." Six weeks later, the senior engineer proposes a significant change to the caching strategy. The manager reviews it and says: "I'm not sure about this - let's keep the current approach for now." The senior engineer, who believed they owned the decision, is confused and frustrated.

What went wrong: The delegation was not specific enough about what "own it" meant. When a decision arose, it turned out the manager had retained veto power without having said so.

The fix: When delegating a domain, be specific about what decisions the person can make without approval, what decisions they should flag before making, and what decisions remain with you. "You own the technical direction of the data layer. That means you make the call on implementation approaches, library choices, and internal API design. For changes that affect the contract with external teams, flag me before you commit."

Decision Making Under Pressure

Decisions made under pressure are the ones most likely to be made badly - and the ones whose quality matters most. A poor decision made when there is no time pressure is usually catchable before it does significant damage. A poor decision made at 2am during an incident, or under delivery deadline pressure, can be very expensive.

The Pressure Traps

Anchoring to the first option - under time pressure, the first plausible solution gets evaluated and often accepted without considering alternatives. The first option has significant anchoring power over subsequent thinking.

Narrowing too early - pressure creates the urge to converge quickly. The problem is that converging on a good option requires having generated enough options first. Under pressure, the generation phase is often cut short.

Ignoring reversibility - under pressure, the reversibility of a decision gets less attention than it deserves. The question "can we undo this?" can transform a terrifying decision into a manageable one.

Deferring to authority - in high-pressure situations, teams naturally look to the most senior person present to make calls. This concentrates decisions upward regardless of who has the best information.

Building Pressure-Resistant Decision Practice

The practices that help teams make better decisions under pressure are not emergency techniques - they are everyday habits that become available under pressure because they are already natural:

• Articulating the decision clearly before discussing solutions (what are we actually deciding?)
• Asking "what are we not considering?" before converging
• Checking reversibility as a default step in any significant decision
• Being explicit about who is making the call and why they are the best person to make it

These habits, practiced consistently in non-urgent contexts, are available when urgency arrives.

Decision Documentation

Most organisations have worse institutional memory than they think. The decisions that shaped the current architecture, the team structure, the tooling choices, the process design - most of these were made by people who have since left, in conversations that were not recorded, for reasons that have been lost.

The consequence is that the current team cannot learn from those decisions, cannot evaluate whether they still apply, and often re-litigates them from scratch rather than building on them.

Architecture Decision Records

Architecture Decision Records (ADRs) are the most common tool for documenting significant technical decisions. A minimal ADR contains:

• Context - the situation and problem being addressed
• Decision - what was decided
• Rationale - why this choice over the alternatives
• Consequences - what becomes easier or harder as a result

ADRs are stored alongside the code they relate to, so they are discoverable by engineers working on the relevant area. They are version-controlled, so they can be updated when a decision is reversed.

The most common failure: ADRs become part of the new joiner onboarding checklist and are never actually read. This is usually because they are not easy to navigate or because the tooling for discovery is poor. Make ADRs searchable, link them from relevant code areas, and reference them in design reviews when the decision is relevant.

Decision Logs for Process and Team Decisions

ADRs are for technical decisions. Process decisions, team structure decisions, and operating model choices also benefit from documentation - but are rarely given it.

A simple decision log in Confluence or Notion, with entries covering: the decision, the date, the owner, the key reasoning, and a "revisit by" date - creates the institutional memory that prevents repetitive re-litigation and enables genuine learning from past choices.

When to Document and When Not To

Not every decision needs documentation. The overhead of documenting trivial decisions produces a system that nobody reads because the signal-to-noise ratio is too low.

A useful threshold: if you would expect to explain this decision to a new team member six months from now, document it. If you would not, do not.

The decisions worth documenting almost always have at least one of these properties:

• They are hard to reverse
• They set a precedent for future similar decisions
• They were made over significant disagreement
• They depend on context that is not obvious from the outcome
• They were made by someone who may not be around to explain them later