With people, move authority to the information. With agents, the other way around

In Turn the Ship Around!, David Marquet has just taken command of the USS Santa Fe, the worst-rated submarine in its fleet. On one of his first watches he gives a speed order the submarine cannot execute. Physically cannot.

And what happens? Nothing. The officer repeats it, the chain of command passes it along, and everyone tries to do something impossible because the captain said so.

I read the book a few weeks ago, now that I'm leading people more closely than ever. When I got to that scene I thought: this happens to me. But not with my team. It happens with agents.

Recently I asked one to simplify a service that calculates delivery windows. And simplify it did. It removed a branch that looked like dead code and actually covered local holidays. Tests green, of course, because nobody had ever written a test for that case.

The agent didn't say "hey, are you sure?". It did exactly what I asked. Just like the crew of the Santa Fe.

Where this comes from

I've spent years as a Staff Engineer supporting teams, but lately I'm leading people much more directly. And at the same time, like almost everyone, I'm handing more and more work to agents.

I'm learning to delegate in two places at once, and I keep seeing parallels.

I'm not the first one, either. Addy Osmani wrote that your coding agents need a manager. His point is that when you work with agents at scale, the problem stops being writing good prompts and becomes managing, and that what makes a good tech lead carries over almost as is.

I agree with almost everything he says. But when I finished it something was missing. It tells you what to do, but not so much why it works, or when it stops working.

That's where Marquet helped me. He ended up turning the Santa Fe into one of the best-rated submarines in the fleet, and the book tells how. His central idea is to move from a model where the captain thinks and the crew obeys to one where everyone thinks and decides within their scope. He builds it on three pillars: control (distributing decisions), competence (people knowing how to decide well) and clarity (everyone understanding the goal and the criteria). And his thesis is that you can only hand out control if the other two are in place. That thesis is what helps me know when I can let go of control with an agent without everything falling apart.

The ladder (which you probably already use)

The most practical tool in the book is the ladder of leadership. It starts from a simple observation: the way someone talks to you tells you how much autonomy they have.

On the lowest rung, the person asks for instructions: "tell me what to do". A bit higher, they tell you what they see and let you decide. Then they give their opinion ("I think we should…") and after that they propose something concrete ("I would like to…"). Halfway up is "I intend to…": the person has already decided and is just letting you know in case you object. Above that, they tell you what they've already done. And at the top they don't even need to report, because they've been doing it for a while and everyone knows.

What Marquet asks of the leader is to help each person climb. If someone asks you "what should I do?", instead of giving them the answer you ask "what would you do?". If they say "I think…", you ask them to turn it into a proposal. Every time you answer with an order, the person stays on the rung they were on.

The ladder in the book has a few more steps. I've simplified it a bit here.

Put it next to how you work with agents and it's almost identical. I've added a column with what I require before moving an agent up a rung:

The key rung is "I intend to". On the Santa Fe, moving from "may I do this?" to "I intend to do this" meant the person executing was the one thinking. The captain only had to say "very well".

With an agent it's the same. Before it touches anything I ask for a plan, to check it has understood the problem and isn't solving it wrong at full speed.

And the ladder isn't fixed. You don't give an agent the top rung just because, the same way you wouldn't give it to someone who joined the team last week. You move it up when you see it can handle it. Which is exactly what the pillars are about.

Clarity: the what and the why, not the how

I'm starting with this one because it's the one I see most clearly, even though it comes last in the book.

Marquet insists on giving goals, not methods. If you tell someone how to do something, you take away their initiative and miss out on solutions better than yours.

With agents you notice it a lot. "Add an index to this table" is an instruction. "This query takes four seconds at peak time and people are dropping off, I need it under 200 milliseconds" is a goal. With the first, it adds the index. With the second, sometimes it discovers the problem was an N+1 and the index had nothing to do with it.

The other thing they do on the Santa Fe is use guiding principles to decide. Principles the crew actually used when nobody had told them what to do.

When I read this I thought of the Model at Mercadona, the Spanish supermarket chain where I work. What struck me most when I joined wasn't any process, but that anyone, in a store, in logistics or in tech, understands why they do what they do and uses that to decide when nobody has told them what to do. It's exactly what Marquet was after on the Santa Fe.

For an agent, that's the project's instructions file. The conventions, the architecture decisions, the things we never do here. If that only lives in three people's heads, the agent will decide as if it didn't exist. Same as someone new, by the way.

