If you're a programmer who's been thrust into management, you'll probably want to keep coding. It's the only way to truly understand what's happening inside the engineering team, and nobody wants to become a pointy-haired boss. Your non-programming responsibilities will take a lot of your time though, so how can you pick the right tasks to take on? I've worked with several outstanding lead engineers at Apple and elsewhere, and here's what I've noticed about what their coding responsibilities look like.
Boring
The only way to motivate good hackers is to give them something interesting and challenging to work on. As a greybeard engineer, you've probably gone through your career fighting for chance to work on tough, rewarding problems, so your reflex will be to jump in on the most daunting and fun tasks. If you're a good manager, you'll stop yourself! Look for tasks that nobody else wants to take on instead. You shouldn't need the motivation yourself, leading the team should be enough, and you'll be able to offer your engineers a more rewarding bunch of work. It also builds respect for you in the team if they can see you're willing to sacrifice something meaningful for their benefit.
Ubiquitous
In the short-lived Police Squad, Johnny Shoeshine always supplied the 'word on the street' for all sorts of implausible topics. Being a lead is a lot like that! You need to know the nitty-gritty details of what's happening in the code base, and understand intimately how it's evolving so you can offer meaningful advice and head off potential problems early. The only way to do that is to touch as much of the code base as possible as often as possible. That means picking tasks that are cross-module, whether it's integrating multiple parts of the code, or a service that's used everywhere.
Non-blocking
The sad reality of a manager's life is that you're unpredictably called away from your day to day duties, especially when deadlines are looming. That can be disasterous if other team members are relying on you to deliver code so they can make progress, or if bugs are going unfixed because you're unavailable. You need to find something that can be worked on incrementally in small chunks, and doesn't prevent others from making progress if you do get waylaid for a week.
Following this philosophy, one of the things I've ended up building is the activity log analysis system. It's not something anybody else wants to work on, we need to record events almost everywhere in the code so it touches every module, and it doesn't stop us shipping if improvements get delayed.
If you're a lead, give boring a chance, you'll be amazed at how effective an approach it can be!
Pete Warden's blog 