DEV Community: Marian Kamenistak

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

Marian Kamenistak — Sun, 01 Nov 2026 21:27:51 +0000

Originally published at marian.coach.

Most span-of-control advice stops at eight direct reports. This is what changed when one engineering manager I mentor wrote his weekly routing down as rules and let a script run them.

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.

Source	The number	What the number measures
Gallup, 2025 data	average 12.1, median 5 to 6	engagement; no single right span, manager talent and their own IC work decide
Jellyfish	around 1:6 to 1:9 in high-performing orgs like Google, Microsoft and Amazon	manager-to-engineer ratio
Jade Rubick	4 to 8 early, 8 to 10 as the org matures, 12 "pretty hard", 20 rarely done well	org maturity
McKinsey manager archetypes	player-coach 3 to 5, coordinator 15+	how much of the job is coordination

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.

Routing job	Script, by rule, no tokens	Claude	Waits for Adam's yes	Stays with Adam
Chasing status	who owes an update, what is late	drafts a friendly nudge	sending the nudge	the talk when it keeps slipping
Collecting context	pulls Jira, Slack, email, calendar and CI every 4 hours	summarises long threads	nothing, it only reads	the decision
Spotting risk	flags Yellow and Red updates, passed dev-complete dates	ranks the top five	nothing, it only reads	what to unblock first
Status reporting	lists the Jira changes and Slack threads	drafts the update, shows the rules it applied	posting it anywhere	the edits
1:1 prep	collects the shared notes doc, Slack, the feature channel	writes the brief and a suggested agenda	nothing, it only reads	the conversation
Calendar (added after the scar)	checks the next two weeks of 1:1s every day	proposes fixes	every change	who Adam meets, how often

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.

Platform Team Business Case: 1 Quarter In, 3 Back

Marian Kamenistak — Sun, 01 Nov 2026 17:22:59 +0000

Your platform teams spend 60% of their time keeping production up and 2% opening their components to the teams that wait on them. That was the measurement one VP of Engineering brought me, and the exec deck built on it had no money in it. Here is the business case we built instead: where the capacity goes, what the quarter costs, when it comes back, and the one task you measure before you bet the org.

"We shipped more features this year than last year. I didn't see the revenue." That was the head of product's answer when Tomáš, a VP of Engineering, promised his exec team three times the throughput. A platform team business case is the ask that survives that answer: one quarter of roadmap capacity, shown coming back within three, in money.

Tomáš (not his real name) runs engineering at a B2B SaaS company. His platform teams spend 60% of their time keeping production up, 2% making their components open to other teams and 38% building features. The product teams can't move without them, so every cross-team initiative waits in someone's queue.

His deck was good. Dependencies drawn as spaghetti, autonomous teams, a 3x target. Every number on it was a percentage.

One slide was missing, and I told him so. There wasn't a single dollar in the deck. Stripe's Developer Coefficient found developers spend 17.3 hours of a 41.1-hour week on maintenance, bad code and technical debt. Your exec team already pays that bill, so show them the invoice.

Boards fund a payback date

Ask ChatGPT how to get a platform team funded and it tells you to "stop selling it as an engineering improvement and start selling it as a business investment". Right, and not enough. An investment without a date is a wish.

So say the date. "Give me half of Q1. You'll have it back by the end of the year, and from then on we run faster." You're not scratching at the door for platform time, you're a VP selling an investment.

A percentage invites a negotiation about the percentage. A payback date invites a decision, and the decision belongs to the people in the room. That's where you want it.

The bill is big enough to carry it. CIOs told McKinsey that 10 to 20% of the technology budget meant for new products gets diverted to tech debt.

Tomáš got lucky. His CEO had his own "the train is leaving without us" moment the weekend before the offsite and was ready to break the roadmap. But a mandate doesn't come from one hour of talking, and the payback slide is what you keep coming back with. At Mews and at the companies I advise since, I've watched that fight take half a year to a year before people get it: you're not selling a slower roadmap, you're speeding up the company.

