The AI-Native Manager Stops Assigning Work

Last post left a question: if alignment lives in written artifacts, review runs continuously, and knowledge lives in the meta repo, what's left for a manager to do? Honest answer: the job changed shape more than it shrank.

For most of my career, a big part of managing engineers was dispatch. Who's working on what. Who reviews this. What's next for that person now they've finished. A real slice of a manager's day was being the router, holding the state of the team in your head and matching people to work. I was good at it, and being good at it was partly a symptom of the problem, not a solution.

Because dispatch is exactly the kind of thing that should live in the system, not the manager. On our team, "what should I work on next?" is answered by the same /whats-next queue from the earlier posts. It looks at what's assigned to you, what's blocking you, the size and conflict-risk and importance of the open PRs, and a few hard rules we set: finish what's blocking you before you start something new, don't carry more than three things at once, clear the urgent stuff first. Then it just tells you. No manager in the loop, no morning ritual of me handing out tasks.

Intake runs through the meta repo too. Instead of routing work to a manager who slots it in, developers add the tasks they think need doing straight into the meta repo. Those get prioritized into the same queue automatically, and I step in only to help sort: bump something up, push something down, merge two things that are really one. The team proposes the work, the system orders it, I adjust the ordering. Very different relationship to a backlog than owning it.

What that leaves me doing is setting the policy, not making the moves. I don't decide that a specific engineer reviews a specific PR. I decide the rules PRs route by, what counts as too much work in flight, and what "high priority" means this quarter. The system plays every move by those rules. When the routing produces a bad outcome, the fix isn't to step in and re-route by hand. It's to find the rule that produced it and change the rule. Different muscle than dispatch, and I won't pretend I've fully built it.

The other half of the job that got bigger is deciding what we measure, because the old metrics actively lie now. Lines of code is meaningless when an agent writes the lines. Headcount as a proxy for output is worse than meaningless. Even velocity-as-tickets-closed mostly measures how we sliced the tickets.

What we watch instead is closer to whether the machine is healthy: how much of what gets opened actually merges, how much ships without a human circling back, how fast a change moves from "planned" to "in front of users." And one counterintuitive one: we want the count of bugs caught in our pre-production stage to go up, not down. A rising number there doesn't mean we're getting worse. It means our automated checks are catching more before it reaches customers, which is the whole point. A manager who panics at that number and "fixes" it is optimizing for exactly the wrong thing.

These aren't only our internal scorecard. They're the same numbers we watch for our clients, on the PRs their own PMs open through us. Merge rate, how much ships untouched, how much needed a developer to step back in: that's how we tell whether the people closest to the product can actually ship it, on our team and on theirs.

Now the honest part.

Some people don't want to be un-dispatched. Not everyone finds "the queue tells you" freeing. For some it felt like losing a relationship, the manager who knew them, knew what they were good at, pointed them at the right growth. Real loss, and pretending the system replaces it is a mistake. The dispatch went to the system. The development of people stays with me, and it needs more of my attention now that it's not buried under routing.

Setting good policy is harder than making good calls. A one-off routing decision I can make well on instinct. A rule that routes well across hundreds of cases I haven't seen yet is genuinely hard, and my early rules were too blunt and produced dumb outcomes at the edges. Policy-setting is a skill I'm still learning, and the feedback loop is slow.

You can hide from your team behind the system. The one I watch myself for. When the queue routes the work and the checks enforce the standards, it's easy to mistake the dashboards for knowing your team. Not the same thing. The tooling handles the coordination so I have more room for the human parts, judgment, growth, trust, the hard conversations, not less. If it quietly becomes an excuse to do less of that, I've used it exactly backwards.

Which brings the series back to where it started. The first post was about the handoff tax, the cost we pay every time work passes between people. Everything since has been one move, repeated: take the slow human-gated handoff and replace it with something durable and shared. Alignment into written artifacts. Review into continuous checks. Knowledge into the meta repo. Dispatch into the queue.

The reward isn't that the team runs without people. It's that people spend their attention on the parts that actually need a human, what to build, whether it's any good, and each other, instead of on the tax. That's what AI-native has meant for how we run R&D. Not a bigger model. A team reorganized around where humans are genuinely needed, with a system carrying everything else.