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. The skills that made you a good engineering manager do not automatically make you a good director.

This is what I have learned running engineering at scale—the frameworks, the mistakes, and the counterintuitive lessons that took years to internalize.

The Fundamental Shift

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 direct involvement.

This shift requires letting go:

Your job is to ensure the right people are in the right roles, with the right context, and the right support. Then get out of the way.

Structuring Teams Across Engagements

I typically oversee 10-15 concurrent client engagements. Here is how I structure for scale:

The pod model: Each engagement has a dedicated pod with a tech lead, 2-5 engineers, and clear ownership. Pods are self-sufficient for day-to-day decisions. They escalate to me only for cross-cutting concerns or resource conflicts.

Shared services: Some capabilities span engagements: DevOps, security, architecture review. These live in horizontal teams that consult across pods. They do not own delivery; they enable it.

The rotation principle: Engineers should not stay on the same engagement forever. Rotation spreads knowledge, prevents burnout, and builds organizational resilience. I target 12-18 month tenures with overlap for knowledge transfer.

The Say/Do Ratio

The single most important metric I track is the say/do ratio: did the team deliver what they said they would deliver?

High-performing teams have a say/do ratio close to 1.0. They might commit to less than low-performing teams, but they deliver consistently. Consistency builds trust—with clients, with leadership, and within the team.

Low-performing teams over-promise and under-deliver. They commit to heroic goals and miss them. Each miss erodes trust. Eventually, nobody believes their estimates, and planning becomes fiction.

When I see a low say/do ratio, I do not 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.

Managing Engineers You Do Not Manage

As a director, most engineers in your organization do not report to you directly. You influence through their managers. This requires a different toolkit:

The Information Diet

At scale, you cannot process all the information flowing through your organization. You must be intentional about what you consume:

What I monitor continuously:

What I review weekly:

What I dive into on-demand:

The goal is to see the forest without losing the ability to examine trees when needed.

Decision Rights

Clarity about who decides what prevents both bottlenecks and chaos. I use a simple framework:

When decisions are made at the wrong level—either too high or too low—I correct the process, not just the decision.

Building Bench Strength

The most important thing I do is develop future leaders. My job is to make myself replaceable.

The Lonely Parts

Leadership at scale has isolating moments that nobody prepares you for:

Find peers outside your organization. Build a support network of other directors and VPs who understand the role. You need people you can be honest with.

What I Wish I Knew Earlier

A few lessons that took too long to learn:

← Back to Home