Measure where the capacity goes before you ask for any of it

You can't sell a payback date on a guess about today. The first slide shows where the time goes now, and the numbers have to come from the teams, not from you.

Five buckets, planned or unplanned

Split every team's time into roadmap work, platform investment, reactive production work (incidents, on-call, hotfixes), customer escalations and help for other teams. The first two are planned, the last three mostly aren't. The unplanned share is your headline number: it's how much room your teams really have for the roadmap.

No timesheets

Each team lead splits their team's person-days into the five buckets. Fifteen minutes, ±10% is enough. Run it for two weeks as a pilot, then switch to a rolling six weeks, because one big incident skews two weeks completely.

Tag who asked

Next to every bucket, write which division asked for the work. Now capacity becomes a budget you can hand out: "Your division has 400 person-days this quarter, you decide what goes in." A new request becomes a trade, and the fight over priorities moves to the people who own the priorities.

Turn days into money

Person-days times the fully loaded cost of a day. That's the number a CFO reads. If you've never priced an engineering decision for an executive, I wrote up the smaller version of this in how to talk to executives.

Here is what Tomáš's measurement and target looked like. These are one real company's numbers, anonymised. The product-team target is a target, not a measurement.

Team type	Work	Today	Target
Platform teams	Keeping production running	60%	30%
Platform teams	Opening components to other teams	2%	50%
Platform teams	Customer-facing features	38%	20%
Product teams	Keeping production running	35%	10%
Product teams	Changes in the platform (via contribution)	3%	10%
Product teams	Customer-facing features	62%	80%

Look at the bottom row. The product teams already spend 62% on features.

What holds them back is the 35% they spend looking back at production and the queue they stand in for the platform. More feature capacity is a side effect of removing that. If you want an outside read on where your teams' time goes before you build this slide, that's what an engineering productivity audit is for.

Your platform team should build features last

Tomáš's priority order for platform teams is production first, opening the components second, features last. 30% production is the desired share, not a cap: when production burns, production wins.

The platform-team flip Tomáš asked for. Today's 2% on opening components isn't drawn.

Why features last? Ten autonomous teams that all need the same five people in the shared core aren't ten parallel streams. They run fast for a few weeks, then they wait on reviews, questions and dependencies again.

The queue only moved. DORA's research calls this "downstream disorder": gains in coding speed get swallowed by bottlenecks in testing, security review and beyond.

Own 10%, open 90%

A small set of components stays owned end to end: authentication, authorization, privacy, the things where you want to be careful. In Tomáš's plan that's about 10% of changes. The other 90% become "owned, but open": the owner decouples, documents, writes down the intents and limits, adds tests, and builds safe paths so any team can contribute without breaking the core.

The 90/10 rule: 90% of changes flow through open components.

Contribution runs both ways

Product teams change the platform when they need to. Platform teams change product code when production needs it, for example when something falls over or can't keep up on performance. Both sides have to be fine with someone else in their code. Years of strong ownership at Tomáš's company grew red tape around every component, and he wants 90% of it gone.

Don't build for the drawer

No capability "because it might come in handy in three years". Build what a team needs now. The platform follows where the product teams go, it doesn't run ahead of them.

Measure the platform by how fast the others run

Platform teams get measured by how much faster the product teams ship, not by what they built. That's the Team Topologies idea of a platform team in practice: an internal product that exists to speed up the stream-aligned teams. If you want the role itself explained, here's the platform engineer role.

The counter-voice deserves a fair hearing. The 2024 DORA report found a 6% gain in team productivity with a dedicated platform team, and an 8% drop in throughput among those using a platform. A platform done badly slows you down, which is exactly why you measure it by the other teams' speed and prove it on one task first.

Turn the percentages into money: the one-for-three slide

This is the slide Tomáš didn't have. Three numbers make it.

What the quarter costs

Person-days moved off the roadmap times the loaded day cost. That's your investment, in money.

When it comes back

