# Nobody Taught Developers to Delegate
Coding agents didn't make developers into button-pushers. Never being asked to delegate did.
The senior who did it by hand
This year we built a workflow around our coding agent: a set of commands and agents that scope a ticket, plan the delivery and hand the work back for review. In the first few weeks of introducing it, one of our senior developers was handed a well-formed plan through it. We expected to see something within a few days. After more than a week we were still at the “it’s coming together” stage, and we were starting to ask why.
So I had a catch-up with them, and it was clear that while they were following the plan, they were still doing everything manually. They were very open about it. They were struggling with the idea of forming the plan and delegating to agents, so they had reverted to writing the code by hand.
This wasn’t a discipline problem. The developer had a plan written to be delegated, and they executed it the way a good individual contributor executes a plan: themselves, by hand. What they needed was someone to sit with them, so we did some pair teaching on how to use the workflow, and restarted the ticket from the beginning.
That catch-up is what resistance to agents has looked like on my team. Nobody refused, and nobody argued about job security. Seniors wanted to feel in control of the process, so they quietly ignored the workflow and the tools and carried on working the way they always had. When one of them said it out loud, it sounded like “I don’t see why we need to change our process, I’ve been doing it this way for years and it’s worked fine.”
People who have managed humans find this natural
The gap I saw in that catch-up is one I recognised, because I had to learn the same thing about 15 years ago.
My first delegation began when I started to hire developers at CookiesHQ, the agency I co-founded. It was a learning experience, delegating things to other people. Most delegation fails, in my opinion, because of a lack of understanding. The person delegating assumes the person receiving the plan will make certain decisions, so those decisions are never surfaced: use this code pattern, achieve X this way. When the person receives the task and implements it, they don’t have that context, so they make their own decisions. Most of the time, that creates divergence between what was asked for and what was produced.
With a human colleague, at least some of those missing decisions get asked about. Someone walks over and says “did you mean this or that?” With an agent, they get made silently, and you find out at review, if you find out at all.
Learning to surface those decisions before you hand over is the skill, and it’s why the distinction worth drawing has little to do with seniority. A senior individual contributor has led code, sometimes for decades, but has never led people. Someone who has handed work to another human and lived with the result is a different animal, whatever their title. The seniors on my team who quietly resisted were the first kind. The CTOs I see taking to coding agents without much fuss are mostly the second.
What the second group has learned is to formalise a plan and hand it over to other team members to execute. They have learned to trust their team to make decisions and take ownership of the work. And most importantly, they have learned to smell the right touch points, and to know when to step in and when to step back.
They don’t delegate by saying “AI, do this for me.” Delegation has two halves: a plan someone else can run, and checking what comes back at the right moments. A developer who has never handed work to a person has practised neither.
Why developers don’t have it
Developers were trained to do. They were trained to write code, implement features and fix bugs, and they were proud of their ability to produce something tangible. Until a certain level, nobody trained them to delegate.
They were formalising a plan before, but only to be consumed by themselves. Most likely it was a rough outline of the steps to follow, in their head or in a few bullet points, not something detailed enough to hand to someone else.
I can see that pattern in how we worked before the workflow. We knew what we wanted to build, but we didn’t have a granular plan in place. The developers would start building, and as they went along they would hit new challenges that caused the plan to change. That led to confusion and delays, because the team was constantly adjusting its approach and reworking parts of the codebase. It cost us time.
For a lot of developers, building is the fun part, and delegating isn’t. It comes out of a desire to create, and handing that over to someone else works against it. Delegation is learned through experience, often too late in a career, and the best way to learn it is to be forced to.
Same tool, opposite experience
On 20 September a developer posting as v0xium wrote a thread on X that had about 7 million views by the time I read it two days later. He was half a month into a new role at a big company. “The specs, code, tests, PRDs, tickets, resolution of those tickets, reports”, all of it was being made by Claude Code. “Everyone, literally everyone, from an L1 to an L7 engineer here is doing the same thing.” “People are working 12 to 13 hours a day just to press enter.” The line most people quoted was “In reality, nobody is thinking anymore.”
I can’t say anything about his experience, really. I don’t work there. His own diagnosis pointed at management measuring the team on sprint velocity, PR count and features shipped, without giving engineers time to review the generated code or understand the architecture underneath it.
This is everything I’m trying my hardest to not introduce in my team. It’s a management decision. The difference I can speak to is what I asked for: a plan before the agents start, and time to check what comes back.
The CTOs I mentioned earlier have the delegation habit and can’t see that it is a habit. So they encourage everyone to jump on the AI bandwagon and then struggle to understand why their teams aren’t as productive as they expected. Their developers were on the receiving end of instructions for their whole career, and were never asked to delegate.
Button-pushers are made, not hired.
If your team is pressing enter 13 hours a day, you handed them a subordinate and never taught them to manage one.
On my own team the pressure runs the other way. My role as a CTO is to look forward, and my bet (and I accept I can be wrong) is that writing code by hand is a skill that will be less and less valuable, so I want the workflow used. But the last thing I want is a team of button-pushers, mindlessly approving what the AI suggests without being able to explain it. It’s a fine line between the two.
What we do instead
The way we walk it is to build the delegation into the steps, so a developer can’t skip it even when they would rather build.
It starts with a scope. A team lead or I will write a ticket scope: what this ticket introduces, for whom, the problem we want to solve and how we envisage solving it, followed by a series of user acceptance criteria. That’s what the developer receives, and we introduce it in a catch-up meeting to make sure of three things: that the problem understanding is clear, that the outcome understanding is clear, and that we are aligned on the plan forward. That meeting is where the decisions I would otherwise assume get surfaced, which is the failure I described at CookiesHQ.
Then the developer runs a command we call /dev-plan on the issue. It requires the developer to explain how they would approach the task, in which order, the gotchas, the things not to miss, and which patterns or libraries they might decide to use. Its job is to encode the developer’s thinking before anything is passed to the agents that build. This is the plan written for someone else, the thing an individual contributor never had to produce.
The build then happens in phases. When the agents finish one phase of the plan, they stop and ask the developer to review the code, and they won’t progress without approval. This is where the developer steers the shape of the feature, phase by phase. It’s also the checking half of delegation, the touch points, built in as a stop rather than left to whoever has the time. In the final part, one agent runs a visual QA of the implementation and asks the developer to check it as well.
We use the tools, but we don’t delegate the decision-making to them. The workflow is designed to force some thinking time and input from the person on the ticket. I wrote about the result in the last post: 50-odd tickets built through it with a low rejection rate, and the seniors who resisted at first saying they are doing a better job with it.
The fair pushback on all of this is that plenty of developers can plan fine, and the button-pusher is made when nobody budgets time to check what came back. That was v0xium’s point too. I agree, which is why I said delegation has two halves. The phase stops are our version of the checking half, and the right side of the workflow, QA and release, is what we are building now.
The second pushback is that the problem in that thread is the 13-hour day, not a missing plan. Management has to be responsible for the workloads and their impact on the team. If management is demanding a 13-hour day, it indicates a deeper issue with how work is being assigned and prioritised. The workflow is our management decision about where the saved time goes. At Amba, the time we’ve saved on writing code is going back into planning what we write and checking what comes back, not into more tickets and not into longer days.
And yes, this is what seniors always did. I took that one on in the last post and won’t re-argue it here.
We’re soon getting two new developers on the team, so we will see what teaching this from day one looks like. In the past it was easy: you would give them some small, light tickets you knew would touch a broad surface of the app, let them loose and let them discover. I have no idea what that looks like today.