The Director's Playbook: Running Engineering at Scale

Managing a single team is hard. Managing multiple teams across different projects, clients, and time zones is a different kind of hard — and the skills that made you a good engineering manager don't automatically transfer.

This is what I've learned running engineering at scale. Some of it is frameworks. A lot of it is mistakes I made and had to correct. A few things I'm still figuring out.

The Shift Nobody Tells You About

As an individual contributor, you ship code. As a manager, you ship teams. As a director, you ship systems — the organizational machinery that produces good teams and good code without your constant involvement. That last transition is the one that catches people off guard.

I remember the first time I genuinely couldn't keep up with what was happening across my engagements. I was trying to review architecture docs, attend too many standups, and stay close to a dozen different technical conversations simultaneously. A senior engineer on one of my teams — someone I trusted enormously — pulled me aside and said something like: "I think you being in every meeting is actually slowing us down." He was right, and I didn't want to hear it.

The shift requires letting go. You can't review every PR, and trying to means your tech leads don't actually own their codebases. You can't attend every standup, and doing so signals distrust even when you don't mean it that way. Your job changes from doing the work to building the conditions where the work gets done well. That's a much harder and lonelier thing to be good at.

How I Structure Teams Across Engagements

I typically oversee somewhere between 10 and 15 concurrent client engagements at any given time. The structure that's worked best for me is a pod model — each engagement has a dedicated team with a tech lead, somewhere between 2 and 5 engineers, and clear ownership. Pods are self-sufficient for day-to-day decisions. They escalate to me for cross-cutting concerns or genuine resource conflicts, not routine calls.

Separately, some capabilities span engagements: DevOps practices, security reviews, architecture standards. These live in horizontal teams that consult across pods. They don't own delivery; they enable it. The distinction matters — the moment a horizontal team starts owning delivery outcomes, you get turf conflicts and confused accountability.

One thing I feel strongly about: rotation. Engineers shouldn't stay on the same engagement indefinitely. I aim for something like 12 to 18 months with meaningful overlap for knowledge transfer. It prevents the kind of single-point-of-failure dependency that only becomes visible when someone quits.

The Say/Do Ratio

The single metric I track most closely is what I call the say/do ratio: did the team deliver what they committed to delivering?

High-performing teams have a say/do ratio close to 1.0. They might commit to less than some other teams, but they deliver consistently. That consistency is where trust comes from — with clients, with leadership, with each other.

Low-performing teams over-promise and under-deliver. Each miss erodes trust a little more. Eventually, nobody believes their estimates, and sprint planning becomes a kind of collective fiction everyone tacitly agrees to maintain.

When I see a deteriorating say/do ratio, I don't push for more output. I push for more realistic commitments. A team that delivers 80% of a modest plan is healthier than a team that delivers 50% of an ambitious one. The math isn't complicated, but convincing ambitious engineers that committing less is actually better — that takes real conversation.

Influencing Engineers You Don't Manage

Most engineers in your organization don't report to you directly. You influence them through their managers, through culture, through the choices you make visible. This requires a different set of habits.

I do skip-levels with every engineer at least quarterly, without their manager present. These aren't performance conversations. They're listening sessions. What's working? What's frustrating them? What do they need that they're not getting? You hear things in these conversations that would never make it through formal channels — not because anyone is hiding anything, but because organizational hierarchy filters signal before it reaches you.

I also hold open office hours each week. No agenda required. Whoever shows up, we talk. It's low-overhead and surfaces more interesting problems than most structured meetings.

I try to stay technically close enough to ask good questions. I can't be expert in everything my teams are building, but I can read architecture documents and attend design reviews often enough that I'm not asking embarrassing questions. There's a version of "empowering your team" that just means you've stopped paying attention. I don't want to be that person.

And when teams do excellent work, I make noise about it. Recognition from skip-level leadership carries more weight than people realize. Use it generously and specifically.

What I Actually Pay Attention To

At scale, you can't process everything. You have to be intentional about what you consume and what you let pass through.

Continuously, I watch delivery metrics (that say/do ratio, velocity trends, escaped defects), team health signals (attrition, how often escalations are happening), and client satisfaction — not just formal NPS scores but informal signals from executive conversations.

