Leading a small engineering team without losing your hands-on edge
Moving from senior engineer to running a team of five was not the kind of promotion I had pictured in my head. I had assumed it would be a scaled-up version of the same job, more code, more decisions, more responsibility. What actually happened was that the job changed entirely. My calendar filled with other people's questions, with review meetings, with judgement calls that did not have a clean answer. The amount of code I personally shipped each week dropped to a fraction of what it used to be.
For a while that felt like losing something. I had built my identity around being the person who could just go away and produce a working system. Now my output was measured in conversations and decisions, not in pull requests. It took a few months to accept that this was the actual job, and a few more to figure out how to do it without quietly starving the work I cared about. This post is a short version of what eventually worked for me.
Stay close to the code without owning all of it
The single most useful habit I built was reading every meaningful pull request that the team opens. I do not block merges and I do not act as a gatekeeper. I read because it is the cheapest, fastest way to know what the system is doing this week and how each engineer is thinking about the problems in front of them. When I notice a pattern that worries me, I bring it up in our weekly sync rather than in the diff. That keeps the review process light and the architectural conversations where they belong.
When I do write code myself, I take a real piece of work that the team actually needs. Not a side experiment, not a refactor no one asked for. The point is to feel the system from the inside, to hit the same rough edges the team hits, and to remember why the boring foundation work matters. It also keeps me honest when I argue for a particular architecture in a planning meeting.
Decide fast and write the decision down
Most decisions a small team makes are reversible. They feel large in the moment, but a month later the team will have learned enough to revisit them anyway. I have stopped trying to run every choice through a long Slack thread. Instead I make a call, write a short note in Notion with the context, the options I considered, and the reason I went one way, and share it with the team. People who disagree can push back and I will revisit. People who agree can stop thinking about it and get back to building.
Written decisions also turn out to be the cheapest onboarding document a team can build. Six months later, a new engineer can read the trail of choices and understand not just what the system looks like, but why it looks that way. That is worth far more than the twenty minutes it cost to write the note.
Protect focus time, mine and theirs
We meet twice a week as a team. Standups are async in a short Slack thread. Every engineer has a clearly protected half-day block each day with no meetings on the calendar, and I do the same for myself. When I broke this rule for a few weeks because everything felt urgent, the team's output dropped noticeably and so did the quality of the work I was doing. Focus time is not a luxury for a small team, it is the thing that lets them actually finish anything.
Hire for taste and the discipline to finish
Technical skills can be taught. What is harder to teach is taste, the instinct for what to build and what to cut, and the discipline to push through the last ten percent of a feature where everything is boring but everything matters. When I am hiring or evaluating people for bigger work, I look for those two qualities first and I am less worried about the specific stack experience on their CV. The team I have now is small, and that is on purpose. A few people who care deeply about the craft will outship a larger team every time.