Engineering Management: Leadership and best practices

The hardest part of management for many former engineers is not learning the people side. It is accepting that staying technical and staying available are often in tension. I still want technical context, but I do not want the team waiting on me to ship. In this guide, I explain how I balance technical work and management: where I stay close, where I step back, how I protect time for leverage instead of ego, and the rules I use to avoid becoming the hidden bottleneck in my own team.

Counting tickets closed gets you more tickets closed. Counting lines of code gets you more lines of code. I do not think either tells me if we are building the right thing, building it well, or building a team that can keep doing it next year. In this guide, I show how I measure team performance as a system: combine DORA and SPACE into a balanced scorecard, track delivery, quality, and team health as trends, avoid vanity and individual metrics, and roll it out without creating a surveillance culture.

A 1:1 is the only meeting where the agenda belongs to your report, not to the project. Done well, it builds trust, surfaces problems early, and grows careers. Done poorly, it becomes a status update neither of you needed. In this guide, I show how I think about engineering 1:1s that work: weekly cadence, shared agenda, practical structure, questions that open real conversations, feedback that lands, notes with follow-through, and remote adaptations.

Engineering Manager and Tech Lead are often confused – both lead, both mentor, and both sit in architecture discussions. I think about the split this way: one owns the system while the other owns the conditions that let the team build it well. In this guide, I compare what each role actually does, where they overlap and collaborate, the common failure mode of asking one person to excel at both, and how I would choose the path that fits your strengths and what energizes you.

I have seen a team of five that ships reliably become a team of twenty that ships more slowly, with more meetings, hand-offs, and quiet frustration. Scaling is not just adding headcount – it is designing the conditions where more people produce more value. In this guide, I cover how I think about building and scaling a high-performing engineering team: what high performance actually means, how I hire for trajectory and ownership, how I onboard so people ship early, what operating system and structure scale without bureaucracy, how I measure what matters, and the traps that quietly break growing teams.

Micromanagement rarely starts as a desire for control. In my experience it starts as diligence under pressure – one extra check-in at a time – until capable engineers stop deciding and start waiting for approval. The fix is not to step away, but to manage differently. In this guide, I show how I try to give engineers real ownership while keeping clear accountability: how I frame outcomes instead of prescribing steps, how I use guardrails and delegation levels, how I turn 1:1s and milestone checkpoints into trust-building tools, and how I hold the line on results without hovering.

At 5:00 PM I can close the laptop after a day of meetings, 1:1s, a hiring discussion, and two conversations nobody else was going to have - and still wonder what I actually accomplished. I wrote no code and closed no ticket. Engineering management has no contribution graph, so the job is easy to do and hard to measure. In this guide, I break down what I actually do all day: the five responsibilities I keep coming back to, where the time really goes, how I run 1:1s that matter, how I unblock and set priorities, when I stay technical and when I delegate, the traps that feel productive but are not, and how I think about a role whose output is other people's output.

When I moved from senior engineer to engineering manager, it looked like the next rung on the ladder. In practice it felt like a career change: my output became the team's output, feedback loops stretched from hours to quarters, and my calendar became my production environment. In this guide, I walk through what changed for me, what stayed the same, which traps catch most new managers, and how I think about the first 90 days. I also cover the questions I would ask before deciding whether the manager track really fits - or whether the staff path is the better move.