The roadmap output you lose in the investment quarter against what you gain after it, quarter by quarter, until the running balance turns positive. Expect the teams to slow down, or nearly stop, for about two months while they adopt new tools and a new way of working. Say it out loud on the slide: slow down to get faster later.

Don't guess the speed-up. Take it from the pilot (next section): whatever the benchmark task shows at the first read is your Q2 number, and you don't extrapolate further than the pilot proved.

What it's worth

Your CPO should know how much revenue you generate every quarter and how much of it is attributed to new functionality. That's your price per quarter of roadmap. Put the result on the slide as a hypothesis, and still put the number there. That's when people stop debating whether to allow it.

Here's the shape, with numbers made up for this post (illustrative, not Tomáš's). Output is in "today's quarters", where 1.0 is a quarter like the current one, and $3M a quarter of revenue comes from new functionality.

Quarter	Roadmap output	Running balance	Extra revenue vs today, if adoption holds
Q1, investment	0.5	−0.5	−$1.5M
Q2	1.2	−0.3	+$0.6M
Q3	1.4	+0.1, break-even	+$1.2M
Q4	1.6	+0.7	+$1.8M

One quarter in, three to get it back: by the end of Q4 you're 0.7 quarters ahead, about $2.1M. If year two holds the Q4 speed, that's 0.6 extra quarters of output each quarter, about $7.2M a year.

Read the last column header again. "If adoption holds" is the head of product's objection, written onto your own slide, and it's why the next section exists.

Reliability and security work gets a revenue number too. Jade Rubick's ValueSum scores a delivered item so that 100 points means adding 100% ARR over one year, multiplied by the probability of success. His reliability example, step by step:

Step	Score
A third of customers at risk of churn from this instability	33
They skew large, so it's really about 45% of revenue	45
Real churn risk per customer about 20%: 45 × 20%	9
Reputational damage doubles it: 9 × 2	18

Rubick also gives you the argument for a standing platform share instead of a fight per project: "a certain percentage of every engineering organization should be focused on things that make the organization more efficient over time", because that work "will typically get shortchanged" if you only optimise for value delivered.

"We shipped more and revenue didn't move" is the right objection

The head of product was right. That we speed up the machine doesn't mean we'll deliver the right things at that speed. Pendo's feature adoption report found that 80% of features in the average software product are rarely or never used.

So the business case needs a second owner. I told Tomáš what we did at Mews, where I grew engineering from 8 to 80 teams as VP of Engineering. My KPI, the one I was known for: every quarter I delivered at least 80% of the roadmap. If I didn't deliver, they could fire me.

I tracked it as roadmap contribution: what percentage of my teams' time goes on the roadmap as opposed to off it. Two teams working off the roadmap for whatever reason put the whole quarter at risk. I taught my leaders the rule I lived by: if you don't bring me the roadmap, I have a problem too.

My product peer had another KPI. "Thank you, Marian, for building me a fast machine. But I have to throw things into the machine." His job was to feed my roadmap with things that matter, measured as product adoption, and we set it up on purpose so we'd be twins in a pair.

A faster machine sells nothing on its own. Somebody has to own what goes into it.

Every initiative was locked in a quarter and had a custom field in Jira with its adoption grade. I'll admit it, we graded by hand, there was no automated metric:

Grade	What it means	Counts toward 65%?
Ultra-high	It makes us a lot of money	Yes
High	As expected	Yes
Neutral	It earns back what it cost: people, licences, infrastructure	No
Disaster	It doesn't earn back its cost	No
To be evaluated	Too early to grade, allowed for one quarter at most	No

Timing is part of a good product decision, so nothing stays ungraded longer than a quarter.

I had 80% roadmap delivery. The product leader next to me had 65% product adoption, meaning high or ultra-high. Waiting doesn't count, because waiting doesn't generate money.

And honestly, we yelled at each other. "I'm holding a fast roadmap for you, and you're throwing junk into it? Then my people are unhappy and somebody leaves."

Sometimes I said a thing didn't belong on the roadmap. Sometimes he wanted to label something a success and I said, that's probably not a success. But now you have valid discussions, about value.

