How I lead engineering teams as an Engineering Manager

Over the last two decades I've moved from individual contributor to team lead, then to leading multiple teams as an Engineering Manager. Along the way I've learned that the job is not to be the smartest engineer in the room. It's to build the system that consistently ships the right work, at the right quality, without burning people out.

In this post I'll share the concrete patterns I use as an Engineering Manager to run healthy, high performing teams, especially on products where design, front-end engineering and user experience carry a lot of weight. These are the same patterns I look for when hiring senior engineering leaders.

1. Start with outcomes, not output

At Engineering Manager level, my primary responsibility is to make sure engineering effort is aligned with business outcomes. That means being deeply plugged into product strategy and constantly translating abstract goals into concrete, measurable results for teams.

I work with product and design partners to frame every initiative around a small set of outcomes: improved activation rate, reduced time-to-first-value, higher creator retention, lower support contact rate, or reduced infrastructure cost. Then I help teams design technical approaches that move those numbers while paying down the right amount of technical debt.

Tools like OKRs are useful, but only when they are tied to the reality of the codebase and the constraints of the people doing the work. As a Director, I regularly audit our roadmap against the current architecture and staffing so we don't commit to outcomes we can't realistically deliver.

2. Build teams around problems, not technologies

One of the biggest levers I have is how teams are shaped. I prefer long-lived, cross-functional teams that own a slice of the customer journey end to end, from discovery and delivery through to maintenance, rather than temporary "project" groups.

In practice that means a "Monetisation" or "Acquisition" team that owns everything from tracking and experimentation through to front-end flows, APIs and data pipelines. My job is to make sure they have the right mix of skills, clear interfaces with adjacent teams, and enough autonomy to move quickly without constantly asking for permission.

When we do need centralised specialisms, like a core platform or design systems group, I'm explicit about their mandate: they exist to enable product teams, not to gatekeep them. I measure their success in adoption and reduced friction, not line counts or ticket volume.

3. Make architecture a team sport

Directors who try to personally review every architectural decision quickly become bottlenecks. Instead, I focus on building lightweight decision frameworks that senior engineers can apply consistently.

For example, on design-heavy products we codify guardrails for performance budgets, accessibility, and reliability. We agree thresholds (like "largest contentful paint under 2.5s on a mid-tier device") and empower teams to choose frameworks and patterns that meet those bars.

I use practices inspired by Architecture Decision Records to capture major decisions in a way that's searchable and easy to revisit. This creates a shared memory for the organisation and reduces the need for endless re‑litigation.

4. Invest heavily in design and front-end excellence

In many organisations, design and front-end engineering are treated as "the last mile". As a Director of Engineering with a strong product design background, I deliberately invert that. Our design systems, component libraries, and front-end architecture become first-class citizens.

Practically, that means funding a small, senior design systems team, building shared primitives in React (or your framework of choice), and ensuring those primitives are accessible, themeable, and easy to consume by product squads. It also means making sure front-end engineers are part of architectural conversations, not just handed tickets.

I want Directors and VPs who read this to understand: investing in design and UX engineering is not a "nice to have". It's a competitive advantage that compounds in every feature you ship.

5. Grow leaders, not heroes

Perhaps the most important part of the job is building the next generation of leaders. I actively mentor staff and principal engineers, helping them shift from "I can fix it" to "I can build the system that doesn't need me to fix it".

Concretely, I run regular architecture reviews, facilitate design critiques that include engineers, and block time each week for one-on-ones focused on growth, not status updates. I expect senior people to own a domain, drive cross-team initiatives, and coach others in the process.

Resources like Will Larson's writing on Staff engineering have been influential in how I structure these career paths.

6. Communicate in layers

As you move into Engineering Manager roles, your impact is limited by how clearly you can communicate up, down, and sideways. I think in "layers": executives need a narrative tied to business outcomes, peers need trade-offs and risks, and teams need crisp context and clear priorities.

I maintain lightweight engineering updates that emphasise impact over implementation details, and I make sure roadmaps and decision logs are discoverable. This reduces surprise and helps product, design, data and marketing feel like equal partners.

7. Balance ambition with sustainability

Finally, great engineering leadership is sustainable. I've seen too many organisations chase aggressive goals at the expense of people. As a Director, I pay close attention to cycle time, on-call load, and qualitative signals from one-on-ones and engagement surveys.

When those signals degrade, we slow down, simplify, or explicitly invest in reliability and tooling. The best products I've worked on were built by teams that had room to think, experiment, and recover, not just ship.

If you're evaluating engineering leadership candidates, look for people who demonstrate this balance: they can talk in detail about systems and architecture, but they also care deeply about how teams feel and how sustainable the pace is. That's the bar I hold myself to as an Engineering Manager.