Your #1 source for producer skills the the PMBOK (Project Management Book of Knowledge) - but it's a very very dry read. However as it is pretty much a reference work there are many books presenting the same topics in a simplified manner. Also, not all topics of the PMBOK apply to producers work anyway. Mostly risk management, resource/time planning, stakeholder management. There should be tons of books on the subject. Asking a producer can be a good starting point. Here at my company, for example, a couple of producers are PMPs, so those are the guys I would ask.
In general as a lead you don't need to know as much as a producer anyway. But it helps knowing about the topics and the issues they deal with.
SDLCs are a typical software engineering topic. Agile is a form of SDLC (the other well known one is Waterfall). What's interesting to learn is not necessarily how other SDLCs work, but how to do things by the book. I often meet people who claim to do Scrum who have no clue about how to do things by the book. It's like saying "I'm an abstract painter" when in fact you have no clue about anatomy, perspective or color theory. You're not an abstract painter because of skill, but because of the lack of it. Anyway, you want to read up on requirements engineering, specification, planning, best practices, progress tracking, reviews, configuration management, etc. Some of it is covered in the books mentioned below.
For practical tips McConnell's Code Complete 2 is the best book imho. The Software Project Survival Guide (also by Mc Connell) adds the project management part that's missing from Code Complete. "The Pragmatic Programmer" takes a bit more philosophical stance on what is good software. Definitely read "The Mythical Man Month". I also enjoyed "Software Engineering for Game Developers" (Warning: this book is NOT about making games in practice, and I don't think anyone makes, or should make, games like describes in this book!; However it is a fairly easily readable introduction to all things Software Engineering which is pretty close to what is being taught at college. It describes how to do things by-the-book.). Only once you understand the rules - i.e. how you should do things - you can break them. At this point you should do Scrum (note: Scrum is pretty much both a SDLC and project management approach).
If you've started out as coder, especially one heavily invested in algorithms, you should brush up on your architectural skills. As a lead you give direction and your "grunts" will do all the typing. They will often focus on units and rely on you to provide the big picture. Or you could designate someone as "architect" in your team, but I've never seen this in practice in a TA / tools team yet. Read up on some practices how you can write down software architecture. i.e. how modules are arranged, how they interact and what their dependencies are. This will help your team to understand how their work fits into the big picture. Take a look at UML, especially class diagram notation. No need to stick to the book though. Use it as inspiration to share ideas about software architecture with your team, and as basis for discussion. Sharing the big picture (and holding it in a written down form) with your team is important! (or else everyone will forget the grand design halfway during production and your software will be a convoluted mess).
Again, your knowledge doesn't need to be as deep as someone who designs e.g. an entire game engine. But you should be familiar with the topics and issues.
Resource and time planning: PMBOK covers this. It's basically a major part in MS Project. But for team leader purposes you can do it with fewer bells and whistles, and this knowledge mostly comes handy for longer projects - e.g. you develop a pipeline or some other complex tool with multiple people working on it. Being able to make a GANTT diagram and identify the critical path allows you to indetify the most resource intensive tasks, the tasks which can or cannot delay, and it allows you to experiment with different schedules and see how they affect your overall project. Basically it lets you explore different scenarios of how you schedule the project, which is nice.
Sure, it's game dev, and things change all the time, but it helps if you have a plan, as guidance, that shows you the "ideal direction" to follow, rather than being completely lost without any plan. As alternative you can use the Scrum approach. But even there it helps to have some grand design or path in mind and not totally let customers jerk you around all the time (i.e. Scrum is flexible, but it also often happens that clients themselves have no plan)
Edit: Theodox has some books listed on his website, I think there are also a couple which could be useful for a lead to know.