0.15 versus 0.47. Those two numbers were my whole answer to Daniel.

Daniel is an engineering manager I mentor. He owns an SDK at a B2B company in a regulated market, and this autumn he asked me how to tell top management that a custom deal for one customer will cost them for years, without saying no to the deal.

Daniel was right about the SDK. He was right in the wrong currency. Talking to executives as an engineer means putting each technical argument in money: the value you earn or the risk you avoid, as an approximation you can defend.

I've run 3,662 one-on-one leadership sessions, and Daniel's question comes from engineers with the better technical case who still lose the room.

My position, and the one Daniel pushed back on: an 80% number you can defend beats a 100% model you can't explain.

"Great engineer, not there yet" is a label you hand them

Daniel described his problem like this. He sits in meetings with higher management where he holds context the others don't. Things that are obvious to him aren't obvious to them, and the discussion turns into a confrontation. Part of his job is risk management, he's analytical, and he sees long-term issues the others at the table miss.

So I played a CTO for a minute, any CTO. What a CTO hears from an engineer in that kind of meeting is that he's using excuses why things cannot go this way.

And then comes the label. A really great person, but not there yet, doesn't understand how business works. It isn't true, but it's how top management tends to perceive engineers who argue this way, and I told Daniel straight that if it happens, it's his fault, 100%.

Look at it from the other side of the table. Your yearly bonus comes from the same revenue you're arguing against when you ask for clean code instead of the deal. Basically, you demote yourself.

The calmer you are, the more power you have in the room

Before the money, the temperature. It took me years to learn this one and I still have to remind myself of it.

I used to think being very vocal about everything I saw was passion. I was shooting for the right thing, loudly. Then I imagined having that person in my own team, and I could see him as toxic.

Every argument I won by raising my voice, I lost, because other people would stop or be more reluctant at communicating with me. The dog who's afraid the most barks all the time.

On stage at an engineering leadership event. Photo: ELC.

Daniel is further along than he gives himself credit for. He hasn't raised his voice in 2 to 3 years. When a meeting heats up, he lets it cool, sleeps on it, and picks it up in a one-on-one the next day. That habit has saved me too.

His worry is the other side of it. If he doesn't stop an argument in front of his own team, he feels undermined. One sentence does stop it, without dropping the point: "Let me come back tomorrow with the numbers." More on that move at the end.

Before you argue, check the difference is worth a meeting

When I disagree with someone, I turn it into a talk about value. Two options on the table and one question: which one brings more?

When engineers and managers fight, I see two root causes. The first is emotional, two people who don't like each other. The second is two options of nearly the same value, defended as if the company depended on the outcome.

It's a technical detail, or one week of difference in a sprint. We spend half an hour of discussion and confrontation about shit, because the difference isn't big enough to talk about. Sometimes you find out neither option brings value and it's just egos flying.

So ask it out loud: "What's the difference in value between these two?" If the honest answer is small, pick one and move on. If it's big, you've found something worth pricing.

Executives buy two things: value and less risk

A manager's job is to reduce risk. The risk of building the wrong product, of being fined, of delivering too late, of missing the skills or the budget. So every time I speak with someone on the executive level, I turn the talk into money, in one of two directions.

Value

"If we build this, it costs us one sprint and it can open a market worth $2 million in ARR." That's the right conversation to have.

Risk

"If we don't build this, we're not compliant, and here's the level of the fine. If we go ahead partly compliant, I need your approval for that." The risk gets a number, and the decision goes to the person who owns it.

Now the counter-example, from my own kitchen. When one of my engineering managers starts talking to me about Kubernetes, the new version, how great the new tool is, it doesn't stick, and I'm technical. My questions are simple: has it raised our availability, what does the customer feel, does it earn money or save costs? Without those answers I have no reason to care.

Will Larson's Present to executives is the best guide I know on structure: "give the summarizing idea before you give the individual ideas being summarized." It doesn't put a price on the decision, and a well-structured summary without a price is still an opinion.

If you're one level lower and trying to get your own manager to listen, I wrote that ladder up separately, from naming the problem to ROI, in six levels of influence.

