The Management Skills I Brought Back to IC

For now, I do not have direct reports. That was part of what I wanted from this chapter.

More and more, though, a development session starts somewhere that does not feel much like engineering. Before writing anything myself, I am deciding which of the problems in front of me is worth handing off at all, giving one of them enough background that the work will not start from a wrong assumption, stopping something that turned out to be solving the wrong shape of problem, leaving another alone because its plan was going somewhere reasonable. Then I review what arrived while I was doing all that.

That is not how I would have described a morning of engineering work a few years ago. It is much closer to how my mornings looked when I was leading a team.

The recognition arrives with some discomfort. This feels suspiciously like management.

Not because agents are colleagues. They are not, and I will come back to how much that matters. But a familiar set of problems shows up whenever execution can be handed off: what to delegate, how much context to give, how much room to grant, and how to tell good work from work that merely looks plausible.

I started out thinking AI was turning delegation into an engineering skill. The longer I sit with it, the less certain I am that delegation ever belonged only to management — staff engineers and tech leads have been splitting and coordinating work without direct reports for as long as I have been doing this. What changed is narrower and more mechanical. Delegating execution has moved into the daily work of an individual engineer, and it now happens several times before lunch.

The names the industry already gave it

I am clearly not the first person to notice this, and it would be strange to pretend otherwise.

Microsoft's Work Trend Index describes an "agent boss" — someone who builds, delegates to, and manages agents — and asks organizations to think about a human-agent ratio: how many agents a role needs, and how many humans to guide them. OpenAI's writing on harness engineering compresses the idea into three words: humans steer, agents execute. Anthropic's work on multi-agent systems reads, in places, like an org design document, and Harvard Business Review ran a piece in February arguing that companies need "agent managers" as a distinct role.

Most of that vocabulary is organizational, written from the outside about how firms will be shaped and which roles will exist. The question catching my attention is smaller: which of the things I learned managing people turned out to be portable, and why they came back without anyone announcing them as engineering skills.

Deciding what is worth handing off

The part of delegation people skip is the part that happens before the handoff.

A manager who distributes everything on their plate is not delegating. They are dispatching. The judgment sits in the selection: what genuinely needs your own thinking, what is defined clearly enough to hand over, what would help develop the person receiving it, what combination of risk and context makes handing it over sensible. With agents one of those criteria disappears completely — nothing grows from a stretch assignment — and the rest get sharper, because the cost of starting has collapsed and the cost of evaluating has not.

Capability turns out to be a poor criterion on its own. Not everything an agent can do deserves to be delegated. Some of that work is where my own understanding of the system gets built, and handing it off buys an afternoon at the price of not knowing what I am looking at next week.

Delegating execution saves time. Doing the work yourself sometimes buys understanding, and those are not the same currency. The task you are most tempted to hand off is occasionally the exact one you need to do yourself, because you do not yet know enough about the problem to judge the answer when it arrives. That trade is easy to get wrong in the direction of speed, and the cost shows up late, usually as a review I am not equipped to do.

A study in this year's ACL findings, on human-AI cooperation in question answering, separates two decisions people tend to blur: whether to hand the task over at all, and whether to accept what comes back. Participants got both wrong in opposite directions, passing up correct suggestions and adopting confident wrong ones. The domain is not software, so I would not stretch the numbers, but the split is the useful part. The first decision is the easy one to skip now that handing something over costs almost nothing.

Those two decisions sit at either end of the work, with the question of how much room to give it while it runs in between. Most of the tooling conversation lives in that middle. The judgment tends to live at the ends.

What the handoff has to carry

A weak manager delegates an instruction: do this, in this way, by Thursday. A good one delegates something heavier — the outcome, why it matters, the constraints that are not negotiable, which decisions belong to the person doing the work, and what "done well" looks like when nobody is watching.

That asymmetry shows up with agents, and it shows up fast. Anthropic's write-up on their multi-agent research system has a detail I keep thinking about: when the orchestrating model gave its subagents short, simple instructions, they duplicated each other's work and left gaps in coverage. The fix was not a smarter model. It was giving each one an objective, an output format, and clear boundaries. Anyone who has split work between two people with a single sentence in a planning call knows that failure by its other name.

The skill was never writing longer prompts. Good delegation compresses context without removing judgment — you are trying to get someone to the point where they can make a decision you would recognise as reasonable, including decisions you did not anticipate. Deciding where that context should live is a conversation about how the team works more than a tooling problem. Writing it down is not overhead. It is the work.

Autonomy as a design decision

You do not normally ask a senior engineer to get approval for every step. Someone in their second week on an unfamiliar system gets more checkpoints, and that is not a judgment about them — it is a judgment about how much the system will forgive.

With people, that calibration mostly happens by feel, adjusted over months of watching what comes back. With agents you have to make it explicit, which is uncomfortable at first and then clarifying. Autonomy stops being a switch and becomes something you compose: scope, which tools are available, which actions need a human first, how reversible the result is, and where the plan gets inspected before anything runs. Anthropic's writing on trustworthy agents makes the shape concrete with plan mode, where the model shows its intended approach up front and oversight moves from the individual step to the overall strategy. That is the move a manager makes when someone earns more room.

Both failure modes are easy to reach. If you approve every individual step, you pay the coordination cost while keeping most of the work, and the agent becomes an expensive typist. Hand over a wide scope with no checkpoints and it is not delegation either. Delegation ≠ Abdication. The difference is whether you designed the boundaries before the work started or discovered them afterwards.

The new span of control

One agent is a clear multiplier. A few more still feel manageable. Somewhere past that, something changes, and it is not the agents that break.

