The year I stopped being the person who writes all the code
Moving from “the developer” to leading a development team is not a promotion so much as a change of job. The skills that got you there are not the ones the new role needs.
For a long stretch, being useful meant writing the code. If something needed doing I did it, usually that evening, usually well. Then the team grew, the products multiplied, and the thing that had made me useful started making me a bottleneck.
The uncomfortable arithmetic
A developer working flat out ships one developer's worth of work. A lead who spends that same day unblocking four people ships considerably more, but at the end of it there is nothing in the commit log with your name on it. If your sense of a good day is tied to what you personally built, the first months feel like failure.
What helped was changing the unit of work. The output is not my code. The output is whether the product moved, whether the release was calm, whether the person who was stuck at 10am was moving again by 11.
Your throughput stops being what you finish and becomes what stops being blocked.
Reviews are where the culture lives
Code review turned out to be the highest-leverage thing I do. Not as gatekeeping, but as the place where standards get transmitted without a meeting. A review that explains why a pattern matters teaches; a review that just says "change this" only corrects.
I try to separate the two things I might be saying: "this is wrong and here is the problem it will cause", versus "this is not how I would have written it." The second one is usually not worth spending someone's afternoon on, and the discipline of noticing which one I am about to say has improved my reviews more than any checklist.
Roadmap is a filtering job
Owning the roadmap sounds like deciding what gets built. In practice it is mostly deciding what does not, and being able to explain that decision to the person whose idea it was without making them regret having ideas.
Every "not this quarter" needs a reason that survives contact with a customer request, a support trend, and a competitor's release notes. If it does not, it was a preference dressed up as a plan.
What I kept
I still write code: the advanced features, the architecture, the parts where the shape of the thing is not yet clear. That is partly self-interest: a lead who has not touched the codebase in a year starts making decisions from memory of a system that no longer exists.
But the balance moved, and so did the definition of a good week. It took a while to stop measuring it in commits.