Delegating to leaders

Day 30: Hand over the objective function, not the instructions

When you lead leaders, your output stops being the work. It becomes the quality of the decisions other people make when you're not in the room. Delegate in a way that strips out their reasons for deciding, and you end up with a team that can only escalate. If you spend your days directing AI agents, you can do this without ever noticing.

1. The moment: 'Just tell me exactly what you want'

A few months ago one of my tech leads closed a 1:1 with this: 'Honestly, just tell me exactly what you want and I'll do it.' There was no hostility in it. It sounded tired and cooperative, the tone you use with a manager you've decided to stop arguing with.

That line scared me more than any missed deadline. A missed deadline tells you about the work. This told me about the system. A senior person had concluded that their judgment wasn't wanted and that the efficient move was to execute. Once a lead says that, there's no lead in the seat. There's a very expensive pair of hands that sends every hard decision back to you.

Today's concept comes straight out of that. **Delegating to a leader means handing over the objective function**: what we're optimising for, what we won't trade away, and which calls are theirs. Not a step list. A step list makes the work legible to you. An objective function lets them keep going when the plan stops matching reality.

2. The leak: two messages, one afternoon

I went back through what I'd sent that week. Here are two real messages, anonymised and lightly trimmed. The first is a task spec for a Claude agent swarm that triages and fixes flaky integration tests. The second is what I sent my lead about the agent-generated PR backlog that same afternoon. See if you can spot the difference.

# Message A: to the agent swarm (orchestrator prompt)

Task: Reduce flaky integration tests in services/billing.
Steps:
1. Run the suite 5x, collect tests that fail intermittently.
2. For each flaky test, classify: timing, ordering, shared state, external dep.
3. Fix timing issues with explicit waits; isolate shared state via fixtures.
4. Open one PR per test. Title format: [flaky-fix] <test_name>.
5. Do NOT touch production code outside services/billing/tests.
6. Report back a table: test, cause, fix, PR link.
Done when: suite passes 5 consecutive runs.

# Message B: to my tech lead (Slack)

Hey, can you take the agent PR backlog?
1. Add a second reviewer pass (Claude review agent) on all agent PRs.
2. Update CODEOWNERS so each agent PR auto-assigns a human owner.
3. Set a 4h review SLA and add it to the team dashboard.
4. Keep PRs scoped to the ticket, no drive-by refactors.
5. Post a summary in #eng-leads by Friday: queue size before/after.
Done when: backlog is under control.

There isn't one, and that's the problem. Same numbered steps, same output format, same 'done when'. Message A is a good prompt. Message B is the same prompt sent to a human. Hundreds of hours of agent orchestration had given me a habit, and I'd carried it straight into how I talk to the people I'm supposed to be growing.

Now look at what Message B leaves out: why the backlog matters right now, what I'd be willing to give up to fix it, and what they're free to decide. All of that was in my head. None of it made it into the message.

3. What it cost over one quarter

One message doesn't do the damage. The pattern does. Looking back over one quarter, I can see three signals:

• ▹**Fewer pushbacks in staff meetings.** Proposals sailed through with little debate. I read that as alignment. In fact people had stopped treating the meeting as a place where decisions get made.
• ▹**More 'is this ok?' pings on Slack.** Small calls leads used to make on their own, like rollout order or whether to cut a scope item, started coming back to me for sign-off.
• ▹**One lead quietly stopped proposing architecture changes.** No conflict, no complaint. The design docs that used to turn up unprompted just stopped turning up.

Here's the name for it: **precise specs get compliance, and compliance at the lead level is escalation with extra steps.** When a lead is executing your plan, every situation the plan didn't cover turns into a question for you. You haven't delegated the work. You've delegated the typing and kept every decision.

The AI era makes this worse because agents reward precise specs so directly. Tighten the prompt and you get a better PR within minutes. That loop is fast, measurable and satisfying, and it trains you hard. People respond to specs on a much slower loop, and the cost (judgment slowly wasting away) shows up months later, somewhere you weren't looking.

4. Why agents and leaders need opposite inputs

This isn't 'agents are dumb, people are smart'. They're different kinds of mind with different properties, so they need different inputs to do their best work.