Span of control, in management, was never about how many people a manager could talk to in a week. Calendars are solvable. It was about how many contexts one person could hold well enough to make decisions inside them — enough of the problem, the history, the constraints, and the half-finished work to know when an answer is wrong. Past that number, the manager is still present in every meeting and useful in none of them.

The same ceiling exists here, and it arrives sooner than the tooling suggests. Microsoft's own framing of the human-agent ratio carries a warning I did not expect from that source: too many agents per person overwhelms the human capacity for applying judgment and decision making. OpenAI, describing what they learned building a product with a team of agents, lands in the same place — human time and attention as the resource the whole thing is organized around. Machines pay coordination in tokens. We pay it in attention, and that budget does not scale with the hardware.

Capacity is not throughput. You can have a dozen things executing and nowhere near the capacity to supervise a dozen things, and the gap between those numbers is invisible from outside — the dashboard looks the same either way.

The anti-pattern I have started catching in myself is Blind Fan-Out: starting more parallel work than you can meaningfully evaluate, because starting is cheap and evaluating is not. It feels productive. Then the reviews get shallower, one by one, until you are approving things because they look like the kind of change you asked for rather than because you followed the reasoning.

The signal I watch for now is the quality of my own questions. Inside my span, I ask about specific decisions — why this boundary, why this order, what happens when the input is empty. Past it, the questions turn generic, the kind you could ask about any diff. That shift shows up before anything goes visibly wrong, and it is the only early warning I have found that does not depend on hindsight.

The coordination cost is not identical to managing humans. There is no morale, no calendar, no career at stake, no cost to interrupting someone at four in the afternoon. But dependencies still collide, work still gets duplicated, and someone still has to hold the map of what is in flight. That someone is you, and there is only one of you.

Feedback with nobody to coach

Here is where the two things start to come apart.

When feedback to a person lands, its effects can compound. They carry it into work you will never see, and six months later they are making the call themselves. That is the return on the awkwardness of the conversation.

Correct an agent mid-session and the correction holds for that session. Unless it is captured somewhere durable, there is no reason to assume it will shape the next one. The second time you type the same thing, it is a signal. The third time, it is a defect — not in the model, in your system. The correction belongs in an instruction file, a test that fails loudly, a tool that makes the wrong thing harder than the right one.

OpenAI's harness engineering post puts it well: when something failed, the fix was almost never to try harder, but to ask what capability was missing and how to make it legible and enforceable. That is a systems question, not a coaching one.

A person can internalize feedback and apply it somewhere you never explicitly encoded it — not automatically, and rarely on the first pass, but they get there. With an agent, the version of that learning I can rely on is still whatever I captured in the system around it.

Which is humbling, because it is also true of teams — the same friction keeps returning to retros when nobody converts the conversation into anything the system can hold. The difference is that with people the structural fix is never the whole answer.

Where the management analogy breaks

The analogy is useful right up until it becomes an excuse for sloppy thinking.

Agents do not have careers. They do not need purpose, or recognition, or a reason to stay. They do not experience psychological safety or its absence, they do not get quieter after being overruled twice in a week, and they do not burn out. A large part of what management is — protecting people, growing them, noticing the week someone stops sounding like themselves — has no counterpart here. Not a smaller version. None.

This is also why I keep flinching at the habit of calling agents junior developers. A junior engineer accumulates organizational context, develops taste, and needs progressively less from you over time. The improvement I can count on here comes from what I encode in the system, not from assuming the agent learned the lesson. Confusing the two makes you worse at both jobs: you stop investing in the person, and you keep expecting the tool to remember.

Both of the decisions from earlier, whether to hand it over and whether to accept what came back, stay with you. You can delegate execution to an agent. You cannot delegate accountability to it, and nobody is going to ask the agent what it was thinking. The engineering work that leaves no commit has quietly grown a new component: being answerable for output you did not personally produce, which used to be one of the defining discomforts of the manager's job.

What travels between the two modes

When I moved back into an IC role, I did not come back as the engineer I had been before management. I brought things with me: a habit of deciding what deserves attention before starting anything, a tolerance for not controlling every implementation detail, a sense of when stepping in costs more than the mistake, some comfort with acting on information I know to be incomplete.

I assumed those were skills I would use less while spending a chapter closer to the implementation work. I wrote about returning to the craft not being a step backwards partly to argue that the range was worth keeping, but I imagined it showing up as perspective — better questions, a wider read on why systems end up shaped the way they are. Not as daily mechanics. Instead they surface several times a day, in decisions I would once have made only about other people's work.

I should be honest about the limits. I am describing a handful of parallel threads, not a fleet, and the shape of the problem may change at a scale I have not worked at. Some of this is probably a property of this generation of tools and will look quaint in eighteen months. There is also a version of the argument that curdles into treating everything as a coordination problem, which would be a sad way to spend a career that started because building things was fun. But it has held long enough that I have stopped treating it as a novelty.

Final thoughts

What surprised me was the order they came back in. Not the technical judgment, which I always assumed was the durable half; that travelled too, but it never really left. It was the other set — the ones I was quietest about, that felt like the tax I paid for having a title, hardest to put on a CV without sounding like I had stopped being an engineer.

Those were never about having people to manage. They were about what happens when you are not the one doing the work, and that condition turns out to be far more common in engineering than our career ladders tend to suggest.

Moving back to IC did not put those years on pause. It changed where the skills show up, and left the question of what I do next genuinely open. Which makes me think the interesting part of moving between management and engineering is not which side you end up on. It is what turns out to be portable between them.

The org chart was never where that work lived. It was only the place we had learned to file it.