How Many Direct Reports Is Too Many? Manage 16+ With AI

Here is a day of an AI-native engineering manager with 26 direct reports, on the EM Dashboard we built together. It’s an example put together from our rules and screens, not a diary entry.

• 9:00. One ranked list instead of seven inboxes. The US teams worked overnight, and a Claude paragraph plus the top five tell the EM what needs attention first.
• 9:15. Two status updates are late. The dashboard has drafted a friendly nudge for each, and they go out with one click.
• 9:30 to 12:00. Focus time. Our calendar rules keep the mornings free of 1:1s.
• 13:00 to 17:00. 1:1s, one after another, in the same meeting room. Before each one, the EM reads a brief built from that person’s notes, messages and feature channel, so the hour goes to the person.
• Once a day. A calendar check looks two weeks ahead for clashes in the 1:1s and proposes fixes. Nothing moves until the EM says OK.
• Fridays. No 1:1s. The dashboard drafts the status updates from Jira and Slack, the EM edits them and clicks “Yes, post”.

Span of control is the number of people one manager leads directly. The usual answer for an engineering manager is five to eight. In Gallup’s data, the median manager had five to six direct reports in 2025. The average was 12.1, pulled up by a minority of very wide spans.

I think five to eight was a routing limit from the start. A manager at eight spends the week moving information around: who owes an update, which project slips, what happened in a thread they weren’t in, what to ask in the next 1:1. Take the routing off the manager and the people part goes past 16.

With one of my mentees, I’ll call him Adam, we built an EM Dashboard that takes the routing off his week. In 2025 the org was 8 people in one team. Today it’s 26 people in three teams, all reporting to Adam. The dashboard is how Adam kept the same working hours: “I have a family and I want to have a happy wife.”

Two team leads help run the teams. Every one of the 26 has a recurring 1:1 with Adam, bi-weekly, and weekly for new joiners in their first two months. That’s about 13 1:1s a week, a few more while someone is new, and the calendar is where span of control costs you.

What 26 people look like at 8 a.m.

Before the why, here is what the EM Dashboard looks like. Three screens below, the ranked list, the status draft and the 1:1 brief, are redrawn from Adam’s app. The rest are mock-ups we sketched for inspiration. Every name and ticket is invented.

One ranked list instead of seven inboxes

The US teams work while Adam sleeps, so the mornings used to start with surprises. Now the first screen pulls Jira, Slack, email, calendar, tasks, CI and status updates into one list: a Claude paragraph, the top five, then everything else in falling priority.

Any item becomes a Google Task with a slot on Adam’s calendar. The list remembers what’s been cleared, so an item only comes back when it changes. “Theoretically it is improving every day,” Adam says.

Status updates Adam only approves

Adam says it plainly: “I don’t like writing the status updates.” Every Friday the dashboard drafts them from the Jira changes and the Slack discussion. Next to the draft it lists what it used and which rules it applied, format, dependencies and voice, so Adam can check the work instead of trusting it.

Adam edits in the box, clicks “Yes, post”, and the dashboard posts it to Jira and the other places the process asks for, “because unfortunately our processes are very complex.” The dashboard doesn’t fix the process. It stops the process from eating Adam’s Friday.

A brief before every 1:1

Adam calls this one “the most controversial”, and it’s the one Adam is happiest about. Before each 1:1 the dashboard reads the previous 1:1 notes, the person’s emails, Slack messages and DMs, and the channel of the feature they work on. It writes a brief: what the two discussed last time, open items and who owns them, what is worth raising, each linked to its source, and a suggested agenda.

That’s personal data, so three things hold. The team knows what the dashboard reads, the Anthropic API runs on a company-approved account, and nothing that touches a person goes out without Adam’s yes.

Adam is in about 150 Slack channels and doesn’t monitor them. “But I would know that this person has a problem,” because the brief surfaces it, and it can be escalated before the 1:1 even starts.

The routing jobs on screen

Three more routing jobs, with the full split in the table further down. The calendar screen comes later, with the story of how it broke.

Five to eight measures the routing

Ask four sources how many direct reports is too many and you get four numbers.

The numbers disagree because they measure different weeks. In the McKinsey row, the role that coaches least carries the most people. The span moves with what the manager does all day, so the useful question is what fills the week, not how many names sit on the org chart.

Gallup has one more number that matters here. 97% of managers also do individual work, a median of about 40% of their time. So a typical manager runs their people with about three days a week. Something has to give.

The strongest case against wider spans

