How to Practice that Art of Delegation without creating Control Freaks

Working title

Delegate without becoming a control freak

The problem is trust under pressure

Most people do not struggle with delegation because they do not understand the concept.

They struggle because delegation is a trust exercise, and trust gets weird when the deadline is real, the stakes feel personal, and you can see the work being done “wrong” in real time.

So “leaders” do what feels responsible. They step in. They rewrite. They “just fix it quickly”. They keep the task technically delegated, but they keep the control.

That is how you end up with the worst of both worlds, the team feels micromanaged, the leader feels overloaded, and nobody actually learns to carry ownership.

This post is about delegation that builds capability, not delegation that offloads tasks.

Delegation is a skill

If you want a sports analogy, think about a coach who never lets a player take a shot in a real game because the coach wants to win.

The coach can protect the short‑term result, but the team never develops.

Delegation is the same.

If the leader always steps in at the moment it gets messy, the team never gets reps at:

• Making tradeoffs
• Communicating risk early
• Recovering from mistakes
• Owning outcomes

And then the leader concludes, “See, I have to do it myself.”

The control freak trap

Here are the common behaviours that look like “high standards”, but function like control:

• You delegate tasks, not decisions: the person is doing work, but cannot choose how to do it.
• You keep the real context to yourself: you do not share why the work matters, what constraints exist, or what a good outcome looks like.
• You provide feedback too late: you wait until the final draft, then rewrite everything.
• You punish uncertainty: people stop asking questions because questions get treated as incompetence.

None of this is malicious. It is just what happens when the leader is carrying too much responsibility and trying not to drop the ball. Or when systems aren’t in place when things get chaotic and busy.

A practical delegation framework

There are multiple situations where the delegation of tasks needs to be different.

In an office setting, when a presentation needs to be made to accomplish a goal, but it has to be done by Thursday with $0 extra from the budget, that needs to be explained.

On the other hand, in a kitchen when the lunch rush hits 15 minutes early and someone needs to drop fries, two words needs to be enough.

In an office setting, there can be a conversation. In a kitchen or an emergency room, there needs to be a quick order and some way for the person in charge to know it was received.

Can I get a “Yes, chef!”

Both situations are examples of delegation, but they are very different.

How to Practice with Video Games

Video games are a safe place to practice both versions, because the feedback is fast, the work is visible, and the stakes are low enough to experiment.

Version 1: “Project delegation” (slow, high-context)

This is the kind you use for presentations, client work, curriculum design, anything where quality has multiple dimensions and tradeoffs.

How to practice it in Minecraft (project management simulation)

• Set a real outcome + constraints (what + by when + what you cannot break). Example: “Build a village trading hall that can produce X resource reliably, by the end of the session, without anyone dying (or without using Creative).”
• Delegate decisions, not just tasks. Give one person authority over layout/architecture, one over resource pipeline, one over risk management (food, beds, lighting), etc.
• Create explicit decision rights:
  • Captain decides priorities.
  • Builders decide implementation.
  • Everyone flags risks early.
• Run short check-ins, not constant oversight:
  • Every 10 minutes, stop for 60 seconds.
  • Three questions only: “What changed?”, “What is blocked?”, “What decision do you need?”
• Use a “definition of done” that can be verified in-game: “The farm produces X per minute,” “The route is safe at night,” “The system still works when one person is offline.”

Debrief prompts

• “Where did we lose time, because we did not share context?”
• “What decision did the captain keep that should have been delegated?”
• “What decision got delegated that should have stayed centralized?”
• “What was the smallest intervention that would have prevented the biggest rework?”

Version 2: “Operational delegation” (fast, low-context)

This is the kind you use in a kitchen, during incident response, or any moment where speed and clarity matter more than perfect elegance.

How to practice it in League of Legends (5 players, one shot-caller)

Set up a normal game (or custom) with one player as captain/shot-caller. The goal is to win, and to practice clear delegation under pressure.

Rules of the drill

• Only the captain calls macro: objectives, rotations, when to fight, when to back, when to trade towers.
• Everyone else owns micro + reporting:
  • Players communicate what they see, what they can do, and what they need.
  • They do not argue in the moment, they execute, then review after.
• Two kinds of comms only:
  • Captain: commands (“We trade dragon for top tower, reset after.”)
  • Team: signals (“No flash mid, jungle seen bot, I have TP in 20.”)
• Pre-commit decision rights (so the captain does not become a bottleneck):
  • Each lane calls their own “danger/need help” threshold.
  • Support calls vision priorities.
  • Jungler calls pathing adjustments, but captain calls objective commits.

What to watch for

• The captain over-explaining (that is control disguised as clarity).
• Players going silent (they stop owning the situation).
• Late feedback (the captain waits, then blames the last fight).
• The team hiding uncertainty (no one wants to “sound dumb,” so they do not report).

Debrief prompts

• “What did the captain assume that should have been said out loud?”
• “Where did we get ‘technically delegated’ but still controlled?”
• “What calls were too centralized? What calls were too distributed?”
• “If we replay that moment, what is the smallest change in comms that fixes it?”

The transfer point

Both games force the same leadership move. Set outcome and constraints, name decision rights, and use check-ins as guardrails, not as surveillance.

What this looks like in a real team

The moment delegation gets tested is not when things are going well.

It is when:

• The task is behind
• The quality is not what you hoped
• The person made a decision you would not have made

In those moments, the question is not “Should I take it back?”

The question is, “What is the smallest intervention that protects the outcome and still preserves ownership?”

Sometimes that intervention is:

• Resetting the constraint
• Narrowing scope
• Adding a check‑in
• Coaching the decision

Not grabbing the controls away from someone else.

A quick self-check for leaders

If you are worried you are micromanaging, use these tests:

• Do people bring you problems, or do they bring you options?
• Do you change the work, or do you change the thinking?
• Do people hide drafts until the last second? (That is usually a trust signal.)
• Are you delegating to reduce your workload, or to grow the team?

If the answer to the last question is “reduce my workload”, you will drift toward control.

If the answer is “grow the team”, you will tolerate some mess, on purpose.

The bigger point

Delegation is leadership practice.

It is how you build a team that can carry responsibility without you.

And if you are building anything ambitious, that is the only sustainable path.

If you want to delegate without becoming a control freak, start with two habits:

1. Say the outcome and constraints clearly
2. Name decision rights and check-ins before the work starts

Everything else gets easier once those two are in place.

---

— J