As an IT manager, you'll have team members who initially aren't able to get things done as quickly as you or other experienced team members can. A good portion of that productivity gap is due to their lack of your codebase, development process, etc. So one way you can speed their progress is to ensure that they have access to domain knowledge through a wiki, training videos, documentation, shadowing other programmers, etc.
There's an old joke about how knowledge is most of the battle.
There was a business whose expensive machine suddenly stopped working. Since the machine was vital to daily operations, they called in an expert to do the repairs. The expert looked at the machine, checked a few settings, pulled out a hammer, and rapped the machine lightly on the side. The machine instantly sprang to life and the business was able to move forward with its work.
The delighted business owner said, "Great, what do I owe you?" to which the expert replied "That'll be $100."
"100 dollars?" the owner cried. "But you were only here for 5 minutes! $100 for one swing of a hammer doesn't seem worth it."
So the expert quickly wrote up an itemized invoice and handed it to the owner. The owner reviewed the invoice, sighed, shrugged, nodded, and paid the expert his $100.
On the invoice were two line items:
Swinging the hammer -- $1
Knowing where to swing the hammer -- $99
One of the things I do is help new team members know "where to swing the hammer" by suggesting approaches, resources, or even the particular modules, files, & functions that they would probably be working with. I ease up on that direction as they come up to speed, but I feel it's valuable initially to help new people focus in on the problem and still get things done. I'm not robbing them of a chance to learn the systems, since I'm only providing a high-level suggestion, and they'll still be working on the code in depth.