Two lines on a chart: Daniel's custom SDK, priced

Back to Daniel. A customer wants to use the SDK in a different way, which means opening functionality in an SDK every customer shares, then testing and maintaining a custom path for as long as that customer stays. He didn't want to say no. He wanted the key stakeholders to know what they were buying.

So I drew him two lines, with illustrative numbers, because Daniel's real ones don't exist yet. In my made-up version, sales wants three custom SDKs a year, and the deal on the table is worth €300,000.

One line is the upkeep of a standard SDK: say each one costs 0.15 of a full-time engineer to keep healthy. The other line is the upkeep of a custom one: 0.47 FTE each, because each custom path adds tests, backward compatibility and code you can't change without checking the custom cases first.

€6,000 a month is roughly what a mid-to-senior engineer costs a company in Prague: a gross salary inside the Platy.cz band for software engineers plus the employer's social and health insurance. Put in your own market's number.

It's a very simple game

€72,000 a year against €300,000. Take the deal, and say out loud that it comes with one more hire.

Ask how long the contract runs

If the €300,000 is paid once and the hire stays, the upkeep catches up with the deal in about 4 years: 4 × €72,000 = €288,000. The contract length belongs in the same conversation.

Count the slowdown too

Each custom SDK makes the next change to the standard SDK slower, because you have to check you didn't break the custom scenarios. Don Reinertsen's rule from The Principles of Product Development Flow fits here: "If you only quantify one thing, quantify the cost of delay."

When the answer is no

Change one input and the same chart gives the opposite answer. A small customer with no potential, a product manager and a sales guy asking for something highly custom that nobody believes in: you have the full privilege to say that's not a good deal.

If you've never built a money case before, the four-line formula in how to convince your manager to pay for coaching works for other spend too.

An 80% number beats a 100% model

Daniel's pushback was honest: "Always I have the challenge on how to create these magic numbers." Where does 0.15 come from, and how does he defend 0.47 in front of management?

Everybody on the top management level knows these numbers are approximations. It's your privilege and duty to come with them anyway.

Where the number comes from

Go through the last 2 or 3 years of your history: cycle time, incidents, hours spent on custom paths. Or write a best case and a worst case for each option and use the value in between. That's your educated guess, based on data.

For Daniel, that means pulling five changes from the last year that touched a custom path and noting the hours each one took. Douglas Hubbard's Rule of Five gives a 93.75% chance that the real median sits between the smallest and the largest of those five. Five tickets, and 0.47 has a source.

How good it has to be

If your approximation is 80 to 85% correct, that's great. You need to keep the messaging very simple.

Never shoot for 95 or 100%, because you end up with a formula nobody will understand, including yourself. And then nobody trusts you.

What happens when someone challenges it

I guarantee you that once per quarter somebody will jump on you: why the hell is it 0.15? Your answer is one sentence. "It's my educated guess from 2 years of our SDK history, here's the sheet."

Nobody will open that sheet. It's some sort of pre-agreed magic that works on top management.

When I challenge my own managers on a number, all I want to understand is that they put some thought behind it.

Engineers resist this because a guess feels dishonest. It's honest as long as you call it a guess.

Don't win it in the room. Come back tomorrow with a recommendation.

Speaking at an engineering leadership event. Photo: ELC.

In the room

When the discussion goes sideways, the move is one sentence: "Let me come back with the analysis on what's the impact on value, cost or risk."

That's where Daniel landed by the end of our session, in his own words: "I should say, okay, I will look at the proposal, at the estimation, and then come back." He walked in asking how to warn management. He walked out with a sentence for the room and a sheet to build.

The alternative is what I see when an engineer stays and fights: but I think, and I think, and I think. It doesn't help anyone. As the CTO in that room I'm lost after 15 minutes, and what I hear is excuses.

The next morning

Two options, a number for each, with the best and the worst case. Then your recommendation, said plainly, as opposed to hidden in the last slide: "My recommendation is the custom SDK, plus one hire. What do you think?" Ask, because the decision is theirs and the analysis is yours.

What it buys you