John Farrier makes the opposite case: AI raises the volume of change in a team but not anyone’s capacity to review it or coach people. In his words, “When AI increases code volume, do not assume you can widen management span.” He is right about review. Adam’s teams spend more time reviewing code than before, because they still gate every merge on a human.

Reviewing the work, performance conversations, hiring and pay need judgment, and no rule file removes them. A rule can still shrink how much of it lands on the manager. Review needs a policy: what gets a deep read, what gets sampled, who looks first. Deciding that policy is a management call, and once it’s written, the manager stops sitting in every review thread.

So review capacity is real. I just don’t think it caps the span at eight, because status, context, risk and 1:1 prep are the part a script can take.

The teams got faster. Adam’s week got worse.

Here is what Adam measured on the three teams, from Jira and Adam’s own calendar.

The teams got up to about 30% faster, and the time from started to done dropped by about 35%. Adam’s side went the other way: more dependencies to track, more meetings, and 2.5 times more double-booked hours.

In Adam’s words: “I had to start attending more meetings, the dependency sync-ups, some escalations, some tracking meetings, and my calendar started to be fully booked. Sometimes I was double-booked, triple-booked, and nobody knew which one I would attend.”

Adam is honest about the caveats: Claude crunched Adam’s own data, it’s hard to quantify, and AI was not the only cause. It accelerated a problem that was already there.

The 2.5 times measures the growth itself: April to September 2026 against the same months of 2025, while the org went from 8 to 26. Roadmap delivery gives a cleaner before and after. Adam started on the dashboard in April 2026, so Q2 was partly a build quarter and Q3 the first full quarter on it. That quarter the teams delivered 81% of the quarterly roadmap, up from 55% in 2026 Q2.

Adam also counts 60% less context switching, and reports better sleep, more time for focus work, and less time lost on ops issues and on finding out where the truth lives. These are Adam’s own numbers from one org, not a controlled study. The org and the AI tools changed over the same months, so I don’t credit the dashboard alone. The people side, like engagement or how the 26 rate their 1:1s, isn’t measured yet.

This is one case of a measured pattern. In Faros AI’s data, teams with high AI adoption merged 98% more PRs and spent 91% more time on PR review. Faros sells measurement tools and the numbers are correlations, so treat them as directional. In Atlassian’s 2025 developer experience survey, 68% of developers saved more than 10 hours a week with AI, while 50% lost 10+ hours a week, largely to organizational inefficiencies.

DORA’s 2025 report puts it in one line: AI “magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.”

Adam sees the same thing one level up. “The supporting roles, either the managers or the PMs, may not be scaling that fast.” Some PMs Adam knows can’t write PRDs as fast as their teams now consume them.

Faster teams don’t automatically deliver more. They move the queue to the people who route the work, and on most teams that person is the engineering manager.

The engineers now manage agents

In the 1:1s, Adam hears the same story. A developer hands a task to an agent, the agent runs for hours, and one engineer now brings his own grips to the office foosball table, “because his agent is working for him.” A Hacker News commenter, quoted by Addy Osmani, said it shortest: “You’re not coding anymore, you’re supervising.”

“Developers are becoming managers of the agents… That’s basically what I was doing as a manager, and I was hoping for the best,” Adam says. Some engineers decided “this tool is not for me,” others need parallel agents explained “like a branching mechanism,” and for Adam “it is really about the mindset of the people.” Those conversations take the manager’s time, and at 26 people that time has to come from the routing.

Write the routing down before you automate any of it

We started with a list of what Adam repeats every week.

Spotting risk, for example, means catching a project that should end next quarter while the work is “still 10% in.” None of the four is leadership. All of it is routing, and it lands on the manager because the how lives only in the manager’s head.

So we wrote it down. Adam talked it through with Claude first: “I started talking to Claude and I explained what I do, and we started writing some rules.” Each rule got an id like SU-5. Here is the weekly status rule:

# weekly-status.md
# Expect a weekly update when the project
- is in progress, has a dev-complete date,
  or has 2+ issues in the current sprint
# Flag it as at risk when
- the latest update is Yellow or Red
- dev-complete date passed, work still open
# When an update is overdue
- draft a short, friendly nudge
- send it only after I confirm

The ids are there for the hard conversations. When a project gets flagged and someone disagrees, they point at SU-5. As Adam says, “we argue about the rule, not about feelings.”

Writing the rule is the hard part, and Adam admits it: “It is the hard part at the beginning.” A manager knows in seconds that a project is at risk. Naming the conditions that made them think so is slower, and that naming is the delegation.

The better you can explain your judgment, the more reliably you can delegate it.

A script runs the rules. AI only gets the judgment calls.

