DEV Community: Amy Wightman

Meta's 50:1 Ratio Is Extreme. The Direction Isn't.

Amy Wightman — Fri, 20 Mar 2026 10:42:25 +0000

Meta recently announced a target of 50 engineers per manager. The number made headlines. But the signal underneath it matters more than the specific ratio:the era of the 6:1 engineering manager is ending.

The pressure is coming from every direction. Headcount is scrutinized. AI is making individual engineers more productive. And leadership teams are asking a question that would have been heresy five years ago: do we really need this many managers?

The answer isn't to eliminate managers. It's to change what they spend their time on.

What Breaks at Higher Ratios
When a manager goes from 8 direct reports to 15 — let alone 50 — the first casualty is the 1:1. Not because managers don't value them, but because there aren't enough hours in the week. At 50 reports, weekly 1:1s alone would consume your entire calendar.

Even at 15, the math gets brutal. You can hold the meetings. What you can't hold is the context. Who mentioned a blocker last Tuesday? Whose goal is stalled? Who hasn't shipped anything in two weeks and why? At 8 reports, a good manager carries this in their head. At 15, they're guessing. At 50, they're flying blind.

The second casualty is signal detection. A manager with 8 reports notices when someone goes quiet. At 15+, subtle signals — declining sentiment, creeping burnout, a slow withdrawal from collaboration — disappear into the noise. By the time it surfaces, the engineer is already interviewing.

The third casualty is the performance review. When review season hits, managers scramble to reconstruct six months of work from memory, scattered docs, and a guilty scroll through Slack history.

The reviews become generic.
The feedback becomes useless.
The Problem Isn't the Ratio. It's the Tooling.

Today's engineering management stack was built for a world where managers had 6 direct reports and spent their days in meetings. The tools reflect that assumption: shared docs for 1:1 notes, spreadsheets for goals, HR platforms designed for annual review cycles.

None of it scales.

What scales is continuous signal collection and AI-powered synthesis. Not replacing the manager's judgment — augmenting it. The same way an IDE doesn't write code for you but makes you dramatically more effective, the right management tooling doesn't manage your team for you. It ensures you never walk into a conversation unprepared.

Imagine walking into every 1:1 with a prep brief built from actual data: standup patterns, goal progress, sentiment shifts, blocker history. Not a blank doc you scramble to fill five minutes before the meeting. Not a generic "how are things going?" opener. Specific, actionable context that lets you have the conversation that matters.

That's what makes 15:1 possible. Maybe even 20:1.

Managers Don't Disappear. They Build.

Here's what gets lost in the "do we need managers" discourse: the best engineering managers don't want to sit in meetings all day. They want to deliver software.

The shift to higher ratios, done right, doesn't eliminate the manager role — it reclaims it. When AI handles the signal detection, the prep work, the review drafting, and the routine follow-ups, managers get time back. Not to manage more people the same way, but to manage differently.

They write code again. They pair with engineers on hard problems. They make architectural decisions with context they actually have, not context they're pretending to have. They become the technical leaders they were hired to be, with the organizational awareness they need to be effective.

Every team still needs someone to make decisions, unblock work, drive clarity, communicate outward, and act as the buffer between their engineers and the demands of the organization. That role doesn't go away at 15:1 or 50:1. But the administrative overhead of that role — the prep, the tracking, the pattern-matching across dozens of people — that's what tooling should absorb.

The Real Question

Meta's 50:1 number is a provocation. Most engineering organizations won't get there, and probably shouldn't try. But the direction is clear: teams are going to scale with fewer managers and more builders.

The organizations that do this well won't be the ones that simply cut management headcount and hope for the best. They'll be the ones that invest in tooling that gives every remaining manager the context, signals, and preparation they need to lead effectively at scale.

The alternative is what most companies do today: overloaded managers, stale 1:1s, missed burnout signals, and performance reviews written from memory.That doesn't scale at 8:1. It certainly won't scale at 15:1.

The ratio is going up. The question is whether your tooling is ready for it.

This is what we're building at Vereda AI — the tooling layer that makes higher ratios possible without losing the signal.

Most Engineering Managers Wing Their 1:1s.

Amy Wightman — Wed, 11 Mar 2026 12:01:44 +0000

I managed my first engineering team for almost a year before I admitted something: I was winging every single 1:1.

Not intentionally. I’d open my calendar, see “1:1 with Sarah — 30 minutes,” and think: I’ll figure out what to talk about when we start. Sometimes I’d glance at Slack. Occasionally I’d remember something from last week’s standup. Most of the time, I’d open with “So… how’s it going?” and hope something useful came up.

It felt fine. Sarah seemed fine. Everyone seemed fine.

Then Sarah put in her notice. And in the exit interview, she said something that stuck with me: “I kept bringing up the issues, but it never felt like anything changed.”

I had heard her mention various problems here and there. I just hadn’t connected it to a pattern. I hadn’t connected anything to anything because I was walking into 1:1s with zero preparation and zero context and my notes were not great. Note takers help, but they are not easy to scan.

