Collect all tasks in a to-do list -- I started doing this fairly recently (in part prompted by an internally delivered training course I went on) and it's actually made a bit of a difference. It certainly makes the work-load I'm dealing with *feel* like it's more manageable. It also makes it seem like I've achieved more when I can see a list of items crossed off a list.

Delegate when feasible -- Something that I know I don't do as much as I should do. "Dump It. Delegate It. Do It". The three options I was told to use (in the same training course!) whenever a task comes my way. I'm a hoarder at times. I keep tasks for myself because I think that I'll be able to do them better and quicker than anyone else. Mistake. Repeat after me, "Others can do the job too."

Identify your Timewasters -- Is someone dragging the rest of the team down? If they are, is it even their fault? Maybe they're out of their depth. Maybe they don't like the job they're doing. Maybe they're just bone ideal. All people have a working style, some peoples working styles just aren't right though. Changing a persons working style is one of the hardest things to do, the soft option is to manage them out of the business.

Reward Yourself -- (and your team!) Nothing provides for team motivation and cheer than a reward of some kind. Even a thankyou can be a reward. It's surprising how many people don't say "Thank You" for a job well done at work!

Developers -- Semack.Net - On Being a Manager

Keep Everyone Pointed in the Right Direction -- It's all too easy in a big project for people t o take divergent paths. Requirements are easy to interpret in any one of a thousand ways. Many things can be implemented either in a very simple way, or in a very complicated way. The very complicated way often has a lot of benefits associated, but, will they ever be used? To a developer the complicated way is good, because it is. To a development manager the simple way is good, because its quick and will bring the project in on time/budget. To the good development manager, the middle road that follows the same path as the rest of the development team, utilising any pre-existing code and best practice. This is also the way that was planned out and documented prior to the start of the project.

Double-Check Everyone's Work -- This ties back to keeping everyone pointed in the right direction. There's such a thing as "Specification Creep" and hand in hand with that comes "Implementation Creep". As well as checking to make sure a piece of work has been implemented correctly (including following any development / coding guidelines in place) and in an efficient manner, ensuring that what's been done actually fits the specification is just as important.

Evaluate Employees -- This applies to everyone, not just developers. Spend some time talking to your team. Coaching and guidance should be a constant and ongoing thing, but, always take time to block out 15 minutes a week to touch base with each person in your team. Use the time to find out how things are going, to deal with their concerns and to track their professional development. Annual appraisals are all well and good but everything that gets written on the appraisal form should be things you've discovered and discussed during the year previously. An appraisal shouldn't have any surprises for the appraiser or (especially!) the appraisee.

Most of this is a reminder to me. Things I should do. Practices, process and procedures I should implement. I just need to make sure I do it now!