Delegation

Delegation

Before Starting

Check for EM context first. If .agents/em-context.md exists, read it.

If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

Response Style

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

• State the likely diagnosis or recommendation first
• Ask at most 2-3 targeted questions only if the missing context changes the advice
• Give the next concrete action and, when useful, exact wording the manager can use
• Mention the relevant framework briefly, but do not explain every part of it
• Offer a deeper version only after the direct answer

---

How to Use This Skill

Identify the situation first:

• You're the bottleneck — doing too much yourself → The Two Things to Delegate First (start here)
• Not sure how much involvement to have on a task or with a person → Task-Relevant Maturity
• Wondering if you're micro or under-managing → Micromanagement vs. Under-management
• Engineers wait to be told rather than acting → Intent-Based Leadership
• Want to give engineers deeper ownership beyond individual tasks → Giving Engineers a Kingdom
• Assigning work across the team strategically → Three-Layer Assignment Framework
• Feeling anxious about letting someone do it differently than you would → read references/extended.md — Delegation Anxiety
• Going on vacation / someone needs to cover → read references/extended.md — Covering for You While You're Away
• Deciding which tasks to pick up yourself as EM → read references/extended.md — Being Hands-On: Choose Tasks Intentionally
• Someone on the team seems entirely self-directed → read references/extended.md — Free Electrons
• A process keeps breaking despite repeated asks → read references/extended.md — Mechanisms Over Intentions
• Engineers keep coming to you for answers instead of deciding → read references/extended.md — Pulling Instead of Pushing
• Feedback about being too controlling or too hands-off → read references/extended.md — 4 Decision-Making Modes

---

Default Response Shape

When helping with delegation, diagnose the bottleneck before giving tactics:

1. Delegation target: what work should move away from the manager.
2. Maturity read: how much context, autonomy, and follow-up the person or task needs.
3. Delegation contract: owner, decision rights, check-in cadence, and done criteria.
4. Risk controls: what the manager should inspect without taking the work back.
5. Script: exact wording for assigning the work or resetting ownership.

If the manager is anxious about quality, address the control fear directly and design a review loop rather than advising them to "just let go."

---

The Two Things to Delegate First

1. Day-to-Day Operations: The Team Rep

The most impactful first delegation is the daily operational load — alerts, support requests, production issues.

How it works:

• Each day/week, one team member is the "Team Rep" (rotating)
• The Rep is responsible for: monitoring alert channels, helping the support team, debugging new issues, coordinating incident response
• The Rep is NOT responsible for fixing everything — the developer who introduced a bug fixes it. The Rep coordinates and learns.
• The manager is NOT the first call. The Rep is.

Setup tips:

• Put it on the calendar as a recurring rotation with a written guidelines doc
• In the first rotations, consultations with you are fine — but never solve it yourself
• Keep yourself in the rotation. Don't exempt yourself from the load you're delegating.

Benefits:

• No single point of failure (bus factor)
• Increased ownership and debugging skills across the team
• Developers feel "we're in the same boat"

2. New Projects: Epic Ownership

Stop being the one who meets with the PM, does the technical design, and breaks down the work.

How it works:

• When a new epic arrives, assign a team member as the owner
• They: meet with the PM, write the technical design, break it into tasks, decide work distribution
• You: stay involved — share thoughts, ask questions, review — but they make the decisions

Each developer leads only one project at a time, so they can be 100% dedicated to it — often producing better designs than you rushing through five simultaneously.

---

Knowledge Ownership

If you're the go-to person for every system and every question, that's a problem. Divide the team's systems and applications across people with clear, explicit owners. When someone asks you about a system, redirect them to the owner.

---

Delegation Principles

• Never delegate 100% of an area. Stay in the rotation. Do the work yourself occasionally.
• You can share at least 50% of your current work. The exceptions are fewer than you think.
• Never solve it for them. When they're struggling, coach — don't rescue.
• Match the task to the person's driver. When you delegate something that doesn't align with what motivates someone, they procrastinate and you end up nagging. When it aligns — they take ownership without being asked. A Connection-driven engineer will thrive as the team's interview coordinator; an Impact-driven one will take on the CS sprint you've been avoiding; a Growth-driven one will light up when you hand them an architectural decision. "Every task you don't like can be a growth opportunity for someone else." (See engineer-motivation for how to identify each person's driver.)

---

Intent-Based Leadership

From Turn the Ship Around (Marquet): instead of asking permission or waiting for direction, team members state their intent and proceed unless stopped.

The pattern: "I intend to deploy the release at 2pm — let me know if you see a reason not to." Instead of: "Should I deploy the release?"

Why it works: asking permission transfers ownership to the person being asked. Stating intent keeps ownership with the person acting, while still maintaining oversight. Over time, it trains the entire team to think like owners rather than executors.

How to implement it:

• Model it yourself with your own manager: "I intend to finalize this hire — flag me if you have concerns" (this is also how you earn delegation upward)
• When a report comes to you asking "should I do X?" — ask them what they intend to do and have them tell you. Then respond to their intent rather than making the decision for them
• Reserve overrides for cases where you have information they don't. If you're overriding purely because you'd do it differently, ask whether that's worth the cost to their ownership

The goal: a team that moves without being told, rather than a team that waits to be told.

---