Leading people: delegating, trust, and a manager's time

Ask a freshly promoted manager how it's going, and you'll almost always hear the same sentence: "I don't have time for my own work." It's a strange sentence when you think about it. Leading people is their work now. But they don't feel it that way, because nobody prepared them for the fact that the promotion changed their unit of output. Before, they did the work with their own hands and saw what they'd accomplished by evening. Now they get work done through other people's heads, and by evening they see nothing — just an inbox that's grown back.

This mismatch is behind most managerial struggles that look like a time problem but aren't. A manager working fourteen-hour days usually isn't suffering from too many tasks. They're suffering from having kept tasks that should have stayed with other people and handed off the ones they should have kept. Leading isn't about how much the manager gets done, it's about how much other people get done because of them — and how long that holds up if they go on vacation.

This chapter is about the mechanics of leading: a manager's time as a shared resource, delegating as a transfer of context, checkpoints, 1:1s and feedback, and finally the moment a manager has to stop working with their own hands. It builds on the chapter on processes and automation — that one was about the path work travels through a company; this one is about the path accountability travels between people.

A manager's time isn't theirs

A rank-and-file employee has their own time. When they protect it, they get more work done, and the company benefits. For a manager, it works the opposite way, and it's the least understood thing about the whole role.

A manager's calendar is a shared resource of the team. When it's full, nobody can get to it, and the team stalls. When half an hour doesn't open up on Monday for a decision blocking three people, the loss isn't half an hour — it's three people times two days. The manager is the cheapest place to save an hour, and the most expensive place to create a queue.

Three consequences follow from this, and they run against typical productivity advice.

First, a manager can't afford a calendar booked to the last slot. They need spare capacity, because their main function is unblocking things. A calendar with no slack means every new item waits three days for the first open slot — and three days of waiting multiplies across a team. A reasonable rule is to keep roughly a quarter of the week free and guard it just as hard as meetings.

Second, availability can't be solved with constant openness. A manager who can be interrupted at any moment never gets an unbroken block for thinking, and thinking is the one part of their job nobody else can do for them. The fix isn't shutting the door — it's predictable availability: a fixed window everyone knows about, plus a clearly defined channel for things that can't wait. Predictability is worth more to a team than constant presence — a person who knows they'll get their turn Tuesday morning will happily wait. A person who doesn't know will chase you down.

Third, a lot of what gets a manager interrupted is status updates: where something stands, whether it's happened yet, what's next. None of that needs to pass through anyone's head or calendar if a written overview exists that people can check anytime. The tip A written status instead of a status meeting describes a concrete way to do that.

Delegating is a transfer of context, not a task

The most common form of delegating sounds like this: "Please prepare the client materials by Thursday." The manager breathes a sigh of relief, glad it's off their plate. Thursday comes, and what they get back is half wrong; they spend an hour fixing it and decide next time it'll be faster to just do it themselves.

The work didn't come back because the colleague lacked the skill. It came back because they got a task without everything that goes with it. In the manager's head there was a whole pile of things left unsaid: that the client reacted badly to long presentations last time, that the price has been held for three months because of volume, that the decision-maker is the CFO, who cares about numbers, not a story, and that "materials" means two pages, not twenty.

Delegating means transferring enough context that the other person can make the decisions you'd have made yourself. Without context, all you've delegated is execution — and execution without decision-making always comes back, because every task contains dozens of small choices.

A useful brief structure has five parts and doesn't take more than a few sentences:

Notice what's not on the list: the procedure. When you also hand over the procedure, you get exactly what you pictured and nothing more — and, crucially, you've just bought yourself a lifelong obligation to keep inventing that procedure. Delegate the result and the boundaries, not the path; that idea has its own tip, Delegate the result, not the procedure.

A practical trick for surfacing the context hiding in your head: before sending the brief, walk through it out loud with AI as the counterpart, and have it list the questions the recipient would have to ask. Usually three or four things you'd taken for granted fall out. The tip Delegating with AI: a brief that won't come back walks through the process and a sample brief. The usual rule applies: AI proposes, the human approves, and nothing containing colleagues' personal data belongs anywhere but a paid company account with contractually secured data protection.

Three levels of delegating, and how to state them

Most misunderstandings around delegating have one cause: the manager and the colleague have a different picture of how much autonomy was handed over. The manager thought they'd delegated a decision. The colleague heard a task and waited for instructions. Or the other way around — the manager expected a proposal, and meanwhile the colleague sent it straight to the client.

The fix is embarrassingly simple and costs one extra sentence. For every assignment, state out loud which of three levels you're operating at.

Do it. The decision is mine, the execution is yours. Used for things where the path is clear and variation adds no value, and for people who are new to the area. It sounds like: "Please do this exactly like this, by Thursday, and if anything doesn't fit, get in touch."

