You are doing work your team should be doing. You know this. You tell yourself you will delegate when you have time to delegate. But you never have time to delegate, because you are too busy doing work your team should be doing.<\/p>\n
This is the delegation trap. It is not a time management problem. It is a leadership identity problem.<\/p>\n
There are surface reasons leaders give for not delegating: “It is faster if I do it myself.” “No one else will do it to the standard I need.” “The stakes are too high to risk someone learning on this.” These reasons are occasionally true. More often, they are rationalizations for an identity pattern.<\/p>\n
The leadership identities that block delegation:<\/p>\n
You rose to your position because you were the best at something. Your identity as a leader is still partly organized around being the most capable person in the room on this topic. Delegating this work means ceding the activity that confirms your value. The threat is not operational \u2014 it is existential: if I am not doing this, what am I?<\/p>\n
Delegation requires tolerating uncertainty about how the work will be done. For leaders whose identity is organized around control and predictability, this uncertainty feels dangerous rather than merely uncomfortable. Delegating becomes possible only when you have resolved the control identity \u2014 when you no longer need certainty about execution to feel secure in your role.<\/p>\n
Some leaders conflate accountability with execution: if I am responsible for the outcome, I need to do the work. This is a misunderstanding of how senior leadership works. As you rise, your accountability expands while your direct execution should shrink. Maintaining the responsibility identity at senior levels is not conscientiousness \u2014 it is a failure to develop.<\/p>\n
William Oncken Jr. and Donald Wass introduced one of the most useful delegation frameworks in management literature: the “monkey on your back” metaphor, published in the Harvard Business Review in 1974 and still widely cited.<\/p>\n
The metaphor: every unresolved problem, pending decision, or open action item is a “monkey.” Every time a team member brings you a problem and you take it on \u2014 say you will think about it, take an action on their behalf, or give them advice that makes you the next step \u2014 the monkey moves from their back to yours. You leave the conversation with more work. They leave with less.<\/p>\n
This dynamic is not always visible in the moment. The manager who says “leave it with me” or “I will handle that” feels helpful. But they are systematically building a monkey collection that eventually makes them the bottleneck for every decision in their team.<\/p>\n
Oncken and Wass proposed four rules for keeping monkeys where they belong:<\/p>\n
Delegation is not binary. “Do this for me” and “you decide” are two ends of a spectrum. Most delegation errors happen because the manager does not specify which level they are delegating at, and the team member makes an assumption that is inconsistent with the manager’s expectations.<\/p>\n
The five levels:<\/p>\n
Most managers delegate at level 1 or 2 when level 3 or 4 would be appropriate given the team member’s capability and the stakes involved. This over-supervision slows decisions, frustrates capable team members, and keeps the manager in an execution role rather than a leadership role.<\/p>\n
Strategic delegation is not just about creating capacity for the manager. It is a primary mechanism for developing team members. The team member who is given real ownership of a problem \u2014 who has to figure it out, make decisions, navigate ambiguity, and deliver a result \u2014 develops capabilities that they cannot develop in a supervised execution role.<\/p>\n
This means that delegation decisions should be made partly on the basis of development intent: which team member is ready for this stretch? Which level of delegation will develop them without overwhelming them? How much support structure do I need to build around this delegation for them to succeed?<\/p>\n
When delegation is done with development intent, it creates a self-reinforcing cycle: the team member grows, earns more trust, earns more delegation, and develops faster. The manager’s capacity grows as the team’s capability grows. This is the core of the GROW manager development framework<\/a> \u2014 building managers who expand team capacity rather than carrying it themselves.<\/p>\n Pair strategic delegation with strong 1-on-1 meeting practices<\/a> to provide the check-ins and development support that make higher-level delegation safe, and with managing up skills<\/a> to ensure that your own delegation of upward accountability is equally well-structured.<\/p>\n Because delegation is an identity challenge, not a skill challenge. Most managers understand how to delegate. The barriers are identity patterns: the need to be the expert, the need to control outcomes, or the belief that accountability requires personal execution. Until those identity patterns are examined, delegation techniques do not produce lasting change.<\/p>\n<\/div>\n<\/div>\n<\/div>\n A delegation framework from William Oncken Jr. and Donald Wass that describes how managers accumulate ‘monkeys’ \u2014 open problems and pending decisions \u2014 when they take on work that should belong to their team members. The framework proposes four rules: every monkey has a next move, every monkey has an owner who is not the manager, every monkey has a feeding schedule, and the total number of monkeys is capped.<\/p>\n<\/div>\n<\/div>\n<\/div>\n Match the delegation level to two factors: the team member’s capability and experience on this type of problem, and the stakes of the decision. High capability, lower stakes: delegate to level 4 or 5. Lower capability, higher stakes: delegate to level 1 or 2 with explicit support. The development intent question also matters: if the goal is to stretch the team member, a higher delegation level with a stronger support structure is usually the right call.<\/p>\n<\/div>\n<\/div>\n<\/div>\n By being explicit about expectations at the point of delegation \u2014 what the outcome should look like, by when, and at what level of quality \u2014 and by following up at agreed intervals. Accountability after delegation is not micromanagement; it is the management structure that makes higher-level delegation safe. The team member needs to know what ‘done’ looks like and that you will check.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n Build a team of managers who delegate strategically and develop their people. Explore GROW<\/a> or schedule a call<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"You are doing work your team should be doing. You know this. You tell yourself you will delegate when you have time to delegate. But you never have time to delegate, because you are too busy doing work your team should be doing. This is the delegation trap. It is not a time management problem. It is a leadership identity problem. Why Leaders Fail to Delegate There are surface reasons leaders give for not delegating: “It is faster if I do it myself.” “No one else will do it to the standard I need.” “The stakes are too high to risk someone learning on this.” These reasons are occasionally true. More often, they are rationalizations for an identity pattern. The leadership identities that block delegation: The Expert Identity You rose to your position because you were the best at something. Your identity as a leader is still partly organized around being the most capable person in the room on this topic. Delegating this work means ceding the activity that confirms your value. The threat is not operational \u2014 it is existential: if I am not doing this, what am I? The Control Identity Delegation requires tolerating uncertainty about how the work will be done. For leaders whose identity is organized around control and predictability, this uncertainty feels dangerous rather than merely uncomfortable. Delegating becomes possible only when you have resolved the control identity \u2014 when you no longer need certainty about execution to feel secure in your role. The Responsibility Identity Some leaders conflate accountability with execution: if I am responsible for the outcome, I need to do the work. This is a misunderstanding of how senior leadership works. As you rise, your accountability expands while your direct execution should shrink. Maintaining the responsibility identity at senior levels is not conscientiousness \u2014 it is a failure to develop. The “Who’s Got the Monkey?” Framework William Oncken Jr. and Donald Wass introduced one of the most useful delegation frameworks in management literature: the “monkey on your back” metaphor, published in the Harvard Business Review in 1974 and still widely cited. The metaphor: every unresolved problem, pending decision, or open action item is a “monkey.” Every time a team member brings you a problem and you take it on \u2014 say you will think about it, take an action on their behalf, or give them advice that makes you the next step \u2014 the monkey moves from their back to yours. You leave the conversation with more work. They leave with less. This dynamic is not always visible in the moment. The manager who says “leave it with me” or “I will handle that” feels helpful. But they are systematically building a monkey collection that eventually makes them the bottleneck for every decision in their team. The Four Rules for Monkey Management Oncken and Wass proposed four rules for keeping monkeys where they belong: Every monkey must have a next move specified. When a team member brings you a problem, the conversation ends with a specific action assigned \u2014 and that action belongs to the team member, not to you. Every monkey has an owner who is not the manager. You can consult, advise, and review. But ownership of the action stays with the team member. Every monkey has a feeding schedule. You agree in advance how often you will check in on the problem \u2014 not waiting for it to become a crisis, but not micromanaging either. The number of monkeys is capped. You have a finite capacity to carry monkeys. Know your number. When you hit it, stop taking new ones until old ones are resolved. The Five Levels of Delegation Delegation is not binary. “Do this for me” and “you decide” are two ends of a spectrum. Most delegation errors happen because the manager does not specify which level they are delegating at, and the team member makes an assumption that is inconsistent with the manager’s expectations. The five levels: Look into this and report back. The team member does analysis and presents findings. The manager retains the decision. Look into this and recommend an action. The team member presents findings and a recommended next step. The manager approves or redirects before execution. Act and then tell me what you did. The team member executes and informs the manager after the fact. No prior approval needed. Act unless I say otherwise. The team member moves forward unless the manager intervenes. The manager is informed by exception. This is yours to own. Full delegation. The manager may receive periodic updates but has no routine approval role. Most managers delegate at level 1 or 2 when level 3 or 4 would be appropriate given the team member’s capability and the stakes involved. This over-supervision slows decisions, frustrates capable team members, and keeps the manager in an execution role rather than a leadership role. Delegation as Development Strategic delegation is not just about creating capacity for the manager. It is a primary mechanism for developing team members. The team member who is given real ownership of a problem \u2014 who has to figure it out, make decisions, navigate ambiguity, and deliver a result \u2014 develops capabilities that they cannot develop in a supervised execution role. This means that delegation decisions should be made partly on the basis of development intent: which team member is ready for this stretch? Which level of delegation will develop them without overwhelming them? How much support structure do I need to build around this delegation for them to succeed? When delegation is done with development intent, it creates a self-reinforcing cycle: the team member grows, earns more trust, earns more delegation, and develops faster. The manager’s capacity grows as the team’s capability grows. This is the core of the GROW manager development framework \u2014 building managers who expand team capacity rather than carrying it themselves. Pair strategic delegation with strong 1-on-1 meeting practices to provide the check-ins and development support that make higher-level delegation safe, and […]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[62],"tags":[71,67],"class_list":["post-6255","post","type-post","status-publish","format-standard","hentry","category-manager-development","tag-delegation","tag-identity-gap"],"yoast_head":"\nKey Takeaways<\/h3>\n
\n
Frequently Asked Questions<\/h2>\n
Why is delegation so difficult for managers?<\/h3>\n
What is the Who’s Got the Monkey framework?<\/h3>\n
How do you know what level to delegate at?<\/h3>\n
How do you hold team members accountable after delegating?<\/h3>\n