I agree with most of what's been said alreay, but I also believe that it's possible (although quite difficult) to be a good manager and a good technician at the same time. It's been my good fortune during a lot of my life to work in environments where people are expected to switch between technical roles and management roles quite often, because the top managers believed (correctly, I think) that the most productive workers tended to be those that understood both management and technology through both training and real experience in both, so when some of the earlier comments have suggested that goiong back from management to being technical is unusual my reaction has been that it's something most good managers and most good technicians have done and should be thought of as the norm, not as something unusual.

There was one thing in the editorial that worried me: the apparent belief that being an English major was some sort of negative for being a DBA, or perhaps for being any sort of technician. This isn't a view held by anyone I know in the computing business, and R&D teams I have managed have included people whose degrees (some PhDs, some Masters, mostly Bachelors) were in Music, History, Theology, and all sorts of other things (including more than one person with a degree in English) as well as people with no degrees at all. Perhaps the best software engineering manager I ever worked for had a master mariner's certificate rather than a university qualification. I think it must be a phenomenon of comparatively recent times - after all, undergraduate courses in CS are a pretty recent phenomenon, and those in IT are even more recent, so in the old days we didn't expect our people to have a computing or IT degree.

As for still being technical while being a manager - well, I have done it myself, and that's one of the reasons I believe it's possible. So have a lot of other people. For example I started to learn queuing theory in my lateish 20s (well over 35 years ago) when I was running a couple of smallish project teams (about 20 people in all) because no-one on the teams had the mathematical background to handle this and I had chosen, as an undergraduate and as a research student, to neglect this part of mathematics as "uninteresting", little knowing that it would be critical to system design. For something over 20 years after that I was that company's (20,000+ employees world wiide) technical expert on queuing theory and on related performance modelling and simulation activities - whether I was currently managing a team or a programme or currently acting as a technical leader (which, in that company, meant being completely on top of the technical details in the special area) in some area to which queuing theory was completely irrelevant, or buried up to my neck in the politics of inter-dividional dispute resolution (for a while I was the company-wide authority on resolution of interworking problems, whether caused by different divisions interpreting common specifications differently, or by the need to continue to support legacy systems, or by one division's inability to do precisely what it had committed to - that's the sort of role where it really comes home to you that technical correctness and commercial correctness are not the same thing, and if you let Technical win out over Commercial the company goes bust). I wasn't trying to tell people how to do the calculations, or what assumptions they should make, or how to design simulations that would provide useful performance data, or o micromanage anyone - but engineers. technicians, and managers just kept coming to me for advice on these topics. So I reckon I can claim to having been the leading technical light on a specific area of technology in a large international company at the same time as having been a senior manager or a very senior political animal, and the two things didn't interfere with each-other at all (of course I could never have handled the political role while being a project or programme or department manager - that would have been asking for trouble, since everyone would assume my decisions were biased). Maybe the trick is to ensure that the technical area in which you remain the acknowledged top expert is not the one which the people you manage work in? Or to have so much going on that the senior developers welcome another pair of hands (I've been there too)?