Propose it. The decision is mine, but the prep and the recommendation are yours. The most useful and least used level. You don't want a finished thing, you want an option with a recommendation: "Prepare two variants and write which one you'd pick and why. We'll decide together on Thursday." This level teaches people to make decisions without you risking the cost of a wrong one.

Decide it. Both the decision and the execution are yours; I hear about the result. It sounds like: "This is yours from now on. Up to a hundred thousand, it's your call, above that let me know. I'll hear the result at the monthly review." Without stated boundaries, this level doesn't work — a person who doesn't know where their mandate ends either freezes up or overreaches.

Two things this usually breaks on. First, the level isn't assigned to a person, but to a combination of person and area. The same colleague can be at "decide it" for their own area and at "do it" for something they're doing for the first time. The claim "they're self-sufficient" is therefore a half-truth; self-sufficient is always self-sufficient in something.

Second, the level should move up over time, and that shift has to be said out loud. When someone's brought you a good proposal three times in a row, tell them that from now on they decide on their own — otherwise they'll keep bringing proposals and you'll be under the impression they're not self-sufficient. An unspoken increase in mandate never happens.

Checkpoints instead of micromanagement

Micromanagement isn't a character flaw. It's usually anxiety about uncertainty, resolved the one way a manager thinks of — checking more often. The problem is it doesn't work for either side: the manager spends time checking and still has no certainty, the colleague loses their sense of ownership, and when something goes wrong, both sides think it was the other one's fault.

The alternative is called a checkpoint, and it's an agreement made in advance, not oversight carried out continuously. The difference matters: a checkpoint is on the calendar, both sides know about it, and it concerns the output, not the activity.

Three rules that make checkpoints a functional tool:

• Agree on them when you assign the work, not later. A checkpoint agreed in advance is part of the brief. A checkpoint requested midway through the work is a signal of distrust, even if that's not how it was meant.
• Put the first checkpoint early, not halfway through. The cheapest moment to correct direction is after ten percent of the work. A short check-in after two days on a two-week task saves you from redoing the whole thing.
• Check the output, not the process. The question is "show me what you've got," not "what did you do on Tuesday." The first reveals a problem; the second just triggers defensiveness.

For longer pieces of work, the principle of decreasing frequency applies: more frequent checks at the start, less frequent as trust builds and it becomes clear the direction is right. This is also the fair answer to the objection that checkpoints are micromanagement in disguise. They're not — micromanagement is unannounced, irregular, and about how the work gets done. A checkpoint is announced, regular, and about the result.

When a checkpoint reveals things are going in the wrong direction, don't immediately reach for the work. Ask first what was missing from the brief. In the vast majority of cases you'll find an unstated piece of context — and that's a fix that'll help next time too. Taking the work back over helps once and permanently damages the relationship.

1:1s as the backbone of leadership

A one-on-one is the only place where you can find out things that never come up in a group meeting. And yet it's the first thing to get cancelled when things get busy — which is exactly backwards, because "busy" is precisely the state in which problems hide easiest.

A few rules that turn a 1:1 into a tool instead of another obligatory meeting.

It belongs to the colleague, not the manager. The agenda should mostly come from the other side. When the manager brings their own list of items, the 1:1 turns into a status meeting, and a status can just be written down.

It doesn't get cancelled. A cancelled 1:1 carries a stronger message than twenty words about trust: you're not a priority. When the time genuinely doesn't work, move it to a replacement slot right away, so it's clear it's being rescheduled, not cancelled.

It has its own memory. One living document both sides keep adding points to, and where conclusions get recorded, turns a series of independent conversations into a continuous relationship. Without memory, every 1:1 starts from zero and both sides forget what was agreed last time. A practical form is in the tip 1:1 with a living document; prep and continuity with AI's help is covered in 1:1 with AI.

What belongs in a 1:1: what's blocking the person, what they enjoy and what they don't, where they want to grow, feedback in both directions, things that don't get said in front of others, and a longer-term topic there's no room for in the daily grind. What doesn't belong: project status (that belongs in the written overview), task assignment (that belongs in a brief), and team decisions (those belong in a meeting, otherwise a sense of backroom dealing sets in).

A useful opening question isn't "how are you" — that gets answered with "fine." More specific variants work better: "What slowed you down most this week?" or "What would you change if you could?" And then the hardest part of the whole 1:1: staying quiet, and letting the pause run longer than feels comfortable to the manager. Most of the important sentences come after that pause.

Feedback that neither wounds nor gets muddled

Feedback fails in two opposite ways, and both are common. The first is muddling: the manager wants to be nice, so they wrap the criticism in so much padding that the recipient reads it as praise with a minor footnote. The second is wounding: the manager sat on something for too long, ran out of patience, and then said everything at once, in the wrong tone.

Both failures share the same cause — feedback gets postponed. Postponed feedback inevitably grows, loses specificity, and picks up emotion. Feedback said right away is small, concrete, and calm.

