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."
Reduce your CVS access to "read"
The best thing you can do for yourself as a technical manager is move into a strategic role. Working as a programmer/manager is an uncomfortable and difficult business -- luckily, with ten years of experience, you can still work with the software architects and as an "expert-on-call." You don't want to lose your technical competency, but accept that you're not going to work as a developer even 20% of the time, let alone 80%.
I think the best description of a technical manager I've read comes from Debugging the Development Process, by Steve Maguire. He likens a TM to the guys who range ahead of "wide load" haulage, "arranging to have overhead power lines disconnected and removing other obstacles" in the way of the truck. Your developers are that truck; you've got to move those power lines.
Be strategic, not tactical
In a strategic role, you are now responsible for the success or failure of the project. You can't beat a deadline by working everybody fourteen to sixteen hours a day, so you'll need to think through all levels of the development cycle. If you're not familiar with the Systems Development Lifecycle (SDLC), and development methodologies such as the Structured Systems Analysis and Design Method (SSADM) or Jackson Structured Programming (JSP -- no, not that JSP!), then get a quick introduction to them. I've listed some resources at the bottom of this post, but the best resources are those who have been through the wringer before -- requirements and systems analysts, project managers, and the like. Even so venerable an institution as the SDLC changes dramatically between organizations, so for every abstract description you get, YMMV (as per the usual).
Your boss is the end user
Make friends with the requirements and systems analysts you'll work with, as well as with the (dreaded) userbase. 40-60% of delays are due to missing, poor, or misleading user requirements. Don't let this happen to you! Every piece of code should map at some level to a functional requirement; every functional requirement should map to a technical requirement; every technical requirement should map to a business requirement. This is probably the most important part of a systems development cycle -- missing a critical user requirement or whiffing an analysis will make you miss your delivery date. (I'm a systems analyst, so I'm quite biased -- but I've also seen what happens with a bad analysis.)
Fight on the beaches, fight on the shores...
Don't lie to your users, don't put your developers on the spot. Don't give in to the temptation to haul in delivery dates or reduce expected costs under pressure from others. If we all budgeted and planned software projects honestly, we'd probably have an 80% hit rate, rather than an 80% failure rate.
Don't Panic!
Most of all, relax. As a manager, you get to help develop the talents of great programmers. As a manager, you get to guide projects into completion, and see them in use. Best of all, you get to ensure that at least four programmers don't have to suffer from clueless, craven managers. That's not such a bad deal.
Resources
Oddly enough, some truly great books on development management come from Microsoft Press (makes you wonder what they'd create otherwise!). Maguire's Debugging the Development Process is a great piece of work, as is Karl Wiegers' Software Requirements. Probably the classic work on software development is Brooks' The Mythical Man-Month, which has been updated with recent content reflecting the rise of OO methodology. Lientz and Rea's Breakthrough Technology Project Management is a much better book than its title suggests, while Liberty's Clouds to Code is the "All Quiet on the Western Front" of project management books -- a grunt-level account of a development project. Also, check if your company has any internal resources for managers -- most large companies have well-defined processes for lifecycle management, and can help you get used to the strategic environment.
For the traditional side of management, try Deming's Out of the Crisis, which should appeal to your quantitative side; Goldratt's constraint-theory masterpiece The Goal is a seminal work for production managers -- the same lesson applies to us. Peter Drucker is also pretty good, though he works the softer side of management.
Stay away from the one-minute anything, and anything having to do with cheese. Those books perpetuate the myth that you can become an effective manager by reading a slim, childish volume written by a agoraphobic psychiatrist ... um, sorry. The point is, being an effective manager takes a lot of work and constant self-evaluation and criticism. Good luck!
There are lots of jobs that a skilled "lead developer" should never have to do.
Chief among them are hiring, firing, and performing annual reviews of the staff, and other administrative functions. As a technical leader, I consult to the management about a person's value to the organization, and to my project, but I do not wish to spend my time (a) hearing someone whine, (b) attending meetings.
I believe my company knows that I am most valuable to them, when I do the things that I am best at, and just as we have administrative assistants to handle clerical and accounting aspects of our projects, we have qualified competent people-managers. Our project teams are small, we do the simplest thing that could possibly work, and we don't get lost in blobbograms or wordy design documents. Our projects go well, they grow organically, and we throw out code and components that don't work well, and we keep the stuff that works. It ain't perfect, but it's sure better than having to endure the politics and endless meetings.
If you're frustrated that your company wants you to move from purely technical work, to managmenet, convince them of a third alternative. Become a recognized "technical leader". Your responsibility is the design, architecture, and software development methodologies, but not the people. For that, you need some help from a real People Person. Perhaps there are some techies who can handle a joint management/tech role, but there are others who would just be miserable, innefective managers.
Warren Postma
What you are describing is a transition, not a promotion.
Management is a distinct problem space. The skill set that a good manager needs is completely different from that needed to be a good technical person. If you become a manager (and good luck, by the way if you choose this course) you will be leaving one career and starting another.
I've been in this position a few times, and have decided that there are plenty more interesting things to do, ways to be "promoted" and ways to make money as a techical person. I enjoy what I do, and I'm not interested in a change.
One last point. The very best managers I've come across could manage pretty much anything. They rely on experts for expert information, and focus on allocationg the resources they have (money, people etc..) to the tasks they face. Being a good persion in any field does not qualify you in another, so your current technical abilities give almost no information about how good a manager you could be.
Your desire to kick ass and get work done is a quality any company should cherish given the amount of un-productive human resource out there. However, 10 hours at work every day is an extension of your life and how you think, what you say and how you behave at work is truely an extension of who you are in real life.
If you shut people out and don't give them the time of the day to interact with them even if sometimes for trivial pleasentaries, will harm your social skills out site.
Also wouldn't you loose a certain amount of your humanity to think as people carrying out buttonholed conversations with you all the time? You will just become a machine with the view of others as other machines that either add value to your buttom line or need to be igonred.
Just make sure you don't have much more than log(n) managers for n employees, in a well-organized structure; otherwise, it can become intractable. 20% is probably reasonable to help ensure this.
Also, make sure you understand statements like the above, still. You might want to read other people's code occasionally, so you can decide when to butt out from what they're doing, or become a full-time manager, or retire, or find another line of work...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Indeed; artists are not paper-pushers. All the good examples I've seen here of successful managers sound more like mentors, helping you find your way without getting bogged down in the system. Maybe that would be a better word to use.
;)
I'd much rather see book suggestions for coding, though; I guess I should post it. For C, I'd definitely recommend the (now ANSI) C Book, of course, by K&R, because they are artists... But that's not as much fun as crossposting to comp.lang.* to find out what the "best" programming language is. Any volunteers?
Have you read the book Holy Fire? If not, where did you hear the term used, because that's exactly the same concept. The book was okay overall, but the ideas are fascinating.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Well, in a sense. Generally, a coder has great skills in coding, not paper pushing. A manager should have great skills in paper pushing, not coding. And if they know anything about distributing tasks and delegation of authority, they will want to do the paper pushing, not the coding, because they can verify that it is done quickly and well, whereas the coder can't, necessarily. That's just common sense.
I'm a coder, and I'm taking a course in accounting; I understand the material, but I'm not great at it. I wouldn't want to do your taxes, and you wouldn't want me to, either. Got it?
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Poliics, politics and meetings. Politics with lunch. Politics when you come back from vacation.
This is what it is to be a manager, really. :(
-- The unsig...
I wish the Congress-critters being lobbied by big bucks tech companies on the H1B visa issue would read this thread. If they're all so starved for tech talent then why do so many people feel forced to move into management after 10 years? Or leave the industry altogether?
Woof.
The revolution will NOT be televised.
Although I strenuously resist any form of management responsibility I inevitably end up doing a fair bit. And what I have noticed, both for myself and for team leaders I've worked with, is that there is never enough time to do the technical type work when you have to look after four other people - you will spend 60-80% of your time doing management tasks - talking to the customer (internal or external), project plans, man management, reporting to senior managers, catching up with paperwork, chasing people your team is relying on for a response, etc. Don't underestimate how much grief this is going to cause!
Of course, that's why managers get paid more..
~Cederic
Just remember the Golden rule of management - watch your back - no, seriously: try to be the type of manager YOU'D want to work for. And remember, the only thing harder than being a new manager is working for one. You'll do fine.
[Insert pithy quote here]
I recently got forced into this myself. Having spent the last 10 years emersed in as much tech as I could get my hands on and loving it, changes in the company mean I now spend about 95% of my time in meetings, answering email and generally making decisions I feel unqualified to make. And I don't like it one bit. I've come to realise that it requires a completely different mentality, with different motivations and to a large extent a different language that I struggle to understand.
My solution? In the short term I'll change jobs. I am still young enough to be able to get the sort of dirt under the fingernails position I want, and I'm lucky to know there is plenty of such work out there. In the long term I know I'm going to find it harder and harder to do this. I have yet to figure out what I'll be doing in 10-15 years time, maybe technical writing, maybe start my own business, maybe get out of the industry completely... Kelp farming has always struck me as a nice line, the fresh air, be your own boss, as much kelp as you can handle, bliss...
orlando...
-= This is a self-referential sig =-
I've been through many manager that I would have liked to have killed. And very few that have been great. I think that what makes a good manager is one that has been in your position or at least trys to understand it. Also all the good ones, told us the truth about what was going on, the CEO would lie to our face, then we turn around and our manager would tell us what's really going on. The really good ones will be there with you ALL night working on the same problems with you. That's where the respect is earned. The really good ones didn't try to become our friend, but they did earn it... It really takes a ginuine attitude.
I just hope that I remember all this stuff in a few years down the line when I end up managing a crew. I think that from what I have seen from the my managers I can improve the workplace.
I'm suprised that no one has told you of the exciting alternative to management. As any good programmer gets older, they are given the ultimatum to "grow up" and join the mgmt corps. That's an emotional argument designed to shame you into being "mature" about your role in the company. What they don't tell you is that you'll never touch the product again.
But there is an alternative for the "lost boys" who want to play with toys: contracting!
As long as you do a good job and stay current with technology, you can do contract jobs until you die! So sign up with a contracting agency, fill out your time cards each week, and make more dough than you would as a manager. The jobs last from 3 months to 2+ years each. If you're willing to move or live in an urban area, you'll never be out of work.
Anyone who thinks you should "take your career more seriously" is already dead. Don't listen to them. You have plenty of other outlets for their model of maturity (spouse, kids, mutual funds, etc.) Unless someone has been a contractor in the past, IGNORE THEM!
Buy a copy of "Contract Professional" to get started. I have no affiliation with this magazine, but it's a great place to get leads.
If you hear yourself saying, "That sounds great, but..." then you are 'weak with fear from within'. Either you'll have the guts to leap into this brave new world or you will stick with what you know: the corporate security blanket. I say "C'mon ya wimp. That security is an illusion!"
I'll bet you could quit your job, join a local contracting firm, then get hired on at your company for 15% more than what you make currently.
Those are just some words of encouragement to kick your ass out of the house. Mama ain't gonna take care of you anymore. Stop whining...
This is all fine and dandy when you are managing things that you have expertise in. I work for a engineering consulting company whose business is always changing. While it is great that the company is always trying to adapt, they don't really need my area of technical expertise as much. So what happens, well I, as a long-time employee, do management. Except, more often than not, I am managing stuff that I couldn't do myself, because of the shift in work areas.
So here I am in on Sunday working on revised project budgets, manpower planning, yuck! It's so distasteful, I have to break down and read Slashdot for relief. Ok I know, quit your bitching and find another job. I've heard that many times before!
My view is that a good manager should do everything he can to make the projects successful. This includes taking care of the team members, the people. This guy has found a way to get the best out of his people, to make sure they can concentrate on their jobs; to be better on their jobs. Is that wrong ?
Managers are very important: they are meta-programmers, enabling lots of other people to do their work and facilitating them doing it better. It has been statistically shown that the best engineering managers are good engineers (good engineers don't necessarily make good managers, however. This is a one-way thing).
Like a battlefield commander, the worst thing a manager can do is nothing. People look to you to lead them, and you need to lead them somewhere, even if you don't have enough information to make the optimal decision at the time.
Listen to people on your team and other managers. Being a manager is not about coming up with good ideas; it is about recognizing them when you hear them.
Shirts with high polyester amounts feel crappy but don't need to be ironed as much.
Good luck!
-m
My old manager used to be able to rattle off bugs fixed bu SUN kernel patches 6 months prior, but micromanaged. My new manager is not technical, and has no illusions about this. He works as a bullshit filter, and to remove obstacles from my way, so that I can get my Real Work(tm) done. He is interested in what I am doing, and comes to technical presentations by vendors and architecture meetings (I work operations, not engineering), but does not interfere, and generally asks very good questions. In general, he is the best manager I have had yet, just because of those points.
While I realize this doesn't work for everyone, it does definitely work for me.
I would tend to disagree about the influence of an individual programmer. Cream rises to the top, to use a cliche. If a tech is good at what he does and an honorable person, his opinions and actions carry more weight. That's true in every programming shop I've worked in, regardless of the position of the programmer. In many cases, the respected tech can influence the manager as well by merely stating opinion.
First of all, consider this. Have you reached the highest possible level (in terms of salary and in terms of who you report to)? You should try to reach to highest possible level without having anybody "officially" report to you. Once you are satisfied that you have done that and you still feel the (greedy/powerhungry) need to move up in salary and responsbility then consider moving into management.
But seriously...
Once you are a manager and developers are reporting to you, remember this: you work for them. It is analogous to a rock and roll band. A rock band hires a manager to do the dirty work: arrange gigs, deal with promoters, do paperwork, handle legal matters, etc. The artists write the songs, put on the performances and decide the creative direction of the band. You've got to make sure nothing interferes with the band's ability to do its work.
I've moved from nitty gritty technical work to management of technical projects & people. There are tons of books to read, but here are the two things I'd recommmend taking to heart.
1) When managing, you must let your people do things their own way. Unless the method they choose won't work or is critically flawed, let them choose how to solve a problem. Resist the temptation to make them do things your way. If you show faith in your people, they will support you. If you micromanage people, they will fight it and the projects will suffer.
2) Learn finances. In any company, the beancounters drive most of the decisions. You must learn to justify your requests on a financial basis. If you need to buy new widgets, you will be asked to show how the new widgets will help the bottom line. When you save money in a project, make sure your higher ups know you did.
Good luck.
-----
nuclear iraq bioweapon encryption cocaine korea terrorist
... us techies, with our logical, orderly "there is one correct answer" orientation ...
:)
If you think that, you really should try PERL. Have fun
----------------------------------------------
the pun is mightier than the sword
It will take, and it will take experience (just like any other sophisticated job).
The best book I can recommend is "Peopleware - productive projects and teams" by Tom DeMarco and Timothy Lister. It will help you to avoid teamicide.
Duct tape + WD40 => DevOps
Check out "The One Minute Manager" by Kenneth Blanchard and Spencer Johnson (ISBN 0-425-09847-8). This book is short, easy to read, and presented in story format: possible to finish in a couple of hours. It presents the best way to perform various management duties in a short amount of time. I only manage a couple of interns, but I feel the book has helped me streamline more aspects of my work than just "Managing."
http://jones.ling.indiana.edu/~prrodrig
Please don't treat me the way you want to be treated unless you're sufficiently similar to me as to not have the things you like piss me off.
>Silently sneak up to them to see if they're reading Slashdot on company time.
And give them raises if they are! Those are the employees that you want to keep working for you.
First, ask yourself why they (the PHB's) want you to manage a technical group, rather than being a valued senior technician. Is the product design hopelessly flawed? Are they missing schedules? Unless you can say "No" to both these questions, you might be the latest fall-guy for management.
OTOH, if your management is great, then you might enjoy joining them. Do what feels most right....
Do what I do: back to school and get an MBA. It's fun, :)))))))))
it's academical, and there are some
terrific looking girls which almost
made me regret that I chose a technical
field 12 years ago
BTW the math will make you laugh.
In recent days I show up only for quizes
and midterms (and for the girls!!)
Managers having no brains, I'll agree with, but engineers having no brains is another story.
Engineers at least understand (for the most part) exactly what is going (to an extent) at all levels of projects they are attached to, unlike managers and programmers who tend to be extrememly narrowly(overly?) focused on relatively minor components of projects, or atechnical components(managers.)
I've noticed that programmers tend to memorize/become attached to a single API or extrmemely small set of APIs, leading to their general obsolescence. Engineers on the other hand tend to be used to switching tools/APIs fairly frequently for various projects, and tend to be more adaptable to new situations and projects where as your programmer buddy would need extensive training to fit in again.
--- C00l
my employer is moving me from application develpoment to project management.
now i'm reponsible for a tech team of 6. i guess what made the decision easier was the fact
that i'm now much much higher up in the company, responsible for technical direction as well.
my advice is to go pick up your PMP certificate, i'm doing mine at university of toronto eh.
hardest thing for me was having to divorce the tech side of my job, which is essentially nonexistent
now, from the managing side. the upside of that is the fact that i develop much more at home now.
best of luck
links:
U of T program
Think about it... you may have not done management but most certainly you've have plenty of experience with managers in 10 years. Hopefully you picked up on the good and took note of the bad.
To some extent the transition is inevitable for anyone with any sort of leadership skills (or even potential ones). Shoot... someone has to rise to the occasion and make sure the next generation of techies are given good guidance and not a heavy hand of an idiot.
If you can get a good techie to be a good manager it's better than taking some worthless business major with 2 courses in team management and making the techies suffer.
Brian Macy
I was lead tech, moved into management for 7 yrs or so and am back to pure tech. The managment role got to be very dull and not challanging (in the way I like to be challanged). I choose to go back to a tech-only roll and thank my stars daily that I did.
I was a very good tech and a average manager - but the managment stuff will get you down, exp if you have a low tolerance for politics.
-- Raz
- If you don't, someone else will. And that person, less technically competent, will soon be telling you what to do.
- This is you chance to do it right. Over the last ten years, you've built up a big catalog of stupid boss tricks. You can now be the kind of boss you wished you had.
- You can tackle bigger things. There's a limit to what one person can do. If you build and lead a good team, you'll be able to build a lot more cool stuff than you can as The Lone Coder.
Really, it's worth a go. If you hate it, you can always go back to doing straight technical work. Here are a few tips:- Be honest with your people. You have the great advantage of managing techs, who prefer the honest, unvarnished facts. If they come to you, as a manger, with a problem that you don't know how to handle, just ask them what they are hoping you'll do for 'em. That may seem a little lame, but it's much better than saying "Oh, that's an issue; let me get back to you." Geeks are good at detecting bullshit, and you will lose their respect quickly if you aren't honest.
- Learn diplomacy. Although frankness works well with your fellow geeks, it is frequently not the best way to handle the other folks you'll soon be forced to deal with. And although some managers seem to think differently, note that "being diplomatic" isn't the same as "lying your ass off".
- Protect your people. In your team, you should strive mightily to create a little bubble of sanity, isolated from external nuttiness.
- Learn politics. Yes, politics is ugly, disgusting, and depressing. Of course, so are many APIs, but sometimes you still gotta use 'em. Find a political mentor who understands the ever-shifting balance of power at your organization, and have them explain things to you frequently.
- Don't burn out. As a manager, much of your job is to provide sanity, balance, and perspective. If you are overworked or burnt out, you can't do any of those.
Unfortunately, you didn't mention what part of management you're being asked to take on. There are a lot of things they might be expecting:- Techincal lead - This is just being in charge of the geeky decisions.
- Project manager - Perhaps they also want to you do schedules, timelines, progress reports, resource planning, and the like.
- Personnel manager - Will the people on your team look to you for things like performance reviews, raises, vactation scheduling, and so on?
- Technical mentor - Do you plan to spend time helping the junior developers get to be kick-ass coders?
- Liaison - Your team may have to deal with customers, vendors, QA, user testing, marketing, and about eight million other people. If it's not explicitly somebody else's job, it will be yours.
These are all different sorts of management, requiring time and effort. None of them are easy. If you are being asked to take them all on for a team of four, 20% of your time isn't enough. (It's more like 120%.That's a relative argument. A team leader's job MIGHT be as exciting, for certain people. However, many of the people who went so far as to obtain very strong technical skills, decided that the issues for a team lead are boring.
I am currently filling in a team lead role. Personally, I think it sucks. It is not always the case that a team lead decides programming languages or other technologies. More often than not, that decision was made long ago. And in a company that has a strong focus on changing technology, they will have an R&D group that keeps an eye out for the latest and greatest. Most team leads and managers lose their deeper technical skills, and think very high-level (as is needed). And that makes them a HORRIBLE choice to be deciding technologies to use for a project. They will base their decision on "marketted" factors, and not actual testing. They will go with the buzz-word decision.
In my experience, and from friends in similar situations, the engineers of a company will make recomendations to management, and are often ignored. Or management suggests a new product against the comments provided from below. This is not just one or two cases. I have seen this almost everywhere I've been, and in other companies that I have friends at.
Most management is about control and power. "Who can I get to do X" is often the thought process, without much thought about the real reasons WHY they should do it. Management often gets too lazy, and sees the lower level technical decisions as irrelevant. Granted, in their screwed up number crunching methods, the numbers work out, for the overall picture... but what they don't realize is that the criteria used for measurement is GROSSLY incomplete, and doesn't take into account many supposed "insignificant" factors. But those factors ARE important to the people 1-2 levels below them. This would be analogous to making project decisions that force a specific lower level implementation. And because they are so high up, and are "protected" from the lower levels, they are not aware, or don't care that they made a decision that makes some tasks/jobs "unacceptably" complex.
I am all in favor of having solid management. But in my opinion, it shouldn't be expected that a solid engineer/tech person will move "up" into management. Rather, I think managers should be forced to LEARN how to manage their group. There are MANY books on how to manage an engineering staff. Things usually go wrong when people don't pay attention to knowledge that has been known for decades, and try to figure it out on their own.
This is not really a flame, but rather a counter argument. I don't think management is "all that". And quite frankly, I'd rather go a technical route that involves decisions such as future technologies, areas to explore, etc... WITHOUT having to manage. What I find rediculous is that those tasks are considered the role of management, when it should be part of the alternate career path for a technical person, who has no desire to manage. Anyone know of many companies that do this? I know that Qualcomm has some cool technical career paths.
Cheers,
-DM
My new VP does this. Sometimes I wish he would acknowledge that I know he doesn't know shit. But from time to time, he repeats technical terms that he was told or explained. Sometimes he knows that it comes across as a "canned" response, and thinks he's being cute. In fact, he's just making himself look more like a dumb-ass.
As someone mentioned in another portion of this topic, programmers are expected to tell the truth. As such, we're used to working in an environment where the truth is told, and told with precision. Management often doesn't realize that a programmer SEES their BS very clearly, and that it's frustrating. At the same time, I've seen management conceal information, because they try to hide/control other information that would be revealed if "too much" was said. And being the data oriented/pattern matching kind of people we are, they know we'd figure out some of their "secrets". I've talked to some other executives, and they said that it's true. As it is, my company is trying to keep a lot of things hidden (higher level planning), but are sucking at it. We were told more truthful details, but then pointed out that we already knew all of that, based on information we see in the database, or seemingly irrelevant requests.
Anyone else feel paranoid about the secrets they keep? At least my paranoia is being justified as more information I already figured out, gets officially revealed.
Cheers,
-DM
Being a technical manager can be a lot of fun, if you think like a General (or even a Captain or a Colonel). Even though you have to accept some additional responsobility, the paperwork doesn't have to be a killer, just make sure they let you hire a good admin assistent to take care of that stuff. That will free you up to actually ENJOY steering a group of really smart guys into acomplishing more than the sum of thier parts.
I can NOT stress enough, that if you remain unorganized, and don't PLAN for things to happen, you will be a crappy manager, and no one will want to work for you. A good manager's FIRST rule (at least if you manage talented technical types)
is that YOU work for THEM, not the other way around. This give you the chance to lead them in the direction/towards acomplishing the goal the YOUR boss wants done. Not to drop into sales droid speak, but that would be a WIN/WIN situation, the best anyone can hope for.
Just because a lot of the more technicaly gifted people that post here don't have a taste for the responsibility and challange of being in charge, don't let them frighten you off (unless you really believe you CAN'T do it.) There is NOTHING wrong with admiting you can't do something before you royaly screw the pooch.
Good Luck!
I've been doing network management and support since 1989, and working with desktop to departmental systems since about 1977.
My last job was pure hell. I left the job before that because I thought things were bad, but my last job definitely forced me to recalibrate my scale of "bad". Pretty much everyone was always working overtime, downtime was seldome scheduled more than 15 minutes in advance, and we were often asked to work the weekend at about 5pm on Friday. The company wasn't that bad, but our department was a disaster. Most of the problems were due to a lack of planning and foresight, not because of any valid emergencies. I'm still looking for any good points...just so I can see that there was some positive impact.
When looking to get out of hell, I found that I could easily pick up a contract job in a week or two that would get me by. Not a perfect job, by any means, but something that would hold me for a year or two and pay all my bills. This kept me going, looking for the perfect job, because I knew there was a safety net.
I looked at what was important to me. Near the top of that list was to get to do the right things technically for sound reasons, rather than to constantly be playing political or bureaucratic games. Not to be constantly reacting, but to be proactive. And to get my evenings and weekends back. The more I looked, the more I realized that was going to mean moving into management or moving into a narrow technical specialty. At my age (I was 34 at the time, now 36) I was a bit worried about the narrow specialty, but also worried about having to deal with managing. In the end, of all the jobs I interviewed for, the ones that looked the most interesting all involved managing a small department. The best purely technical prospects all involved sitting in a cubicle.
In the end, I found a much smaller environment where I am a now department head. I get to keep my hands on technically, but we get to do things my way. I have management responsibilities, but they're, well, manageable.
I was used to supporting 500-2000 node networks, now I'm supporting a 50-60 node network. But it gives me the opportunity to set the direction, establish the policy, and prevent most of the stupidity I've suffered through elsewhere. By the time I'm ready to move on, I'll be better at dealing with the management aspects, and ready to move back into a larger environment. But I'm not really in any hurry. The deadlines are largely of my own creation, and I can keep politics from dictating network design or policy.
Yes, it can be a headache to deal with managing. But in my experience over the past year, I'm far happier to deal with the management issues than with the insanity of having non-technical managers dictating tech policy irrationally. We have a better network for it, and even our most cynical users recognize that. And I get to keep what little sanity I have left. When it comes down to it, getting to do things my way is so much more rewarding than any management inconvenience can detract from.
http://drteknikal.blogspot.com/
I recently went through a simiar decision. After 15 years as a stand-alone geek, I was asked to take a position as a director of product management, with a staff of four. I decided to take the job, because I saw it as an interesting challenge and a chance to grow.
For me, the most interesting aspect was that I went from a position of being a know-it-all who could bitch loudly about what was wrong and tell you how to fix it, to being a manager who had the power to both fix the problem, and see why you *can't* fix the problem. It was definitely a slap of reality to me, it would be nice if non-managers could see things from that point of view... maybe force someone to manage for three months or something.
As my current boss says "Everything is a people issue." The reason why your software doesn't work, why the software is great, why support can't answer questions, why reviewers are trashing your product, is a people issue. Ultimately, someone in the company did the job well or not. You either had enough people to finish the project on time or not. There are some really hard decisions that you will have to make. For example, one decision I had to make right away after taking the job was to either focus on a new release of my product or fix serious stability issues with the current release. I decided to fix the current release, but this pushed back the release date for the next release, which impacts our revenue. Many of these choices aren't easy, and either way you go, people inside and outside of the company will scream at you.
This is the big-picture perspective that management gives you. When you're involved in a large software project, the dynamics of the people on the project are far more important than any individual contribution. That's hard to get used to. When you're a "star" contributor, you like to think that the company will fold up without you. It probably won't.
To me, the job of a manager then is to be captain of the boat. The captain of the boat doesn't directly maintain the engines, but he needs to take input from the mechanics and decide whether or not what they are doing is the right thing. So you take people's individual needs and wants and make sure that they make sense for the group as a whole. This "holistic" perspective is really the job of the manager. If you're used to doing everything, you're going to find yourself overwhelmed quick since you *can't* do the job of five people. Plus, your staff will hate you for not trusting them. It's tough to captain the boat when the mechanics have quit and the engines aren't working.
I've found the job really interesting, and I'm happy with the switch to the management side. I think it could be *really* frustrating to a person who is used to being a big individual contributor.
- "When you want something with all your heart, the entire universe conspires to give it to you" -Paulo Coelho
I too felt the cold breath of management on my neck, so I made the move to consulting about 2 years ago. So no it has been 11 years of nothing but tech and still going strong. If you want to challenge yourself try consulting. I have worked on more types of projects since I left my last full time job (and many more Linux related jobs!). There is a lot of hustle required to make sure your pipeline is full, but if your used to the "programmers ethic of working" your no stranger to that.
It can take a big leap of faith too. My wife provided the faith, and I made the leap. We have not looked back since.
~Sean
I think most people don't understand the relevance of this book. Another one would be Principles of War by Carl von Clausewitz. The concept of "center of gravity" is really applicable to management and managing large projects.
push for dual-track career paths in your company - if you're really good and your company is worth working for they will do this.
Yep, roblimo's right. Your job as manager should be to clear the way so your team can get stuff done.
Also, if you are being promoted on your technical compentance, another role should be to pass on that competence to your team.
Another thing is to make sure your people get what they deserve. Many times management will want you to take explain or take positions that your group will not find popular, and you will have to. But, the flip side to this is when you really need to stand up for them (i.e. pay issues, flexible scheduling, etc.) you need to do that as well.
If at all possible, try to get managment guidance from your manager. I have learned alot from my managers over time. Many times it is like giving technical insight to your manager in return for managerial insight. Valuable, valuable stuff.
With that all said, the kind of move your talking about is the kind of move I'm glad I made a few years ago, it can really pay off and still provide you a job you'll like.
You are assuming, of course, that Cliff will be unable to learn how to manage.
Sometimes that assumption will be true, often it will not be.
In many disciplines, professional advancement means going into management - these tend to be areas where there are a lot of people-skills going on, where it makes sense that those who understand their field will also make good managers.
For a lot of engineering jobs, however, this is just not the case. I often draw a parallel with Air Traffic Controllers. They don't go into the job expecting advancement to become Area Manager, Air Traffic or Director, Air Traffic Research - they expect to be Air Traffic Controllers for their whole life - just getting better and better at it.
Where I work, I have structured technical jobs in this way - that there is a clear choice between progression into management and progression into just getting better and better.
If you find yourself being forced into management because there is nowhere else to go, don't stand for it - there are a lot of businesses out there that can do with experience, and wide experience is especially valuable in new fields. No matter if you're getting a bit long in the tooth, if you can demonstrate an agile mind they would be foolish to ignore you.
I can say, however, that my move into management around six years ago has been hugely rewarding. Technical Management is HARD. VERY HARD. It's certainly the most challenging thing I have tried.
Advice I would give to me if I was doing it over again would be, I think:
I could go on like this forever, but basically if you know your subject, treat people like adults and believe in yourself, you shouldn't have too much trouble. Over time you'll find the really difficult bits start happening automatically and then you can start concentrating on the really interesting bits, like strategy.
Enjoy, this could be the best decision you ever made.
When I was working as an engineer (before striking out on my own), I was fortunate enough to have been able to set through a couple of SkillPath Seminars (http://www.skillpath.com/) paid for by my employeer. I'm not saying that SkillPath is the only, or the best, but it is one of many organizations that contract with experts in many fields to present classes on all kinds of topics.
As you move from managing computer code (techie) to managing people (management), you're going to find yourself needing a whole new toolbox, and tools to go in that toolbox. SkillPath (and others) can help you fill that toolbox up.
You're going to have to look at the world through different eyes, and these kinds of people can help you do that.
I also suggest one, short, easy to read book to help you get excited about management:
Tom Peters, The Persuit of WOW! This is not a book about theory and schools of management, it's about being great at what you do. It's a glimps into organizations that do what they do very well. It's a fun book to read.
Finally, don't forget to LISTEN. Don't forget that you don't know anything. Don't forget that you're human, falable an error prone. Don't get sucked into up-line butt-kissing. Don't be arrogant. Don't fall into the trap that you're the manager because you're better than the people that work for you. Don't ever stop learning. And... don't stop doing what you love, just cause you're "management" now.
Have fun. If you can't have fun at your job, find a new job that you can have fun at. Management is not a bad place to be. It just very, very different.
Don't you think it's time to start communicating?
Don't do it. Middle managers have no control over their destiny whereas software analysts have high job security. If age discrimination is looming then start developing software on the side as a consultant so that you have something to fall back upon when you get laid off.
Books: "Getting to Yes", "Getting Past No", "Getting Together", and all the rest by the Harvard Negotiation project. IIRC, the authors of the first are Ury and Fisher.
I have been in this business for 25 years. Being a task lead is the price I pay to get to do the high level design. I am an excellent programmer and a competent task lead and intend to stay that way. I would rather be doing what I am good at, but who doesn't.
Advice? Compliment good work. If you can't find any good work by someone, look harder, find them some place to succeed, or get rid of them. What out for heroes and saviors. They may be cranking out incomplete code to look good, that others will find or trip on the bugs and look bad. Anyone who is working 60+ hours/week isn't doing their job in the planning department. Remember you are dealing with people, they have lives, wives, kids, significant others, bad days, and deaths in the family. Learn something about the Meyers-Briggs Type Inventory. Extraverts annoy/terrify introverts by thinking out load. Sensation types annoy Intuitives by demanding facts, data, etc. Good intuitives annoy sensation types by being right without having facts, data to back it up. Process types are great in emergencies where the pre-made plans don't apply. Judgement types are great with setting schedules and planning (and reducing the number of emergencies). Try to understand peoples strengths and weaknesses. Let them flex their strengths and get them help with weak areas that are needed for their job. This is especially true for yourself. Read the magazines that slant towards technical management (e.g. Software Development).
Finally, ask your self if you really want to be a manager. My father and I both tried it and decided no, knowing it meant that our "juniors" would be making more money and have more authority.
Gorkman
Someone below makes the point that it can't be expected that the CEO knows how to do every job under him. Sure, I agree with that, but he had damn well better know how to do the job of everone who directly reports to him, and be expected to help out from time to time as well.
Also, from a lower level manager standpoint, how the heck are you going to review someone if you don't know what they do, can't possibly do it yourself, and have no plans to learn how to do it? KLOCS?
"Well, good luck finding a judge that doesn't run a bestiality site."
The worst managers out there don't bother to get their hands dirty, or haven't been out of their office in 10 years, etc. I've noticed this type of manager is usually the one who golfs every Friday, uses every corpspeak buzzword out there, and generally has no clue as to how things work.
Lucky for the rest of us, most of them are going away these days, what with consolidation and all...
"Well, good luck finding a judge that doesn't run a bestiality site."
Just keep applying yourself and doing whatever it is that has made you successful so far. Obviously you have to be good at problem solving to get where you are today, but what is the single most important thing that got you there? The ability to analyse a problem, come up with a solution and do the grunt work to carry it through . Not just any old way, but with the unique flair and ingenuity which is your personal hallmark. As an engineer you had to deal with computers and software, as a manager you will be dealing with people and schedules. So what makes you think it will be so different?
Antidisestablishmentarianism would lose its point if it were hyphenated
There are two excellent books out there: Personality Plus and Personality Puzzle, both by Florence Littauer. Both of these books are on the topic of human personalities, and the second one deals more with personalities in the work place, so it would be an excellent choice for those in management positions, as you may have to deal with people in the other departments. As for being assimiliated, all I have to say is "Success has a price, pay up or lose it."
I switched from tech to management just a half year ago, and thats exactly how I feel.
There is a big difference between being a good tech and being a good manager. A good tech is solving problems and is rewarded accordingly. A good manager is dealing with problems; moving them around, pushing them onto anothers disk, hiding them for the customers etc. etc. The success criteria seems a lot more blurry but if you're doing resonable and avoids the worst disasters you will be given time. Management is hard - good management is even harder - and it takes time to learn.
Another big difference is how you manage truth: As a techie you are expected to tell the truth. If I was to cooperate with you and I downright lied about the interface specification between our modules, I would be a lousy programmer. OTOH if I was telling our customers the truth about the status of our projects I would be a lousy manager. It takes some time to get accustomized to :-)
Not that I didn't wanted to enter management - oh no - but I was taken somewhat by surprise by the new requirements.
BTW: Those 20 percent you were talking about ? Forget it ! You should expect at least 50 percent and most likely 80 percent until you are a little more experienced.
Anyway: Go for it ! And good luck.
For those who have not read it, I would describe it as an empiric investigation of the human mind. It is so refreshingly free of all the usual pretty-painting of the world and the mechanisms that keeps it together. Instead it focusses on how people are instead of how they ought to be.
Truely recommendable
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?
That depends.
If this is one of the people in your organization that you need, without whom everything would go to hell, you're damned right you should.
Otherwise, you need to explain to the person as nicely as possible that they're providing you with a bit too much detail. But you still need to be clear that if they have anything they really need to talk about, they should feel free to come see you about it.
It's in figuring out how to delicately balance these sorts of issues that a manager earns the additional pay they get. If they can't figure this out, they shouldn't be managing.
Yikes, I guess this was a flame. Bad Karma! Bad Karma!
I was a technical-manager, just like you are to be. I think, among the biggest challenges, there is the trend to make all the work. The manager must divide the work among the team-mates (yes, the manager should be in the team, not above it).
I was overworked, and my team-mates not. I was a bad manager, so. This error I won't make again (there is a lot of new errors...).
Good luck!
I've been offered a job as the head of technology stuff at a new startup consisting mainly of business- and money-type guys, but relying 100% on technology. My job is to scope out all of our tech and to get it up and running. It's a really heavy-duty project, so I will have to end up hiring and "managing" a tech team, as well as being the management consultant for all things technological.
I'm kind of fascinated by it, because even though it means I have to do a ton of presentations and budgets and whatnot, it gives me a chance to take a poke at what I always bitched about with _my_ bosses. Also, I don't intend to relinquish my technical involvement if at all possible, since this will always give me a ticket out.
Lastly, this sort of thing may give me exposure to all the politicking and similar B.S. I would need to know about if I intend to start my own company. No matter what happens, I don't think it's a waste of time.
Frankly though, I would never ever ever dream of taking a similar position in a large, established company's hierarchy.
Cole's Law: Thinly sliced cabbage
On a furthur note, its a good idea to refuse a few meetings here and there. Companys get sucked into the "Lets make a new mission statement" style of meetings. Ive seen the cycle break and work get done when a few of us have said "Nah, dont really think that meeting is important, I have work to do."
Remember you are Technical and Manager now, which means you can still get a job anytime you want. Make changes and dont do the things your previous bosses did you thought was really stupid. The experiance and the power is important but dont let it eat your skills away completely.
--- Always remember. 99.36% of all statistics are inaccurate.
see Jargon definition of suit
...Invariably worn with a `tie', a strangulation device that partially cuts off the blood supply to the brain. It is thought that this explains much about the behavior of suit-wearers.
;)
well, maybe it's not that bad after all ! (depending on the money you'll make because after all, this is the main reason why you're to accept the job aren't you)
Nostalgia isn't what it used to be.
This question applies to all professions but is more pronounced in the tech industry, due to the nature of the work and the personalities that chose to do that work in the first place.
Many people who don't gain energy from interaction with others have chosen the tech path to focus on getting the work done independently. I don't think these people are ever going to be happy in management, regardless of increased income. Indispensable: computers
People who require interaction should be safe in choosing management. This allows them to focus on talking to others about the work as an abstraction, persuading others, playing political games, etc. All of which require constant interaction with others. Indispensable: telephones
I'm not implying that there is no overlap in these two categories.
~
~
Being a manager in the Corps was a challenge, but I honestly believe being a tech manager, especially in a high-tech field today with low unemployment and demanding schedules would be a greater, or greater challenge than anything that I had faced.
But if it wasn't a challenge it would not be worth doing.
all persons, living and dead, are purely coincidental. - Kurt Vonnegut
The main danger in advancing the career into the management area is turning out INCOMPETENT in the new position due to requirement of completely new skills and thus falling under the glorious Peter's Principle. One should check what would be his/her duties after the possible promotion and after such analysis it could be that you'd want to refuse such a promotion.
If someone wants to target a career up the administrative hierarchy it could be worth to attempt first a minor managerial position, such like project management, to try extensively the administrative skills. I was lucky that I was forced to such position during my military service - right in between my IT-career.
Moreover one might want to reread the books on management - like the mentioned above Peter's Principle, or Carnegie.
-- "If you had fallen into a shit pit during a battle, lick yourself off and move on." - Jaroslav Hasek
Basically if after 6 months or so, most people including you, agree you're a bad manager, _and_ are likely to remain that way, then they might as well let you return to doing what you were good at, _without_ prejudice.
I am not a manager but I believe that that's a way to make sure that good talented people who end up in unsuitable positions don't stay there.
Also, knowing that you can go back without prejudice (unless you behave really badly!) takes a lot of pressure off you which may allow you to actually work better.
Cheerio,
Link.
I was in your shoes about ten years ago, and the transition does not have to be painful. There can be a certain amount of satisfaction from helping others achieve greatness. Just remember that at least half of management is dealing with people, and all people are different.
Now, here are the two books that I recommend:
1. The One Minute Manager. This book shows how to give out reward, critisism, etc. without over doing it.
2. The Mythical Man Month. This is the best book on technical management that I have seen. Some of the examples are outdated, but the general ideas remain true.
For bonus points, read The Soul of a New Machine. Although it's almost twenty years old, it does a great job at how obsessed people in our industry can be with their jobs.
/Don
Hah! That sounds like our project; originally supposed to GA in November, now it will beta in Nov. and GA in February. And we spend our time teleconferencing between our office, the CA office & the NC office.
Take a look at the Mythical Man Month.
This book was written more than 25 years ago and it continues enlighting people until now. And the 25th anniversary edition comes with new chapters, that give an updated (and not so changed) view on the same problems.
From the "one click method owner":
Fh
Everyone's already recommended the books I would have.
If you have a training budget, a good series of classes is Zenger-Miller's/achieveglobal's Core Interpersonel Skills. It's the one the American Red Cross and I see that the next winter olympics are using them too.
One piece of advice I would give you is to always, from your first day, be looking for someone to replace you. In almost any ladder-climbing situation (welcome to management), it's much easier to move up if you have a replacement already lined up. If you can't be replaced, you're more likely to be stuck where you are because you're too critical.
Also, along with the good recommendations I've seen here, consider Peopleware by Tom DeMarco and Timothy Lister. This is a great book on what management can do to make the people in software development more effective. Some of DeMarco's other books are quite good too. Check them out!
The key question is what do you want?
If your company is successfull its unlikely you won't soon find yourself consumed by managerial tasks.
Secondarily, there remains a surplus of managers in tech, and a shortage of good programming/technical talent. Point being - your true value may be in your approach to projects and the things you create
www.hiredinsight.com
I'd recommend you read some books on Leadership... I started with "The 21 Irrefutable Laws Of Leadership" by John Maxwell. Leaders are far more valuable than managers - and the two do not always coincide - I've worked with good managers who were leaders and managers who were NOT leaders.
Look around your company. If it's successful then there are leaders. You may like them or not but they lead - get things done and lead others to get things done too. Leadership is learned but it appears less tangible than the technical stuff.
I recommend that you "go into management". Just do it as a leader. The world has too many "managers" and not enough "leaders" (just look at the elections here in the U.S. and you'll know what I mean!)
I have read all responses, so I am not sure if what I am going to write is already written.
I am a pure techie too, and now have to manage the ISP/IT department for the company I work for.
I think this is the best move I have made. People who work for me are quiet happy with me, cause I underStand that they can get drunk and not come to work the next day. On the otherhand, they too underStand that when there is work to do, there is no day or night.
They are pretty happy that Word Documents or any other Microsoft stuff is now banned comming to IT department.
If there is stuff like that coming from customers, it has to be filtered through the project managers and has to be transformed into text or html format.
Starting work ours are undef and so are finishing work hours.
Either I am a very bad manager or a very good one.
Looking into my bank account from the money that my employees are making for me, I think that I am doing the job pretty well.
Too bad you have some assholes above you that dont understand you.
--
If Microsoft is the solution, I want my problems back
If this is one of the people in your organization that you need, without whom everything would go to hell, you're damned right you should.
This is called taking hostages. I agree, there are some people that are extremely valuable, but if they are such a pain in the ass as to need extra special coddling, shouldn't they be gotten rid of? I mean, come on. We live in a society, not e therapy circle. No situation is worth putting up with _anyone_ who is a total asshole. As to the humanity arguments, you are all correct, but I still think that I am not wrong in wanting to choose the humanity that I acquire, rather than having it foisted on me by having to deal with morons all the time. The point can go on forever, b/c you can never excape morons who talk too much about things that have no relevance.Ahhh you misunderstand the power of the Borg.
This guy has found a way to get the best out of his people, to make sure they can concentrate on their jobs; to be better on their jobs. Is that wrong ? For him, no. And for someone who doesn't think that people should have some intrinsic self-sensoring mechanism that tells them, "I am wasting his/her time and mine by saying this, let me shut up" it is fine too. And point well taken, Money, about it only taking a few minutes out of any one day, but there is all the angst built up while your toes are clenching in your Kenneth Coles. What toll does that take? How much does that cost after 10-years of the same incompetent, slovenly person telling you about the carrots on her desk? And you just taking it? Now it feels like I am the one in therapy!
While it was written as a handbook for social action, it's all about organizing people. And there are plenty of pragmatic tips on how to get people to work outside of their experience. Also, a good discussion of lines of power and degrees of separation. Basically, if Machiavelli left the dark side he would become Saul Alinsky.
My dad works as a music teacher at a college nearby. Although his job is not programming, the same type of thing happened to him - he was "asked" to move up to a management position, with no change of pay, etc. Much to his surprise, he found that he really did like doing some administration stuff. Perhaps he still enjoys teaching a little more, but at least it wasn't an awful, horid experience. So, I would say, give it a go! You might just like it.
In more than one company that I have done consulting/contracting work, this is the definite trend - business analysts, project managers (most who know nothing of the technical details of a system from even a high level ...) are valued and have salaries/rates that now are on par with the most talented of the programmers ... now, granted, most of my work has been done not at software companies, but banks, big insurance companies, utilites, manufacturing firms, etc ... but I see the programmmers being increasingly looked at as "rote and repetitive" drones that are easily "out-tasked" to cheaper substitutes ... and it is quite amusing to me, as a lot of the code that powers these companies is really, really old - and new fixes/enhancements/features are just kludged on top of eachother to the point that so many questions are asked by business users who don't even know the business rules of the systems tools they use for their job everyday! The rules are "embedded" within the code, and any "human" knowledge dissipated off to higher postions or new jobs, or ...
I agree totally with your perspective, but the CIO of most large firms see things from a different perspective ... their focus seems solely on "lowering cost" to the business operational user - without truly analyzing the real reason that costs have become so bloated (i.e., redundant systems, under-experienced contract houses building systems, extreme bureaucratic hurdles - in fact, the shop I presently consult for makes me fill out 25+ ISPF panels, dozens of panels for source version control, Lotus notes notifications, etc ... most of my time is spent "crossing T's and dotting I's" ... but the fix is to "throw the baby out with the bath water" - instead of looking at the processes of software development, the easy fix is to just find cheaper programmers ... though in the long run many of us know that this is a recipe for diesaster for the company ...
Even little things like smaller office space, less bonuses for programmers ... what is funny that is for a lot of developers or whatever technology is "hot", this all might not be true ... but all is cyclical (again, I don't speak for firms that their only product is "software" ...) ...
<rant off>
AZspot
Telephone calls, meetings, interviews ...
I am in the exact same position as this guy. 3 months ago I moved into a management position. I am resposible for hiring, budget, business development, and day to day operations. There is one other manager at my level with no technical knowledge whatsoever. We report directly to the senior management.
This is in direct contrast to what I did previously, working part-time and coding from home.
From my _brief_ experience, here are some observations:
a. Forget about coding. You'll be surprised how busy you will be with phone calls, meetings, and interviews. You won't be able to keep any set schedule. Issues pop up all the time, and you have to resolve them. It's surprising how people avoid making decisions.
2. Forget about a sense of accomplishment. Coding gives a tangible sense of accomplishment every day, and huge loads of accomplishment when you finish projects. You won't have that feeling any more, because it doesn't seem like you are doing any work.
d. Get used to complaining. People love to complain and it puts you in a seemingly impossible position.
And, to counter those observations, some advice:
$. Draw the line early. One thing I have noticed is that you are ready and willing, people will continue to dump work into your lap until you can't effectively do anything. Do what you can to remain effective, know your limits, delegate as much responsibility as your team can take. Whatever you do, lay down the grounds rules, and if there is something you don't want to do, don't do it. The chief engineer in my first tech job was great - he went home at 4:30 pm every day, NO exceptions. I wish I could do the same.
X. Insist on coding. Choose projects or parts of projects and code them yourself. You may have to get out of the office to do this. Either way, you're a manager, so you're empowered to make decisions. Make it clear that you are working on a project and are not to be disturbed.
This is key to keeping yourself on both tracks. (Aside: the great thing about the GPL is that it takes power out of the hands of the corporation and puts it into the hands of the programmer. You have to know the code to benefit from it.) The best way to keep up with the technology, and keep yourself in high demand, is to know how to use it.
[]. Get good people. (and the contrapositive, get rid of bad people). I cannot stress how important this is - take the extra time to get good employees, and make them happy enough to stay. Making them happy is not just $, it's also giving them a challenging working environment, keeping them learning, and being a good listener.
Want a simple test of whether your staff is working well? Spend three days at home coding (or vacation or whatever). Make sure everyone is aware you are doing this. When you get back to the office, what state is it in? If it is a clusterf$ck, you'll know pretty quickly who is not pulling their weight. If it's running smoothly, you'll know pretty quickly who was pulling the strings when you were gone. The ideas is to reduce the amount of the former and increase the amount of the latter.
Or, you can think of it like a software developer: when coding, if you code something twice, you put it into a function, and don't have to do it again. Management is no different, except that the transfer function between input and output is a little more complicated than the box in front of you. Recognize similar problems and build functions to handle them - then delegate the functions to staff. Soon, the management will be evenly distributed, and everyone will have time to focus on what they do best.
Whatever you do, remember that the manager is on the list of endangered species, so keep getting your hands dirty as much as you can.
g
Perhaps you could print out this /. article, and show them just how much some techies dislike the thought of moving into management - this could be a shock to many of them; if they're motivated by money and "position" they may well think you are too.
If they insist, you could agree to do it on a trial or temporary basis. Instead of trying to manage for 20% of the time (which will be very difficult), agree to do it for a fixed period - say six months, or for the lifecycle of a particular project. Make them understand you're serious about this being temporary.
This gives you enough time to really get a feel for management, but gives you a way back into techiedom - "I said I'd try it for six months, and I meant it".
Given the current shortage of training^H^H^H^H^H^H^H^H IT specialists nowadays, you should be in a good position to get a techie job back without having to leave. Remember, you're senior enough, and sufficiently well thought of to have been offered a move into management in the first place.
Promotion to a position of responsibility from the technical ranks is not "inevitable" at all. If it happens, especially if it happens early (say in your first 10 years), it distinguishes you as "one of the good ones." Someone voted for you by sharing money and prestige with you -- the real marbles in the game. The value of that for your future can hardly be overstated.
That's why I always recommend that techies seek to deserve promotion to management and accept the position when it is offered. A management job is a great learning experience, great resume fodder, and maybe a great new career path. You really can't lose.
Is it written in stone somewhere that you have to accept a promotion? Treat an offer of promotion as the starting point in a negotiation. Find out what's behind the offer. Management may be trying to "reward" you. Intead, ask for money/time off/a neat conference instead. That's worked for several friends. Or, they may be trying to fill a hole. If you don't want that hole, say so. "Accept this promotion or you're outta here" is pretty rare in my world.
After the age of thirty going home to your spouse or signifgant other might seem like a whole better way to live than sleeping in a cubilcle. Leaving the office while there is still light out is quite nice to. The number of young talented people with the latest skills an willingness to spend large numbers of hours in the office probalbly outnumbers the number of talented managers. Besides insted of joining a project that you find interesting you may get the chance to start the projects that interest you.
By definition, a government has no conscience. Sometimes it has a policy, but nothing more. - Albert Camus
I like to code. I like designing even better, but I also like to manage. Not because I get my kicks out of being "the boss", but because I am good at managing projects. Most of all I enjoy producing quality software and management is inevitable part of it -- just as desigining, coding and testing.
I agree. Don't forget Covey's other book, "Principle-Centered Management."
It's another good one that focuses explicitly on the topic at hand.
include $sig;
1;
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.
Remember that power is not something that's given you...power is something you take. (Jock Ewing)
If you have the title of manager, take the authority, take risks, tell people what they need (not want) to hear, and give your people what they need to do their jobs. If you're not doing these things (even if it goes beyond what upper mgmt. wants you to do), you're plainly ineffective. It's easier to ask for forgiveness than it is to ask for permission. Do what a good manager should do, *not* what clean-arse higher-uppity types think you should do.
A great manager understands, facilitates, demands and protects. With a smile on their face.
Steve Magruder
Steve Magruder, Metro Foodist
Come on, you've been fighting 'fires' for ten years, You will slide into that no problem. I did did after 7.
While I've no doubt that you have had a terrible experience I can tell you it's been the opposite for me. I developed for years for my current employer and eventually was offered a choice: take a leadership role or they'd have to bring someone new as my leader. I had already seen our 8 man company grow to 30 - including two folks between me and the top - there was no way I could allow this trend would continue. I faced leadership the same way I faced my develoment role -> head on and eager to dominate!
Fortunately for me my boss is a good guy - so long as he thinks I'm trying hard and doing at least a decent job he leaves his door open and stays out of my way.
It's sad you feel this way -> but it would be tragic of only idiots took jobs as managers as then developers would forever be dealing with... well... dilbert style managers.
-----
As a manager coming from a development position I play a critical role in deciding if, when and which companies we should acquire. This involves meeting with the managers and developers of prospects and discussing their designs so I can evaluate their technology as well as their skills. I realize that not everyone would find this exciting ...
Finally this did all come at a price. I have more than quadrupled the number of stock options I have vesting and my salary has more than doubled over the last 5 years. I have gotten three promotions in as many years. Finally on this point I would point out that I took a 30% pay cut to go from consultant to FTE when I first started and I've made about 5000 years of consultant fees in the 5 years since. I work today because I WANT TO DO MY JOB and not because of any financial constraints whatsoever. I'm here on slashdot Sunday morning because I WANT TO.
To paint a complete picture I present the downside as well. I have had as many as 15 employees under my supervision and that took nearly 50% of my time - I think I am lucky here because all my engineers are technically strong - or at least capable of fulfilling their duties so I need only manage their happiness, careers, and any politics that may creep into our space. The fact that I was a developer along side many of them helps inspire confidence in them. Probably the shittiest part of my job is protecting my team from folks outside of engineering - although I feel good about protecting who I was from who I didn't want to deal with. There are also the occasional service escalations [fires] - these used to razzle me but after some experience I realize that so long as I do the right thing [usually obvious] it's usually just a quick decision and some delegation to the team.
If you don't want to be a manager and you are a capable developer the odds are quite good you can stay at your current position. You certainly don't have to go into management - but it can be a shitload of fun.
-----
These may be my opinions, you don't have to share yours
-----
Where I work it's all about forced anal sex. I'd rather not talk about it.
--Giving to trolls for the benefit of us all
Is it true that the dark side is more powerful?
True it is, and the hours you work are less. Only when you wear a suit a true manager will you be.
I made the move from pure technical (software developer) to management about 5 years ago and discovered about a year ago that I hated my work life.
For me the fix was leaving my position as a technical project manager and becoming a programming grunt at an internet startup.
What surprised me the most was that I could make more money in today's market as a software developer than as a project manager. Go figure.
--- -- - -
Give me LIBERTY, or give me a check.
Ditch the macho politics (Who Dares Wins etc.) and new-age stuff (7 Habits).
Ditch even those books that are very good books, but really not relevant to management (Machiavelli, Sun Tzu) - these are just flogged to managers to flatter them. They don't tell you about managing people, they just make you paranoid and up-tight (unless you're really high up in the politics).
Read Peopleware by DeMarco and Lister, Debugging the Development Process (yeah, its an MS book but its well written and gets to the points clearly), and one or two SHORT books on software process management. Maybe read The One Minute Manager (but not all the followups) to get a good base on how to tell people "you did good/bad" in a way that doesn't confuse them or you.
Then try to apply what you've learnt so far, before going on to learn more. Don't try to get to jump straight to SEI Maturity Level 5 in one step. Don't try to be a complete manager on day one. You'll be busy trying to do work without reading 75 odd books.
Most importantly, gradually release the "I'm the chief developer here" role, as a manager you must let other people know more than you, be smarter than you, be closer to the implementation than you (it will happen, so you might as well encourage it rather than fight it). Groom your replacement for the role you had. Give your team chances to impress you, and tell them when it happens. Remember "If I treat my team like idiots, I'll only get a team of idiots". Remember that the project plan is only a picture of what you thought the future would look like, it's not reality. And relax...
And if that would work in the real world it would be a good idea. So where are you a manager at again? :)
"My job is being right when other people are wrong." -- George Bernard Shaw
You can stay where you are, or you can move. You can move out, or you can move up. It's you choice. Does it mean that that you should not move? I don't think so...
This book can nearly always be recommended, whatever the need is ..
;-).
Sun Tzu: The Art of War
And if you do want a more laid-back approach to your managementstudies, you could always stack up a bunch of Dilbert comics
If you can't write it, you can't design it. So designing is part of the process. It's simply telling beforehand what you are going to try. But then again, you're most likely going to end up with a different strategy, because your original idea has run into insurmountable obstacles. Designing is an iterative process very closely linked with coding. You can't separate both.
Testing consists in writing test modules that continuously challenging (your own, or someone else's) assumptions under different conditions. You can't test, if you can't write. So it's part of the process.
Management is stating what end result must be attained by the functionality of the code, by which resources and by what end date; then staff the team accordingly; and periodically find out if things are still on track. Management is not part of the process.
Most often management doesn't even understand the process; and the more they interfere, the more likely things will go wrong.
I haven't read the book. I actually got the term from a song "The holy fire that bombards the heavens", by the Scene. (The song is in Dutch)
The waterfall life cycle of a project has been dead for decades now. You must be prepared to redo things or else miserably fail.
The one, single, main reason for total project failure is the inability of management to face the truth and agree to redo the things that didn't work out as planned. Even though it sounds extremely tempting, just continuing according to plan, is not an option.
You can always do what I did in 1979 when it happened to me. Leave the industry and take up blue collar work. I have never regretted either the work or the money but I did spit a few chips when IBM released a computer to which they didn't own the rights. I'm not seriously suggesting that you do what I did but I did honestly do it. You don't have to take the job. You don't have to be promoted. You are part of a team so someone else will be promoted and you not depriving anyone. You are going there because you choose to. Either admit it and go, or spit the dummy (Australian for 'say no emphatically') and stay where you are. After twentysix years in and following the industry I'd say take the new job. New fields make new horizons. Good Luck.
I work in a so called "software service company".I have seen managers with '0' technical knowledge being brought into the company much to the horror of my team members.This happens due to the lack of technically experienced people willing to come forward to accept such responsibilities.Given the fact that you have 10 years of technical expertise my team mates would be happy to have u as our manager...interested ? :-)
There are a couple of books that I have read that have given me real insight and inspiration into the whole software management thing (I say 'inspiration' since with software projects being "always late", who would want to be managing them!)
The first is "Debugging the Development Process" by Steve Maguire (ISBN: 1556156502). This is a great book! Even if your company doesn't follow the development strategies he outlines, the team management strategies are great! Steve is also the one that wrote 'Code Complete'; Steve is someone who started a techie and then learnt all sorts of things about running software projects.
While I'm on Steve's bandwangon, I *highly* recommend "Software Project Survival Guide" (ISBN: 1572316217). An awesome read.
(Also, while you are at it, checkout out his other books, I've got them all and they are quite good).
The other book I'd recommend is "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis" (ISBN: 0471197130). As well as having some great techie-level advice, it has some interesting management-level rules-of-thumb that no-one in the software profession (techie or not) should be without.
Good luck, hope that helps!
It's worth the investment in time and effort.
Should you do it?
What do you want to be? I'm way past middle-aged and have been in this since Hollerith cards. I'm a techie and I have been a manager and now do NOT put the latter on my resume because as soon as potential employers see it they start slobbering like they've found the Holy Grail. Which maybe they have because I have never never seen someone who is good at both tech and management. Oh, some think they are great at both but inevitably they give short shrift to one or the other and just don't see the problem in themselves. I'm convinced that the skillsets for tech and management are diametrically opposed.
If it's money you want and you're a good guy technically -- really good -- you will probably hurt yourself by going into management. I make more than my boss and his boss and because of the pay I get it's in their best interests not to bother me with trivialities. Good techs are replaced much less often than managers; if you know that you can exploit it to get the money, tools and assignments you want.
As I said, I did a stint as a manager and according to my boss and most people I managed, I wasn't bad. I could've been better, but it wasn't what I wanted to do with my life. The guy who said in his comment that you should do the management job so you could do what you really wanted to do (code) in your off-hours is just silly. It's much nicer to do what you want to do and get paid for it.
One thing you say makes me suspect your bosses haven't got the best motives: that you'll only have to spend 20% of your time doing management tasks. Malarkey. What you describe will consume at least 75% - 95% of your time, probably with a median of 80% or so. Are they deluded or lying to you? Either way, something's wrong here.
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
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.
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
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.