• ▹**An agent has no stake in the outcome.** It doesn't care whether the billing service is healthy next quarter. It optimises what you told it to optimise, so an ambiguous goal comes back as a confident wrong answer.
• ▹**An agent can't carry intent between sessions.** Unless you write that intent into its context (a CLAUDE.md, a spec file, memory), every run starts from zero. Scope has to be explicit because nothing else persists.
• ▹**A leader's whole value is acting well once the spec runs out.** A production incident, a customer escalation, a dependency that slips. None of it is in the plan. A lead with intent adapts. A lead with only steps has to stop and ask.
• ▹**A leader holds context you don't have.** They know which engineer is close to burnout, which module is cursed, which customer is about to churn. A spec overrides all of that. Intent puts it to work.

A quick aside from my PhD work on multi-agent systems. Even among software agents, the classic teamwork models are built on shared goals and constraints, not step lists. In Cohen and Levesque's joint intentions theory, and in Tambe's STEAM model built on top of it, agents commit to a shared goal and to telling each other when that goal becomes achieved, impossible or irrelevant. Tambe argued that teams coordinating only through precomputed, scripted plans are brittle: when the environment drifts, every agent keeps running a script that no longer fits. In my experience today's LLM agent swarms work the same way. An orchestrator that gives subagents the goal, the constraints and the stopping conditions recovers from surprises much better than one that hands out steps alone. The more autonomous the mind, the more it needs the objective function.

So the rule isn't 'specs for agents, intent for humans', full stop. It's this: **match the input to how much autonomy the mind can carry.** Inside a single session, today's agents carry little, so they need tight scope and a bit of intent. Leads carry a lot, so they need rich intent and a handful of hard constraints.

5. The rewrite: delegation as context

These days I use a three-part template when I delegate to a leader:

• ▹**The outcome, and why it matters now.** What good looks like, and the pressure behind it this quarter.
• ▹**The non-negotiable constraints.** The few things that aren't up for trade-offs. Keep this short. Once it grows past about five items, you're writing a spec in disguise.
• ▹**The decisions that are explicitly theirs.** Name them, or they'll assume they need your approval. Then say when you *do* want to hear from them, so they know exactly when to escalate instead of guessing.

Here's Message B again, rewritten:

# BEFORE (spec)
Hey, can you take the agent PR backlog?
1. Add a second reviewer pass (Claude review agent) on all agent PRs.
2. Update CODEOWNERS so each agent PR auto-assigns a human owner.
3. Set a 4h review SLA and add it to the team dashboard.
4. Keep PRs scoped to the ticket, no drive-by refactors.
5. Post a summary in #eng-leads by Friday: queue size before/after.
Done when: backlog is under control.

# AFTER (context)
Hey, I'd like you to own the agent PR backlog this quarter.

OUTCOME + WHY NOW
Agent-generated PRs are piling up faster than humans review them, and
I'm worried reviewers are starting to rubber-stamp to keep up. The real
goal isn't a short queue, it's that what we merge is understood by a
human who could debug it at 2am. That matters now because we're about
to put the billing service in front of two enterprise pilots.

NON-NEGOTIABLES
- No agent PR merges without a named human who has actually read it.
- No change to billing or auth paths without the existing security review.
- Don't solve this by burning the team out (no weekend review rotations).

YOURS TO DECIDE
- How review works: tooling, ownership, SLAs, whether to add a review agent.
- How much agent output we generate in the first place. You can throttle
  or pause workflows if that's the right lever.
- What 'healthy' means and how we measure it.
Pull me in if: you need headcount, it touches the pilot dates, or you
want to change a non-negotiable.

Share your approach when you have one. I'd rather see a rough plan
early than a polished one late.

Look at what moved. Every step from the BEFORE version is now just an option under 'yours to decide'. And the sentence that matters most, 'the real goal isn't a short queue', never appeared in the original. Without it, the most efficient way to satisfy my spec was to shrink the queue by making review faster and shallower. That's exactly the failure I was worried about.

6. What changed in the next six weeks

What came back first wasn't a plan. It was a question: 'Can I look at why the PRs are so large before I touch review?' That alone was a change. They were asking about the problem, not asking for permission.

Then came the decision I wouldn't have made. **They paused one of our agent workflows for two weeks and changed how tasks were broken down upstream**, so each agent PR covered one concern instead of bundling three. No second reviewer agent. No SLA. Their reasoning was that review was the symptom. Big, mixed-concern diffs were pushing reviewers into skimming, and a second AI reviewer on top of a skimming human would only add confidence, not understanding.

