Delegation & Empowerment

Why Delegation Is Hard (And Why Leaders Get It Wrong)

Delegation sits at the intersection of three tensions that engineering leaders face daily:

1. Quality vs. speed of development. You can do it faster yourself. But if you always do, your team never learns, and you become the bottleneck.
2. Control vs. trust. You want the outcome to be right. But over-controlling the process signals distrust and kills motivation.
3. Short-term efficiency vs. long-term capability. Doing it yourself is efficient today. Delegating is efficient at scale.

The Delegation Paradox

The leaders who most need to delegate are the ones who find it hardest. The better you are at a task, the more painful it is to watch someone else do it slower, differently, or imperfectly. This is especially true for engineering managers who were strong ICs — watching a junior engineer take three days on something you could do in three hours feels wasteful. It is not. It is an investment.

Andy Grove in “High Output Management” (1983) puts it bluntly: “The manager’s output = the output of their organization + the output of neighboring organizations under their influence.” Your output is not what YOU produce. It is what your TEAM produces. Every task you hold onto that someone else could do is a direct reduction in your output as a manager.

---

Delegation Levels — The Spectrum

The most useful model for engineering leaders is a spectrum of delegation levels, not a binary delegate/do-not-delegate switch. Multiple frameworks describe this (Jurgen Appelo’s Management 3.0, Tannenbaum & Schmidt’s Leadership Continuum). Here is a practical synthesis:

The Seven Levels

Level	Label	Description	Engineering Example
1	Tell	You decide. You inform. No discussion.	“We are using PostgreSQL. The decision is made.”
2	Sell	You decide. You explain your reasoning to get buy-in.	“We are using PostgreSQL because [reasons]. Here is why I considered and rejected MongoDB.”
3	Consult	You ask for input before deciding. The final call is yours.	“I am leaning toward PostgreSQL. What do you think? I want to hear concerns before I decide.”
4	Agree	You decide together. Shared decision.	“Let us evaluate PostgreSQL vs. MongoDB together and agree on the best choice for our use case.”
5	Advise	They decide. You provide input and advice.	“This is your call. My advice is PostgreSQL for these reasons, but I trust your judgment.”
6	Inquire	They decide. You want to understand their reasoning after the fact.	“You chose the database. Tell me about your reasoning so I can learn from it and stay informed.”
7	Delegate	They decide. You do not need to know the details.	“Handle the database selection. Let me know if you need anything.”

Choosing the Right Level

The level should be calibrated to two factors: task-relevant maturity (the person’s competence and confidence for this specific task) and consequence severity (what happens if the decision is wrong).

	Low Consequence	High Consequence
High Maturity	Level 6-7 (Inquire/Delegate)	Level 4-5 (Agree/Advise)
Low Maturity	Level 3-4 (Consult/Agree)	Level 1-2 (Tell/Sell)

Common mistakes:

• Using Level 7 for everything because “I trust my team” (abdication, not delegation)
• Using Level 1-2 for everything because “I need to make sure it is right” (micromanagement)
• Using the same level for all tasks with the same person (not calibrating to task-specific maturity)
• Not being explicit about which level you are operating at (the person thinks Level 5, you think Level 3 — mismatch creates frustration)

Making Levels Explicit

The most effective delegation practice: state the level explicitly.

• “I want to consult you on this — I will make the final call, but your input will shape my decision.” (Level 3)
• “This is your decision. I would like to understand your reasoning afterward.” (Level 6)
• “This is a joint decision — let us work through it together.” (Level 4)

This eliminates the most common delegation conflict: the person thinks they are deciding (Level 5+) and the leader overrides them (revealing it was actually Level 2 all along). That destroys trust instantly.

---

Task-Relevant Maturity (Andy Grove)

Grove’s concept from “High Output Management” is the most practical lens for calibrating delegation:

Task-relevant maturity (TRM) = a person’s experience, training, and confidence for a specific task, not their general seniority.

TRM and Management Style