It happened to me with a rule the whole team knew and nobody had written down: schema changes on large tables are done in several steps, never in a single migration. Among people it worked by word of mouth and the occasional attentive review. Until an agent generated a one-shot migration for me and I had no choice but to write it down. And the next person who joined the team found it already documented.

Competence: with agents, the repo is the one that learns

For Marquet, giving control to someone who doesn't know how to do the job is reckless. That's why he replaced the briefings where he explained things with ones where the people in charge had to show they were ready. Less briefing, more certifying.

With agents we already have that: tests, types, linters, CI. An agent with a good test suite can climb rungs safely, because if it gets something wrong, it finds out. One working on code without tests is on the first rung, however much we want to fool ourselves.

The same goes for "deliberate action", that thing of pausing and saying out loud what you're about to do before touching something delicate. It's what you ask of an agent when you force it to explain its plan before a big change.

But there's a difference that took me a while to see. People learn. Every mistake leaves them a bit better and next time they climb on their own. An agent remembers nothing between sessions unless someone writes it down.

So with people you invest in the person. With agents you invest in what's around them: the test that now catches last time's failure, the new rule in the instructions, the skill that explains how something is done. Competence ends up living in the repo.

And honestly, I don't know if this is temporary or will always be this way. With how fast agent memory is improving, this paragraph might make no sense in a year. For now, it is what it is.

Control: this is where it flips

The most famous idea in the book is that you shouldn't push information up to whoever is in charge, but push decision authority down to whoever has the information.

On a submarine it makes complete sense. Whoever is in the engine room knows much more about that room than the captain. Sending the information up so the captain decides is slower and turns out worse. Let them decide.

On a team it's the same. The people who touch the code and talk to the business every day usually know more than I do to make the call. My job is to make sure they're clear on where we're going, and from there let them decide.

With an agent it's exactly the opposite. It arrives knowing nothing. It doesn't know why that module is the way it is, or the incident we had two years ago, or what the business cares about this quarter. I know that.

So with agents you have to make the opposite move. You move the information to where you've put the authority.

This has a name, we now call it context engineering. I'm not discovering anything new. But I think Marquet explains very well why it matters. And also why so many people get frustrated with agents: they give them autonomy and don't give them context. It's like the captain who delegates to someone who just came aboard and is then surprised they decide badly.

And someone will say: "sure, but you also have to give context to a new person". Of course. The difference is that the person picks it up on their own: they go to meetings, they live through incidents, they talk to the business. The agent only knows what someone has left written where it can read it, whether in the instructions, in a memory or in the tests.

So what you want is to set things up so the agent keeps accumulating it and, with that, keeps climbing rungs. Which, deep down, is coming back to Marquet by another road: when the information is where the agent works, you can give the authority to it.

What doesn't fit (and what agents have taught me)

I have to say that half the book doesn't apply.

Marquet talks a lot about trust, caring for people, their careers, the pride of belonging to something, recognizing work on the spot. None of that makes sense with an agent. And I don't want this to read as "treat your team as if they were agents".

What has happened to me is that agents act as a mirror.

If I can't explain what I want without saying how to do it, an agent makes that clear in ten minutes. With a team the same problem takes months to surface, and by then you've already blamed it on them "not understanding the business".

If I can't stop myself from reviewing every line an agent writes, I'm probably also over-reviewing what my team does. And if I struggle to move an agent up a rung even though the tests are green, maybe the trust problem is mine.

It happened to me with reviews. I caught myself reading line by line every diff from an agent that had gone weeks without failing on a very specific kind of task. When I asked myself why, I didn't like the answer at all: I didn't trust what I hadn't done myself. And then I saw the same thing in how I reviewed my team's PRs.

And it works the other way too. When an agent messes up and instead of thinking "this model is terrible" I think "what context was it missing?", I'm practicing exactly what I should be asking myself when someone on my team makes a bad decision.

The captain who's no longer there

Marquet says a leader is measured by what happens after they leave. The Santa Fe kept running brilliantly years after he left, and many of his officers went on to command their own ships.

With agents I think there's something similar. What tells you whether you're doing it well is whether what you've built around them (the tests, the written principles, the context) lets them work well without you watching.

I have no idea how this will evolve. Maybe in a couple of years agents learn on their own and half of what I've written here is unnecessary. Honestly, I don't know.

What I do know is that I'm learning to delegate in two places at once, and each one is helping me with the other.

A question for you: have you caught yourself doing something with agents that you later recognized in how you lead your team?