''I've been there. Don't put yourself on the critical path for anything, or you _will_ end up doing two jobs. Managing should be your primary job (which includes doing anything that's needed to make your team happy and productive. Doing that can involve programming - I used to do some of the more boring bits, writing little utilities and utility functions, gentle refactoring, and basically filling in around the edges)''

My approach was similar. I assigned myself NONE of the work... some developer OTHER than me was responsible for each and every bit of development. I then took on two tasks. One was addressing integration issues... this required me to know how different people's sections worked (in more detail than the specs since if the specs had been sufficient there would never have been an integration issue!). It worked out nicely, since I wanted to delve a little into the details of everyone's code as manager too. The other role I took on was pinch hitter... when someone raised the flag and said they wouldn't be able to meet their deadlines I let them assign some (well-defined) part of their coding to me, and when one developer quit suddenly I finished off his piece. -- MichaelChermside

''I've found that the biggest issue lies in managers who wrote code a long time ago. The manager in question has not kept up with recent development practices. They don't write structured code. They don't write unit tests. They add arcane "optimization code" that hasn't changed the speed of the program since 10 years ago. And, worst of all, this puts them in a prime place to decide that your project will be written in the DeadLanguage that they programmed in years ago. I got stuck developing in HtBasic (HPBASIC in some circles) for a project that way. Ah, the joys of a code editor that saves the source in a proprietary format and occasionally interprets the undo command as license to delete a line of code 10 pages back without indicating to you that it has done so... -- SeanDuggan''

----

See also DeveloperTurnedManager