TRM	Management Style	What It Looks Like
Low	Structured. Task-oriented. What, when, how.	Detailed specifications, frequent check-ins (daily or every other day), explicit success criteria.
Medium	Support-oriented. More emphasis on the individual.	Discussion of approaches, check-ins on blockers, feedback on direction. Weekly cadence.
High	Minimal involvement. Set objectives, monitor results.	Agree on outcomes and timeline. Check in at milestones. Monthly or as-needed.

The nuances Grove emphasizes:

1. TRM is task-specific. A Staff Engineer with 15 years of backend experience has high TRM for system design but might have low TRM for their first architecture decision document (different skill: writing, stakeholder management, conciseness). Adjust your delegation level for the specific task, not the person’s title.

2. TRM changes over time and is not monotonic. Someone might start at low TRM, build to medium, then regress to low when the problem space shifts (new domain, new technology, changed requirements). This is normal, not a failure. Adjust accordingly.

3. The wrong TRM assessment is worse than no delegation. If you treat a high-TRM person with low-TRM management (micromanagement), they disengage. If you treat a low-TRM person with high-TRM management (abandonment), they fail. Both outcomes are your failure as a manager.

---

The Delegation Process — Step by Step

Before Delegating

1. Define the outcome, not the process.

Bad: “Write a service in Go that calls the OpenAI API with retry logic and circuit breaker, stores results in Redis, and exposes a REST endpoint.”

Good: “We need a service that generates AI responses reliably. It should handle API failures gracefully, cache results, and be accessible to our frontend. Target: 99.9% availability, P95 latency under 500ms. How you build it is up to you.”

The first specifies process (which kills learning and ownership). The second specifies outcome (which enables creativity and growth). For low-TRM individuals, you might add more constraints, but even then, constrain the what and why, not the how.

2. Define decision boundaries.

Be explicit about where their authority ends. “You own the implementation decisions. For anything that changes the API contract with team X, loop me in first.” This prevents both over-delegation (they make decisions you should have been involved in) and under-delegation (they check with you on everything because the boundary is unclear).

3. Agree on check-in cadence.

Match the cadence to TRM:

• Low TRM: Daily or every-other-day standups on progress
• Medium TRM: Weekly sync, async updates between
• High TRM: Milestone check-ins, “call me if you are stuck”

4. Clarify the “done” criteria.

“How will we both know this is done?” Ambiguity here leads to scope creep, rework, or the person declaring done while you expected more.

During Delegation

5. Resist the urge to take it back.

The hardest part. When things go slower than you would like, or the approach is different from what you would choose, resist the temptation to grab the keyboard. Ask questions instead of giving answers: “What options did you consider?” “What is your biggest concern?” “How would you handle [edge case]?”

6. Create a safe space for asking for help.

“If you get stuck, come to me. Asking for help is a sign of maturity, not weakness.” If someone struggles silently for a week and then delivers a broken result, you failed to create the conditions for them to ask for help earlier.

7. Provide air cover.

If stakeholders pressure the person directly, step in. “Jane is leading this. She has my full support. I will handle any escalation.” Being delegated to should not mean being exposed to organizational pressure without support.

After Delegation

8. Debrief and learn.

After the task is complete, discuss: What went well? What was harder than expected? What would you do differently? This turns every delegation into a learning opportunity and builds TRM for next time.

9. Give credit publicly.

“[Name] designed and delivered [X].” Not “my team delivered X” and definitely not “we delivered X.” Specific, public credit for the person who did the work. This reinforces delegation as a growth opportunity, not a chore dump.

---

Empowerment — Beyond Delegation

Delegation is about tasks and decisions. Empowerment is about building an environment where people take initiative without being asked — where ownership is the default, not the exception.

Marquet’s Intent-Based Leadership

L. David Marquet’s “Turn the Ship Around!” (2012) describes the transformation of the USS Santa Fe from the worst-performing submarine to the best. His framework is directly applicable to engineering teams.

The core shift: From “tell me what to do” (permission-based) to “I intend to…” (intent-based).

