What Nobody Tells You About Becoming a Team Lead as an Engineer

For most of my early career, the job was simple to describe: take a ticket, understand it, write the code, ship it. I was a PHP developer, then a full stack developer, and the feedback loop was tight. Code either worked or it did not, and I got to find out the same day.

Becoming a team manager broke that loop, and nobody really warns you about it in advance.

The work stops being yours

The hardest adjustment was not technical at all. It was realizing that my output was no longer measured by what I personally shipped, but by what my team shipped, whether the deadlines were realistic, and whether people knew what to do when they got stuck. Some weeks I wrote very little code. That used to feel like I was falling behind. It took a while to accept that reviewing someone else’s approach to a problem, catching a bad assumption before it became three days of rework, was the actual job now, not a distraction from it.

Planning is a skill, not a formality

Nobody teaches you how to plan a project as an individual contributor, because you are usually planning your own slice of it, not the whole thing. Leading a team means owning the plan itself: breaking work into pieces that make sense for the people who will pick them up, being honest about what fits in a deadline and what does not, and saying no to scope creep before it quietly becomes everyone’s problem. I got this wrong more than once early on, usually by underestimating how long integration and testing take once multiple people’s work has to fit together.

Technical judgment does not disappear, it changes shape

I still write Go and PHP and touch AWS infrastructure regularly. What changed is when I use that judgment. As an individual contributor, technical decisions were mostly mine to make. As a lead, the more valuable move is often asking the right question in a code review or a planning discussion, so a junior or mid-level engineer arrives at the right answer themselves instead of just being handed one. It is slower in the moment and pays off over months.

What actually made it work

A few things helped more than any leadership book:

• Staying hands-on enough that I could still credibly review the hard parts, not just the easy ones
• Treating deadlines as something to negotiate honestly with stakeholders, not absorb silently and pass the pressure down to the team
• Being the person who stays calm when something breaks in production, since a manager who panics teaches the team to panic too

None of this is dramatic. It is mostly a lot of small decisions about attention: what to review closely, what to trust, and when to step back in. Getting that balance right is still the part I am actively working on, years in.