How do you know when to make the move from a programmer into a manager of programmers / projects?
What are some risks to make the jump to manager and can you go back?
NB: I'm looking for some specific bullet point questions that a developer can ask himself/herself to help in the decision making process.
I notice that you ask "when" and not "if".
I guess there are many programmers that will never want to be managers :-)
Questions
"Am I okay with spending more time with non-technical and non-programming tasks than developing".
"Do I prefer to work on the bigger picture or intricate details of a project"
"Are you comfortable with spending time dealing with employee issues, motivation, vacation, etc."
One of the risks I see with making this jump is losing your technical edge. Being a manager requires extra effort if you wish to stay at the top of the technical ladder. It can be done but many times it requires work outside of your day job to do that.
The time to make the move from development to management is when being managed has eroded your enjoyment of development such that you think its time to step up to the plate and (try to) do a better job.
Complaining is easy (and "fun too" as Homer said). Doing something about it is hard.
It's hard to reduce this to a bullet list of criteria because they're quite different paths. One is writing code and the other is managing people. Those are extremely different disciplines requiring different personality traits, skills and attitudes.
For one thing you can't be a friend to your team and their boss. That doesn't mean you can't be cordial with them and encourage a good team environment but ultimately you are their boss and are responsible (to your management) for the results. You can't forget that and neither can they.
The risks are basically that your skills will become obsolete. Even 6 months out of programming can have a negative impact. Things can move that fast. Go up to 2 years and you may almost be up to the point of needing retraining. You'll certainly need to do some serious catch up.
The good thing is that the experience will help you if you go that route and go back. Plus you'll know for sure that you don't want to do it rather than wondering. That's a good thing.
I think the question is flawed.
There's a premise that management of programmers is somehow different from programming.
My thesis is that managing programmers should not be dramatically different from being a programmer. I think there's a smooth transition from mostly programming to mostly managing.
First, you code, directed by someone else. An apprentice directed by a master craftsman.
Second, you code, collaborating with others. A journeyman, working with journeyman, directed by a master craftsman.
Third, you code, collaborating with others and directing others. You're a master, working with journeyman, directing some apprentices.
If you accept that a manager is not an active, working programmer, you have to then accept clueless managers making inappropriate technical decisions. I don't think the concept of "pure management" is unrealistic; it doesn't work in business, technology, law, government, anywhere. If you don't get the technology (or the business or area you're managing), you can't manage it effectively.
Edit
If you are working professionally (all levels: apprentice, journeyman, master) you are constantly managing something. Either yourself, the group of peers or your apprentices. If you're not managing the work, you're probably not going to finish and get paid for anything.
There's no abrupt change in skills between working more and managing more. Only a shift in focus from managing yourself to managing others.
Altruistically:
Realistically:
Cynically:
Am I prepared to give up coding? (in other words - don't fool yourself into thinking you can both manage and code; you're unlikely to do well at either if you try to, in most situations.)
Do I have an exit strategy?
What do I want from my career?
Who was my best manager ever? What made him/her great?
Who was my worst manager ever? What made him/her awful?
Of the above, who am I more like? Which management practices and attitudes will come naturally to me, and with which will I struggle?
Can I really let go of coding? Will I lose control - and can I relinquish control?
Going from developer to manager is like going up level up in abstraction. You're not head down writing nuts and bolts code anymore, you're setting the general direction the project should go. And that of course includes squishy-mushy factors like managing people.
Questions I'd ask myself:
- Do I know how to manage myself?
- Do I know how to manage people?
- If I don't, am I willing to learn?
- Do I feel comfortable going into a learning mode? (some people prefer to stay in what they know, out of fear of the unknown. In a sense, being vulnerable)
- Do I want to become a facilitator? (my favorite managers are the ones that try their best to keep you happy and working, by keeping obstacles out of your way, instead of micromanaging)
- Am I willing to listen to others?
I'm hesitant about putting questions about "giving up" things. You're not giving up anything, you're taking on new responsibilities and learning new concepts that build upon your experience.
Also, in my experience, being a manager or a programmer isn't mutually exclusive. Different projects require different amounts of management. And I've known many people who've gone from programmer to manager and back, so I don't think you'll have many issues with that.
I have wrestled with this particular issue for about two years now. However, the further I moved down the "management path" the more I realized I wasn't ready. For instance:
From my experience, I do not think a manager can also be a coder on any reasonably-sized project. If there are enough people on the team to warrant a manager, there isn't time for that manager to code. The reason I say that is because as a technical person, you are going to want to code, and you're not going to want to do spreadsheets, and salary reviews, and settle petty programmer squabbles, and the like. I have worked for people like this, and it's one of the reasons I've had 1 review in 4 years. A manager/coder does not make for happy subordinates.
Still considering it? Ask yourself:
RISKS--Absolutely!
Honestly, I think you need to stick your big toe in the water. If you see something manager related that needs to be done, just do it! For instance, you're in a meeting, and somebody says, we need to define the tasks for the next sprint, offer to take the lead and get input from the other devs. Schedule some meetings and position yourself as the face of the team. Pretty soon that management work will come your way. And, if like me, you don't like what it turns into, slowly back off of those responsibilities, claiming you aren't getting enough "real work" done.
Here's a few bullet point questions to ask about ascending into management, along with a bit of an explanation on why it is important:
Am I prepared to handle politics and bureaucracy that come with having more responsibility? IOW, do I have diplomacy, persuasion and debating skills to deal with this?
Do I feel comfortable handling the responsibility of telling others what to do and be held responsible if they don't? This is kind of that "stepping up to the plate" metaphor originates and things like motivating others can also be in this area of concern.
Are there training programs or mentoring programs to ease with the transition to being a manager? This is helpful in that if there are resources it may not be as difficult as you think.
Do I want to manage people or projects? These are different things to my mind and may require slightly different skills as the person manager may be responsible for ensuring self-improvement and professional development of their team while the project manager has the focus on just completing projects and doesn't have to worry about professional development.
Have I been a technical or team lead on previous projects that illustrate my leadership skills? This is for that HR or other person that may raise the question of, "What kind of previous leadership experience do you have?"
Risks of the jump:
Learning new skills and the failures that come as one develops the skill. Dennis Stevenson on ITToolbox.com has in his blog examples of this under the heading of the 4 P's.
That the responsibility shfit may be too great and there are sleepless nights as the worrying goes up a notch now that your job is on the line.
Anyone can try to go back, but they usually end up in a different position as the management experience may be a plus for some positions I'd think.
get and read Behind Closed Doors it is a book specifically targeted at people making the transition to management - its quick and easy to read and it pretty much describes how you will be spending your time - if what it describes is what you want to do then it's time to think about making the leap.
One thing that you could do as a developer is to make a list of things that you think your current manager does well, and what things he/she could do better. From this list you could ask yourself what you can do to be a better manager then your current manager.
By the way, I am just merely a developer, never been a manager. But as a developer I respect managers that know what it takes to develop quality software and has solid development experience (and not just experience using IT systems and has played around with access VBA)
Also, if you wish to become a manager prepare to do less development, you will have to choose between managing people or staying a developer and writing code (please don't try to do both at the same time!)
Tavis,
I would tell you that going to a manager of programmers is generally 2 steps beyond being a developer yourself.
Being a developer falls into the category I call "Product Centric". That is, it relates to creating a product, understanding the product quality factors, pursuing the elements of excellence in creating product.
The next level that comes is "Process Centric". Typically I think of a project manager in this role. It stands (generally) on the shoulders of a set of Product Centric experiences. But it is primarily focused on how to organize people and tasks to accomplish a set goal. It's easy to organize in familiar circumstances. But this goes into how to organize when you don't know the outcome and how to structure in the face of ambiguity. It's a very different skill set than being a developer.
Thirdly is Manager. This is a People Centric job. Ask any manager, and they will tell you they spend a lot of time dealing with the people and related issues. The fundamental questions center around "how do I sufficiently motivate the right people to do the right process and thereby produce the right product?" In this capacity you have to look at elements of product and process - but the real work is done at the level of people.
JB King referenced my blog which discusses the 4 Ps. I would recommend the following post in specific to outline the career progression I have discovered: 4 P's and Quantitatve Analysis
To answer your question... When you find yourself drawn more to Process or People as the central focus of your energy, rather than product - you are ready to move. Fundamentally, it's a worldview shift of what is important and requires your attention and effort. If Management remains a "necessary evil" which "doesn't get it" and serves as an impediment, then you should not move.
Dennis Stevenson
As someone who has moved a number of times back and forth between management and development, perhaps I can shed a little insight.
First of all, the two are, really, completely separate disciplines and require a completely different set of skills. Programming requires a high level of attention to detail, a very narrow focus on the specific code for which you're responsible, and a personal drive to be the very best there is. I've never known anyone I considered a top-drawer programmer who did not demonstrate, often in the extreme, all three of these skills.
Management, on the other hand, requires that you take a bigger-picture view. You must be able to look at an overall system, divide it into reasonably bit-sized pieces, decide who has the right skills for each piece (you don't stick a networking server developer on a UI piece, for example), and then follow through as the parts are developed and delivered. You must be able to tell programmers when their code is good enough, and when they must spend the weekend because it's not anywhere close.
If you're going to be a manager, you'll need to answer the following questions positively:
In short, management is about taking care of your people. For some this is simply a matter of pointing them in the right direction and making sure that they have the resources they need. For others this means making sure they have training, books, and people they can use as resources or mentors. In some cases it means developing and implementing a personal improvement plan.
People think that managers just sit and grab glory. Not true. Good managers are always fighting for their people. A good manager is promoting their good people and doing their best to shore up those less capable. Are you prepared to take these steps?
Can you go back? Absolutely. I've done it at least 4 times. I've just recently moved back into an IC role from a management one. The argument that programming skills erode is crap. Good programming is a discipline. You may have to train up in a new language of set of tools, but good design, implementation, and debugging skills don't change significantly. I'm still using some of the tricks I learned 30 years ago when I was coding with punch cards, and I'm using some I learned yesterday.
Your skills are yours. Maintaining them is your responsibility. Letting them "atrophy" is a decision you make and for which you must take responsibility.
How do you know when to make the move from a programmer into a manager of programmers / projects?
Managing is like programming in the sense you do need skills and/or techniques to do it right.
There are bad managers as there are bad programmers.
As well as in programming having a mentor is invaluable. Start managing a small team ( 2-3 coworkers ) while still coding. Get feed back from your manager, and you'll learn a couple of thing in the process.
The same as in programming, you need to learn the basics, and learn them well, and put them in practice in a small controlled scenario.
If you liked the experience and you didn't really miss the compiler, ask your manager or his boss to let you manage something bigger, and so on.
What are some risks to make the jump to manager and can you go back?
Like in programming you may:
You can jump back of course, and this time you won't think your manager job's is easy.