Instead of an engineer asking “should I refactor the authentication module?” the empowered version is “I intend to refactor the authentication module because [reasoning]. I plan to approach it by [method]. Are there any concerns?”

Marquet’s formula:

Control + Competence + Clarity = Effective Empowerment

Element	Definition	How to Build It
Control	Pushing decision authority to the person with the information	Explicitly state what decisions they own. Increase scope as TRM grows.
Competence	Technical skill, judgment, and experience	Training, pairing, stretch assignments, deliberate practice, mentorship
Clarity	Understanding of goals, constraints, values, and priorities	Communicate vision and strategy repeatedly. Ensure people know what “good” looks like. Share context generously.

Critical insight: You can only increase Control as fast as you increase Competence and Clarity. Pushing authority to someone who lacks competence creates chaos. Pushing authority without clarity creates misalignment. All three must develop in parallel.

The Ladder of Leadership (Marquet)

A progression from full dependence to full proactivity:

Level	Language	Autonomy
1	“Tell me what to do.”	Zero
2	“I think we should…” (waits for approval)	Minimal
3	“I intend to…” (states plan, waits for response)	Moderate
4	“I intend to… unless you see a concern.”	High
5	“I did X because [reasoning].” (informs after acting)	Full
6	“I have been doing X. Here are the results.” (reports outcomes)	Maximum

Your job as a leader: Move each person up this ladder at a pace that matches their growing competence and clarity. The goal is Level 4-5 for most decisions with experienced team members.

---

Accountability Without Micromanagement

The false dichotomy: “either I check everything or I trust them and accept whatever comes.” Neither works. The balance is accountability through outcomes and checkpoints, not through process control.

The Accountability Framework

Element	What It Looks Like	Anti-Pattern
Clear expectations	“Here is what success looks like, including quality bar and timeline”	Vague expectations followed by disappointment
Regular visibility	Agreed check-in cadence with progress transparency	No check-ins until the deadline (then surprise)
Ownership of outcomes	“You own this. If it goes well, you get the credit. If it struggles, we troubleshoot together.”	Shared ownership = no ownership
Consequences	Success is recognized and rewarded. Repeated failure (after support) has consequences.	No consequences either way
Support	Proactive offer of help. Removing blockers. Air cover.	“You own it” and then disappearing

The Delegation Dashboard

For engineering managers with 16 reports, tracking delegation becomes a management challenge itself. A simple mental model:

For each direct report, know:

• What are they owning right now? (Current delegated work)
• At what delegation level? (1-7)
• What is their TRM for this work? (Low/Medium/High)
• When is the next check-in? (Cadence)
• What is their growth edge? (What are they stretching into?)

You do not need a spreadsheet for this. But you need to be able to answer these questions for each person. If you cannot, you are either under-delegating (doing too much yourself) or abdication-delegating (not tracking enough).

---

Common Delegation Failures

The Yo-Yo

You delegate a decision, the person makes it, and you override it. Then you delegate again, they make another decision, you override again. After 2-3 cycles, they stop making real decisions and start trying to guess what you would decide.

Fix: If you find yourself overriding, you either assigned the wrong delegation level or you have not given enough clarity on constraints. Fix the input (constraints, criteria), not the output (their decision).

The Dump

“Hey, you are owning the migration now. Good luck!” No context, no success criteria, no check-in cadence, no support.

Fix: Delegation without scaffolding is not empowerment — it is abandonment. Even for high-TRM individuals, a brief handoff conversation establishes shared understanding.

The Phantom Delegation

You say they own it, but you are still doing the work. You review every PR, attend every meeting, rewrite their documents. They nominally own it; you actually do.

Fix: If you cannot let go, be honest about why. Is it a trust issue (address it directly) or a control issue (work on it, possibly with your own manager or coach)?

The Reverse Delegation

The person delegates back up to you. “What do you think I should do?” asked repeatedly until you are effectively making the decision.

Fix: Respond with questions, not answers. “What options have you considered?” “What would you recommend?” “If I were not available, what would you do?” Build their decision-making muscle by exercising it.