Rubick lands in the same place from the other side. He recommends re-scoring every feature three or six months after delivery and keeping both the predicted and the retroactive score. Two more rules from that work I'd copy: product or division leaders score the value, not engineering, and you don't use the score to rate individuals or teams.

Tomáš couldn't get an adoption KPI agreed at the top yet, so his version of the twin sits one level down: every autonomous area gets a product manager and an engineering manager who own one business outcome together. The pair should exist on every level, team, director, VP, CTO and CPO. If you're an engineering director setting this up below the VP, your product counterpart is your twin.

Prove it on one task before you ask for the whole org

Tomáš wrote a small code change himself, his first in two years. It should have taken three hours. Reviews, pipelines and information he couldn't find about how the change would hit customers turned it into a day of development, and gating turned the rollout into a week.

That task became the benchmark:

Benchmark task	Today	End of the pilot	Long term
Develop	1 day	~4 hours	2 hours
Roll out	1 week	a couple of days	2 hours

For the pilot he set one target. By the first read, 60% of the friction points on that task's path get better. Each one is small, an hour here, half an hour there, fifteen minutes somewhere else.

If your teams work with AI agents, the friction list includes what the agent can't do: see a slow endpoint before a customer does, know the product history, run a dev instance, observe the deployment.

Pick a quiet team for the pilot

Tomáš started with a team that had a light roadmap, so the pilot wouldn't kill the plan. You need a reference before you need a transformation.

Lend it a tooling SWAT

A small tooling group builds what the pilot team can't build itself: feature flags, faster pipelines, whatever the friction list asks for. After the pilot, the SWAT becomes a regular team with more people.

Cut the areas to the leaders you have

Tomáš cut his candidate outcome areas for autonomous teams from 18 to 5. Each area needs a strong engineering leader and a strong product leader, and five pairs is what he has. The existing leaders own fewer, broader areas, with no new leadership layer.

The six slides, and what I'd add

Here's the deck I'd want Tomáš to walk in with. Each slide answers one question an exec will ask anyway.

Slide	The question it answers	What's on it
1. What today costs	Where does our engineering money go?	Capacity split, unplanned share, in money, by requesting division
2. Why we're slow	Why don't more people make us faster?	The shared components every team waits on
3. The contract	What will teams spend time on instead?	Target split per team type, the 90/10 rule, reported every sprint
4. The trade	What do we give up, and when does it come back?	Cost of the quarter, running balance, revenue if adoption holds
5. The litmus test	How do we know before betting the org?	Benchmark task, pilot team, date of the first read
6. Who owns the outcome	Who makes a faster machine earn?	Delivery KPI, adoption KPI, named owners, grading scale

I put the outline, a capacity sheet and a payback sheet into a free kit: download the platform business case kit (16 KB zip: Markdown, Word and three CSV sheets, no email needed).

Bring a proposal, not only a photo. A snapshot alone invites "why so much on support?" and then someone else decides. Let your directors collect the data; your job is to interpret it and propose one change.

Report the contract against reality every sprint. Every quarter my 100% was split into three agreed boxes, product, tech and everything else, and I checked them each sprint. When the delta grows, the right call is sometimes paradoxical: stop the technical work for two sprints and do product work, to get the balance back.

And the hard part comes after the yes. Not everyone will make the switch, either because they don't take ownership or because they can't work in a pair and are big egos. A few of them will have to leave.

Tomáš walked out with agreement to start the pilot. Its first read is still ahead, so I can't show you his benchmark numbers yet; when it reads out, I'll add them here. What will your exec team say when you ask for one quarter and promise three back? If you want to build that slide together before you present it, that's what my CTO mentoring is for.

Originally published at marian.coach on 1 November 2026. Czech version: Business case pro platform engineering. Polish version: Platform team business case.

Marian Kamenistak mentors engineering leaders 1:1 and ran engineering at Mews as VP of Engineering, from 8 to 80 teams. Names and company details in this piece are anonymised.