The Real Cost of Unprepped 1:1s

Here’s what I’ve learned since then: the cost of winging 1:1s isn’t that they go badly. It’s that they go okay. They’re pleasant. They cover surface-level updates. And you leave feeling like you did your job.

But you miss things:

You miss patterns. An engineer mentions being blocked on an API dependency on Monday. By Thursday’s 1:1, you’ve forgotten. They mention it again next week. You nod sympathetically. Three weeks later, they’re frustrated and you still haven’t escalated it. No single conversation was alarming, but the pattern was.

You miss sentiment shifts. Standups get shorter. Responses become formulaic. The engineer who used to share detailed updates starts writing “No blockers” every day. These shifts happen gradually. Without tracking them, you only notice when it’s too late.

You miss the career conversation. When you don’t prep, urgent topics eat your 30 minutes. That goal review you meant to bring up? Pushed to next week. The growth conversation? Next quarter. Before you know it, your report’s career development hasn’t been discussed in four months.

You miss the signal in the noise. An engineer shipped three PRs this week, closed two tickets, and updated their goal. That sounds productive. But one of those PRs has been in review for six days with no reviewer assigned. They’re quietly stuck and not asking for help. You’d never know from a standup summary alone.

What “Prep” Actually Looks Like

When I say “prep,” I don’t mean spending 30 minutes reading Jira tickets before each 1:1. Nobody has time for that, especially if you’re managing six to eight engineers.

Good 1:1 prep answers three questions in under 60 seconds:

What should I definitely bring up? Overdue action items, at-risk goals, active signals like sentiment drops or repeated blockers.
What’s the context? What have they shipped recently? What have they been stuck on? What came up in their last standup?
What did we say last time? Follow-ups from the previous 1:1 that I need to close the loop on.

That’s it. Three questions. The problem is that answering them requires pulling data from five or six different places: your standup tool, your project tracker, your notes app, your memory. By the time you’ve assembled that picture, the 1:1 is half over.

The Tools Don’t Help (Yet)

Most 1:1 tools, Fellow, Lattice, 15Five give you a shared agenda. A blank document where you and your report can add topics before the meeting. That’s fine. It’s better than nothing. But it solves the wrong problem.

The problem isn’t that there’s no place to write what you want to discuss. The problem is that you don’t know what you should discuss. You need someone (or something) to look at the data and tell you: “Sarah’s been blocked on the same thing for four days. James hasn’t updated his goal in two weeks. Alex’s standup sentiment has been declining.”

A blank shared agenda doesn’t do that. It just gives you a nicer place to wing it.

What Actually Changed for Me

I started building structured prep into my workflow about a year ago. At first, it was manual: I’d spend 5 minutes before each 1:1 checking standups, Jira, and my own notes. Even that basic habit made a noticeable difference. I caught blockers faster. I followed up on action items. Engineers started saying things like “Oh, you actually remembered that.”

That’s a low bar, but it mattered.

The tool I landed on was Vereda AI, which generates what it calls a “prep brief” before each 1:1. The brief pulls from standups, GitHub/Jira/Linear activity, goal progress, risk analysis, and previous check-in data. It surfaces talking points prioritized by urgency: critical signals first including sentiment, overdue items, blockers, and career development.

What I like about it is that I’m not reading a dashboard, I’m getting a prioritized list of “here’s what to talk about and why.” It takes about 30 seconds to scan before a 1:1. The engineer doesn’t see the prep brief — it’s manager-facing so there’s no “being evaluated” dynamic in the room, it guides the conversation.

The Principles Behind Good 1:1 Prep

Whether you use a tool or build a manual habit, the principles are the same:

Prep should be fast. If it takes longer than 2 minutes per report, you won’t do it consistently. The prep needs to be a glance, not a research project.

Prep should surface what you’d miss. The value isn’t confirming what you already know. It’s catching the things you’d overlook: the stalled goal, the third time someone mentioned the same blocker, the engineer whose standup tone shifted.

Prep should include what you said you’d do. Half the value of 1:1s is follow-through. If you committed to escalating something, checking on a promotion timeline, or unblocking a dependency — your prep should remind you.

Prep should not be surveillance. This is important. The goal isn’t to walk in armed with evidence. It’s to walk in informed. There’s a difference between “I noticed your PRs have been sitting in review — what can I do to help?” and “I’ve been tracking your PR merge times.” The first is supportive. The second is creepy.

Career development should be a default topic. If you don’t prep, career conversations get pushed out by urgent issues. Good prep systems include a “career development” talking point by default so it doesn’t get lost.

A Simple Framework You Can Start Today

If you manage engineers and you’re not prepping for 1:1s, here’s a framework you can start this week with zero tools:

Before each 1:1, spend 2 minutes answering:

Check their last 3–5 standup responses. Anything concerning? Any repeated blockers?
Check their active goals or current sprint. Any stalled? Any at risk?
Check your notes from the last 1:1. Any follow-ups you promised?
When was the last time you discussed career growth?

Write down 2–3 things you want to bring up. That’s your prep.

