Programming

Just care for your team.

Realise you need to spend most of your time working with your more junior developers, making sure that they understand the problems they're solving, doing some whiteboard-design sessions, jumping in and pairing frequently to teach them as well as keep things going in the right direction. A lot of that is giving your team enough confidence that they're going in the right direction that they can make the decisions they need to make.

But you should not see yourself as someone that picks up tasks and gets things done by themselves. You need to work through your team. That can be difficult. And if the team gets larger, that gets even more difficult! You'll need to find some seniors you can trust, and use them to pick up some of that leadership/guiding work. You will run the risk of getting further removed from the practical technical work, and will have to find a balance. You'll probably be doing more work around the team than in the team. Maybe get involved with planning more.

But the most important thing is the above: make things clear for your team(s), don't leave them guessing about the direction, but don't prescribe the solution too much, teach as much as you can, but give people room to make their own decisions too.

Personally, I've had an experienced manager and took great inspiration from him.

A few things I fell into:

• it was a lot faster for me (I.e. experienced senior dev with context knowledge) to finish a task than for me to assign it to someone less experienced who has to learn the context and takes 5x as long to do it, with lots of help needed from me still. This yielded me not building up my team either in experience or knowledge.
• I assumed deadlines I got told were set in stone and my job was to meet them. This made business-y people happy. It made everyone else (including me) miserable. I had to learn to say no and push back, it very much changes between companies but most of the time I found it to be a negotiation and either the deadline could move or I had to argue to exclude things from the scope to make the deadline reasonable.
• on the above, everything takes at least 3-5x as long as I think it takes. If things finish early, great time to give my team some slack, add in additional QA work like extending tests or repay some tech debt. Delivering something early gives a pat on the back for us but no discernible benefit to the team.
• every time someone said "you'll have time to write tests/repay tech debt/upskill later once X is shipped" it never came true. Those things have to be built into delivery scopes, and it's a constant battle - if you don't do this, nobody else will.

I'm sure there were other things too, but these are the ones I mainly recall. Talk to your team, ask for feedback. Every team, project and company are different - you'll have to adapt.

I didn't use any learning resources. I lead from experience, mindful, by example, communicative. It comes naturally to me.

You said you had bad experiences. Doesn't that conclude to knowing what to evade and what you would have wanted more of from a lead?

id check out some of the lower level, free 'project management' courses out there. its all about communication and documentation.

assuming youre just a great, helpful team member; the lead will have excellent project management skills.