Engineering Management: Leadership and best practices

The promotion email goes out on a Tuesday. By Wednesday, the people who reviewed my pull requests last week report to me. Nothing has changed about the people, yet everything has changed about the structure around them. In this guide, I share what managing former peers taught me: how to hold authority without arrogance, handle the friend and the rival, set boundaries that protect both sides, and resist the pull back to the individual work that got me promoted.

Management has a nasty habit of punishing the instincts that made me a great engineer. When I stepped into the role I brought years of technical experience and almost no people skills, and I got most of it wrong before I got any of it right. In this guide, I share the mistakes that cost me most, in roughly the order I made them: staying the hero engineer, solving instead of coaching, avoiding hard conversations, saying yes to everything, and what each one taught me to do instead.

Great engineers are rarely found. They are built, through intentional hiring, thoughtful onboarding, and consistent development. I hire for trajectory over current output, onboard for momentum in week one, and develop by giving people problems slightly bigger than they think they can handle. In this guide, I share the system I actually use: how I define the role before I post it, how I run a structured interview loop, how I onboard so new engineers ship early, and how I develop them long after they are productive.

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.