Engineering leadership is a discipline, not a promotion. The day you stop being the best individual contributor on your team and start being responsible for the output of ten people who are each better than you in some dimension — that is a fundamentally different job. The tools are different. The feedback loops are different. The measure of success is different.
I’ve spent years figuring out what that job actually is. This is my current thinking.
The core shift: from output to environment
When you write code, the relationship between your effort and the result is tight and legible. You make a change, run tests, ship a diff, and something happens. The loop is hours or days.
When you lead engineers, the relationship between your decisions and outcomes stretches across weeks and quarters. The code your team ships reflects decisions you made about hiring, project scoping, architecture review, and psychological safety — months before the commit landed. You don’t see the compound effects of your choices in real time.
This means the work of engineering leadership is mostly invisible in the short term. It lives in the conversations you have, the decisions you make clearly, the things you say no to, and the environments you create for others to do their best work.
What you’re actually managing
There are three things engineering leaders manage, and most of the difficulty comes from conflating them.
People. Not headcount — people. Each engineer on your team has a career trajectory, a set of strengths they haven’t fully developed yet, and a set of fears they carry into work each day. Your job is to understand all of that and create the conditions where they can do their best work and grow. This takes time, attention, and genuine curiosity.
Work. The allocation of human attention against a set of priorities. This sounds mechanical but it isn’t. Knowing which problems deserve your team’s best people at any given moment, and which can be handled with a lighter touch, is a judgment call you have to make constantly. Get it wrong for long enough and your team will feel it as burnout or boredom.
Systems. The processes, norms, and rituals that govern how your team operates. Code review culture. On-call expectations. How decisions get made and communicated. These are the operating environment your team lives in, and they compound — good systems make everything easier; bad systems make everything harder, and they’re usually invisible until they break.
The quality bar problem
One of the most common failure modes I’ve seen in engineering leadership is what I call the quality bar problem. A leader sets an explicit standard — for code quality, for architecture decisions, for incident response — and then fails to hold it consistently. Either they enforce it selectively, or they let exceptions accumulate until the standard is meaningless.
The hard part is that holding a quality bar feels harsh in the moment and wise in retrospect. When you push back on a design decision in a review, the engineer feels slowed down. When you hold a postmortem to a high standard of rigor, it takes longer. These are short-term costs for long-term gains, and it takes discipline to keep paying them.
The other failure mode is the opposite: holding such a rigid standard that the team can’t move. The right quality bar is the one that maximizes the team’s long-term output per unit of energy. That’s different for every context, and finding it requires judgment.
What I’ve stopped worrying about
I used to think my job was to have the right technical opinions and enforce them. I’ve largely stopped thinking this way.
Strong teams have strong technical disagreement. My job isn’t to resolve it by being right — it’s to create a decision process that the team trusts, make the tradeoffs visible, and then move forward with enough conviction that the team can execute.
I’ve also stopped worrying about whether my team thinks I’m smart. That’s not the job. The job is to make the team smarter than it would otherwise be.
The thing no one tells you
The transition to engineering leadership is lonely at first, because the feedback you got as an individual contributor disappears. No one tells you that your 1:1s are getting better, or that your planning is sharper this quarter. You have to develop your own internal compass for whether you’re doing the job well.
Build that compass deliberately. Reflect on your decisions. Seek feedback from the people around you. Read broadly — not just engineering management books, but history, psychology, organizational design. The job is hard enough without trying to figure it out purely from first principles.