Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Moving From Tech Into Management? 175

Posted by Cliff from the becomming-a-B-without-growing-the-PH dept.
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."
This discussion has been archived. No new comments can be posted.

Moving from Tech into Management? More

Moving from Tech into Management?

Comments Filter:

  • A Canticle For Management (Score:1)

    by Anonymous Coward
    Management can be an enjoyable, rewarding experience. It can also be a miserable slog through dozens of death marches and dying projects. It all depends on how you approach it.

    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!

  • 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)

    by Anonymous Coward
    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 [ncsu.edu].
  • 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 [ncsu.edu].
  • 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 [ncsu.edu].
  • Yeah, if you WANT to be "that guy", go ahead and do it. It's a concious decision wether you become the guy that simply sits back and writes the schedule, or if you're actually a respected and commanding force that makes the lives of the techies you manage enjoyable. It's your choice really. As far as getting in to the role, get ready to deal with a lot more politics than you're used to.

    Poliics, politics and meetings. Politics with lunch. Politics when you come back from vacation.

    This is what it is to be a manager, really. :(

  • 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.

  • 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.
  • 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...
  • 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 [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...
  • 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.

    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!

  • It sounds like you are more of a therapist than a manager

    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 ?

  • I highly recommend
    Steve Macguire "Debugging the development process"
    and
    Leavitt et al. "Readings in Managerial Psychology"
    as well as "The Mythical Man Month" if you have not read it already.

    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.
    -----
  • ... us techies, with our logical, orderly "there is one correct answer" orientation ...

    If you think that, you really should try PERL. Have fun :)

    ----------------------------------------------
  • 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.
  • 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."
  • 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.
  • 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 [utoronto.ca]
  • 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
  • You should, without question, do it. Why?
    • 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%. :-) ) Make sure that your responsibilities are clear before you sign up. You also asked for books I liked. These have come in handy for me:
    • Getting To Yes: Negotiating Agreement Without Giving In, Roger Fisher - A great general book on negotiating, a skill you'll soon need a lot.
    • Rapid Development, Steve McConnell - A great book for you, and a great one to hand to PHBs when they ask you to do something impossible. Full of useful statistics that help you defend your decisions, like, "This study showed that 73% of projects that [did stupid thing X] failed utterly."
    • The Mythical Man-Month, Fred Brooks - Deservedly, a classic.
    • Extreme Programming, Kent Beck - If this fits with your product life-cycle, many of these techniques can be great.
  • 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
  • He never tried to make it look like he knew more than he did - he didnt know jack about making the details work

    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

  • > "ADD" people, strangely enough - the best programmers

    "ADD" - wossat?

  • 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!

  • 7 Habits (Score:2)

    by Anonymous Coward
    I strongly recommend you read Stephen Covey's The 7 Habits of Highly Effective People. If you can manage not to be grossed out by the buzzword bingo that can be played (It sickens me to the point that, while I normally read a book in a day, it's taken me weeks to finish this one), it has a whole lot of useful ideas. It's just the writing that's awful.

    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

  • One thing to beware of is your choice of management books. There's a lot of "fad" books out there that purport to tell techies how to become good managers of technical projects. I've seen a good programmer thrash ridiculously from fad to fad as he tried to manage a technical project, depending upon which book he'd last read. The fact of the matter is that management is a messy seat-of-the-pants operation in many respects, and us techies, with our logical, orderly "there is one correct answer" orientation, are generally ill-suited for management.

    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

  • 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.

    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
  • to 'managing' a fire team of 4 sysadmins (love that term, 'fire team' ;) about 4 months ago, things have gotten interesting... here's a few notes:

    • I've taken to a kind of 'primus inter pares' or 'president pro temp' role when it comes to tech stuff. The guys know what they're doing, I trust their judgement when it comes to tech, I just keep a handle on what they're doing and try to provide some 'direction' (as in, here's where we want to be in 1 month, 3 months, etc..)
    • I don't really monitor the outstanding task list or the nittiest of gritty, I end up relying on feedback from outside the group, which is probably the right way of doing it.
    • The key thing I offer my superiors in the management arena is the ability to deconstruct technical concepts, using metaphor and ample explanation, and make legitimate arguments for or against technologies/processes. This is often not what they want to hear (for example: they wanted to consider rewiring our floors 'wirelessly'. There's between 60 and 120 people per floor. "We're supposed to be a wireless broadband company!" Took quite an effort to disabuse them of the practicality of a 802.11 NIC for each CPU and hubs for every 10 users)
    • Our communication is IMHO excellent, because I try to foster an atmosphere where people can discuss things without worrying about offending anyone or saying the wrong thing. As a great American philosopher once said, "there are no stupid questions, only stupid people" ;)
    • People liken managing tech groups to herding cats. Wrong. Herding cats is easier: at least they're lazy enough to head towards a single food source.. Tech guys (myself included) can easily hop from raise to raise. I personally believe that fostering the kind of environment/culture that keeps people happy and wanting to come to work is my key function. When we've got too much to do, there's no time to think about leaving. When we're on downtime, there's Quake3/Homeworld/Age of Empires at 5:31pm.. Basically, I'm trying to have the group dynamic I've always want to work in. Now's my chance.
    • Never ask someone to do something above-and-beyond if you aren't willing to do it yourself. If someone needs to come in on a weekend for something you can't do (NT stuff in my case), be there. Bring coffee, go out for lunch, cheerlead but don't be underfoot. Push for as much remote admin as possible, as much reduction of drudgery as possible. Call it 'reducing downtime' or 'reducing opportunity for human error' to sell it to your boss. Even better: simply allude to the job market and the need to retain good people (they're hard enough to find).. Luckily, one of the key criteria in analyzing my corp's industry is employee retension, and we're currently one of the best if not the best in our group.. With the stock being what it is, we really don't need one of our key indicators going south...
    • Humor, keep 'em laughing while they're toiling, if you can. Joking at best, Gallows humor at worst.
    • I'm not sure which is better: being in the same room/area with your team or not. I think being in the same room is better, but you have to keep the concept of 'going native' in mind, and remember what's practical for the company may not make your roomates happy. The best fix for this would probably be to have fairly consistent and well-known ways of thinking of things, so that the team (and those above/around you) have a good idea of where you're coming from.
    • Thank goodness I only have to evaluate, not decide on raises. Still, when evaluation time comes, if you don't already know how you feel about your guys you aren't doing your job. Have an informal chat or two before formal evaluations, if you (and (s|)he) are comfortable (which you should be if you're doing your job) so that you both know how they'll go down.
    • Proper spelling and grammar help when corresponding with non-techies. I should take some time to improve mine! ;)


    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...

    --
  • 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.
  • Great book, possibly the best, on what makes software development organizations work: Peopleware by DeMarco and Lister [fatbrain.com]. (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.)

    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 ... remember how many choices you really have. --PSRC
  • While I also heavily recommend reading PeolpleWare [amazon.com], you might want to start with The Deadline: A Novel About Project Management [amazon.com], 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 [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.
  • Well, I once worked at a mission-critical transaction processing software company in tech support, and both of my managers were very good at handling support calls that got escalated to them. Neither of them started out as managers. (Neither of them seemed to be really good at managing itself, as office and customer politics were a large influence in why I left.) I now work for a GIS firm, and my boss is an ex-techie. His name is all over the entire code base, and he is a very competent programmer. So far, he seems to be an extremely effective manager as well. That, or else my new company just doesn't have office politics that touch my job.

    Anyway, YMMV. Not all managers are bad. It seems to really depend on what their background was. I have little respect for people who are managers because that's what they majored in in college. In my experience, anyway, that is that major that all the people who couldn't hack something serious take, and it really doesn't teach you anything about managing people that you wouldn't know or easily learn if you had the "knack" for it already.
  • I'm in the odd position of working in a department where I'm temporarily "on loan" to a new manager. My original manager is technically excellent - one of the most knowledgable people in his field, and in addition to that, he is extremely dedicated and efficient. He leads by example and expects us to do our best. We do. It's a pleasure to work for him.

    The new manager I'm working for is probably a more experienced manager, and is certainly good at organising things, but he lacks the technical knowledge. I don't like working for someone who knows less than I do, and that's possibly the feeling for many of us. Slashdot readers are typically "techies" and proud of it. This is perhaps where the concept of a "suit" comes from - someone who may be good at managing, but doesn't really understand the technology. I have to confess to finding it difficult to give the same level of respect to my new manager.

    What I'm trying to get at is if you are a "techie" in charge of other "techies", then as long as your experience is credible, they will enjoy working for you, and will want to work for you. You can build up a very loyal team this way that really pull their weight.
  • it's about time i read someone else out there is on the same path as i am.

    management isn't a curse... really.

    and if you're fired, how many managers have you heard were not given at least a "silver" parachute, if not a "golden" one?

    now you know why some managers are incompetent -- they're looking to get fired and get paid a bundle in the process.

    -m
  • There are three things that managers do:

    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.
  • 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:

    1. The president, to whom I report directly, is of the opinion that the best managers are the ones who can afford to walk around, harassing the employees with trivia questions and requests for snacks. If you have the time to do so, then you've properly delegated the work for your department, and are free to do the primary function of your job, which is management and supervision - making decisions and seeing that they're carried out.
    2. As manager, you get to design projects, set deadlines, and assign tasks, and generally make people do for you those things you used to do yourself. While this sounds like death for a programmer, it means that you can assign tasks to yourself, thus taking part in a project; it also means that the larger tasks, like designing specs and choosing strategies for the development of the system are yours, and they can be just as challenging as coding.
    3. As a manager, you get to tell other people 'no'. "No, the IT department will not add another report to that system for you - there's four like it already"; "no, the network isn't slow - it's that desktop-background-changing program you have on all the time, and the set of special muppets cursors"; "no, inventory is off because your staff refuses to use the scanners correctly - here's the records".
    4. There's a different kind of reward as a manager. That reward comes when you've designed and delegated a four person project, and on the deadline, are looking at a finished product that's ready to deploy according to your standards. That's rewarding.
    5. The mickey-mouse, personal politics bullshit isn't really any worse at the management level than it is at the bottom; it just takes a slightly different form, and it's still up to you how much or little you play.
    6. It's nice to get others working productively, and be able to treat them as well as you think you should have been treated when you were among them. In my case, this includes signing authority for a certain amount that allows me to buy things like manuals, RAM, spare components, and all the mickey-mouse shit that the old manager used to spend a week evaluating. It also means going to the manager of accounting and getting her to sign off on a new server when we need it. It also means taking the department out for lunch or beers after work sometimes.

    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.

  • > 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

  • Since you are mixing management and technical work, you have an excellent opportunity to focus on team management via a design-to-test strategy.

    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.

  • 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

  • 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?

  • You forgot the cherry on top of the cake: become the envy of all the top management. They simply loathe to have someone so much younger, so much brighter, and especially so much RESPECTED by the young engineers...

    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 [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]
  • 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.

    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 !
  • Unfortunately, things have changed a lot in the last 10 years. Foremost is the idea of what management's role is supposed to be.

    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.
  • Comment removed based on user account deletion
  • The concept of "management" is based upon an incorrect assumption, that people must be watched over, controlled, and dominated.

    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.


  • You make the change you become one of "them"!

    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".

  • 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 ...
  • 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 [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)

    by Eric Green ( 627 ) on Sunday September 24, 2000 @10:49AM (#758470) Homepage
    There is something to be said for creating a product from scratch -- defining its feature set in a competitive matrix, deciding its basic architecture, figuring out how to allocate the available resources in the most effective manner to actually get the product created, decide what language or languages will be used to meet the various criteria, etc. You will not (usually) do this as an ordinary techie in most companies. You'll need to be at least a team leader to be able to do this -- and that's a management position, bucko.

    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)

    by Morgaine ( 4316 ) on Sunday September 24, 2000 @04:26AM (#758471)
    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.

  • unwilling manager... (Score:3)

    by capsteve ( 4595 ) on Sunday September 24, 2000 @05:11AM (#758472) Homepage Journal
    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.

  • Re:Use OTHER people's experience. There's plenty. (Score:3)

    by Money__ ( 87045 ) on Sunday September 24, 2000 @05:11AM (#758473)
    You're absolutly right. These conversations are as grating as fingernails down the chalkboard in yoga class . ."And then I was thinking maybe we're skipping the simple stuff, but just poping the stack? that's to easy..so then, when I went to adjust my chair, the little knob broke off and when I went to get another chair from an empty cubical, I thought I would call my cousin who works at the chair company, who can get us this really great deal on chairs, and I'm talking about the good kind, the kind his kid likes...and did I tell you his kid worked for netscape? pretty cool huh? of course, JWZ was the last cool guy to work there, they're all AOLheads now..and now my little sister got AOL and . . ."

    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)

    by Money__ ( 87045 ) on Sunday September 24, 2000 @04:25AM (#758474)
    This is an insightfull post. I manage a teamand every day, regardless of what's on my plate, I make it a point to talk one on one with each of them, on any topic. I spend most of the conversation listening and watching body language for signs of stress, discomfort with co-workers, or frustration with the job. Just listening.

    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)

    by gargle ( 97883 ) on Sunday September 24, 2000 @02:57AM (#758475) Homepage
    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.

  • Read Steve McConnell's Rapid Development (Score:3)

    by hyssop ( 106019 ) on Sunday September 24, 2000 @05:44AM (#758476)

    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).

  • Remember that there is a distinction between leadership and management. A leader is followed. A manager looks after resources. A manager may also be a great leader. A leader may be a terrible manager. Sometimes it's hard to distinguish the difference.

    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)

    by kxr ( 176150 ) on Sunday September 24, 2000 @03:57AM (#758478)

    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.

  • The good news is, you've probably already been in management and didn't know it. Now you're just getting the chance to work without the net.

    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:

    • Money may bring people into the office each morning, but it can't make them do their best work. For that, they need to feel like they're on a mission, and that you have given them the tools and the autonomy to succeed.
    • Different people will need different amounts of help. Even the same person may need different kinds of help for different jobs. Adjust your strategies to each person, not each person to your strategies.
    • When someone tells you they want to leave, let them go. There are enough jobs in the world that no one has to be working on something they don't like.
    • When hiring, place more emphasis on finding people who share your corporate and personal values than on those who have the perfect technical skills. Technical skills are much easier to teach than values.
    • Be strictly fair with people. Never allow race, religion, politics, sexual preference, or anything else that isn't directly related to the job to come into your hiring and firing decisions.
    • There are basically two kinds of job skills: technical and emotional. Gaps in technical skills are addressed by training, gaps in emotional skills are addressed by coaching. People with no gaps are rare and precious; treat them well and delegate to them freely.
    • Create a good relationship with your team members, but don't try to be their friend. If they think of you as a friend, they'll take advantage of that friendship to avoid being challenged.
    • Your primary responsibility hasn't changed: job #1 is still to make the boss look good.
    • Fight for your team. Make sure they have the tools and the time to do their best work.
    • Challenge your team. Make them improve their work by sharing it with each other and learning from one another's mistakes.
    • Don't walk around looking for things to punish. Instead, search for things to praise. What you praise you'll get more of. What you punish simply goes underground.
    • Give them structure: teach them how to make changes safely, and when no changes are safe.
    • Realize that software is never done, but sometimes it's shippable. Work to keep the code in shippable condition as often as possible.
    • Create a culture of early bug detection. Find problems before QA does. Fix them before anyone notices them. Document them so that you don't do them again. Create tests for them to make sure.

    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)

    by Bezanti ( 235957 ) on Sunday September 24, 2000 @02:49AM (#758480)
    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 ...

  • Not that bad.. (Score:4)

    by Anonymous Coward on Sunday September 24, 2000 @02:23AM (#758481)
    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

  • Re:No Sweat (Score:4)

    by Roblimo ( 357 ) on Sunday September 24, 2000 @05:10AM (#758482) Homepage Journal
    It depends on how you slide, and how far, and how much of your time gets taken up by administrative details like expenditure approvals. That's a company-by-company thing, and I don't know what your company is like in this regard.

    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)

    by joss ( 1346 ) on Sunday September 24, 2000 @03:49AM (#758483) Homepage
    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.

    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/inde x.html

    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)

    by FFFish ( 7567 ) on Sunday September 24, 2000 @07:55AM (#758484) Homepage
    Could be the Peter Principle at work.

    The basic idea of the Peter Principle is that people rise to their level of incompetency.

    Y'see, four years ago, Cliff was the best coder his employer had. His employer wanted to reward him.

    So they made him the project lead. There was a bit of a pay increase, and there's certain prestige in being the project lead.

    Well, Cliff is a darn good project lead. Not the best the company has ever had, but certainly toward the front of the pack. It's been four years, and it's time to reward him again.

    So they'll make him management. Cliff won't be programming, but he'll get to review code and assign programming roles and stuff like that.

    He'll be okay at it. He's an experienced programmer, so he'll be good at assigning roles. He's not very experienced at managing scheduling, but he'll be okay.

    His next promotion will make him middle management. He'll never see code or coders again. He'll be organizing other people.

    And he'll do terribly. It'll require skills that outside his expertise.

    And that's where the promotions will stop. He'll have risen to his level of incompetency. His employer will have promoted him from his best expertise -- coding -- into a field where he's truly incapable -- middle-level managing.

    The Peter Principal is such a refreshing and sensible way of accounting for the people in a company. They were, almost always, extremely good at something -- and so, as a reward, they were promoted until they weren't any good at something completely different.

    The system is malicious. Instead of promoting Cliff, they should throw more money at him. He's a great coder -- so let him code!!


    --

  • Re:Train the young jedis, Obi-Wan (Score:4)

    by Ratface ( 21117 ) on Sunday September 24, 2000 @03:08AM (#758485) Homepage Journal
    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"

  • Management for those who can (Score:4)

    by Myxx ( 21264 ) on Sunday September 24, 2000 @02:55AM (#758486)
    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.

    ----------

  • It's not a pleasant experience (Score:5)

    by mikeb ( 6025 ) on Sunday September 24, 2000 @02:27AM (#758487) Homepage
    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!

  • Consider carefully (Score:5)

    by smoon ( 16873 ) on Sunday September 24, 2000 @02:41AM (#758488) Homepage
    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

  • Good book (Score:5)

    by kylerk ( 69856 ) on Sunday September 24, 2000 @03:08AM (#758489) Homepage

    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)

    by adapt ( 105738 ) on Sunday September 24, 2000 @02:51AM (#758490) Homepage
    You asked the one million dollar question...

    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)

    by VaguelyBarming ( 162695 ) on Sunday September 24, 2000 @02:13AM (#758491)
    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.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close