Delegation and Team Empowerment Worksheet

A 47-year-old director of engineering at a mid-size SaaS company was promoted from principal engineer eighteen months ago. He has three senior engineers reporting to him, each with a team. He reviews every pull request. He rewrites design documents after his leads submit them. He attends code review meetings his reports run. His work calendar is 80% individual contributor activity and 20% management. His leads have stopped bringing him early-stage thinking because they've learned he'll change it anyway. The Delegation and Team Empowerment worksheet is introduced to map what he's holding, who should hold it, and what he believes would happen if he let go.

Frame this as the cost-benefit analysis he hasn't run. 'You're doing the technical work you're best at and that you trust. The worksheet asks you to look at the cost of that pattern: what is the team not developing because you're doing it? And what are you not doing at the director level because you're doing the IC work?' The beliefs section is the most important part of the worksheet for this client. 'I want you to write the actual belief driving each of the five tasks you identify — not 'I'm protecting quality' in the abstract, but the specific belief about what would happen if you handed this off. Write the worst case you're actually afraid of.' The named belief is what makes the coaching work possible.

Watch for his five delegation candidates to all be framed as 'tasks' rather than as development opportunities — the PR review isn't just something to offload, it's something his senior engineers need to own for their own growth. The reframing from task to capability-building changes the delegation conversation. Also watch for the team readiness ratings to be systematically low — if he rates every engineer at 3-4 out of 10 on readiness for tasks he's currently doing, either his team is genuinely underdeveloped or his readiness bar is set at his own standard rather than at 'good enough to grow into.' The distinction is worth investigating.

Start with the beliefs section. 'Read me the belief you wrote for the first item on your list.' Then: 'Has that belief been tested — have you actually seen that outcome when you've handed off similar work before?' Most cases will reveal the belief has never been tested because the handoff has never happened. Then: 'What would you need to see from [specific engineer] to raise your readiness rating from a 4 to a 6?' That question identifies what the development gap actually is, rather than treating low readiness as a fixed state. Close with the expectation-setting plan: 'For the first handoff on your list — what exactly would you say to that person when you hand it off?'

A 52-year-old executive director of a mid-size environmental advocacy nonprofit has been running the organization for eight years. She is deeply competent and genuinely mission-driven. Over the past two years, staff turnover has doubled, exit interviews reference 'micromanagement' and 'no room to grow,' and her two program directors have both flagged to the board that they feel underused. She came to coaching because the board suggested it. She does not use the word 'delegation' as a problem — she describes her style as 'high standards and close oversight.' The worksheet is introduced as a team development tool, not a behavior change tool, because the reframe is necessary for her to engage with it.

Frame this as a team audit, not a self-critique. 'Your two program directors have both said they want more ownership. This worksheet maps what you're currently holding, what they're ready for, and what it would take to move work into their hands in a structured way. The goal is a team that's more developed and more engaged — which also means less dependent on you.' The worksheet's team readiness section is critical here: completing it honestly may reveal that her ratings underestimate her team's capability. 'I want you to rate each delegation candidate for readiness based on what you've seen the person do, not on what you'd do differently in their place.' The standard she's applying matters.

Watch for her delegation candidates to be operational tasks rather than decision-making authority — she may offer to delegate task execution while retaining all decisions. That's not delegation as empowerment; it's delegation as task management. The distinction is worth naming. Also watch for the beliefs section to contain a pattern of organizational responsibility: 'If I let this go and it fails, the mission suffers' — this is the version of the delegation belief that is hardest to challenge because it's partially true. The coaching work is distinguishing between legitimate oversight and control that has become reflexive.

Start with the team readiness ratings. 'You rated [program director] at [score] for [delegation candidate]. What specifically have you seen from her that produced that rating?' If the evidence for the low rating is thin, name it: 'You have limited evidence for a low readiness rating. What's the risk in setting that rating higher and seeing what happens?' Then go to the beliefs section: 'You wrote that your concern is that errors would harm the mission. In the last year, what errors happened because you kept things close?' If there are few errors, that evidence belongs in the conversation. Close with the expectation-setting plan: 'What would you say to your program director if you handed this off for real?'

A 43-year-old VP of sales operations at a financial services company does delegate. She assigns work, names deadlines, and holds her team accountable. Her team's complaint — which showed up in a recent engagement survey — is that she reassigns work mid-stream when she doesn't like the direction it's going. She takes back decisions she said she'd made. She asks for updates at a frequency that communicates distrust rather than support. Her team describes the experience as 'can't win.' She came to coaching to work on executive presence and team engagement. The Delegation and Team Empowerment worksheet surfaces the pattern she's named as a mystery: the 'takes it back' cycle is visible in the beliefs section.

Frame this as diagnosing the midstream pattern. 'You delegate and then you re-enter the work before it's finished. The question this worksheet is designed to answer is why that happens — what's the moment where you decide the work needs you back in it?' The expectation-setting section is the most useful for this client — the 'takes work back' pattern almost always traces to an expectation that was set ambiguously at handoff. 'When you delegated the last three things that you ended up taking back — what exactly did you say when you handed them off? What was the expectation about when and how you'd be updated?' The worksheet builds an explicit expectation-setting plan because implicit expectations are where the re-entry happens.

Watch for the beliefs section to reveal that she defines delegation success as the output matching what she would have produced — not as the work getting done to an acceptable standard by someone else. That's perfection tolerance rather than delegation. Also watch for her expectation-setting plan to be well-intentioned but thin on specificity: 'I'll check in at key milestones' is not an expectation, it's a vague intention. Push for: at what date, in what format, and what decisions will still be hers versus transferred. The more specific the handoff agreement, the less ambiguity for either party to fill with anxiety.

Start with the last three takeback examples. 'Walk me through the last time you took work back from someone. What was the trigger?' Then: 'At the point of the original handoff — what exactly was the expectation about quality standard and check-in frequency?' The distance between those two pieces of information is usually where the problem lives. Then go to the expectation-setting plan she built: 'Read me the handoff plan for item one on your list. At what point in that plan, if anything, would you feel the urge to re-enter?' That question locates the vulnerability in the plan before the handoff happens. Close with: 'What would it mean for the handoff to succeed, even if the output isn't how you would have done it?'