What makes feedback usable:

A specific situation instead of a trait. "In yesterday's meeting you cut off the client three times" is fixable. "You're not empathetic" isn't feedback, it's a verdict — and people defend against a verdict instead of thinking about it.

Impact instead of judgment. Say what happened as a result: the client stopped talking, we lost the information, a colleague had to redo it that evening. Impact is a fact you can't argue with. Judgment is an opinion you can argue with forever.

A question instead of a verdict. Before stating a conclusion, ask how the other person saw it. Sometimes it turns out you didn't know half the story. And even when you did, a person who got the chance to describe it accepts the conclusion differently than one who was simply told it.

One thing at a time. Three points of feedback in one conversation means the recipient will remember the most unpleasant one and have no capacity left for the rest.

And one thing hardly anyone asks about: upward feedback. A team won't tell a manager what they're doing wrong until the manager explicitly and repeatedly asks for it — and until they've proven once that nothing bad happens afterward. The first honest answer to "what bothers you most about how I lead" is a test; how the manager takes it decides whether a second answer ever comes.

The monkey comes back: reverse delegation, and the end of working with your own hands

Management folklore has an image that's held up for decades: a task as a monkey sitting on someone's shoulder. A colleague comes with a problem, the manager says "leave it with me, I'll take a look" — and at that moment the monkey jumps shoulders. The colleague walks away lighter, the manager has picked up an obligation, and on top of that has become the person everyone waits on.

Reverse delegation is the quietest way a manager's calendar fills up. Nobody does it out of malice. A colleague comes with a legitimate question, the manager wants to be useful and knows the answer. Giving it is faster than drawing it out of them. But that's exactly what teaches both of them something: the colleague learns to bring questions, the manager learns to answer them.

The defense is simple, and it's one question asked before you get a chance to answer: "What would you do?" In most cases, the other person says something sensible and all that's left is to nod. Nothing smaller than that has happened: the decision stayed with them, and they know they don't need to ask next time. When the answer isn't sensible, you've just precisely identified a gap — and that's material for ten minutes of explaining, which is worth more than an hour of doing it for them.

The second defense is stating the handoff clearly. When a manager genuinely takes something over, it should be said out loud what's theirs and what stays with the other person: "I'll find out from finance by tomorrow, meanwhile prepare variant B." Without that, the colleague walks away thinking the matter is settled and waits.

When a manager has to stop working with their own hands

There's a point where a manager's expert work starts hurting the team. It's recognizable by a few fairly clear signals: the team waits on the manager's output more often than the manager waits on the team's. They systematically take the hardest, most interesting parts for themselves. People have stopped proposing solutions, because it'll get redone anyway. And the key things only happen when the manager is there.

The reasons managers hold on to hands-on work are humanly understandable. It produces a visible result, while leading is work whose effect shows up months later. They're good at it, often the best on the team, and being the best at something feels good. And above all — doing it gives them the sense of earning their salary, a feeling that doesn't come easily with leading.

The transition can happen gradually, without drama. Take the three biggest chunks of your expert work and, for each, ask: who on the team could get it to eighty percent, given the context? Eighty percent is a deliberate number — waiting for a hundred means never delegating at all. The remaining twenty gets caught up over two or three rounds, as long as you give feedback and don't take the work back after the first stumble.

The rest is a matter of your own psychology: accepting that a manager's performance isn't measured by what they got done, but by what the team can manage without them. The best test is a two-week vacation with no phone. If you come back to a company on fire, that's not proof of your indispensability — it's the bill for undone leadership. The chapter The psychology of productivity helps with working through your own head in this situation, because the need to be indispensable is more of a personal topic than an organizational one.

When these reflections lead to a concrete change in how a team works, the last chapter of the series awaits: Introducing change and the question of why most improvements die at the pilot stage.

Key takeaways

• A manager's calendar is a shared resource of the team. Spare capacity isn't laziness, it's queue prevention; predictable availability is worth more than constant presence.
• Delegate context, not a task. Result, why, boundaries, what you know and don't, level of autonomy — and never the procedure. Work comes back because of missing context, not incompetence.
• State the level: do it, propose it, decide it. The level belongs to a combination of person and area, should move upward, and that shift has to be said out loud.
• Checkpoints agreed in advance aren't micromanagement. Set the first one early, ask about the output, and when the direction is off, fix the brief, not someone else's work.
• A 1:1 belongs to the colleague, doesn't get cancelled, and needs its own memory. Status and task assignment don't belong in it.
• Give feedback right away, specifically, and through impact. Postponed feedback inevitably grows and picks up emotion. And keep asking for upward feedback too.
• For reverse delegation, a manager has one question: "What would you do?" Asked before they get a chance to answer.
• Eighty percent is enough. Waiting for someone to do it exactly as well as you is the most elegant way never to delegate at all.