This is the part we built together. For years I’ve built dashboards on dev team efficiency, and they are how I was able to lead 80+ teams. With Adam, we extended that idea with AI into an EM Dashboard, so a tech manager spends less time on operational issues and doesn’t burn out.

Adam’s first version, two years ago, was a static page that only showed data. Together we spent 4 months building the EM Dashboard on Adam’s real use cases, with Augment Code and then Claude Code. It has 9 screens and costs about $170 a month, for the automated data pumps and the LLM calls that help draft replies.

Under the screens it’s plain plumbing. Data pumps pull Jira, Slack, email, the calendar and CI every 4 hours with read-only access, and store the raw pulls and a cleaned-up database of people, projects and updates. A plain script then checks about 100 rules, kept in 5 plain-English files, over that database. It spends zero AI tokens and gives the same answer twice.

Adam explains why that matters: “once you have algorithms you are not consuming the tokens, and I can refresh the database quite often without spending a single token.”

Only when the work needs understanding does the script call Claude through the Anthropic API, with just the records the rule selected: summarising a long Slack thread, drafting an update, picking the top five. The result comes back into the app as a draft, with the sources and rules it used. That keeps it cheap, predictable and easy to check, because the rules are code we can read.

The diagram follows the design we built.

The second design choice is the line between reading and acting. Everything that only reads runs on its own; everything that touches a person waits for Adam’s yes. In practice that’s a Jira comment, a Slack nudge, a moved meeting or a report to Adam’s manager, each held in the app until then.

The last column is what’s left for Adam: the decisions and the conversations. The volume moved to the script.

Next, we plan to bring the monthly cost for models and automations down to about $120, and early in 2027 Q1 to roll the dashboard out to other teams and their EMs.

We automated the prep and kept the hour

Here is why the 1:1 brief matters most to Adam: “I want the meeting to be fully owned by the person. I don’t want to spend half of the 1:1 on what are you working on and where it is.”

The easy way to survive 16+ people is to stretch 1:1s to monthly and keep the status talk inside the ones that survive. Adam kept them bi-weekly and moved the status part to the brief, so the hour went back to the person.

Gallup gives the reason not to cut the hour. Of employees who strongly agree they got meaningful feedback in the past week, about 7 in 10 are engaged. Of those who didn’t, about 1 in 4.

The feedback is the part only the manager can give. I wrote about what a good 1:1 is for and about asking questions instead of collecting status. A brief is what makes that possible at 26.

Adam is strict about the line. “It helps me prepare, but I’m still leading the conversation. It is a supporting tool, not the tool which will tell me what I should tell the person or what I should do with the person."

"His agent was complaining to my agent”

I trust this part of the case most, because I watched it break.

In August a new direct report joined Adam’s team, and Adam wanted a weekly 45-minute 1:1 with her. There was no free slot. Adam asked Claude, and Claude could not find one either. It looked at August, September and October and came back with: there is no room if I follow all the rules you gave me.

The calendar was a map of how fast the org had grown. Every new person got a 1:1 wherever it fit at the time. “I had to do the defragmentation of my calendar.”

So Adam wrote the sheet above, with one row per person and the calendar rules on top. Fitting 26 people around those rules by hand would have been “a nightmare”, so Claude would cancel all 26 recurring 1:1s and create them again.

Before Claude touched a single invite, Adam told the team in Slack: “Heads-up that Claude is making these changes on my behalf.”

What could go wrong? Time zones are the obvious guess. Private 1:1 notes shared with the wrong people is a worse one, and Adam admits to not thinking about that at all.

Three days later one of the engineers replied in the thread. The new slot collided with the engineer’s existing 1:1 with a colleague. Under the message, in small grey letters: “Sent using @Claude.”

Adam summed it up: “His agent was complaining to my agent.”

Adam went back to Claude: I told you to check everyone’s calendar before moving the 1:1s.

“You’re absolutely right,” said Claude. Adam’s answer was less polite: fix the slot, go and apologise, and make sure people understood whose mistake it was.

So Claude wrote in the thread, in its own name: “This is a little embarrassing. Entirely my mistake. The good news is it’s already fixed.” The whole team laughed, because two agents were now sorting out a calendar between themselves.

It took a second, corrected run, and it was the only mistake in 26 moved meetings. Since then, on a 1:1 afternoon Adam sits in the same meeting room for hours and the people simply change.

Then we added the guardrail the first run was missing. A daily agent now checks the 1:1s for the next two weeks: Adam’s calendar, the other person’s calendar and the room. It proposes fixes.

