Managing engineering teams at scale: lessons from 30+

The line you cross somewhere past ten people

Managing engineering teams at scale is a different job than managing a small team, and nobody announces the transition. At DXC I managed two teams — more than 30 developers, designers, and architects between them — and the honest summary of my first months at that size is that I kept running the eight-person playbook and watched it quietly stop working.

At eight people, you know everything. You’ve read most of the code, you were in the room for every design argument, and you can hold the entire state of the team in your head. Somewhere past ten — and definitely by thirty — that model doesn’t degrade gracefully; it fails silently. You still feel informed, because information keeps arriving. What you don’t notice is that all of it now arrives filtered, delayed, and pre-shaped by people who know what you want to hear.

Everything in this article is a response to that one problem: at scale, your direct perception is gone, and you have to replace it with systems.

Operating rhythm: the skeleton everything hangs on

The first system is a boring one — a fixed weekly and monthly cadence that the team can set their watch by. Mine, evolved across both DXC teams and the 15-engineer ITAR operations team I led before that, looks like this:

Cadence	Mechanism	Purpose
Weekly	Lead sync (leads + me, 45 min)	Decisions and blockers, not status
Weekly	One-on-ones with each direct (leads)	Their agenda first, mine second
Bi-weekly	Skip-levels, rotating through the org	Unfiltered ground truth
Bi-weekly	Design/architecture review	Where I stay technically connected
Monthly	All-hands, 30 min	Context: why, not just what
Quarterly	Calibration + talent review with leads	Performance honesty, forced

Two rules make the rhythm work. First, status goes in writing, meetings are for decisions. A 45-minute lead sync spent reading out project status is a 45-minute waste of the most expensive room of the week. Status is a doc everyone reads before arriving; the meeting is for the three things that need argument or a call.

Second, the rhythm is non-negotiable, especially when busy. The weeks you most want to cancel one-on-ones are precisely the weeks the team most needs them. Cancelling sends a message you don’t intend: this ritual is optional, and by extension, so are you.

Delegation layers: leading through leads

Past ten people you need leads, and the moment you have leads, your job changes shape: you stop directing engineers and start directing through an intermediate layer. Most of the failure modes of managing at scale are really failures of this handoff.

The mistakes I made, in the order I made them:

• Delegating tasks instead of outcomes. If I hand a lead a task list, I’ve made them an expensive relay. I hand them an outcome, the constraints, and the authority to make the calls inside those constraints — then hold them to the outcome. This is the delegation model I also apply in technical decision making: decide who decides, and mean it.
• Undercutting the layer I built. Early on, engineers would come to me directly to relitigate a lead’s decision, and I’d answer — because I had opinions, and it felt responsive. Every one of those answers taught the team that the lead’s decisions were provisional. The correct move, 95% of the time: “What did your lead say? Start there.” The 5% is genuine escalation, and the lead is in the room for it.
• Confusing delegation with abdication. Handing off an outcome doesn’t mean discovering in twelve weeks that it failed. I inspect at agreed checkpoints — design review, first integration, pre-release — not by hovering daily. Trust, with verification at intervals both sides agreed to in advance.

Picking the leads is the highest-leverage decision you make at this scale. The strongest engineer is the default candidate and often the wrong one. I look for the person others already route questions to — the informal hub the team has voted for with its feet.

Skip-levels: your only unfiltered channel

Once a delegation layer exists, every report you receive has passed through at least one set of incentives before it reaches you. Leads aren’t dishonest — they’re human, and humans summarize in self-flattering directions. If you manage 30 people purely through your leads’ reports, you are managing a model of the team, not the team. Models drift. Every operations person knows what happens next.

Skip-levels are the correction. Every two weeks I take a rotating handful of one-on-ones two levels down, no lead present, and I’m explicit about the contract: this is not a status check and it is not a performance review; nothing said here gets attributed. Then I ask questions that can’t be answered with a slide:

• What’s the most frustrating part of your week?
• If you ran this team for a month, what would you change first?
• What’s something we’re building that you think we shouldn’t be?
• Who here helps you the most? (This question finds your next leads.)

Skip-levels found me a project that was three weeks from a delivery surprise and a lead who was quietly burning out — both months before either would have surfaced in a status meeting. They are also where the servant-leadership blocker question does its best work, because blockers two levels down are the ones nobody escalates.

One warning: never act on skip-level information in a way that exposes the source, and never use it to ambush a lead (“well, I heard…”). Do it once and the channel closes permanently. Skip-level signal is for adjusting systems, not for prosecuting individuals.

Performance honesty at scale

At thirty people, performance management stops being an occasional uncomfortable conversation and becomes a system you either run honestly or run dishonestly — there’s no neutral setting. The failure pattern is universal: every lead rates their people “meets or exceeds,” struggling engineers accumulate in the seams between teams, and your best people slowly conclude that excellence and adequacy pay the same.

What I hold the line on:

1. Calibration across teams, quarterly. Leads defend their assessments to each other. Not stack ranking — pattern honesty. When one team’s “exceptional” is another team’s “solid,” calibration is where you find out.
2. No surprises, ever. If someone hears difficult feedback for the first time in a formal review, their manager failed, and I say so. The formal cycle should be a summary of conversations already had.
3. Act on the strong performers first. Most performance systems spend 90% of their energy on the bottom 5%. The larger risk at scale is the top 10% quietly disengaging because nobody noticed them. Stretch scope, visibility, and advocacy for promotion are performance management too.

Keeping technical credibility when you don’t write the code

The question every engineer-turned-manager asks, and the one I felt most personally. My answer after years at this scale: you will lose currency in the code, and you can remain credible anyway — but only through honesty about the difference.

Credibility at this level doesn’t come from writing the code. It comes from: reading the design docs and asking questions that show you understood them; sitting in incident reviews and following the technical narrative without needing a translator; knowing which technical debates matter and which are taste; and saying “I don’t know this stack — walk me through it” instead of bluffing. Engineers forgive rust instantly. They never forgive pretending.

I also keep one small technical thread of my own — lab infrastructure, tooling, things with no delivery deadline attached (my home datacenter absorbs most of this). It keeps my hands honest without putting me on any project’s critical path, because a manager on the critical path at this scale is a single point of failure the team can’t route around.

What to write down

If you’re crossing this threshold now, start with three artifacts: the operating rhythm (published, so the team can rely on it), a one-page delegation charter per lead (outcome, constraints, checkpoints — ambiguity here is where trust dies), and your skip-level rotation. Everything else — calibration, communication plans, talent reviews — hangs off those three.

The meta-lesson took me the longest: at scale, you are no longer the person who does the work, and you are no longer even the person who directs the work. You are the person who designs the system that does the work. The sooner you accept that as the actual job — rather than a distraction from the actual job — the better you get at it. Where that road eventually leads is the subject of from engineer to executive.