I was a manager several times in my career (most recently "uber tech lead" for almost 4 years at Google, before switching to senior staff engineer, still for Google -- now in business intelligence too, funny coincidence;-)... but never for 30+ direct reports (indirect ones soak up less of your time and energy...): at those levels, people managing (and other managerial tasks such as budgets, coordination with your peers, etc etc) will suck you dry, I have no idea where one would find the time and energy to keep up serious technical contribution (the only real way to "keep your skills sharp", in the end).
Google has a guideline of no more than two dozen direct reports -- and, that's assuming that not all managers (esp. at VP level and above) necessarily need to keep at the top of their tech game, that engineers (especially highly senior ones) and other highly professional figures are almost "self-managing", etc, etc. (Given that we also want to keep our hierarchy very flat, the guideline isn't always followed, but there's always a serious attempt to move towards it).
Within those more reasonable boundaries, I've managed to keep my tech skills quite reasonably fresh and well-honed (as proven by having successfully switched to very senior IC last year;-). I have some presentations on the subject floating around, e.g. here (summary and link to an audio stream) and here (PDF with slides for a slight variation on that talk) -- unfortunately it looks like no video of my presentations is online, except maybe one I gave in Italian (at Pycon Italia) -- but I can't locate its .torrent now (and bittorrent was the only way it was distributed).
It's hard to summarize many hours of presentations (and many years of experience;-) in a few words, but, let me try: point one is that being technically involved and contributing (in the right ways) is crucial to doing a great job in technical management, for many reasons, so it's a TOP priority, well worth dropping a few lesser ones for; managing your time and your priorities carefully can free you up just enough to achieve this goal; the best approach is to "use yourself as a jolly" for those situations where you desperately need an extra pair of skillful, experienced "hands" to fight fires in one or another of your projects.
Rands, of "Rands in Repose" and Managing Humans fame, puts it well, as usual:
“That not coding pitch of mine? Wrong.
Yeah. Start programming again. Start
with Python or Ruby. Yeah. I mean it.
Your career depends on it.”
Python is my main gig, so I sympathize with the recommendation, but I must admit that (if you're also entirely comfy with C++, gdb, RPCs, etc, etc) it also works to keep hacking away at such not-so-entirely-nice technologies you know and love... as long as they're crucial to your projects (doing it as a "side endeavor" doesn't work nearly as well).
I know, because all of those (though not as intensely as Python) have been and are part of my daily fare -- "Python where you can, C++ where you must" has long been my motto, and it fits well with Google's general attitudes in both cluster management SW and business intelligence (some other parts of the company are more Java-y, and I'm a bit rusty in that, though I plan to catch up and refresh when I get a good opportunity to;-).
I hope these reflections and links prove of some use... in any case, best of luck!!!