Moving From Tech Into Management? 175
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."
A Canticle For Management (Score:1)
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 [fatbrain.com] is a great piece of work, as is Karl Wiegers' Software Requirements [fatbrain.com]. Probably the classic work on software development is Brooks' The Mythical Man-Month [fatbrain.com], which has been updated with recent content reflecting the rise of OO methodology. Lientz and Rea's Breakthrough Technology Project Management [fatbrain.com] is a much better book than its title suggests, while Liberty's Clouds to Code [fatbrain.com] 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 [fatbrain.com], which should appeal to your quantitative side; Goldratt's constraint-theory masterpiece The Goal [fatbrain.com] 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!
The Third Alternative - Technical Leadership (Score:1)
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 [mailto]
Not promotion (Score:1)
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.
Re:Use OTHER people's experience. There's plenty. (Score:1)
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.
Go for it... (Score:1)
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 [ncsu.edu].
Re:The nature of software development ... (Score:1)
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 [ncsu.edu].
Re:The nature of software development ... (Score:1)
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 [ncsu.edu].
Oh please... (Score:1)
Poliics, politics and meetings. Politics with lunch. Politics when you come back from vacation.
This is what it is to be a manager, really. :(
H1Bs and getting "forced" intomanagement (Score:1)
Woof.
20% is too little (Score:1)
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
Golden Rule of Management (Score:1)
Same problem (Score:1)
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...
managers (Score:1)
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.
Avoid Mgmt! Go solo! (Score:1)
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 [cpuniverse.com]" 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...
Re:No Sweat (Score:1)
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!
Re:Use OTHER people's experience. There's plenty. (Score:1)
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 ?
Recommended Books & Practices (Score:1)
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
Re:A technically compentent manager is excellent! (Score:1)
While I realize this doesn't work for everyone, it does definitely work for me.
Re:Why not.? (Score:1)
Re:Consider carefully (Score:1)
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.
Two things that will let you make the move (Score:1)
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.
-----
Re:Consider your books... (Score:1)
If you think that, you really should try PERL. Have fun
----------------------------------------------
Don't expect it to be easy (Score:1)
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.
An excellent resource (Score:1)
Re:Good book (Score:1)
Re:How To Manage (Score:1)
And give them raises if they are! Those are the employees that you want to keep working for you.
Well, bulls***! (Score:1)
OTOH, if your management is great, then you might enjoy joining them. Do what feels most right....
Get a degree (Score:1)
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!!)
Re:Don't do it, man! (Score:1)
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.
same thing happening to me (Score:1)
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 [utoronto.ca]
You do have experience... (Score:1)
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
Been there, done that (Score:1)
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
Do it! (Score:1)
Re:A good tech doesn't have to downgrade (Score:1)
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
Re:So don't be a pointy haired boss (Score:1)
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
Re:been there, done that (Score:1)
"ADD" - wossat?
I say GO FOR IT! (Score:1)
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!
7 Habits (Score:2)
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
Consider your books... (Score:2)
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
Re:Old after 10 years ? (Score:2)
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.
Software Development Management can be fun! (Score:2)
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!
Re:Old after 10 years ? (Score:2)
Some advice, a warning, and some books (Score:2)
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
Having just made the move myself.. (Score:2)
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,
Re:Old after 10 years ? (Score:2)
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...
--
Re:The Prince by Machiavelli??! (Score:2)
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.
how (RECOMMENDED BOOK) and why to switch to mgmt (Score:2)
Other good reads: Jim Coplien [bell-labs.com]'s organization patterns [bell-labs.com] (don't worry about the word "process," Cope doesn't believe that process generates quality), also found in the first PLoP book [fatbrain.com]; DeMarco's The Deadline: A Novel About Project Management [fatbrain.com]; maybe Jerry Weinberg's The Psychology of Computer Programming [fatbrain.com]; 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
Re:Use OTHER people's experience. There's plenty. (Score:2)
[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 [amazon.com] [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.
Re:So don't be a pointy haired boss (Score:2)
Anyway, YMMV. Not all managers are bad. It seems to really depend on what their background was. I have little respect for people who are managers because that's what they majored in in college. In my experience, anyway, that is that major that all the people who couldn't hack something serious take, and it really doesn't teach you anything about managing people that you wouldn't know or easily learn if you had the "knack" for it already.
A technically compentent manager is excellent! (Score:2)
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.
Re:Managers (Score:2)
management isn't a curse... really.
and if you're fired, how many managers have you heard were not given at least a "silver" parachute, if not a "golden" one?
now you know why some managers are incompetent -- they're looking to get fired and get paid a bundle in the process.
-m
Re:Consider carefully (Score:2)
--
Management, Design, and HR crap (Score:2)
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.
Being a Manager (Score:2)
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.
Re:Consider carefully (Score:2)
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.
Forget about the 20% (Score:2)
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...
The good parts... (Score:2)
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.
Re:Careful how you straddle the fence (Score:2)
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
Go for it, 'cause you can always QUIT (Score:2)
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
Write the Test Then Design to Test (Score:2)
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.
Re:Train the young jedis, Obi-Wan (Score:2)
a few tips (Score:2)
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.
The Peter Principle: Why things always go wrong (Score:2)
NipokNek
Careful how you straddle the fence (Score:2)
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?
Re:Train the young jedis, Obi-Wan (Score:2)
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
The four books that helped me: (Score:2)
I'm the MIS Director of an Internet firm [ets-inc.com]. 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 [barnesandnoble.com] 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 [barnesandnoble.com] 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 [barnesandnoble.com] 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 [barnesandnoble.com]. 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, [50megs.com]
Yes he should (Score:2)
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!
Old after 10 years ? (Score:2)
It's the begin of the end !
Good luck !
Be a good Coach, a trusted leader (Score:2)
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.
Re:Use OTHER people's experience. There's plenty. (Score:2)
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.
Re:The number one rule for technical team-leading. (Score:2)
Re: (Score:2)
Go Into LEADERSHIP, Not "Management" (Score:2)
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:
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.
Don't do it, man! (Score:2)
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 vs management (Score:2)
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?
The Prince by Machiavelli??! (Score:2)
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".
I wouldn't do it again (Score:2)
Use OTHER people's experience. There's plenty. (Score:2)
If you want some good pointers on where to start, try the book PeopleWare [amazon.com], 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!
Re:A good tech doesn't have to downgrade (Score:3)
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
A good tech doesn't have to downgrade (Score:3)
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.
unwilling manager... (Score:3)
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.
Re:Use OTHER people's experience. There's plenty. (Score:3)
Listening, you feel your toes bunch up in your shoes, that little facial tick you only experianced once durring college finals starts to make your eyelid quiver, and you begin to contemplate the warm joy and solitude of being alone in your cubical and not listening to this conversation for another moment . .then you realise it's gotten so bad that you're pining to be back in the dilbert cube again. But just another 30 seconds, and the conversation drifts back to the topic at hand, and you gently remind him of the task to be done.
Total time? it may seam like a lifetime, but usually it's no more than an extra minute and, you've managed to get through the day without screaming "SHUT THE FUCK UP AND CODE!"
Re:Use OTHER people's experience. There's plenty. (Score:3)
Some people are moody (think NT) and need to be 'rebooted' in order to keep working. Some people are rock solid (think Solaris) and work non-stop without intervention. It's important to know the differance. Why reboot the Solaris box when the NT box locked up?
I have one employee, in particular, that makes it a point to report to me, in fine grained detail, each and every little thing he has done since the last time I saw him. Is this really needed? No. But when I skipped a week listening, he pulled me aside and thought I was mad at him. The lesson? Reporting his position in a project orally gives him the chance to arrange his thoughts. It gives him a sence of accomplishment. If I tryed this with anybody else, they would quickly get bored and think I was micro-managing them to death, but for this particular person, it's needed.
That's really the trick, isn't it? Learning each individuals needs and wants, passions and desires, aspirations and weaknesses the same way software has resource requirements, interoperability issues, and conectivity shortcommings. You've spent years learning how computers work together, now it's time to start learning about a totally differant machine: People.
Why not.? (Score:3)
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.
Read Steve McConnell's Rapid Development (Score:3)
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).
leadership, management and bringing change (Score:3)
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.
Familiar story... Some experiences (Score:3)
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.
Management Is a Philosophy, Not A Job (Score:3)
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 [situational.com].)
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.
The nature of software development ... (Score:3)
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
Not that bad.. (Score:4)
--An outsiders opinion
Re:No Sweat (Score:4)
But even in the best-organized company, your expectation that you will only spend 20% of your time managing is totally unrealistic. This never happens. If you're lucky, you *may* spend close to 50% of your time coding in between taking care of your crew, and as far as I'm concerned, taking care of your crew is a manager's primary responsibility in any field of endeavor from fast food to programming.
I am also a big believer in hands-on leadership; if you spend time working alongside your people you will always have a better grasp of what they are doing than if you are separated from them.
But you will *not* do all that much coding once you start taking responsibility for others' work.
How much have you seen me post on Slashdot lately? And how much do I really write on NewsForge [newsforge.com], our latest site? It's frustrating, because writing is the *fun* part of my job.
But there is also a great deal of satisfaction to be found in helping others do their jobs well. In my case, I work with great people who are also my friends -- the ones you see on Slashdot, NewsForge, Linux.com, and the rest of the OSDN sites -- and what keeps me going on the detail-bogged days is knowing that if I can keep upper-upper management from screwing with Taco, Hemos, Emmett, timothy, and the rest of the gang, I am helping to get more done than if I was simply busting my own ass and not worrying about anything else. Plus, they know what I do and appreciate it. This is the big reward of being a *competent* manager -- kudos from coworkers whose lives you make easier by taking shit they'd otherwise be forced to take themselves. Any extra money you get is nothing compared to the respect and gratitude of the people you work with every day.
I view front-line management as a necessary task, one that *somebody* has to do, and if those of us who have some competence at [coding; writing; art; design; auto repair; you name it] don't take it on, we and all our friends/coworkers will be cursed with incompetent bosses forevermore.
I have never wanted to be in management, and don't really enjoy it. You probably won't like it much either (most of the time). But it's clean indoor work with no heavy lifting, and somebody has to do it, so why not you? :)
Robin 'roblimo' Miller
reluctant editor-in-chief,
Open Source Development Network
been there, done that (Score:4)
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.
Re:Old after 10 years ? (Score:4)
The basic idea of the Peter Principle is that people rise to their level of incompetency.
Y'see, four years ago, Cliff was the best coder his employer had. His employer wanted to reward him.
So they made him the project lead. There was a bit of a pay increase, and there's certain prestige in being the project lead.
Well, Cliff is a darn good project lead. Not the best the company has ever had, but certainly toward the front of the pack. It's been four years, and it's time to reward him again.
So they'll make him management. Cliff won't be programming, but he'll get to review code and assign programming roles and stuff like that.
He'll be okay at it. He's an experienced programmer, so he'll be good at assigning roles. He's not very experienced at managing scheduling, but he'll be okay.
His next promotion will make him middle management. He'll never see code or coders again. He'll be organizing other people.
And he'll do terribly. It'll require skills that outside his expertise.
And that's where the promotions will stop. He'll have risen to his level of incompetency. His employer will have promoted him from his best expertise -- coding -- into a field where he's truly incapable -- middle-level managing.
The Peter Principal is such a refreshing and sensible way of accounting for the people in a company. They were, almost always, extremely good at something -- and so, as a reward, they were promoted until they weren't any good at something completely different.
The system is malicious. Instead of promoting Cliff, they should throw more money at him. He's a great coder -- so let him code!!
--
Re:Train the young jedis, Obi-Wan (Score:4)
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"
Management for those who can (Score:4)
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.
----------
It's not a pleasant experience (Score:5)
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!
Consider carefully (Score:5)
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
Good book (Score:5)
Believe it or not, the book Corps Business: Management Principles of the U.S. Marines [barnesandnoble.com] 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
Train the young jedis, Obi-Wan (Score:5)
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
The number one rule for technical team-leading. (Score:5)
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.