Slashdot Mirror
Moving From Tech Into Management?
Mirk asks: "After 10 years of a software career built on the rock-solid foundation of doing technical work only, I can feel the hot breath of encroaching middle age on the back of my neck, bringing with it the inevitable slide into management. I'm about to do something I used to think I'd never do, and move from a purely technical job into one with a management component. I'll be responsible for leading a team of about four techies, giving perhaps 20% of my time to the management side of things. The problem is, having strenuously resisted all moves in a management direction up until now, I'm going to have to plough straight in without the benefit of any accumulated experience." So what happens when the spectre of management rears its head and you are up to the challenge as opposed to resisting it?
"Obviously I want to do this without being assimilated into the suit-wearing world. I'd like to ask if anyone can recommend any resources for someone in my position? Books would be favourite, I guess, but also Web sites, training courses - anything that can help me convert painlessly from a pure techie into some sort of mutant tech/management hybrid."
The real problem with The 7 Habits (and the reason I'm posting this anonymously, since I'm certain this will be moderated down by somebody who started but didn't finish the book) is that so many of our managers have read it without really understanding it. A lot of the industry bullshit (in fact, a lot of general managerial bullshit) comes out of failing to understand the deeper concepts Covey's going for (the Character Ethic, and the unity of principle and action) and just going for the quick fix stuff. There are a lot of techniques in the book that are in common use but won't really help unless there's an underlying principle to back the technique. And the nice thing about the book (if you can translate the horrible writing) is that it really makes the case for each of those techniques that are necessary but are so often misused that they become maligned by the industry.
An example. Delegation. Delegation is such a buzzword and such a Dilbert-ified concept that it's difficult to realize just how important it is. Covey talks about two different types of delegation (there's a third that he misses). He talks about what he calls "stewardship" delegation versus "method" delegation. We've all seen method delegation in micromanagers, who tell you it's your problem and then want to see every step and make sure they agree with it. Covey's idea of stewardship delegation is to establish a verbal (it can be written) contract on the basics of how it's going to be done, when it's going to be done, who can help you, and a couple other things, and then let the person who is now in charge of the project be the one to do it and to evaluate its success (with of course the manager working with them on the evaluation, but still). It sounds silly but it's so so so important to a good manager.
Please please, moderators, unless you've read the entire thing a couple of times, don't moderate this down because of the awful writing (buzzword bingo) of Covey's book. It really is the best (the only) book that actually covers what it is to be a good manager or leader.
J
This doesn't mean that the skills cannot be learned. If you're interested in management, watch your own managers closely. Look at the good ones, and the bad ones. See what techniques the good ones use for organizing projects, managing difficult people, managing non-difficult people, etc. Then expect there to be a lengthy learning curve as you move upward from team leader to project architect to product manager. For most techies, it takes several years to become a good manager, because it takes that long to be able to accustom yourself to a job that is chaotic, disorderly, and the utter antithesis of everything that you've done previously. It takes that long to come up with effective strategies for dealing with management issues such as effectively marshalling the available resources to put people to work where they are most effective, effectively lobby upper management for the resources you need in order to attain the goals you want, interact with marketing to find out what features the product needs, with sales so that they know what product is coming down the pike and how they will have to sell this product, with IT to get computers for the guys, etc... it's not an easy job, and I'm somewhat wary of moving in that direction myself, but if you know what you're getting into and have adequately prepared yourself, it can be a load of fun.
-E
Send mail here if you want to reach me.
Only if you're a bad manager, a breed that is all too common. A good manager is worth 10 average programmers, because without a good manager, large projects are simply impossible.
BTW, I am assuming that by manager, you mean hands-on project/engagement manager, who is probably also/formerly a senior engineer and system architect, as opposed to someone who has been a manager their entire careers without going through the line-of-business ranks first.
There are generic skills that apply across the management of all disciplines or businesses, but these are only a foundation - a good manager knows where his team (or department) is going, and how to get there, and how to utilize the available resources (people, money, equipment) to do so in the most efficient manner.
After three years of merely Coding Cool Stuff, I've also had to make the transition to management. The first project that I lead was horible. I mean it went well, but instead of coding (and I was promised only 20% management -- but it was more like 95%) you spend all your time
1) Talking to your managers and other stakeholders of the project. Because they did not give you what they promised.
2) CYA: Cover Your Ass. Since you didn't get what you needed, you better make sure that everyone knows that you're not holding things up, but someone else is. Otherwise it means trouble later on.
3) Trying to figure out what The Right Thing to do is. You can do what your manager tells you, but if he doesn't have a clue what he's talking about, then you (if you're good) have to figure out a way to both please him AND make the project something useful for the client/stakeholders.
4) And luckily, if you're merely a squad leader, you get to deal with your team. Which is wonderful: real techies like you think you are. You can direct them, and help them solve problems. The key here is Delegate. You won't have time to dive into The Good Stuff yourself. But you'll have to TRUST your team members, let them do it and check up on them once in a while. I you have a relaxed attitude and are able to teach them your Wisdom, they'll love you.
I've found my interest (at work) shifting towards Things That Stay. Programming languages and tools tend to evolve, but things like Extreme Programming, Unified Process and UML are/will be around much longer. So I'm trying to get experience in those areas. Which actually is fun. And being a manager you get to say (more or less) how things will be done, so you can actually try out stuff.
Here's some books:
Booch, Jacobson, Rumbaugh: The Unfied Software Development Process
Kent Beck: Extreme Programming explained
Betrand Meyer: OO Software construction
Craig Larman: Applying UML and Patterns
There's many more, but these are a good start. They'll tell you all about managing a software project, without the management stuff...
Of course, there is always the itchy fingers when you get home. That's why you need a good PC and internet connection, as some friends. Together you'll lauch a new SourceForge project to stay in touch with the latest technologies. Basically coding like you always did. The tech stuff. The real you.
Go for it!
You are on to something. Where I work, management is one step closer to the door.
Having been involved with the evils of management for some time (one of the reasons I left my last job was that I was spending all my times in meetings rather than tapping at keyboards) I have to admit that it's not all bad. You can get an enormous amount of satisfaction over helping get a project finished --- and anybody who thinks a big project gets done without some sort of overall organisation is just plain wrong.
:-(
:-)
The warning: 20% of your time for managing a team of 4 sounds low. You can easily spend all of your time doing that, especially if you have to deal with the clients/upper-management a great deal. Get a clear description of what your responsibilities are before saying yes, and think long and hard about how long meeting those responsibilities is going to take.
If you *can't* get a description of what your responsibilities are kick up a fuss until you do. If your organisation doesn't know what you should be doing you'll get no gain, and all blame
This all, of course, depends on how good/supportive your organisation is. If you've been managed well, then it's likely that you'll get some decent support. If you've been managed badly --- worry.
My recommended books to help you on your way (or, if you're working for a bad organisation --- your evidence that they're wrong and you're right) would be...
The Mythical Man Month
by Frederick Brooks
- as relevant today as it ever was
Peopleware
by Tom DeMarco, & T. Lister
- I found it a great book for going "look, it's not just me, other people think that you shouldn't [insert something stupid here]"
The Dilbert Principle
by Scott Adams
- because it's *all* true
Hope this helps,
Adrian
I'm sure it'll get more fun.. I get to build out like 50-60kft^2 of user space with a nice server room. Mmmm.. Diesel generators...
Your Working Boy,
In which case, Cliff will be promoted to ever-higher levels of management, until his level of incompetency is reached.
Someone below thinks the Peter Principal was a parody. Alas, he is wrong: while the book is caustically witty, it's also very sincere.
For a good followup, read the Peter Principal. Not only do people rise to their level of incompetency, they tend to build pyramids once there, to protect their sorry ass when their department is put on the chopping block...
--
--
Don't like it? Respond with words, not karma.
The reason I recommend this book is that it gives you a lot of insight to how utterly depraved you may have to be to 'succeed'. The corollary is how depraved some of the people you might run into are.
Companies vary, but there is _always_ some level of political machination going on. The trick is to either be very successful at that game, or to know some techniques to avoid it.
Whether you use the knowledge to steer clear of trouble, or use it to keep your peers biting each others tails (and not your own) is up to you.
If nothing else, you may gain some perspective on _what_ you're all about as a manager, colleague, friend, husband, etc.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
Great book, possibly the best, on what makes software development organizations work: Peopleware by DeMarco and Lister. (Link is to Fatbrain, but everyone carries it.) Possibly the most relevant to your new position: the list of ten things you can do to prevent teams from forming. (There's nothing you can do to make teams form, but lots you can do to prevent them.)
... remember how many choices you really have. --PSRC
Other good reads: Jim Coplien's organization patterns (don't worry about the word "process," Cope doesn't believe that process generates quality), also found in the first PLoP book; DeMarco's The Deadline: A Novel About Project Management ; maybe Jerry Weinberg's The Psychology of Computer Programming ; and (as others have suggested) many books by Steve McConnell.
All these boil down to one thing: You can't do it all. (If you can, you don't need to manage anyone.-) 99.44% of your success will depend on the success of the people who report to you. 99.44% of your job means making sure they're excited, hard working, and pointed in the right direction.
That's how to make this change. Here's why you might consider it.
The best managers (and former managers) I know decided the most important thing about an organization's success was about how the organization worked, not how they as individuals could contribute. They either expressed interest in that, or made an impact without being asked. (The latter is how I got promoted to management in my last job. No one in my group was sure if I was their boss or not. I was happy with the ambiguity. My boss wasn't, so he promoted me.)
You can go home again. When I changed companies (the old company rolled the dice on a new technology and lost), the new position was purely technical, and I'm still there and still happy there. Smart companies will let you "step down" in place, somehow preventing it from being a demotion. Dumb companies aren't worth staying at anyway.
Don't do it unless you really want it. Don't do it unless you can make more of a difference where you're pointed than where you are now. (But don't let fear hold you back.) If your boss says you have no choice
Stupid job ads, weird spam, occasional insight at
While I also heavily recommend reading PeolpleWare, you might want to start with The Deadline: A Novel About Project Management, also written by Tom DeMarco. While Peopleware [1987, 2nd ed. 1999] is a more analytical approach to dealing with humans in the software development process, The Deadline [1997] is a lot of wisdom packed into a novel which makes it a lot of fun to read. Describing several worst case scenarios during the push of Moravia, a fictional former communist country, into the top league of software producing nations, it presents all those problems that arise from the human part of software management in one large context.
[But: Boy, I hate this happy end on the last page, hope he'll never try to write a regular novel - DeMarco is not Herman Melville.]
I find these books especially important because they deal with what seem to be the largest traps for people who grow from tech jobs into management. They come with high expectations, demand they same they demand from themselves from others and try to push the limit even further to prove they can handle this. They fail to see that mainly the manager works for the techies, not the other way around. It's very dangerous to ignore this, because the techies are the people who're going to save your butt when necessary, so you'd better learn to give something back in time. The main aspect here is trust, and I have jet to find another author who gives a deeper understanding of this than DeMarco. Brooks the mythical man-month [1975, 1995] is also excellent, but doesn't focus that much on people. It would be the best book for someone entering software management not from the technical, but the suit site.
memomo: free web based language trainer DE-EN-ES-FR-IT
Well, I once worked at a mission-critical transaction processing software company in tech support, and both of my managers were very good at handling support calls that got escalated to them. Neither of them started out as managers. (Neither of them seemed to be really good at managing itself, as office and customer politics were a large influence in why I left.) I now work for a GIS firm, and my boss is an ex-techie. His name is all over the entire code base, and he is a very competent programmer. So far, he seems to be an extremely effective manager as well. That, or else my new company just doesn't have office politics that touch my job.
Anyway, YMMV. Not all managers are bad. It seems to really depend on what their background was. I have little respect for people who are managers because that's what they majored in in college. In my experience, anyway, that is that major that all the people who couldn't hack something serious take, and it really doesn't teach you anything about managing people that you wouldn't know or easily learn if you had the "knack" for it already.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
I'm in the odd position of working in a department where I'm temporarily "on loan" to a new manager. My original manager is technically excellent - one of the most knowledgable people in his field, and in addition to that, he is extremely dedicated and efficient. He leads by example and expects us to do our best. We do. It's a pleasure to work for him.
The new manager I'm working for is probably a more experienced manager, and is certainly good at organising things, but he lacks the technical knowledge. I don't like working for someone who knows less than I do, and that's possibly the feeling for many of us. Slashdot readers are typically "techies" and proud of it. This is perhaps where the concept of a "suit" comes from - someone who may be good at managing, but doesn't really understand the technology. I have to confess to finding it difficult to give the same level of respect to my new manager.
What I'm trying to get at is if you are a "techie" in charge of other "techies", then as long as your experience is credible, they will enjoy working for you, and will want to work for you. You can build up a very loyal team this way that really pull their weight.
it's about time i read someone else out there is on the same path as i am.
management isn't a curse... really.
and if you're fired, how many managers have you heard were not given at least a "silver" parachute, if not a "golden" one?
now you know why some managers are incompetent -- they're looking to get fired and get paid a bundle in the process.
-m
the books by Niccolo Machiavelli may be found online here: http://digital.library.upenn.edu/webbin/book/searc h?author=Nic colo+Machiavelli+&amode=words&title=&tmode=words
--
-=DaveHowe=-
Management: Manage the project, motivate the team, sort out problems, remove obstacles, speak to customers. Setting standards (0.5).
Design: What should the product do? What approach to building it is most likely to succeed. Which design will yield an elegant system that pleases the customer? Setting standards (0.5)
HR crap: Holidays, pay, endless incoming CVs, "the company line", telling people off for coming in late/improper expenses/playing games.
Actual management is very important but does not take a genius. For most functions of management, a competent professional administrator (a high level secretary) would do better than an engineer. A good administrator manages timelines, large numbers of commitmets, resources, and the like with very high reliability and a certain detachment. The required mindset is very different from the technical person who likes to apply their entire brain power to crack each aspect of the problem in turn.
There are two aspects of management that cannot be done by an administrator. Motivating the team and ensuring high standards. To motivate the team, a manager can use praise, pressure (rarely helps), and persuasion. You can get infinite supplies of pressure from upper management if you ask, but it is almost never wise to apply it to your staff. Your supply of praise and persuasion comes from the respect that your staff have for you. A great engineer or a great manager will command respect and so can use praise and persuasion. An acknowledged administrator cannot, which leaves only pressure, and this is why so much management sucks. As for ensuring high standards, the management aspect of this is only half the picture. It is when manager says "the product has to be better" or "we must do better than this", and so the same principles as for motivation apply.
The second task, design, is by far the most important aspect in influencing the success of projects that are mainly technology bounded. It includes specifying the product from the point of view of the customer, if that is not already done by upper management. Then it involves guessing the right path. This is the black art, the magic trick, where a good designer can make the thing fly or (more likely) a bad one can take it down the drain.
Software engineering is not yet at a stage where projects can be run predictably in a well-proven way. Until then, a correctly designed project sails to completion and a poorly thought out project never gets there. Since this is extremely important and there is no simple formula, most companies, very wisely, promote their most experienced and capable technical people (though not necessarily the cleverest coders) into management, in the hope that they can guide their projects to success. It is not always understood that they guide them through class diagrams, refactoring, and design patterns, not Gannt charts and top-10 risk lists.
A third aspect of design is implementing high standards directly, by specific design choices. Whereas the non-technical manager can say "we must have fewer bugs", the designer can say "we must build the network interface like this so that we have fewer bugs", and actually sell this to the team. This is extremely difficult to do because, again, the recommendations will only be followed to the extent that the team respects the designer.
As for the HR (Human Resources) stuff, it sucks. This is not so much because it's boring (it is, except for hiring new staff) but because it is adversarial. A manager is an agent of the Company and must side with the Company when its interests cross those of the staff. A lucky and capable manager can, at best, ensure that this happens very rarely. An unlucky one will be seen (correctly) to have fallen to the dark side.
Now, in an ideal world, the most capable people in the institution would be designers. They would work together with an accomplished administrator/leader no senior than themselves. As far as possible, HR issues would be avoided or handled by off-team staff. If you are very lucky, you might work in a shop like that. More likely you would have these problems:
There is only a manager, who is basically an administrator, and no designer. This is the common PHB case and few projects survive it.
The designer has to do management because the manager can't assess or estimate the work and won't ask.
The designer fails to do design because he's not very good or does not command enough respect.
The designer and/or the manager are totally bogged down in HR stuff. This is not so bad if you have very good developers, who unofficially act as designers.
A technical person who might make a good designer is lumped with all three management roles and so does poorly.
So, then: My advice to the original poster is see what exactly out of the things that managers do you want to do and feel you can do. Go to your higer management and explain that. Ask them to find other people well suited for the remaining roles. Both you and your company will be a lot happier that way.
Books can only do so much. "Peopleware" was an excellent suggestion. The real skills, however, come from experience. I suggest you look for someone in the organization or in a related organization who's willing to do some mentoring. Having an experienced soundingboard is worth more than a few books.
My own cardinal rules:
(1) The problem is not making a mistake, it's how you handle the mistakes you make.
(2) At some basic level, management is getting other people to do things. Generally, the other people know how to do it better than you.
(3) Always hire people who are smarter than you are. Your goal is to encourage creativity and brilliance, not protect your perogatives.
(4) Techies work best when encouraged (as opposed to being directed.) Play is important.
(5) Play is not the same thing as adolescent behavior.
Best of luck.
"When I grow up, I'll be stable."
The Prince by Niccolo Machiavelli
Having read them both, I find The Discourses to be far more educational -- it is Machiavelli's longer work that the Prince was stripped from as a kiss-ass gesture to the new patriarch of the family that ruled his home province; The Discourses is actually a comparitive study of a variety of management techniques, explaining when force works and when mere backstabbing will do.
I've seen this more than once. Some guy thinks he can both be a manager and an engineer, and gets overwhelmed. ANd the whole team suffers.
At least don't count on spending any time on the tech work. Remember you're a rookie manager, so everything will be slow for you, and you'll make many mistakes. And your managment work must have absolute priority, since if that fails, you're holding up the entire team.
I guess that if you've done this for a few months, and start to get a feel for the managment part, you can be more confident about spending time doing other stuff. But don't count on it...
Six months ago, I became the manager of a small IT department (5 members plus myself) of a manufacturer. Doing so pretty directly cut down on what time I had to do development work, and added a lot of dealing with people to my day.
What has saved me from becoming a paper-shuffling, phone-call-returning drone is a couple things:
Your work habits will have to change, but that doesn't mean you'll spend all day in meetings or on the phone. For myself, I found that taking care of paperwork as it came up, handling phone calls immediately, and being cagey about requests for meetings means that I generally have at least a couple hours a day to code. You can't shut yourself off from the company for any length of time, but if you're well-organized about all the details that come your way, it's not too hard to find time for coding, and I go home between five and six every day.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
> Surround yourself with good people (hire continuously), then trust them to solve problems as they see fit.
:)
:)
I agree, that's certainly one of the tricks of being an effective manager:
"Let people do their job !"
of course which depends on:
"Hire competent people !"
Weekly, or Bi-monthly meetings with the programmers are also usefull, to make sure the whole team is "heading the same way" so to speak. You're the "captain" of the ship, you don't tell the engineer how to run the engines, but you need to check in with all the engineers to make sure everything is running smoothly in case you need to change heading via orders from HQ (aka the management's boss)
Try to schedule programmers to do Code Reviews of each other's code. Pair them up, so ego's aren't bruised. That way they can learn from each other. It might take a while to get the hang of it, but it is definately worth it. (Leveraging an open source benefit here
Score: 0 (Obvious
Cheers
What the Hell! Try it, it's new and new is good. Sometimes. And remember, if you were a good technician up till now, you will still be a good technician later, so if you decide that you really don't have the gift for management and you don't like your new job at all any more, you still have that successful tech career to fall back on. Keep in mind that hi-tech types are, at least these days, in consistent high demand. As far as the prestige angle goes ("I can't step down from management to production, everyone will think I'm sinking!") all I can reply is, "Why should you care more about what other people think than about how satisfied you are with your life?"
The worst mistake you could make, then, in that regard, is if your company gives you a big raise, and you decide to go spend it all right away - i.e. you rush out and buy a new expensive house, car, etc. that you couldn't afford to keep up on your old salary. Do that and you'll find you have painted yourself into a corner, where you can't go back to your old position. So if you do get that big raise, my suggestion would be, at least for the first couple of years, to keep your living expenses where they are at now and invest the difference into savings.
Good luck!
Yours WDK - WKiernan@concentric.net
Basically, you just spend your time programming, but put your efforts into writing and running acceptance tests, starting from the use cases. You are a programmer so you know what is needed to make the tests easy to run for other programmers.
You would be amazed at how quickly the programming team coheres under a design-to-test managment strategy.
Seastead this.
To be Obi-Wan and train some young jedi knights one can assume a mentor role instead of a management role. It doesn't help much with the paycheck but can be a lot more satisfying.
1) Catch them doing something well, and tell them.
2) Be Nice.
3) Don't let your personal feelings cloud your judgement.
4) Be nice.
5) Keep things clear and concise for your group.
6) Be nice.
7) When they whine (and they will whine), smile, listen, don't look at your watch.
8) Be nice.
9) Get the whole team drunk every 2 months.
10) Above all, . . be nice.
Your problem is described very well in the book "The Peter Principle" Basically, it states that, in a hierarchy, people tend to rise to their level of incompetence. It describes why this happens, and what you can do to keep it from happening to YOU. And if I could find my copy, I'd tell you what to do, but I can't so I'll have to let someone else do that :P
NipokNek
Why choose white shoes?
Having recently made (after 10 years) the switch myself, and after struggling like hell with the new role, I hope this helps.
An excellent former manager summed it up for me: "the key to being a great manager is not trying to do more, please more, coach more; work on achieving a better balance.
You know what? You're starting off on a good foot, having had 10 years technical experience. Your first tendancy (as evidenced by your assumption that you're actually going to devote only 20% of your time to management :) is to do what you know best - be technical. You will soon find, however, that your management duties will completely consume your time, leaving weekends for what you still consider your "real" work. Believe me, you'll suffer.
My advice? Surround yourself with good people (hire continuously), then trust them to solve problems as they see fit. Learn what would make your manager successful, and contribute to it. Communication (charts, reports, whatever) is not a distraction to your job - it's (part of) the point of it. Realize sooner rather than later that you will never, ever again finish your work, and learn to go home at 6 and be comfortable with that. Focus on the objectives, sure, but always take the time to build your people. They'll make you proud if you let them.
Hopefully you will come to realize how to do a good job in your new role, and even more importantly, learn to recognize when you've done a good job (nobody's gonna pat you on the back).
And continue to read Slashdot. A better balance - remember?
Anybody can pull rank, but when somebody that can pull rank never does it, and looks at your code and changes just one little thing and the whole piece of junk just turns into a masterpiece, that's when you know why your boss is your boss. He might not be able to pull all-nighters, but he *knows* the Force inside out...
The fact that he is hacking right now downstairs while I am wasting my time on /. also helps to build his reputation. ;-)
adapt
I'm the MIS Director of an Internet firm. We went through a LOT of people in the department before I a) figured out how to find good people and b) learned how to manage them.
The books helped me the most:
How to Work for a Jerk: Your Success Is the Best Revenge teaches the different ways you can become a lousy manager and how to avoid them, while teaching you "suit" methods of dealing with those who outrank you. It also clues you in to the dirty tricks and false fronts those under you will use.
The One Minute Manager essentially tells you hot to avoid becoming a micromanager. It outlines the best practices for letting your staff be creative and do fulfilling work while keeping control of the situation.
Although published by the Borg. and obviously containing advice their OS division does not follow, the Software Project Survival Guide outlines how to run a software development project. It outlines the kinds of methods used by NASA. Propper up front planning, avoiding feature creep and a host of other plans to ensure that your programmers don't pull the heroic all night programming hauls but instead go home to play Quake and hunt for UnixChix after 5:00 comes around, while finishing the project on time and on budget with few bugs.
Last but not least is, believe it or not, Managing for Dummies . A lot of it falls under the "Well Duh" heading but if you have NO management experience it's a decent primer, but not as valuable as the first two books I mentioned.Matthew Miller,
"Live Free or Die." Don't like it? Then keep out of the USA
You are complaining about managers not understanding the concepts of how things work in the real world, which is logical when everybody that does know how things work resist moving into management.
If once in a while a coder with real experience moves into management, all this can be different! So it's not about becoming one of them, let management become part of us!
Very sad to hear. Coders should always look out for new challenges. Managment is going to make you so old, fat and lazy and you'll start thinking that you don't need to learn as much anymore. In another 10 years you may as well be just another bungler manager that doesn't quite know what's going on (flame ?).
It's the begin of the end !
Good luck !
This is nowhere more apparent than in a development group where you're likely to find that the lowest guy on the rung (as far as the organisation chart is concerned) knows more about solving the problems than you do. Under such circumstances, it's much more difficult to adopt the old-school "Me management-you follow orders" approach.
While you don't have to prove that you are the top dog or that you actually know more than your team members do, there are demands on your abilities. The foremost thing is on your ability to attract solid members, being able to coach them and bring out the best in them. All these depend more on leadership than management skills.
To be honest, I'm not even convinced that if you are starting out with a highly motivated and intellengent group of people - that managing them is what's necessary in the first place. In fact, this is probably the way to demotivate them.
However, a good coach knows how to keep everyone focused on what's important - instead of what's urgent. What I find is that if you really want to learn to be good at managing a team - that there is much to learn in the area of sports coaching and in team sports.
During the game, the coach is not the one on the floor. He is not even in control of the outcome or how the game gets played. This is one of the most difficult lessons to learn - letting go of control and letting your team players take charge of the game.
You will find that there will be considerable pressure from the top to force you into behaviour that proves to them that you are 'managing' when in fact you are getting in the way. One thing you will find is that your very best people just need to know from you where/what needs to be done - then they will demand that you get out of the way so that they can do what they do best.
As a manager, what they do demand is that you know enough about their job (and you should, since you were formerly a technical guy) to mobilise the right resources for them, while keeping higher levels of management away so that they can get their job done.
Needless to say - you will now measure your performance by how well they do, instead of how well you do as an individual. If you do these well - you will know that you are doing a good job when (1) people assume you don't do anything and (2) all the best people in the organisation want to work under you instead.
The best team leaders are also people who are always looking out for the best talent. This includes potential or undiscovered talent. I've had the joy and pleasure of turning coders who were slaving away unrecognised in some other development group and they've turned into team leaders themselves within the year. The way I found them was to first start building a small killer team (from scratch, the team had no prior experience) and the person was then attracted to our team (he started spending more time hanging around our work area than at his own desk!).
I'll end off by saying that the best manager (boss and also business partner) that I've had the pleasure of working with/for is someone who's a coach by inclination, who's taken lots of programming classes, but can't write a single line of code to save his life - but is someone that most developers I know gravitate to.
The key is that he respects the opinion of others, has a wonderful ability to build and assemble a team around him and has a true appreciation (going beyond most developers) of technology and has great conflict resolution skills. People who know him want to get on the team because the team knows what it's like to win and to continue enjoying winning.
Good people don't need to be managed, they need a clear vision and strong leadership.
Call me an elitist, but should I really have to deal with someone's neurotic need to tell me every detail about what they've done on the job since the last time I saw them?
I mean, sure if you are friends, you take a certain amount of this type of stuff, but if you are at work, with a limited amount of time to do what's to be done, then get home and lead your _life_, is there really time for this?
I always get annoyed with people at work who buttonhole me into needless conversations, and I'm not even their manager. I just think it's inefficient, and I would rather be doing something else.
It sounds like you are more of a therapist than a manager. And that's fine if that's what you want to do, but what about the coding that needs to get done, and the deadlines? I am not at work to be an altruist, frankly. I am there to kick ass and glorify myself, while being adequately compensated.
Maybe that's the difference between being a "people person" and being a curmudgeonly technician. I don't know.
I think the term "productive meeting" is heading towards the golden shores of Oxymorona.
come for the naked robots, stay for the zombies
Comment removed based on user account deletion
This has never been true, if the employees are motivated and LED by someone they trust.
Leadership is a very different skill from any other, but one of the components of leadership is a solid grasp of the "technical details". For example, I never made claims about my coding ability, but you can be damn sure that I made sure that I could at least read and understand the code being written.
An easy way to start being a leader is to simply make a list of all the "bad things" about managers, and avoid doing them, for example:
- Don't appear to be arbritrary - explain your rationale when announcing a decision.
- Don't be petty - make sure that the "little things" run smoothly, like office supplies and
coke machine refills.
- Stick to schedules and definitions. Defend
your people by defending their reality.
- Motivate your people, don't patronize them.
- Allow your staff to present sucess to upper
management on your behalf - you do not need to
take the credit, and your team's sucess IS your
success.
- When you do out of town, have one of your
reports "be you", and rotate the "hot seat"
duty amongst all direct reports. Encourage them
to make decisions when you are gone, and then
make them LIVE WITH those decisions. This will
allow them to see how difficult YOUR task is.
Of course, none of this makes you an actual leader. A leader must have the ability to CHOOSE a direction or a goal from several options, and the power to provide his people with the tools, time, and support required to attain the goal.Therefore, leadership starts at the top, not at the bottom or the middle, which explains why so many managers jump ship so often - they are looking for leadership themselves.
Science is the art of infallibility, perpetrated upon non-scientists
I've been in the technical workforce for over 15 years and one of the things I've learned: There are two bad things in the industry: Engineers and Managers. Why are they bad? Because they have power but no brains. They have knowledge but absolutely no common sense. They expect things done their way, but have no concept of the real world way of getting it done.
Ack, I can go on for days....
--
Vote Homer Simpson for President!
Technical people are mainly about reality, and getting things to work, 'People people' are mainly about appearances; making things look good as opposed to making things be good.
A good manager from the perspective of the members of his technical team makes sure that the team members have the resources to do what they need to do - while protecting them from outside interference.
A good manager from the perspective of upper management is something very different. Upper management types - are generally clueless about anything technical, and regard technical people about the same way you would think of a draft horse; something that can do a lot of hard work they can't do - but which is interchangeable with any other draft horse. To upper management, the job of lower management is to whip those lazy draft horses into shape.
To the 'people people' types who populate management ranks you are making the transition from being a drudge into being a 'person'. What upper management wants is good looking reports - solid progress predictions - somebody who dresses 'professionally' and has the air about them of being a real 'mover'; someone on the way up.
A little thought tells you that most people can see that the higher ups sign the pay checks - so most managers concentrate on looking good to their bosses - rather than on getting the job done. This is why there are so many PHB's in the world; while they look like idiots to the people they manage, they look great to the people above them.
You have to decide what kind of manager you want to be; somebody who really gets the job done, and is therefore regarded by upper management as an 'asset' rather than a 'person' or do you want to be someone who becomes a 'player' to upper management? If you are an 'asset' you will be left where you are - in lower management where you have proved yourself valuable. Your actual contributions to the company will be denigrated by your corporate competitors; the 'people people' at your level will hate you for actually getting things done - and will do everything they can to make you look bad to upper management. 'People people' almost always hate technical people; they know that technical people can actually do what 'people people' look like they can do.
While it is possible to do both jobs - you have to become 'two-faced' to do it; you have to look one way to your team members - and another to upper management. If you decide to do that you now have a problem: which face do you want to look at in your mirror?
Where do you want to go - up the corporate ladder or stay pretty much where you are? Before you make your choice consider this: 'people - people' are all the ones who wouldn't talk to you in high school - they married the cheerleaders and other girls who didn't even know you existed; what makes you think those kind of people are going to accept you as one of their own now?
This is HORRIBLE reading for a manager, not because you won't get ahead by reading it, but because it's a compilation of everything that's wrong about the world of business.
The prince is encouraged to leave aside questions of morality and focus on maximizing the benefit to his domain. This logic is what justifies the total void of morality in business today. This book was required reading in the business curriculum at my college. Ick.
I guess I'm not saying don't read it, but I am saying think about how it applies, what your place in society is, and how a thousand copmlicit managers who are just "doing their job" can add up to something evil on a societal level. Think officers who were just "doing their job" or "following orders".
microsoftword.mp3 - it doesn't care that they're not words...
I once moved into a management role but got out of it. Dealing with the psychological problems of a bunch of whiny computer programmers wasn't for me. It's probably not a good omen when you want to murder your own staff. "She got carpet in her office. Why can't I have carpet in my office?" Jesus, the very memory is gonna start the night sweats again ...
"If I have seen further than other men, it is by stepping on their glasses." - Michael Swaine
I was in the same situation just recently, and to my surpise and joy, there are several really, really good books out there on what to do and what not to do. The classic mistake is, since we've been managing blackbox interchangeable components for so long -- in our code -- to go and treat our next subject of management -- people -- as blackbox interchangeable components, too. This is understandable from a human perspective, but very, very unfortunate. People don't work that way.
If you want some good pointers on where to start, try the book PeopleWare, considered the bible of tearing industry-style management to shreds and really understanding what a developer community needs. Better yet, it's backed by hard data, so you can justify it to your boss in turn.
When I read that book, it was an enlightening experience. Fact is, I think every manager should read it. Not just once, but once per year.
Good luck!
It's not always the best place in the world to be, but it's not the death penalty you make it out to be either. A team leader's job is every bit as exciting as a techie's job. Figuring out what everybody needs to be working on is every bit as exciting as figuring out what sorting algorithm you need to use for a particular set of data, it's just a different set of excitement, that's all.
-E
Send mail here if you want to reach me.
Mikeb's piece is excellent, but notice his first sentence describing what happened before he gained his experience:
I found myself having to switch from development into management about 15 years ago.
*HAVING* to switch? The circumstances pressured him into doing this before he was experienced enough to know that it was going to be the most unpleasant experience of his professional life -- with the benefit of hindsight he might never have taken that step. (Whether Mikeb would have or not is not important, what's important is his observation about what such a transition entails.)
The moral here is pretty damn obvious. If you're a good tech person, it's not just a waste of your skills and often a waste of your life to go into management, it's also a pretty monumental professional downgrade. Unless you enjoy the slumming experience of being crap at something, just don't do it.
If you're a good tech in computing or Internet technologies, you can easily earn 3-5 times as much as many a good manager by becoming a freelance contractor, and it's an extremely pleasurable experience too. So there's no financial reason to fall into management either.
And if you would rather stay with your present company because of friends or other fringe benefits, then if they value your contribution they'll let you stay technical and perform only the minimalist "management" role of an advisor. (If the company doesn't value you enough to be flexible on this then it doesn't deserve your loyalty anyway.)
You definitely don't "HAVE" to go into management. If you were a good tech in the first place, in the vast majority of cases you will regret doing so. Take the advice of many an experienced voice here on Slashdot and choose an alternative path.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
i got pushed into managing others about ten years ago without my knowledge... my boss at the time had an office manager who was neither good at what she did, nor managed the people who reported to her well. along with another technically adept fellow, we kept finding ourselves troubleshooting problems the other staff was unable to resolve and fixing other problems that were obscure and unique. what did the office manager do? she kept referring problems to us, the two fixit men, cause she didn't have to deal with things she couldn't figure out.
this didn't go entirely un-noticed by either our fellow workers, our owner/boss, or the clientel. the request for our attention to problem and crisis resolution became our full time job, and our co-workers started reporting to the two of us, perhaps out of respect for management that rose from the ranks. at first we were'nt very good at managing others, in fact i sucked, but never backing away from a challenging situation, a few things i learned in the last ten years were:
1) decision making is like a muscle. the more you excersize it, the stronger and more agile this skill becomes. at first you're clumsy, but over time, eventually you'll find yourself making more 'of the right' decisions quicker and easier and often with positive outcomes.
2) treat others nicely, the way you would like to be treated or 'do onto others as you would have other do unto you' it truely makes a difference.
3) praise in public, scold in private. acknowledgement of a job well done has no substitute, conversely, no need to make a bad situation worse by humiliating someone in front of their peers.
4) people are like systems, you'll find yourself maintaining 20% of the staff/system 80% of the time. just don't forget the 80% that doesn't 'seem' to need the same amount of attention. you need to maintain a PM schedule for people as well.
5) resolve situations with problem employees swiftly, with fairness. something as mundane as excessive tardyiness can affect an entire department like wildfire.
everything has some corillary with everything else. if you take a look at a problem at a macro level, you'll find that problems at a micro level have similar symptoms and solutions and vice versa. same with management. the problems/tasks you faced as a skilled technical worker have very similar solutions when managing animate objects like people, but on a macro scale. apply you experience and you'll see things in a familiar light.
three can keep a secret, if two are dead - benjamin franklin
I did an internship as a programmer after graduating from college earlier this year, and the experience has convinced me that if I had to work in a company, I would like to take on hybrid technical/management roles, instead of pure technical roles.
Why? The role and domain of influence of an individual programmer is pretty limited - the feeling is too much like a cog in a giant machine. You work on tasks assigned by the management, and unlike independent research work, there's little room for individual creativity. And the final outcome depends little on your individual contribution. Extremely boring and very dismal.
I think there should be a law that if you're going to be a software engineering manager (actually, a software engineering anything), you must read Rapid Development . It is a distillation of all of the significant research in software engineering done up to the date of publication (a few years ago).
Did you know that the productivity between the best teams and the worst teams varies by a factor of at least 2.6? Do you know how to make sure your team is up at that 2.6 end?
Unfortunately, there is little you can do to get your team up to the 2.6 end. However, there's lots of stuff you can do to ensure they're down at the 1.0 end. Bad managers (which seem to be the majority) don't even realize they're destroying their team's productivity on a daily basis. This book can help you avoid dooming your team to the 1.0 end of the spectrum.
As a side note, I'm in the exact same stage of my career as you. However, I'm in a highly technical team, where the norm is to be on the "techical ladder". So I'm not feeling any pressure to jump into management.
But I have recently come to realize that I'm getting passed over in promotions relative to my peers who have chosen the management ladder. And this is in a company that prides itself in having a technical ladder. I know many companies don't even have that as an option.
Consequently, I'm contemplating whether or not it makes sense for me to try mangagement. That's where the rewards seem to be, and I think I could make a difference in getting my team (and perhaps someday, the entire organization) up to that 2.6 level of productivity.
That's a demon I'm still wrestling with (one of several).
It sounds like you have an excellent bed of experience for your leadership role. Your more junior colleagues will look to you for guidance, technical experience and more. Diving headlong into management activities is not necessarily a bad thing, and although it may sound cliched, you'll learn from your mistakes very quickly.
If you are working in a project-oriented environment, I would suggest that you also look at professional qualifications e.g. Prince II project management. You will find that your development experience will put you ahead of other managers who are learning how to project manage but haven't actually been working at the "coal face".
Being a project manager can be very rewarding - you are steering a disparate group of people towards solving problems in creative ways, and bringing about change in your organisation.
Most of the time it's all about keeping the bigger picture in mind. Assessing risks, understanding the impacts of change. So often the reason why managers don't seem to know what's going on is that they are very busy keeping their eye on 100 different issues at once.
Most of all, it'll be a people role. If are aren't a people person, you'll find this difficult. But like any situation, you'll adapt and change and have every chance to make a success of it.
I've mixed both technical and management roles over the last few years and it's helped me understand both sides of the fence. I'm sure I have plenty more to learn.
Good luck with it!
Rob.
I recently found myself undergoing a similar transition, which has been tough. Throughout my career I had regarded "management" as a dirty word, and only relatively recently came to terms with the fact that there was a very strong chance that I would end up having to take this direction myself.
The first thing that alarmed me was that I was told (by one of the few very good managers I have encountered) that I should expect to spend not more than 20% of my time programming.
I am still on a very steep learning curve, but I think there are a number of things you can do to make this transition well.
Firstly, learn from your own experiences in the trenches. Think long and hard about the ways in which you may feel you have been mis-managed, and draw on that to ensure that you don't make the same mistakes.
Also, take pride in the fact that you really understand the nature of what you are managaing - something that I still feel very few managers in the industry do.
And lastly, develop procedures (if they don't exist already) which allow you to keep track of what is actually going on. This is probably the single toughest thing involved in managing. There are books out there which can suggest good ways of doing this, but better still is to find a mentor. If you can find a talented manager, draw on their knowledge. They've already worked out these skills, so there is no sense in reinventing the wheel.
My definition of management (and I've been doing it for over a decade now) is taking personal responsibility for the overall success of the project, rather than just for your own contribution to it.
There are many books that can help, and many, many more that do little except enrich their publishing companies. (See anything by Ken Blanchard, especially things on Situational Leadership.)
Remember these rules for starters and you'll be OK:
Some days, you'll beg to be just a "regular" engineer again. All managers do.
But remember that when everything works out, it can be one of the most rewarding jobs out there. In management, you can make more good software happen than you can alone. And all of the sacrifices will make software releases that much more fulfilling.
There may be a lot of other aspects to software development, but for me the most important one is creative and determined reasoning through a maze of obstacles to finally reach your goal: beautiful code.
...
...
Coding is much more like an art than a science; you definitely need to be talented and you will never learn it out of a book. Obtaining a degree in it may help a bit, but that still doesn't mean that you have the holy fire burning inside of you.
The relationship between a code and his code is not much unlike the one between a singer and his song, a poet and his poem, a sculptor and his statue
Why do they sing, write, compose, sculpt? Because they can't live without it. The same observation holds true for real, good coders. Writing code is the one thing we cannot live without.
Offering a management position to a developer, is like asking Mick Jagger to become studio manager at Universal. He'll tell you to f*ck off
the few posts so far have been rather negative; i.e. 'don't do it.' I would take advantage of this situation.. don't look at it as 20% of your time going to heartburn, but passing down your accumulated experience.. while boosting efficiency is probably more or less your main job description, you can still pass on tips and tricks about how to do the job in general...
--An outsiders opinion
But even in the best-organized company, your expectation that you will only spend 20% of your time managing is totally unrealistic. This never happens. If you're lucky, you *may* spend close to 50% of your time coding in between taking care of your crew, and as far as I'm concerned, taking care of your crew is a manager's primary responsibility in any field of endeavor from fast food to programming.
I am also a big believer in hands-on leadership; if you spend time working alongside your people you will always have a better grasp of what they are doing than if you are separated from them.
But you will *not* do all that much coding once you start taking responsibility for others' work.
How much have you seen me post on Slashdot lately? And how much do I really write on NewsForge, our latest site? It's frustrating, because writing is the *fun* part of my job.
But there is also a great deal of satisfaction to be found in helping others do their jobs well. In my case, I work with great people who are also my friends -- the ones you see on Slashdot, NewsForge, Linux.com, and the rest of the OSDN sites -- and what keeps me going on the detail-bogged days is knowing that if I can keep upper-upper management from screwing with Taco, Hemos, Emmett, timothy, and the rest of the gang, I am helping to get more done than if I was simply busting my own ass and not worrying about anything else. Plus, they know what I do and appreciate it. This is the big reward of being a *competent* manager -- kudos from coworkers whose lives you make easier by taking shit they'd otherwise be forced to take themselves. Any extra money you get is nothing compared to the respect and gratitude of the people you work with every day.
I view front-line management as a necessary task, one that *somebody* has to do, and if those of us who have some competence at [coding; writing; art; design; auto repair; you name it] don't take it on, we and all our friends/coworkers will be cursed with incompetent bosses forevermore.
I have never wanted to be in management, and don't really enjoy it. You probably won't like it much either (most of the time). But it's clean indoor work with no heavy lifting, and somebody has to do it, so why not you? :)
Robin 'roblimo' Miller
reluctant editor-in-chief,
Open Source Development Network
You may get away with 20% when you're brilliant at it. For now expect to be 90% manager, ie forget about doing any useful coding for the moment. The best thing about this move is that if it doesn't work out - it'll make you a better engineer - you'll have more sympathy for good managers, and more power against bad ones.
e x.html
Read "the 5 minute manager", "7 habits..", "mythical man month", "principles of software engineering management" (Tom Gilb), "the prince", "the art of war", "time management for dummies" and neither last nor least: http://www.reciprocality.org/Reciprocality/r0/ind
As someone mentioned earlier - the hardest thing about this is that it requires an orthogonal mindset. People who are good at focusing intently on a single task for months and getting deeply stuck into a problem ("ADD" people, strangely enough - the best programmers), are *absolutely crap* at keeping track of 100s of trivial tasks. The necessary skills can be learnt by a tech-head, but take it seriously. It's at least as difficult for a tech-head as say - getting a physics degree.
http://rareformnewmedia.com/
Hear hear!
As someone who has taken a management role at a younger age, through default, I certainly hope that I can live up to the sort of image adapt has painted. As a manager, your job is as an interface (a driver of you will) between the suites and the techies.
A management job involves a certain amount of give and take and a lot of politics, but IMHO it is certainly possible to become a manager with a focus on the side of producing a good product by inspiring a team. If you are going to accept such a position, having come from a long-term techie side, make it clear that your strength is your deep knowledge and contact with the technical side of the company.
Sometimes as a manager, one has to make decisions that are going to be unpopular with your team, but if you have a reputation as an honest, approachable and understanding manager, those difficult decisions will be understood by your team.
Finally, don't loose touch of your technical side. While the management role I have includes little time for hacking, I run a couple of my own projects in my free time to keep my skills up to date.
Aim to become an inspiration to your team whilst being a bullshit filter for them and being on top of things for your superiors! It's a challenge, but hacking the method for these can be fun if you let it!
"Give the anarchist a cigarette"
A little planning goes a long way...
Now I have seen many of the respondents not only telling you that you are making a mistake, but that you will become one of them if you do. As Smokey used to say, "Only you can prevent the inevitable downward spiral into middle management mediocity." I have done the same thing you have and sometimes it is great and sometimes it is not.
:-)
I worked as a phone tech and went into management. I had a blast and still kept my technical edge and my people loved me. Or so they said.
When this big ld telecom company sold my division off so that they could merge with another telecom company *coughberniecough* I went into LAN administration. I learned a lot about NT that way. Then I took a job with a large southern US telecom company and went back into management. It was fun again and I was partially technical, but I did begin to lose my edge. I was in customer service totally and spent most of my time in meetings.
Then I swicthed over to training for DSL for that company and it was slightly cool again, but training is a funny beast. If you spend all your time doing your job and none learning new stuff then you lose your edge again. But my students thought I was cool because I made it fun.
That is your challenge and your goal in this case. Go out, don't lose your edge, be a cool boss, and above all do one thing; be the buffer between your people and the real clueless above you. It will suck and it will never get you very far upwards, but your people will appreciate you to no end. And you can get pretty far up and still be this way.
My current department director is about as uber-geek as it gets. You can visit his web site and control robots in his home. He watches battlebots on Comedy Central and plays Unreal Tournament at night. He also speaks good corporate speak. Go be one of those bosses.
Now go do something honorable.
----------
----------
Twisted Little Gnome - The Podcasting Network http://www.twistedlittlegnome.com
I found myself having to switch from development into management about 15 years ago. It is without doubt the most unpleasant experience I recollect in my professional life - you go from being a good technician to lousy manager with the click of fingers. The mind sets needed to manage well are completely different - development calls for intense concentration over long periods, whilst management is all about dealing with hundreds of small issues, each with no clear priority. And don't forget your team: one of the principal jobs of a manager is to listen to unfocused staff whining - if they are having problems in their personal life, this will often come out as half-thought through complaints about the project, the environment or their responsibilities. You will have to watch for the emergence of petty politics and try to stamp on it, try to motivate the team .... the list is endless. Just because Dilbert pokes fun at bad management, doesn't meant that good management is impossible, but it doesn't come about by accident. Becoming a good technician takes aptitude and years of learning and practise. Ditto becoming a good manager.
A good technician reads widely and tries to learn from his or her peers. Ditto a good manager.
If it takes 5 years to make the grade as a competent technician, how long will it take to become a good manager? These are VERY difficult organisational issues to grapple with, because whilst you can usually find a good technician if you look hard enough, good managers are much rarer creatures.
And if you think it will take 20% of your time to manage four other staff, you fall at the first hurdle. General management textbooks will tell you that the limit for even the best managers is to handle about 6 or 7 direct reports (i.e. staff you are directly responsible for). Given that that occupies 100% of a good manager, how much time will four direct reports absorb from a beginner?
Still, if I knew all the answers, I wouldn't be sat here reading Slashdot on a Sunday, I'd be in the Caribbean by now, retired, drinking rum punches instead!
First, good luck and I hope this works out for you. Since you asked, here's some things to consider:
I don't think there's any such thing as a 'management' job that takes '20%' of your time. You're either a manager or not. The 20% will expand (as needed) to 100% and tech work will end up taking a back seat. I personally find this frustrating since I love the tech part of my job, but hate the management part.
If you're some sort of liason between the techie types and some other manager, then you're put in an untenable position; enforce the 'party line' while having little or no authority. Being held responsible for someone elses work, without any authority isn't much fun.
If you will _really_ have some control of things (i.e.: budget, hiring/firing, project timeline...), then you should find a mentor, or get your company to send you to some management development classes. You'll need 'real' contact with teachers and other students to pick up on techniques. Don't give in to the conceit that having _been_ managed your working life you can just dive in and _be_ an effective manager.
If you're in the position of managing former colleagues, that opens another can of worms. Former friends may feel like they are being manipulated or that you've "gone over" (depending on the degree dichotomy of management vs. staff at your company)
Finally, having made that career choice, suppose it doesn't work out and you want to go back to being a pure tech. You'll forever be a 'manager' on your resume (failed or successful) and will always have to explain why you'd want to be a pure tech rather than a manager. Sort of the "you're too qualified for this position" quandry.
On the other hand, management probably pays better and, ironically, most companies will pay a good techie a lot more as a mediocre manager.
I think the computer profession needs a reworking so that you can be just as successful (money-wise and respect-wise) as a pure technical wizard, even if you're not a V.P. or Director with your worth determined by number of direct reports.
Some books that I've found very helpful are:
The Seven Habits of Hightly Effective People by Stephen R. Covey
How to win friends and influence people by Dale Carnegie
The Prince by Niccolo Machiavelli
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
Believe it or not, the book Corps Business: Management Principles of the U.S. Marines by David H. Freedman is excellent.
If you treat your people the way you want to be treated, you'll do fine. I've been in management nearly 20 years and I'm constantly amazed at the number of people who forget that as soon as they've been put in charge. Your #1 role as a new manager is to think ahead and make sure your people have what they need to do their job. You are also there to remove obstacles impeding the progress, as well as being a filter. You filter the BS coming down from management and the BS going up from your people. I really enjoy busting roadblocks but the filtering part wears me down at times.
Good luck! - Ken
I am too young to be in your shoes but I have one example on why you should do it ( and everybody else around has 1000 exaples of pointy-haired-bossization to discourage you from doing it ;-)
My technical supervisor is a rather youngish guy, totally tech-head, extremely accomplished in his field. The progression of his carreer forced him to go into management, i.e., being the project leader and manager in two of our projects. The face of our lab to the outside world, in other words. Although complaining all the time about not having time to do real reseach and relying on the young guys to write papers and getting things done, he shields us from the bullshit meetings and keeps us on track by making time to follow our research and telling us how to do things the right way - when we are cutting corners... If he were not around, I would have taken another job by now, but the fact there is a project leader with an untouchable technological background makes us proud to work for him. Also, the lessons he teaches and the advice he gives are priceless. The drawback is that you have to buy a tie, and move from xfig to powerpoint, but those are small trade-offs. It's time to pass your experience on to the younger techies, it's time to make all that wisdom benefit the others, to make the kids proud to work for you and especially with you.
All the best, adapt
Never ever put yourself on the critical path.
Why? Well, the '20%' of your time that you estimate would be devoted to management-type stuff is very subject to change, especially if the project is running late. For some reason, many managers think that the best way to handle a project that's behind schedule is to haul the team-leader into loads of meetings rather than leaving him/her to do his/her job.