We took one lesson from it. Delegating to AI doesn’t remove accountability. It changes what you need to verify.

Reading the sheet of rules, a human would have checked the other person’s calendar without being told. Claude did what the sheet said and nothing more.

Delegate the work. Keep the responsibility.

That scar shapes the rules Adam runs the team by. They come from Adam’s three principles for 2027.

Lead by example

Adam shares openly how AI gets used, including what fails. When an experiment breaks, Adam and the team laugh at it together. Adam expects the engineers to use AI but doesn’t mandate the tools.

Talk to me through your agent, if it makes sense

“It is fully okay if somebody decides to communicate with me through their agents, as long as it makes sense. It is okay if they write a whole document through the agent, as long as it is not AI slop of 60, 70 pages, and they are still able to sign off on it.”

More output isn’t more productivity

You can generate a 20-page PRD in minutes. If it costs everyone hours to review, the team didn’t get faster. Engineers own what their agents produce, and managers and leaders own the results too.

”My agent did it” isn’t an excuse

“It will be very easy to say: it is not my fault, my agent did it. It’s always the person who ran the agent who is responsible. Otherwise, this will be a real nightmare.”

That applies to Adam too. The calendar mistake was Adam’s to own, and the apology went out because Adam asked for it. Adam also writes the Slack messages to the team personally, because they should sound like Adam.

Claude asks once. The best people keep arguing.

People first ranks first of the three principles.

“AI rarely keeps arguing with me. It can argue with me once, but once I tell it ‘no, go ahead’, it will do it. Your best people will argue with you. If something is fishy, they will go and try to prove to you that they are right.”

AI rarely keeps arguing. Your best people do.

That’s the part of the job the system protects. A manager who spends the week routing has no time left to hear the engineer who disagrees. A manager whose routing runs on rules has.

It’s also why Adam didn’t do it alone. Asked how to keep the same mental capacity at 26 people, Adam named people before tools: “Having the right people and the right team is, I would say, the key.”

Asked what to look for in a third lead, Adam listed people first, communication, the ability to work with AI and to set priorities. And one more test: when their team grows, “by amount of people or amount of agents”, they keep the pace, so “I would not have to be figuring out how to scale this person.”

Your first AI management workflow, this week

You don’t need nine screens or your own app to start. We started with one rule.

1. Pick one repetitive management task

The one you dread on Friday is a good candidate. For us it was the weekly status check.

2. Write down how you decide it, as 3 to 5 rules

If writing feels hard, let the agent interview you. Open Claude or ChatGPT and say: I want to automate this, ask me questions, and at the end write me an MD file with the rules.

Adam’s example for a Friday status check: “Every Friday I check whether my projects are on track. Here are the five things I look for. Help me evaluate this week’s updates.”

3. Let AI apply them, and fix the rules where it’s wrong

“Don’t care about the tokens,” at the start. Run everything through AI and look at the output. When it’s wrong, don’t correct the result by hand.

“Go and fix the rules so that you can repeat it next time.” Turn the rules into a script later, once they stop changing.

4. With every new model, run the same rules again

Some of Adam’s attempts failed because AI could not reach a company portal or the process was too complex. Adam tries again with every new model, because the capabilities keep moving. The same approach covers the vacation catch-up, the quarterly engineering-health slide and the yearly R&D documentation from a year of Jira history.

If you’d rather have a room of your managers write their first rule file together, I run this case as a keynote and hands-on workshop for engineering managers.

Before you take 16

Big spans usually happen to managers instead of being chosen. A backfill gets frozen “because the team has Copilot now”, a reorg merges two teams, and a year later the manager has 14 people and the same week. I wrote about that drift in what AI agents change for the first-line manager. Sixteen people that happened to you and sixteen people you built a system for are two different jobs.

So before you say yes to 16, check three things.

Can you write your routing down?

If you can’t list the five things you do every week to keep the team informed, you can’t hand them to a script. Start there, before the reorg.

Who owns your calendar?

The turning point for Adam was one sentence: “Complaining to my boss that I have too much work or too many meetings is not the solution. Nobody will solve it for me. I need to be the advocate of my calendar, my time and my priorities.”

Who helps you carry the 16?

Adam has two strong team leads alongside. In my 2027 career fork post I wrote that a team stays at about eight humans. That holds for a manager who still routes everything by hand. This case is what the other side of the fork looks like when the routing runs on rules.

Which of your weekly routines could you write down as five rules by Friday? If you want help building this for a group of your managers, that’s what Mentor in Residence is for. If it is just you and your calendar, start with AI engineering manager mentoring.

[Writing time: 6h]