What worked for me was to learn to listen to people, to let them explain the problem and sometimes find an answer as they were talking.  What helped was to do lots of peer reviews of both code and documentation so the the young ones could learn from the old ones and the old ones could get new ideas or more up to date ways of doing things from the young ones.  I came to realise that programming is flow based while leading a team is interrupt driven so I had to learn how to do context switching quickly and to block out areas of time when I could do my own programming.  I had to learn to help people do their work and restrain myself from rushing in to do the work myself.  And I had to learn that my team members were people who had lives outside work that affected the work they did.<p>For example, I had a team member who was a good programmer but had trouble coming to work on time.  He was getting married so I bought him a clock radio as a wedding gift.  That fixed the problem.