Weekly, I review project status summaries from managers, technical decisions with implications across engagements, and resource allocation questions. I've tried to do this less formally over the years, and it hasn't worked. The weekly review discipline matters.

On demand, I dive into specific incidents, critical system architecture reviews, and career conversations for people at inflection points. The goal is staying close enough to the forest that I can examine individual trees when something warrants it — without mistaking tree-examining for actual work.

Decision Rights (and Why Ambiguity Here Is Expensive)

One of the clearest sources of organizational dysfunction I've seen is ambiguity about who decides what. When the answer is "it depends" or "probably whoever feels most strongly," you get either bottlenecks or chaos, depending on the situation.

The way I frame it: teams decide implementation details, sprint commitments, internal tooling choices — no escalation needed. Tech leads decide architecture within their engagement, technical hiring, code standards — they inform me, they don't ask permission. Managers decide resource allocation within their portfolio, performance ratings, promotion nominations — I review these but rarely override. And I own cross-engagement moves, senior hiring, vendor relationships, org structure changes.

When decisions happen at the wrong level, I correct the process, not just the decision. If I find myself making a call that a tech lead should have made, that's a signal I need to have a different conversation with that tech lead, not that I should start making more tech lead decisions.

Developing Future Leaders

My job is to make myself replaceable. I believe this, and I still struggle with fully internalizing it — there's a real tension between the identity of being the person who knows everything and the organizational health of having other people who could step up.

I look for potential early and try to watch for the right signals: who takes initiative without being asked, who do other engineers go to when they're stuck, who handles genuinely ambiguous situations without needing hand-holding. These aren't always the loudest voices in the room.

I put high-potential engineers in stretch assignments — roles slightly beyond their current capability — with heavy support. Most people grow fastest when they're slightly uncomfortable and know someone has their back. The failure mode is putting someone in a stretch role and then abandoning them to figure it out, which produces burnout and resentment rather than growth.

The distinction between mentoring and sponsoring matters here. A mentor gives advice. A sponsor puts their reputation on the line to create opportunities. I try to be a sponsor — nominating people for projects they might not have been considered for, advocating explicitly in conversations they're not in the room for. That's where careers actually change.

The Lonely Parts

I want to be honest about something that took me too long to understand: leadership at scale is isolating in ways that don't appear in any management book.

You can't vent to your team. You've probably figured this out if you've been at it for a while, but the moment you express real anxiety or doubt to the people who report to you, it becomes their anxiety too. Your worry amplifies through the organization. So you learn to sit with it quietly, which is fine until it isn't.

You make decisions with incomplete information constantly. You're wrong sometimes. You live with the consequences of being wrong in ways that affect people's careers and projects and sometimes their sense of themselves professionally. That weight doesn't go away with experience; you just get more practiced at not showing it.

I still struggle with one particular tension: I sometimes see problems before they're visible to others, and I can't always explain why I'm worried. The pattern-matching that comes from experience produces something like intuition, and you have to make calls based on that even when you can't articulate the reasoning. That feels uncomfortable in a field that prizes explainability.

And delivering hard feedback — the kind that genuinely changes someone's trajectory — remains difficult no matter how many times you've done it. I don't think it should feel easy.

Find peers outside your organization. Other directors, VPs, engineering leaders who understand the specific texture of this role. You need people you can be genuinely honest with, not just professionally collegial. This took me longer to build than it should have.

Things I Wish I'd Known Earlier

Your calendar is your strategy. Where you actually spend time signals what you actually value, regardless of what you say in all-hands meetings. Be intentional about this — it's the most visible thing you do.

Slowing down to align on goals prevents weeks of wasted effort. I know this. I still sometimes skip the alignment conversation because I'm impatient. It's always a mistake.

People leave managers, not companies. This is a cliché because it's true. Investing disproportionately in developing your managers is probably the highest-leverage thing you can do.

Your job isn't to be right. Your job is to ensure the organization makes good decisions. Sometimes that means actively championing someone else's idea that's better than yours. This sounds obvious. It is not easy.

Energy is finite. Protect your capacity for the decisions that only you can make. Delegate everything else, and don't feel guilty about it.