“You own this” sounds like delegation. But imagine a tech lead assigning a project to an engineer, then overruling the engineer’s architecture choice, changing the rollout plan, and asking to approve every follow-up decision. The engineer still carries the delivery work, but the lead has kept the authority. In this hypothetical handoff, the result is predictable: the next time the lead says “you own it,” the words mean less.
Delegation works when the lead and the team agree on who has the decision—not just who has the task. Define a level for each decision area, from “I decide” to “you decide.” This six-level framework gives new tech leads a shared vocabulary for transferring authority gradually, without abandoning constraints or accountability.
Why delegation goes wrong#
Most failed delegation is not simply a motivation problem. It is an ambiguity problem.
A lead may mean, “Make the recommendation, then bring it to me.” The engineer may hear, “You have authority to choose.” Both act reasonably according to their interpretation, then discover the mismatch when a decision is challenged.
Three responsibilities are often blurred: task ownership (who moves the work forward), decision authority (who can commit to a choice), and accountability (who answers for the outcome). A lead may remain accountable for reliability while delegating a library choice; an engineer may own delivery but still need approval for a security exception. Without explicit boundaries, the lead becomes an approval queue.
Make the decision contract explicit before work begins.
The six levels of “you own this”#
Use these levels to describe authority for a decision area. They are not a ranking of good and bad leadership. A higher level is not automatically appropriate: risk, reversibility, experience, and organizational constraints matter.
1. I decide#
The lead makes the decision and communicates it. The engineer may be responsible for implementing it, but does not own the choice.
Use this for decisions constrained by a non-negotiable requirement, an urgent incident, or authority the lead is explicitly required to retain. Explain the reason and the boundary; do not label it delegation.
Say: “I’m making this call because the deadline and compliance constraint are fixed. I’ll explain the trade-off, and I’d like you to own the implementation plan within that decision.”
2. I decide after hearing you#
The engineer provides input, options, and risks. The lead listens, considers the evidence, and makes the final decision.
This is useful when the engineer has important context but the lead must retain the decision—for example, a cross-team dependency or a change with broad operational consequences.
Say: “Bring me your recommendation and the strongest alternative. I’ll make the final call after we review the impact.”
3. We decide together#
The lead and engineer discuss the options and reach a shared decision. Neither should assume the other is merely being consulted.
Use this when the decision crosses ownership boundaries, establishes a team convention, or has consequences that both parties must support. Agree in advance what happens if consensus is not possible; otherwise “together” can become an indefinite veto.
Say: “Let’s compare the options against the requirements and agree on the direction. If we cannot resolve it, we’ll bring the specific disagreement to the team.”
4. You decide after checking with me#
The engineer owns the decision but checks with the lead before committing. The lead advises, identifies risks, or points out constraints; the engineer makes the final call.
This is a useful transition level when someone is developing judgment in an area with meaningful but manageable consequences. The check-in is a consultation, not a hidden approval gate. If approval is required, say so directly.
Say: “You own the choice. Before you commit, walk me through the options and the risks. I’ll advise, but the decision is yours.”
5. You decide and tell me#
The engineer makes the decision independently, then informs the lead. The update is for awareness, coordination, or learning—not permission after the fact.
Use this inside agreed boundaries when the lead needs visibility, such as a scoped implementation detail or reversible change affecting adjacent work.
Say: “Make the call within the constraints we agreed. Add the decision and rationale to the project update so I can stay informed. You do not need to wait for my response.”
6. You decide#
The engineer owns the decision and does not need routine approval or notification. The lead remains available for escalation and stays accountable for the wider system, but does not shadow every choice.
Use this when the decision fits the engineer’s role and its boundaries and consequences are clear. Do not use it to disappear or delegate without context.
Say: “This area is yours. Make the decision, document anything the next person needs to know, and escalate only if you hit one of the agreed boundaries.”
Apply a level to each decision area#
Do not assign one delegation level to an entire project or person. Break the work into decision areas. An engineer may independently choose a component's internal structure while the lead retains authority over service-level reliability commitments.
Start with a short table and discuss it with the person doing the work. The examples below are illustrative; adjust them to your team's architecture, risk, and formal responsibilities.
| Decision area | Example level | Why this level may fit |
|---|---|---|
| Local implementation details | 6 — You decide | Inside agreed standards; low coordination cost |
| Library choice for one service | 5 — You decide and tell me | Engineer chooses within an approved stack and records the rationale |
| API contract affecting two teams | 3 — We decide together | Both teams must support the interface |
| Production rollout strategy | 4 — You decide after checking with me | Engineer owns the plan; lead reviews risk before commitment |
| Security-policy exception | 1 — I decide | Formal authority or risk ownership remains with the lead |
Do not create a spreadsheet for every task. Identify recurring decisions where expectations may diverge, agree the level with the engineer, and record it where the team can find it. As context and judgment grow, move individual areas upward—not the person wholesale from level 2 to level 6.
Set the conditions before stepping back#
A delegation level is only useful when the person knows the space they are operating in. Before handing over a decision area, agree on five things:
- The outcome. Describe what needs to be true, not every step the engineer must take. Include the user or system result and how the team will recognize completion.
- The constraints. State fixed requirements such as security policy, compatibility, budget, service-level objectives, deadlines, and interfaces with other teams. Separate non-negotiables from preferences.
- The decision boundary. Name what the engineer can decide independently and what triggers a conversation. Be explicit about irreversible changes, external commitments, and risks outside the agreed scope.
- The escalation path. Agree whom to contact, through which channel, and what information to bring when a boundary is reached. Make clear that escalation is expected when conditions change—not a sign of failure.
- The progress signal. Decide how you will hear about progress: a short async update, a decision log, a milestone review, or a regular check-in. Match the cadence to risk rather than asking for constant status.
A useful handoff: “You own the implementation approach. Keep the API compatible and meet the reliability target. If either is at risk, bring me the options before changing scope. Post an update at each milestone; otherwise, decide within those boundaries.”
Mistakes that turn delegation into control#
Taking the decision back when you disagree. If the agreed level says the engineer decides, do not quietly replace their choice with yours. Ask what evidence they used, explain the concern, and revisit the boundary if the risk was not understood. If you must override because a real constraint was missed, own the change and clarify the level for next time.
Delegating without context. “You decide” is not useful when the person lacks the goal, constraints, stakeholder context, or access needed to decide. Share the information first; authority without context is abandonment.
Using “let me know if you need anything” as the whole support plan. Newer engineers may not know what they do not know, and they may hesitate to interrupt. Define the escalation triggers and a predictable check-in. Ask, “What could block this?” and “Which decision would you want to review before committing?”
Confusing visibility with approval. If the engineer must tell you after deciding, do not make them wait for a response. If you need to approve first, use level 4 or another explicit approval process instead of pretending the choice is theirs.
Treating the levels as permanent. Revisit them when the system, team, risk, or engineer's context changes. A production incident may temporarily require tighter coordination; a familiar and reversible decision may be ready for more autonomy.
Where the six-level method comes from#
This article's six levels are a practical adaptation for tech-lead conversations, not a verbatim reproduction of an established model. Similar scales exist. Jurgen Appelo's Management 3.0 Delegation Poker and Delegation Board describes seven levels: Tell, Sell, Consult, Agree, Advise, Inquire, and Delegate. It also recommends making delegation visible by mapping levels to key decision areas. The six-level vocabulary here follows the same broad idea while not separating Appelo's “Sell” step into its own level.
The principle is that delegation is not binary: the right level depends on the decision and can change. This six-level vocabulary is a simpler working agreement, not a replacement or official Management 3.0 framework.
What to do next#
If you are newly responsible for technical direction, the Tech Lead Toolkit provides a broader set of references for the role. Start with three recurring decision areas that currently bottleneck on you. Agree on a level for each, document the constraints, and review the agreement after the next meaningful delivery milestone.
Delegation becomes real when the person doing the work knows which decisions are theirs—and trusts that the agreement will still hold when they make one.
References#
Software Engineer and Researcher, writing about AI, developer tooling and automation.