Technology is a means to something. For me it's the means to run the company, build the business and make profit. If you get this right, it invites you into the world of top managers. Without approximations, without talking value and risk, they won't invite you in.

Daniel's homework is the five tickets and the two lines with his real numbers, plus one conversation from his week he'd like to replay. We'll rework it in money at our next session, and I'll add here what happened next. If you have a story like that yourself, that's what a mentoring session is for.

Frequently asked

How should an engineering manager communicate with executives?

Price the decision before you present it. Bring two options, each costed in money as value earned or risk avoided, with a best and a worst case, and finish with a recommendation. Keep the technical detail for when someone asks for it.

How do I explain technical risk to my CEO in business terms?

Turn the risk into what it costs if it happens: a regulatory fine, customers lost to churn, hours of downtime, a launch that slips a quarter, or people you will need to hire. Then hand over the decision: fix it now, or accept the risk with the CEO's sign-off.

How accurate does an estimate need to be for executives?

Roughly 80 to 85% right is enough. Executives know the figure is an approximation. What they check is whether there is reasoning and data behind it, such as two or three years of delivery history or a best and worst case for each option.

What should I say when an executive challenges me in a meeting?

Skip defending the detail on the spot. Say you will come back with the impact on value, cost or risk, then return the next day with the options, a number for each, and your recommendation.

Why don't executives listen to engineers?

The argument usually reaches them in technical terms, so it sounds like a preference or an excuse. The same point stated as money earned, money saved or a risk with a price on it gets a decision instead of a debate.

Originally published at marian.coach. I mentor engineering leaders from Staff Engineer to CTO: 3,662 sessions.

Five to eight direct reports is the usual answer, and it holds while a manager routes everything by hand. Here is what one engineering manager I mentor changed to lead 26 on the same hours.

With the Engineering Manager's AI Dashboard, we moved from chaos to AI-assisted management of 16+ direct reports.

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.

The top five follow written rules about what only Adam can unblock. Redrawn from Adam's app, demo data.

Nine goals across three teams, each with a status pill and the rule that set it. Illustrative mock-up, demo data.

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.

A Friday draft with its Scope, Quality and Schedule markers and the sources Claude used. Redrawn from Adam's app, demo data.

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.

Reporting to Adam's manager arrives as a ready draft. Adam edits it and clicks yes.

A one-page weekly report for Adam's manager, each claim tagged with its source. Illustrative mock-up, demo data.

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.

What Adam reads five minutes before a 1:1. Redrawn from Adam's app, demo data.

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.

Adam knows what is happening across 26 people without spending extra time searching for it.

One feed instead of 150 channels, and a list of what it skips. Illustrative mock-up, demo data.

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.

Seven projects, the rule that makes each update due, and a drafted nudge for the late one. Illustrative mock-up, demo data.

64 messages read, one decision left for Adam. Illustrative mock-up, demo data.

Rules flag the risk, Claude ranks it, Adam decides what's first. Illustrative mock-up, demo data.

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 three teams, April to September, 2025 vs 2026. Jira and Adam's calendar, averages, rounded.

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.

The teams delivered 81% of the quarterly roadmap in 2026 Q3, up from 55% in 2026 Q2. Adam sees which goals are on track without chasing anyone.

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.

For each routine we asked one question: which part can AI do, and which part needs Adam?

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.

"My agent doesn't run all day. A script does, and it calls AI only when it needs judgment."

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.

Five sources, data pumps, storage on AWS as one option, the rules engine, Claude for judgment, and an approval gate in front of the tools. Illustrative architecture.

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.

Every run on one table, a few Claude calls each. Illustrative mock-up, demo data.

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 sheet Adam gave Claude at the end of August.

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.

Claude rebuilt 26 recurring 1:1s from one sheet of rules. One went wrong, and it taught us what to verify.

26 1:1s checked against six calendar rules, with one new joiner's clash flagged. Illustrative mock-up, demo data.

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.

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.

Four steps. The first one fits in an afternoon.

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.

Marian Kamenistak mentors engineering managers, directors and CTOs. This post first appeared on marian.coach.