If you want to go further, tools like Vereda AI automate this by aggregating standup data, project activity, and signals into a prep brief. But even the manual version is a massive improvement over walking in cold.

The Difference It Makes

Since I started prepping consistently, three things changed:

Blockers get resolved faster. I catch them in the first week, not the third.
Engineers trust the 1:1 more. When you remember what they told you and follow up, they start bringing real issues instead of surface updates.
I have evidence at review time. Months of 1:1 context beats two weeks of recency bias every time.

The irony is that prepping takes less total time than not prepping. Unprepped 1:1s meander, go long, and produce vague action items. Prepped 1:1s are focused, finish on time, and generate specific follow-ups.

Your engineers deserve more than “So… how’s it going?” They deserve a manager who walks in knowing what matters.

Amy Wightman is the co-founder of Vereda AI, an AI-powered performance management platform for engineering managers. She writes about engineering management, team health, and the tools that make both easier.

How Many Direct Reports Should an Engineering Manager Have?

Amy Wightman — Sun, 22 Feb 2026 23:09:01 +0000

The research says 5-9. Reality is messier.

Every engineering manager eventually asks this question: how many people should I actually manage?

The answer matters more than most people think. Too few reports and you're a glorified tech lead. Too many and you're a meeting machine who can't give anyone meaningful attention.

What the Research Says

The most-cited number comes from management research going back decades: 7 ± 2 direct reports is the sweet spot.

Here's why that range exists:

Below 5 reports: You're probably not fully utilized as a manager. Companies will either add IC work to your plate (making you a player-coach, which has its own problems) or question whether the role needs to exist.
5-7 reports: The goldilocks zone. Enough people to justify a full-time management role, few enough that you can have meaningful weekly 1:1s, give real feedback, and actually know what each person is working on.
8-9 reports: Manageable if your team is senior and autonomous. You'll need to be disciplined about where you spend your time.
10+ reports: You're in survival mode. 1:1s become biweekly or superficial. You miss signals — burnout, disengagement, blockers that fester.

The Variables Nobody Talks About

That 7±2 number assumes a lot. In practice, your capacity depends on:

Team seniority

A team of senior engineers who are self-directed and experienced needs less management overhead than a team with multiple junior developers who need mentoring, code review guidance, and career coaching.

How much IC work you're doing

If you're still writing code 40% of the time (common at startups), you effectively have half the management capacity. A player-coach managing 7 people is really managing 7 people with 3 people's worth of attention.

Organizational complexity

Cross-team dependencies, stakeholder management, hiring — these all eat into your people-management bandwidth. If you're spending 30% of your week in cross-functional meetings, your effective span of control shrinks.

Whether your team has an EM or tech lead split

Some orgs split people management (EM) from technical leadership (tech lead or staff engineer). If you have a strong tech lead handling architecture decisions and technical mentoring, you can manage more people.

What Actually Happens at Scale

Here's what I've observed at companies of different sizes:

Startups (< 50 eng): Managers often have 4-6 reports but are also player-coaches. Effective span is more like 3-4.
Growth stage (50-200 eng): This is where span problems hit hardest. Rapid hiring means managers suddenly go from 5 to 10+ reports. This is the #1 cause of manager burnout I've seen.
Enterprise (200+ eng): Usually better about maintaining 5-8 report ratios, but org complexity adds hidden overhead.

The Real Question: Can You Give Each Person What They Need?

Instead of obsessing over a number, ask yourself:

Can I have a meaningful 1:1 with each report every week? Not a status update — a real conversation about their work, growth, and blockers.
Would I notice if someone was burning out? If you don't have enough signal from your team to catch this early, you have too many reports.
Can I write a thoughtful performance review for each person? If you're copy-pasting generic feedback, you're spread too thin.
Do I know what each person wants to do next in their career? Not their job title aspiration — their actual growth areas and interests.

If you answered "no" to any of these, you either have too many reports or you need better systems to stay informed.

Building Systems That Scale

The managers I've seen handle larger teams well all have one thing in common: they build systems instead of relying on memory and heroics.

A few that help:

Async standups instead of daily meetings. You get signal without burning calendar time. Tools like Vereda run these in Slack and use AI to surface patterns — blockers that keep recurring, people who seem stuck, workload imbalances.
Structured 1:1 docs that carry forward context week to week. If you're starting every 1:1 with "so what's going on?" you're wasting the first 10 minutes rebuilding context.
Lightweight team health metrics. Not surveillance — just enough signal to know where to focus your attention. Are standups getting shorter (possible disengagement)? Is one person always blocked on the same dependency?

The Bottom Line

5-7 is the sweet spot for most engineering managers. Go above 9 and you're making tradeoffs you probably shouldn't. Go below 4 and make sure you're adding enough value to justify a dedicated management role.

But the number is less important than the quality of attention you give each person. A great manager with 8 reports and good systems will outperform a mediocre manager with 5.

I'm building Vereda — a free Slack standup bot with AI analytics for engineering teams. It helps managers stay informed without adding meetings, especially as teams grow. If managing a growing team is something you're dealing with, check it out.