Decision Authority for Engineering Teams: The Four-Level Decision Tree

Decision authority tells an engineer what they can decide independently, what needs an update, and what needs agreement before action. Without that distinction, “take ownership” can still mean waiting for the manager at every step.

The questions themselves often sound ordinary: Which library should we use? Can we change this API? Should we move the release? The problem starts when every one of them needs the same person to answer.

I recognised this pattern in my own team. I wanted to be available. Somewhere along the way, “available” had become “involved in every decision.” Engineers waited for answers I did not always need to give, while I switched between choices with very different levels of risk.

The Decision Tree gives us a language for discussing those boundaries. The examples below apply that language to engineering work; the levels need to fit your team’s actual authority and policies.

What Does “Decision Tree” Mean Here?

This is a delegation model associated with Susan Scott’s Fierce Conversations and Fierce’s delegation practice. It is not a machine-learning model or a branching flowchart.

The metaphor uses leaves, branches, trunk, and roots to discuss increasing involvement in decisions. Here I use the levels as practical working agreements: act independently, act and inform, consult before acting, or involve the people authorised to make the decision together.

A Decision Tree Example: Changing a Production Service

Consider this illustrative service team. All changes still follow its existing review, testing, and release policies. Decision authority does not waive those controls.

The same topic, “changing a production service,” can sit at any level. Impact, reversibility, policy, and the person’s mandate matter more than the technology’s name.

Level 1: Leaves — Decide and Act

For a leaf decision, the owner acts without a separate management approval or special update. Normal engineering review still applies.

In the example, an engineer can improve a diagnostic message within existing logging standards. If the change could expose sensitive data, it no longer fits the example’s assumptions. Reassess the boundary instead of insisting it is “only logging.”

A useful manager response to unnecessary permission-seeking is: “This is within the boundary we agreed. What would you choose?” If the boundary was never clear, explain it rather than blaming the engineer for asking.

Level 2: Branches — Decide, Act, and Inform

A branch decision belongs to the owner, with visibility for agreed stakeholders. The update is not a disguised request for permission.

For the bounded rollout in our example, the update could be:

The rollout is running within the agreed limit. The rollback criteria and owner are recorded in the release note. I’ll include the result in tomorrow’s update, and raise an issue sooner if the criteria are met.

The details must match the team’s release process. If you expect to review the plan before execution, call that requirement out before the person acts.

Branch decisions also expose a manager’s real attitude to delegation. If I ask people to inform me and then treat every update as an invitation to reverse their choice, it was never a branch decision in practice.

Level 3: Trunk — Discuss Before Deciding

A database migration affecting other teams requires a conversation before the team commits. Ask the owner to bring the problem, options, a recommendation, dependencies, and the consequence of waiting.

For example:

We can remove the current bottleneck within this quarter or begin a larger migration. The migration would use capacity reserved for the customer project. My recommendation is to address the bottleneck first. I need agreement on that trade-off before we change the plan.

Specify whose agreement is required and who owns the final decision. “Discuss first” is still ambiguous if each participant assumes somebody else approves. The engineer can continue to own the investigation and execution without owning an organisation-wide commitment.

Level 4: Roots — Escalate the Decision

A root decision requires involvement from the people with the authority and context to make it. Depending on the decision, that may include the team, its manager, a sponsor, or other responsible functions. It does not always mean sending the issue to the most senior executive.

Bring the options, consequences, recommendation, and the date a decision is needed. Keep supporting the work after escalation.

For example, a team may identify a risk that prevents a promised launch. It can describe the risk and propose alternatives; it cannot assume that a delegated release responsibility authorises it to override company policy or obligations. Follow the relevant escalation process. Immediate protective action during an incident follows the established incident procedure, not a wait for a delegation workshop.

Why Engineering Managers Need Clear Decision Authority

If the team hears “you decide” but is criticised for acting, it learns to ask first. If every update triggers a new round of approval, a branch decision becomes a trunk decision in practice.

Make your response consistent with the boundary you offered. When circumstances change, explain the new constraint and revise the agreement. Otherwise people have to guess at rules that only exist in your head.

How to Place a Decision on the Tree

Ask four questions together:

• Who is affected: this person, the team, other teams, or customers?
• How difficult would it be to reverse the decision and repair its consequences?
• What information or expertise is missing?
• Who actually has the authority to commit to this outcome?

A technically reversible change can still damage a customer relationship. A capable engineer may understand an investment better than their manager while still lacking the authority to approve it. Capability, context, and authority all need attention.

How to Introduce the Decision Tree to Your Team

Choose five decisions from recent work, including one that waited unnecessarily. Ask which decisions people made without involving you, which they brought to you, where they were unsure, and where waiting slowed them down. Place those decisions on the tree and discuss disagreements. Write down who decides, who needs an update or consultation, and how quickly escalation must happen.

Keep the agreement short enough to use. Add examples when uncertainty appears, and revisit it after an incident, a change in responsibilities, or a meaningful increase in experience.

Common Decision-Authority Mistakes

Watch for hidden approval, unexplained changes to the rules, and delegation without enough context. Also notice whether asking for help is treated as failure. People should be able to check a boundary without losing ownership of everything around it.

When a decision turns out badly, review both its reasoning and its assigned level. The result alone does not tell you whether the person had appropriate authority or whether the manager withheld necessary context.

RACI Matrix vs Decision Tree

A RACI matrix describes responsibility for work. This Decision Tree describes the owner’s independence when making a choice.

A Tech Lead may own release readiness in RACI. The decision agreement then clarifies whether they can approve a routine release, pause a rollout, or need to discuss an exception. Use the two tools where those are separate sources of confusion, rather than creating two documents for every task.

Decision Authority Should Grow

As people gain experience and context, some choices can require less consultation. Other choices remain constrained by organisational responsibilities regardless of seniority. Discuss that distinction openly instead of treating every root decision as a personal development gap.

Put Five Decisions on the Tree

Moving from Tech Lead to Engineering Manager changes your relationship with decisions. Being the person with the answer may have made you successful as a senior engineer; management asks you to create an environment where good decisions happen without making yourself the centre of every one.

Start with the work already waiting for an answer. Agree on five boundaries, use them, and review where they helped or remained unclear. If the handoff itself is vague, first repair it with the delegation framework. If tasks move but decisions still come back to you, read Delegate Ownership, Not Tasks.