Why it worked better: review conversations got more substantive, reviewers could actually explain what they'd approved, and the backlog shrank because each PR was quicker to understand, not because people were moving faster. That was my real objective. I'd just never written it down.

The uncomfortable part: **it wasn't the call I would have scored highest.** By my instincts at the time (throughput, number of agent PRs shipped), pausing a workflow looked like going backwards. Grading against my own plan, I'd have pushed back. Handing over the objective function means accepting decisions that score badly on your proxy metric and well on the actual goal. If you only accept decisions that match your plan, you haven't delegated anything.

7. The test I run before hitting send

I ask one question before every delegation, whether it's going to a person or an agent:

If the plan breaks on day three,
does this message help them DECIDE,
or only help them ASK ME?

How I use it:

• ▹**For a lead:** if the honest answer is 'only ask me', you've written a spec. Add the why, cut the constraints down to the real non-negotiables, and name their decisions.
• ▹**For an agent:** inside one session you often *want* it to ask, or to stop. So here the test shows you what's missing: a stopping condition ('if X, halt and report') plus enough intent to choose between two valid fixes. For long-running or multi-step agent work, the answer should shift toward 'decide'. That's why good agent setups keep the *why* in persistent context files and not only in the task prompt.
• ▹**For yourself:** the answer tells you which mode you're in. If you're writing a spec to a person, ask whether the work really is trivial or irreversible (both are fair reasons for a spec), or whether you've just slipped into your agent habit.

When NOT to use context mode with a person: an irreversible, high-blast-radius action with one correct procedure (a data deletion runbook, a security incident step), or someone in their first weeks who doesn't yet have the context to use intent. Even then, add one sentence of why. That sentence is how they grow into someone who won't need the spec.

Common pitfalls:

• ▹**Vagueness dressed up as intent.** 'Make the backlog better' isn't context. The outcome has to be specific enough that two smart people would recognise the same success.
• ▹**A constraint list that's really a spec.** Ten 'non-negotiables' are ten steps in a different format.
• ▹**Abdication.** Handing over the objective function doesn't mean vanishing. Ask to see the approach early, and stay reachable at the thresholds you named.
• ▹**Overriding the first surprising decision.** Do it once and everyone learns the 'yours to decide' section is decoration. Disagree out loud, explain your reasoning, and let the call stand unless it breaks a non-negotiable.

8. Closing the 30 days

Look back across the series and every lesson comes down to one move: **transferring judgment, not tasks.**

• ▹**Feedback** works when it changes how someone decides, not just what they did that one time.
• ▹**Delegation** is moving decisions, not moving work items.
• ▹**Trust** grows every time you let someone's call stand when it differs from yours.
• ▹**Hiring** leaders means hiring for judgment you're willing to be overruled by.
• ▹**1:1s** are where you trade context: their view of the ground for your view of the objective.

In an AI-first team, more and more of the work is done by agents and directed by people. Your job as a leader of leaders is to make sure the people directing those agents have the objective function. Then they can write good specs for the machines without needing one from you.

**Your last exercise:** take the next delegation message you're about to send a lead. Before you send it, rewrite it in the three-part template: outcome and why now, non-negotiables, decisions that are theirs. Run the day-three test. Send it. Then watch what comes back. Maybe a question about the problem instead of a request for approval. A plan you wouldn't have written. A decision that scores badly on your proxy metric and well on the real goal. That's what it looks like when you're leading leaders, not just routing tasks.

Extend your knowledge

• ▹Read 'The Art of Action' by Stephen Bungay on mission command and 'directed opportunism'. That's where the idea of handing over intent instead of orders comes from, in its military form.
• ▹Read 'Turn the Ship Around!' by L. David Marquet, especially the shift from 'request permission' to 'I intend to…'. It's a practical way to move decision rights to your leads.
• ▹On the multi-agent side, look up Cohen and Levesque's work on joint intentions ('Teamwork', 1991) and Milind Tambe's 'Towards Flexible Teamwork' (1997, the STEAM model).
• ▹Re-read Anthropic's engineering post 'Building effective agents' and set its orchestrator–worker pattern next to your own delegation. Where do you pass steps, and where do you pass goals?