OK as a lead it is your job to get the projects out the door. So you have to be the one who enforces standards, code reviews, asks for progress reports and all those things when the developers would rather you left them alone. These things are just requirements of management and except for the code reviews don't really grow the employees' skills.
However, you want to help them grow which is a great attribute in a leader.
Code reviews are certainly a first step, they will help you see who has less than stellar skils and needs improvement to even have satsifactory performance. They willl help the developers see other ways to do things and to understand different parts of the code base than the ones they personally worked on. In my opinion, code reviews are best done in person in a conference room with the developer and the reviewer (who should be another developer when possible not always the lead, reviewing other's code is also a skill that needs to be developed) and you as a moderator. You should keep notes on what needed to be changed to identify trends. What you really are looking for isn't mistakes or changes (everyone's code can be improved), but consistent failure to learn from mistakes. Do not tell upper management you are keeping these notes or you will find yourself forced to use them as measurements in the performance review process which frankly defeats the purpose. If several developers are making the same mistakes, a training session or a wiki entry on how to do X may be in order.
Now on to growing vice getting to the minimal level. First, you need to know what skill sets the developers have and what skill sets it would be useful that they had and what they might be interested in getting knowldge in. You need to talk to them and review their resumes and understand what they liek and don't like to do.
Don't give all the interesting assignments only to the most skilled. That doesn't help the others get up to speed on new problems and technologies. You can't move from being the most junior guy getting only the smallest and least important tasks to the senior guy unless someone takes a chance and assigns more difficult work to you. That said, the less experienced may need to be assigned first to pair program with a senior to get more advanced skills. Including the juniors in code reviews will also expose them to more advanced techniques.
First give them a chance to figure out the issue themselves. But sometimes people are stuck and don't know where to start (a skill that you also needs developing especially in new programmers) or what to do to solve a problem.
If you give them a couple of days to research something and they still don't have a direction for how they are going to do something, then you may need to intervene with some suggestions. If you are technical yourself, you may give them some ideas for how to solve the problem. If not, a meeting with several people where you brainstorm ideas can help if the person is stuck. Or asking a more experienced person to give some suggestions. What you don't want to do is take the problem away from them and solve it yourself. But you have to balance getting the project done with the programmer's ego and at times you need to send them in a specific direction. If he has a bad solution and it needs to be fixed, the worst thing you can do is give it to someone else unless you intend to fire the programmer. Making people fix their own mistakes is how they learn not to make them.
I've seen bad programmers coddled, where someone else has to fix almost everything they do. The other programmers resent this and just want the person out of their lives. Coddling a bad programmer leads to the good programmers leaving. You have to find the line between coddling and devloping skills. If you give someone several chances and he or she never gets better, then cut him or her loose.
For the seniors who are already competent in their current skill sets, things are easier. Usually you just need to give them the opportunity to do something new and they jump in and learn it. Just make sure the interesting opportunities get spread around and don't all go to Joe the Wonder Programmer who can fix anything. You want to end up with ten Joes not just one.
Another way to develop skills is to have a weekly 1-hour training session. Make each devloper responsible for a particular topic. This will help them get better at communicating, will make them research something in depth and will give everyone the benefit of their research. Some topics should be assigned to people who are not familair with the topic to force them to grow some knowledge in that are and some should be assigned to people you know are the local experts on that topic. Topics should be a combination fo things you need people to be good at inthe near furture or right now and some coverage of new upcoming technologies that you don't use right now but peoplea re intersted in learning about to see if they could be useful. But everyone including the most junior must be assigned a topic. Doing the training is as much a growth opportunity as listening to the training.
Depending on how your developers' time is billed (this is harder in a customer billing situation), it is usually worth it for developers to have 4-8 hours a week to work on personal projects. They will be excited to do this. The best people will want to work there and they will learn alot that will become useful for the future. It's hard for the bean counters to understand the need for this, but this time will be paid back many times over in employee satisfaction, new features or software that nobody required (or which will help automate some of the drudgery) and faster development due to new techniques learned. Some developers will use this time strictly for personal projects not related to what you do (and that's good, they will still be gaining skills and happy for the opportunity), but many others will use it to solve persistent problmes that, due to the nature of how projects are managed, ndbody had time to fix beforehand. So you may get refactorings that benefit everyone; some people might write tests to improve test coverage to make it easier to refactor; some others might explore some new features that might make your software more useful to it's customers. In general, if you can persuade the bean counters, there is no way to lose by allowing them this freedom.
You have to learn how to balance letting people have some stretch for their skills and keeping the project on track. The less experienced the developer is, the more someone needs to check on progress especially in the early stages when changing direction is easier. The inexperienced may struggle and be afraid to speak up. These people tend to leave just before launch and you find their part of the project isn't anywhere close to being done. Be especially careful to check progress on anyone you have who has changed jobs frequently (unless they were a contractor as that is the nature of contracting).
The more experienced can generally be trusted to tell you when they are having trouble finding the solution and need some assistance from someone with more knowledge in the area or they will go seek out that person and get the knowledge transfer. So they don't need to be monitored as closely in the intial phases of learning a new skill set for a project. They will find a way to deliver the project. Those who have a track record of delivering can usually be left alone except for minimal progress reports (you usually have to report to your management too and thus need some information).