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."
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
Listening, you feel your toes bunch up in your shoes, that little facial tick you only experianced once durring college finals starts to make your eyelid quiver, and you begin to contemplate the warm joy and solitude of being alone in your cubical and not listening to this conversation for another moment . .then you realise it's gotten so bad that you're pining to be back in the dilbert cube again. But just another 30 seconds, and the conversation drifts back to the topic at hand, and you gently remind him of the task to be done.
Total time? it may seam like a lifetime, but usually it's no more than an extra minute and, you've managed to get through the day without screaming "SHUT THE FUCK UP AND CODE!"
Some people are moody (think NT) and need to be 'rebooted' in order to keep working. Some people are rock solid (think Solaris) and work non-stop without intervention. It's important to know the differance. Why reboot the Solaris box when the NT box locked up?
I have one employee, in particular, that makes it a point to report to me, in fine grained detail, each and every little thing he has done since the last time I saw him. Is this really needed? No. But when I skipped a week listening, he pulled me aside and thought I was mad at him. The lesson? Reporting his position in a project orally gives him the chance to arrange his thoughts. It gives him a sence of accomplishment. If I tryed this with anybody else, they would quickly get bored and think I was micro-managing them to death, but for this particular person, it's needed.
That's really the trick, isn't it? Learning each individuals needs and wants, passions and desires, aspirations and weaknesses the same way software has resource requirements, interoperability issues, and conectivity shortcommings. You've spent years learning how computers work together, now it's time to start learning about a totally differant machine: People.
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/
Could be the Peter Principle at work.
The basic idea of the Peter Principle is that people rise to their level of incompetency.
Y'see, four years ago, Cliff was the best coder his employer had. His employer wanted to reward him.
So they made him the project lead. There was a bit of a pay increase, and there's certain prestige in being the project lead.
Well, Cliff is a darn good project lead. Not the best the company has ever had, but certainly toward the front of the pack. It's been four years, and it's time to reward him again.
So they'll make him management. Cliff won't be programming, but he'll get to review code and assign programming roles and stuff like that.
He'll be okay at it. He's an experienced programmer, so he'll be good at assigning roles. He's not very experienced at managing scheduling, but he'll be okay.
His next promotion will make him middle management. He'll never see code or coders again. He'll be organizing other people.
And he'll do terribly. It'll require skills that outside his expertise.
And that's where the promotions will stop. He'll have risen to his level of incompetency. His employer will have promoted him from his best expertise -- coding -- into a field where he's truly incapable -- middle-level managing.
The Peter Principal is such a refreshing and sensible way of accounting for the people in a company. They were, almost always, extremely good at something -- and so, as a reward, they were promoted until they weren't any good at something completely different.
The system is malicious. Instead of promoting Cliff, they should throw more money at him. He's a great coder -- so let him code!!
--
--
Don't like it? Respond with words, not karma.
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.