Managers run out of time and emotional energy. Imagine a monkey on your back, stealing your spoons - that's what's happening!
The solution = leading with empathy + coaching + ownership clarity
Enduring, high-performing teams aren't built by heroes carrying loads of monkeys, they're built by consistent, sustainable management practices anyone can learn.
Why do you have a monkey on your back?
A metaphor from the classic 1974 Harvard Business Review article "Management Time: Who's Got the Monkey?"
Time is an irreplaceable resource, and every problem is a monkey that takes your time.
You might be familiar with the experience: someone sends you a message or brings something up in a meeting "I'm blocked, I don't know how to do this" - and the problem/monkey "jumps from their back onto yours".
Each time you accept the monkey, you've agreed to carry it. You now own the next action.
Management is Results and Retention
"Manager Tools" frames the manager's job as "results and retention".
The organization wants deliverables within a timeframe, but people are not robots. Managing people means managing emotions too.
Requests range from "I wanted a seat near the window" to "I'm going to leave this place if I have to work with X again".
Problems may not be inherently stressful. Yet how we feel about something can be entirely different from what it may take to complete it.
Your job is to bridge the gap. And that takes energy aka "Spoons"...
I (just) can't get started
"Spoon theory" originated as a way to describe the capacity available to people. We start the day with a finite number of spoons, and someone with chronic illness has "spoons" taken by their illness before they even start their day.
Every task, conversation, and decision costs spoons. When they're gone, they're gone.
When you're low on spoons, activation energy feels insurmountable.
Manage your spoons first
Before you can help anyone else, check your own reserves. Do you have enough spoons today to deal with what might come up?
This is not selfish. You cannot pour from an empty cup. If you're already depleted, you won't have the patience for the small stuff, let alone the capacity for a crisis.
Sometimes the right answer when asked something is "Let me think about it and get back to you".
(I'll have another blog post about time management and a "calendar energy audit")
Reading other people's spoons
Lead with empathy: do they have any spoons left today?
Have you built enough trust that your 1:1s are places where people can be vulnerable?
Where they can tell you "I'm not really up for this today" - and you actually listen?
One of the worst 1:1s I ever had was where I asked how someone was doing and they told me they weren't up for a meeting, and for some reason we kept talking.
Five minutes later they were over-sharing work anxiety, in tears. We agreed to end the meeting and mutually forget everything that was said.
My mistake: I didn't truly listen. I didn't realize that given my role power, they may have thought we had to keep talking.
The lesson: when someone signals "low on spoons", believe them. Don't push through just because the calendar says you have a meeting.
Now when I hear someone say they're not feeling well I offer to reschedule or focus on 1 urgent thing and end early.
Give a spoon
Sometimes you can give a spoon: with good listening skills and the ability to reframe a situation, you can sometimes actually restore someone's capacity.
"My memory was that you let me know your highest priority was sitting next to Y, and they got the window seat. They're really happy there, and I'm hoping you're going to be a great combo."
Helping someone see a situation in a positive light, or not in a zero sum way, is one of the highest-leverage things a manager can do. It costs you relatively little and can shift their entire day or even career.
Protect the team, not just the individual
When you notice dysfunction, especially if you care deeply about people, you may be tempted to endure a situation "a little while longer".
Look back at your 1:1 notes: how many times, and how many people, have brought up the same issue?
That’s spoons being subtracted from everyone: yourself, them, and the team.
Your job isn't only to support individuals. It's also to protect and support the team.
Sometimes everyone benefits from addressing the dysfunction directly instead of absorbing it privately.
I had a manager in my team who knew a direct report wasn't carrying their weight. It was even more difficult as they'd previously been peer-level colleagues.
Once we'd gotten through reviewing the data objectively, and a coaching discussion, it was the realization his other direct reports had been indirectly bringing the issue up that became the catalyst for change.
Once the situation resolved the manager and team were not surprised by the outcome and became healthier and stronger.
Helping on a task versus Helping Growth
A classic first-time manager mistake: taking on your direct reports' work as "helping." You use your IC skills instead of your people management skills. It feels productive because you're good at the work.
But you're not helping, you're enabling dependency and stealing their growth opportunity.
Worse: you create an incentive structure where being "good at fixing things" means everyone brings you their things to fix. More problems, more monkeys.
- https://blog.calm.com/blog/hero-complex
I can distinctly remember the one-on-one where my manager once told me "You're working harder than anyone in your team. As a manager, that may not actually be a good thing."
I also remember doing quite a bit of work to help prepare someone's promotion packet. When the promotion didn't happen, it hit me that I'd starting carrying their agency and career growth for them.
People need to build their own problem-solving capacity and self-advocacy - with support.
And every monkey you carry costs you spoons.
Coaching
Coaching is even more abstract than delegating. You're not doing the work. You're not even telling them how to do it. You're asking questions that help them figure out how they want to do it.
This order helps clarify motivation/importance before "What/How"
- "What makes this important to work on?"
- "What does a successful outcome look like?"
- "What have you already tried?"
- "What do you think is blocking you? What options are you considering?"
- "What would you do if I weren't here?"
- "What will you try next?"
(That last part makes it clear - the monkey stays with them)
Measure a leader by what their team does when their leader's absent
Delegation
Specifically for Delegation, rather than seeing it as "all or nothing", Jill Wetzler synthesized a useful framework from Alan Chapman and Jurgen Appelo's work which I paraphrased...
- Level 1 - Tell: I make the decision. I also tell you what to do and how
- Level 2 - Prep: You do the research, I make the decision (I should explain my reasoning)
- Level 3 - Consult: I ask for your input and recommendation first, then we decide together
- Level 4 - Needs Approval: Propose your plan and action, wait for my approval to continue.
- Level 5 - Expect Feedback: You make the decision and execute but keep me updated, I may have feedback or objections
- Level 6 - Informed: You own this - let me know how it goes
- Level 7 - Escalate (if needed): I don't need to know the details but if something goes wrong seek help
- Level 8 - Autonomous: You got this!
https://www.jillwetzler.com/resources/delegation
An important nuance: someone who's great at one thing might be new to a domain or team or project, adjust your level conservatively and accordingly
Concretely for software engineers
Higher levels of delegation means more autonomy; more experienced folks should be able to take on complex things with high autonomy...
- Tell: Giving an intern a fully laid out (small) task with prescriptive How
- Prep: Asking a junior developer to take on a bug fix
- Consult: Having an engineer work on their first architecture/design proposal
- Needs Approval: A remediation for a production incident (note this is "pairing as an ops best practice", and it's similar to "yes we do Pull Requests")
- Expect Feedback: An engineer leading a small project
- Informed: A senior engineer leading a project
- Escalate (if needed): A senior engineer working on a feature (in a domain they know)
- Autonomous: An engineer fixing a small bug (routine, low risk)
Because AI and Agents
2025 addendum
Delegating work to AI Agents is becoming common so here are some examples of how I apply this framework to successfully work with agents...
- Tell: how to update an unusual core data schema - high risk, large blast radius, difficult-to-recover
- Prep: Picking the architecture and tech stack - high risk, large blast radius, not-verifiable
- Consult: Working on a large feature - medium risk, large blast radius, hard-to-verify result
- Needs Approval: Working on a small feature - some risk, small blast radius, verifiable result
- Expect Feedback: Working on a small bug fix - some risk, small blast radius, easily verifiable result
- Informed: Writing unit tests - low risk
- Escalate (if needed): Updating dependencies - low risk, trivial verification
- Autonomous: Updating documentation (have this as a daily cron job) - very low risk/impact
Summary
A manager is great when inspiring and elevating people. Ensure you're in the right frame of mind to be that leader.
Don't be a hero who accepts all the monkeys; they steal all of your spoons!
Give people spoons. Coach them to tame their monkeys.
Over-communicated and mutually understood delegation makes ownership even clearer.