The Scope Creep

You delegate “own the service” and they interpret it as owning the service, the infrastructure, the cross-team API contract, and the product roadmap.

Fix: Define boundaries explicitly at the start. “You own the service implementation. API contracts with other teams go through our team’s architecture review. Product priorities come from our PM.”

---

Delegation as Career Development

Delegation is the primary mechanism through which people grow in engineering organizations. The stretch assignment — a task slightly beyond current capability, with appropriate support — is the most effective development tool you have.

Matching Delegation to Growth Goals

Growth Goal	Delegation Approach
Technical depth	Delegate a complex technical problem in their domain with Level 5-6 autonomy
Technical breadth	Delegate a task in an adjacent domain at Level 3-4 with coaching
Leadership	Delegate team coordination, sprint planning, or cross-team alignment
Communication	Delegate the architecture review presentation or the stakeholder update
Decision-making	Delegate increasingly consequential decisions with post-decision debriefs

The 70-20-10 Rule Applied to Delegation

Development research (McCall, Lombardo & Morrison, 1988) shows that people learn:

• 70% from on-the-job experience (stretch assignments, delegation)
• 20% from relationships (coaching, mentoring, feedback)
• 10% from formal training (courses, certifications)

This means delegation is not just a management efficiency tool — it is the primary vehicle for the most effective form of development. If you are not delegating challenging work, you are not developing your people.

---

Anti-Patterns

Anti-Pattern	Description	Root Cause	Fix
The Heroic Manager	Does all the critical work themselves. Team handles only routine tasks.	Fear of failure, identity tied to IC work, distrust	Start small. Delegate one critical task per sprint. Tolerate imperfect execution.
The Seagull Manager	Flies in, dumps opinions, flies out. Does not own the outcome.	Busy schedule, poor prioritization, ADHD management	Commit to follow-through. If you weigh in, own the outcome of your input.
Delegation as Punishment	Unpleasant tasks get delegated. Interesting work stays with the manager.	Self-serving bias	Deliberately delegate the most interesting work. Your job is to develop people, not to have fun.
Equal Delegation	Everyone gets the same level of delegation regardless of TRM	Fairness anxiety, avoiding difficult conversations	Fair does not mean equal. Calibrate to individual TRM. Explain the reasoning.
Delegation without Resources	“Own this” without time, budget, authority, or support	Poor planning, underestimating complexity	Before delegating, ensure the person has what they need. If not, provide it or descope.
Upward Delegation	Manager constantly escalates to their manager instead of deciding	Low confidence, avoiding accountability, unclear authority	Clarify your decision rights with your manager. Default to deciding, not escalating.

---

References

• Grove, A.S. (1983). High Output Management. Random House. — Task-relevant maturity, manager’s output, and the delegation calculus. The most important management book for engineering leaders.
• Marquet, L.D. (2012). Turn the Ship Around! Portfolio. — Intent-based leadership, the leader-leader model, Control + Competence + Clarity.
• Appelo, J. (2011). Management 3.0. Addison-Wesley. — Delegation poker and the seven levels of delegation.
• Tannenbaum, R. & Schmidt, W.H. (1958). “How to Choose a Leadership Pattern.” Harvard Business Review. — The original leadership continuum.
• Fournier, C. (2017). The Manager’s Path. O’Reilly. — Practical delegation guidance for engineering managers at each level.
• McCall, M., Lombardo, M. & Morrison, A. (1988). The Lessons of Experience. Lexington Books. — The 70-20-10 development model.
• Blanchard, K. & Hodges, P. (2005). Lead Like Jesus. Thomas Nelson. — Situational delegation matched to development level.
• Drucker, P.F. (1967). The Effective Executive. Harper & Row. — Delegation as a core executive discipline.
• Kim Scott (2017). Radical Candor. St. Martin’s Press. — Caring personally while challenging directly in delegation contexts.
• Larson, W. (2019). An Elegant Puzzle. Stripe Press. — Delegation in the context of team sizing and organizational design.