When making the step from developer to management how far away from the code should you get?
The standard advice is 'stop coding' but Rands had an interesting blog post about how its important to keep coding.
http://www.randsinrepose.com/archives/2007/02/07/technicality.html
In my experience (working for a big telecomms company) its difficult if not impossible to keep coding.
I don't think there is one specific answer to this question. This is always going to vary from project to project. That being said my short answer is that I feel an effective manager should help out coding and know exactly what's going on. It's good to get your hands dirty like everyone else.
When I first read your question, I had this funny mental image of a guy in a suit clinging on to a stack of papers with source code on and a bunch of devs trying to yank it from him! :D
Now, I am not a manager, but I would say that I would expect my manager to have an idea of the technologies available (so I feel he is making management decisions based on supporting knowledge). But I would not necessarily expect him to still be actively coding in the same way a developer is/should.
That said, my manager still writes code, just not as much.
I think (and this may be the obvious) "should" is a kinda strong term. I think it depends on your work situation, team size, the amount of actual management they need compared to the amount of code required etc.
I think it is very important to stay in touch with what the people under you will be doing.
Maybe you do not have to code per say, but I think it is important to stay fresh in this area just to be able to appreciate the work your coders do and to be able to estimate realistically.
Though the advice in the article to "trust" those who will be coding is good. Don't keep coding to tell them how to do things, but just to understand them better.
I think your last sentence says it all. I think it would be valuable for the developer turned into manager to continue coding (one never know what life throws at you), but realistically, it is obviously all depending on the corporate philosophy and it is subject to the office conditions, the actual needs, senior management's attitude and the individual's involvement with coding activities and overall personal scheduling and time scenarios.
The standard advise when going into management is to stop doing your old job. I've talked to several managers, albeit higher level managers, who all said the hardest thing to do when they got into management was to stop doing their old job.
That being said, you probably won't have too many responsibilities at first and be able to allocate your time to code/design work and management. I would argue your goal would be to move away from the coding. Ultimately the best managers give the problems to their subordinates and trust them to solve them in the best way. You have to trust the ability of the people you hire and work with. If not, you should look at removing them.
If you want to think in computing terms, management is working at a higher level of abstraction. They are concerned with the business issues. They are concerned with creating an effective team. Who should you hire? What to do about a problem employee? How do you remove the barriers to getting things done? How do you motivate people? When you're doing this well for a reasonable sized team you just don't have time to code.
This really depends on what you mean by management, there are many different management positions that may or may not require much technical skill. Since a manager just doesn't have time to keep coding and manage full time, I'd say you are going to have to "give up the code," but if you are a 1st line manager dealing directly with programmers its important to know your teams skills and build trust. You obviously aren't going to be capable of making all the big technical decisions and you shouldn't be doing that as a manager. To me, thats just micromanaging. You should be letting your developers make these decisions as a group. One book all programmers, programmers who want to be managers, and managers should read is Peopleware. It offers some great insight on what it means to manage a group of developers and helps you understand what makes a great team.
The problem isn't with the question, it's with the industry. What is a Manager. What is a Team lead ?
In my experience to date most Team Leads have had heavy involvement with planning, architecture, bug priortitisation & analysis. Writing code themselves is not part of their remit.
Managers have been further up the chain - defending their team leads and their staff from the evil overlords at the top.
The question would be easy to answer if all employers stuck to those titles, but although I said most companies... I have also been a manager with TL responsibilities and vice versa.
My advice regardless of title being Manager or TL
I manage a team of 16 developers and operators that I grew from scratch. I gave up coding in the application itself some time ago, but still participate by
I strongly recommend that managers of teams this size do some or all of these things to keep in touch. (How can you credibly coach your team or introduce new and better processes if you don't?)
Managers who work for me work in teams of 2-5 people. They continue to assign themselves coding tasks, but in proportion to the size of their teams - managing one other person means you can still spend most of your time coding, but a team of 5 usually means you should only do one or two easy tasks per week.