What Changed When I Started Leading Engineers

The short answer: the thing that actually changed when I moved from senior developer to leading 12+ engineers was realizing the job is a different discipline, not a scaled-up version of the old one — my output became my team's output, code reviews shifted from correcting to teaching judgment, estimates became conversations about uncertainty rather than numbers, and most of my highest-leverage work turned into the invisible job of protecting people's focus and unblocking them.

The first time I was handed a team, I made the classic mistake: I treated management as "senior engineering, but with more meetings." I kept reviewing every PR line by line, kept writing the trickiest code myself, kept being the bottleneck I was supposed to remove. It took a couple of painful quarters at Maxxton — growing from team lead to associate technology manager over a team of 12+ — to understand that the job had actually changed, not just expanded.

Your output is now other people's output

As an IC, a good week is measured in features shipped. As a lead, a good week is measured in features your team shipped and the obstacles you cleared before they became blockers. This is genuinely hard to internalize, because the feedback loop is slower and less visible. You can finish a day having written zero code and still have been enormously productive — if you unblocked three people, prevented one architectural wrong turn, and gave a junior engineer the context to make a decision themselves next time.

Review for teaching, not for correctness alone

Early on, my code reviews were a list of things to fix. Effective, but it meant the same comments appeared on the next PR. I started reviewing differently: fix the blocking issues, but for everything else, explain the why and the tradeoff, and let the author decide. A review that says "this works, but here's what happens to it under concurrent writes — your call" teaches judgment. A review that says "change this" teaches obedience. One of those scales; the other makes you the permanent bottleneck.

I also learned to approve more. A PR that's 90% of the way there and unblocks someone is usually better merged with a follow-up ticket than held hostage over style. Perfect is the enemy of a team that's moving.

Estimates are a conversation, not a number

The most useful thing I did for delivery was to stop treating estimates as commitments and start treating them as a shared understanding of uncertainty. "Two weeks, assuming the payments API behaves and we don't discover the legacy migration is load-bearing" is infinitely more useful to a product partner than "two weeks." It names the risks out loud, which means they get managed instead of discovered at the deadline.

Protect focus ruthlessly

The thing engineers need most and get least is uninterrupted time. A lot of management is absorbing interruptions so your team doesn't have to — fielding the stakeholder question, triaging the "quick favor," batching the status updates. I became the shock absorber. When I did it well, the team barely noticed the chaos I was buffering, which is exactly the point. Invisible work that keeps good people in flow is some of the highest-leverage work there is.

You will miss the code — do something about it

Nobody warns you how much you'll miss building. I keep a foot in it deliberately: side projects, this very portfolio, the occasional gnarly bug I pair on. Not because the team needs me to, but because staying close to the craft keeps my reviews grounded and my estimates honest. A manager who hasn't shipped in two years slowly loses the ability to tell a real two-day task from a real two-week one — and that erosion is quiet until it isn't.

The transition from engineer to leader isn't a promotion so much as a career change that happens to share a job title. The sooner you treat it as a new discipline to learn rather than your old one scaled up, the sooner your team gets a manager instead of a very distracted senior developer.