Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Programming IT Technology

Transitioning From Developer To Management? 541

An anonymous reader writes "After 15+ years as a code monkey, mostly doing back-end systems design / development, I was surprised by recent developments at my workplace that have resulted in my being transitioned into a dual architect / managerial role within the next few weeks. While I am somewhat confident at this point in my career in my experience and training for an architect-type position, I have serious concerns about being able to properly fulfill the role as manager. Aside from 'Become a manager in 2 days' type books, what resources would you recommend I look to for guidance in this transition?"
This discussion has been archived. No new comments can be posted.

Transitioning From Developer To Management?

Comments Filter:
  • Recommend (Score:5, Funny)

    by blantonl ( 784786 ) on Tuesday August 28, 2007 @06:43PM (#20391223) Homepage
    >> what resources would you recommend I look to for guidance in this transition

    A comb for the pointy-hair on the sides of your head and wax for the shinny top.
    • Re: (Score:2, Funny)

      by Anonymous Coward
      Managers don't really do much of anything. If you have minimal people skills then you should have no trouble acting as a manager.
      • Re:Recommend (Score:5, Insightful)

        by smittyoneeach ( 243267 ) * on Tuesday August 28, 2007 @07:12PM (#20391603) Homepage Journal
        This is akin to saying the metadata in the data dictionary does nothing, only the rows in the tables matter.

        Managers don't really do much of anything.
        This can be true in a passive sense, when a good manager acts as a blast shield to protect the team from things such as
        • scope creep from the customer
        • asinine company policies
        • other marauding managers
        • 60 Minutes, and other quasi-human monsters
        • by no_pets ( 881013 ) on Tuesday August 28, 2007 @07:36PM (#20391837)
          I agree.
          A good manager = a good buffer.

          If you have buffer overflow there will be a heap of unwanted behavior from your employees.
          • Re:Recommend (Score:5, Interesting)

            by __aasyaa1156 ( 1076763 ) on Tuesday August 28, 2007 @09:11PM (#20392807)
            I had this really stupid class in college called "Organizational Behavior". To this day, I still don't know what I was supposed to learn in that class. Despite the class being boring and pointless, the professor was actually a very interesting guy. He said something one time that always stuck with me: "Leadership is the reduction of uncertainty." If you think about it, it's true: your employees have to be certain they are doing the right thing, be certain of the requirements, and be certain they will get the support they need. Your customers have to be certain that you're meeting their needs. If you can do all those things, than you're probably doing a good job.

            I also agree with the "good manager = good buffer" statement, but I'd even take it a step further. Great managers have requirements analysts, support personnel, etc. get the information from the customer. Then they form a plan and assign tasks to their development team. In my experience, this works rather well.

            I'm totally going off on a tangent... back to your original question. Karl Wiegers' Software Requirements and More About Software Requirements are both geared towards requirements analysis, but have a lot of info that anybody in IT (and especially project managers) would find pretty useful... Both are worth checking out. I've also heard lots of praise for The Mythical Man-Month, but I've never gotten a chance to read it. Besides those, I would skip books on general management techniques and go straight for anything on software engineering or project management. The R.S. Pressman [rspa.com] website probably has even more recommendations.
            • Damn (Score:5, Insightful)

              by woolio ( 927141 ) on Wednesday August 29, 2007 @02:11AM (#20394959) Journal
              I had this really stupid class in college called "Organizational Behavior". To this day, I still don't know what I was supposed to learn in that class. Despite the class being boring and pointless, the professor was actually a very interesting guy. He said something one time that always stuck with me: "Leadership is the reduction of uncertainty."

              Damn. I took a similar class. The main things I remember is that "competent employees are promoted until they become uncompetent" and "It is more advantageous to have a technical person doing technical work and an incompetent person doing mangerial work instead of vice-versa".

              • Re:Damn (Score:5, Funny)

                by marcello_dl ( 667940 ) on Wednesday August 29, 2007 @03:42AM (#20395431) Homepage Journal
                "It is more advantageous to have a technical person doing technical work and an incompetent person doing managerial work instead of vice-versa"

                Great, you broke it to him. Such tact.

              • by Jim Hall ( 2985 ) on Wednesday August 29, 2007 @11:01AM (#20398707) Homepage

                I took a similar class. The main things I remember is that "competent employees are promoted until they become uncompetent" and "It is more advantageous to have a technical person doing technical work and an incompetent person doing mangerial work instead of vice-versa".

                While funny, your comment doesn't do much to encourage the OP to move upward into management.

                Effective/successful management is a combination of leadership and management. Management is the process of getting things done, repeatability, auditability, process, etc. Leadership is defining direction, pushing initiatives, etc. A typical boss only does management - you see that all the time. But great bosses are a combination of the two. Note that just being a leader is not a complete picture for a good boss, as nothing really gets done.

                Yes, it is important for the successful manager/leader to not do the technical work. When a manager/leader starts to do that, he or she becomes too focused on the "what are we doing" and isn't able to focus on the "what should we be doing". Yes, as a line manager you need to retain technical skills, but you shouldn't do so by doing programming or sysadmin. I try to encourage people at that level to not get their hands on systems - you hired competent staff to do it. A big part of making the transition into management is learning to let go of some of your current technical duties. I'd advise the OP, when he makes the move into management/leadership, to stop coding. Do your best to avoid giving too-technical requirements - "we'll use an AJAX app to do ___" is less good than "we need to do ___". Let the tech team decide what technology to use. Your job should not involve technical details.

            • Re:Recommend (Score:4, Interesting)

              by jhines0042 ( 184217 ) on Wednesday August 29, 2007 @07:57AM (#20396495) Journal
              I am currently finishing that same class. I agree, I have little clue as to what I was supposed to actually learn.

              Mythical Man Month is a good read, I highly recommend it. Sure, it is full of things that you'll say "no duh" when you get done reading it, but you'll have read it and you'll know for certain not to make those mistakes. Plus you can whip it out when other managers ask you about software stuff and you'll look impressive because they haven't read it.

              I would say this: be lazy. Try to avoid doing anything that makes more work for you and your team than is necessary. That doesn't mean that you should avoid work... it just means that you need to apply yourself and your team in the most efficient way possible.

              I would also say this, don't be afraid to be certain of something and never be afraid to be proven wrong. If someone proves you wrong, concede the point and move on. Don't get stuck following a bad decision with justifications. Get back on track and move on.

              Good luck too!
          • "f you have buffer overflow there will be a heap of unwanted behavior from your employees."

            Too technical of a statement. You are not management material. Add some buzz words that you have not understanding of and you'll be a hit!
        • by EmbeddedJanitor ( 597831 ) on Tuesday August 28, 2007 @09:05PM (#20392757)
          The oil in an engine does not do anything that actively makes power, yet it helps by making the engine run smoothly and protects the engine as well as the parts inside it.

          The best managers reasise that employees don't work "for them", but instead they work for the employees, helping get rid of obstacles so that the employees can give of their best.

          • by woolio ( 927141 )
            I don't think changing management every 3 months makes for a healthy company.
        • Re:Recommend (Score:5, Interesting)

          by claytongulick ( 725397 ) on Wednesday August 29, 2007 @12:49AM (#20394459) Homepage
          When I was leading a development team I considered my primary role to be an umbrella for the developers. I did my best (frequently not good enough) to insulate them from the assorted pressures of the management team (political, revenue/sales, deadline etc...).

              All this is sort of avoiding the primary, fundamental issue: when you are a manager you have the power (and responsibility) to fire someone.

              This is the real rub. Can you do it?

              In my case, I came to a decision that I needed to fire a developer who was completely inadequate to the position. Only this: she was one of the sweetest, kindest people I have ever met. Additionally, if I were to let her go, she would be sent back to India - forcing her husband to also go back. It would have been devastating to them.

              So what to do? She was not able to perform her job function and it was costing the company revenue. On the other hand, I wouldn't have been surprised to see Bambi walk up and eat out of her hand whilst blue jays perched on her shoulder (this is how kind hearted and sweet the girl was).

              And I had to fire her.

              So I tried.

              And failed.

              I came to find out this about myself: when confronted with a tearful employee who says she'll do anything, including work for half the salary if only I won't fire her - I cave.

              This turned out, in the long run, to be one of the worst management decisions I've ever made. I agreed to keep her on at a reduced salary. She continued to perform inadequately but over time she had been with the company long enough that dismissing her wasn't an option.

              Everything she wrote ended up having to be completely rewritten and she wasn't learning from experience or coaching. Even though she was working at a reduced salary, she ended up costing the company a high multiple of her salary in lost productivity, alienated clients and rework costs.

              So what was the "right" thing to do in that situation? On the one hand, I felt a moral imperative to help this kind, tender and wonderful person. On the other, I had a commitment and moral responsibility to the company I worked for.

              Finally, I reached the correct solution: I resigned my position as manager of the team.

              As I'm sure you've noticed, I am personally not suited for management. I will never put myself in that situation again.

              Just because I'm a talented developer, doesn't mean that I have the ability to make tough managerial decisions when they are called for. Those are two different skill sets, and one of the reasons that I tend to not resent my managers. Firing someone is brutal, and unless you are comfortable with those types of decisions and _sticking_with_them_ I strongly recommend that you avoid the managerial gig and stay in development.

          • Re:Recommend (Score:4, Insightful)

            by W2k ( 540424 ) <{moc.liamg} {ta} {suilesnevs.mlehliw}> on Wednesday August 29, 2007 @03:25AM (#20395343) Homepage Journal
            Why didn't you just assign her a different position? She may have been better suited to tasks other than development, such as testing (as in manual testing if need be - not writing unit tests). If she was willing to take a salary cut, that would have made changing her job even easier. Even if she had spent her days bringing the other developers coffee, she would not have cost the company multiples of her salary to keep employed.
            • Re:Recommend (Score:4, Insightful)

              by Oligonicella ( 659917 ) on Wednesday August 29, 2007 @06:48AM (#20396191)
              Because being a manager does not mean you can create new positions.
            • Re: (Score:3, Insightful)

              by khchung ( 462899 )

              Even if she had spent her days bringing the other developers coffee, she would not have cost the company multiples of her salary to keep employed.

              Right on! One of the things I need to do as a team leader is to identify and reduce the damage from incompetent programmers. Incompetent programmers not only have less productivity, often they have negative productivity, the grand parent post is good example. Letting them work on the code creates more work for the rest of the team.

              When firing the incompetents i

          • Re:Recommend (Score:4, Insightful)

            by Nefarious Wheel ( 628136 ) * on Wednesday August 29, 2007 @03:36AM (#20395403) Journal
            Been there, done that, fired Bambi.

            I had to look past the sunbeams and imagine the impact both on the firm and the guy if he stayed on. It wouldn't have been good for us, or for him. The guy should have been a life coach or a priest and by not taking the step of sacking him I was keeping him from a chance to do good somewhere else. Sucked having to tell him.

            Then later I found out he'd fabricated everything in his resume in the first instance, coached his friends to act as references (who looks past the phone number?) and screwed up a bid that would have employed another dozen peeps. Sucked finding that out.

            Advice? Don't assume you know everything about people, just like you never assumed you knew everything about software or hardware. HR people -- good ones -- can help, and so would a bit of reading about psychology, body language, every possible fad or truth about knowing people from the best sources you can find. People are a lot more difficult than software. Learn your subject, grasshopper.

          • Re: (Score:3, Interesting)

            I remember the first time I had to fire someone. It was at a startup, and everyone who worked for us at that point was a friend of either mine or my co-founder. In some ways that made it easier -- money spent on someone who wasn't pulling their weight meant that the chances were palpably greater that we'd all be out of a job, which would clearly be worse.

            This guy, "Hacker X," signed on to do a bunch of stuff, and just flat-out didn't do it. He was working from a remote location much of the time, which

          • Re: (Score:3, Interesting)

            by jafac ( 1449 )
            Yeah - lucky me, before I had to fire the guy - I mean REALLY had to, the customer cut off funding for the project and we ALL got fired. Ironically, we were the ONLY project out of the 4 projects the customer had going, that was actually ON SCHEDULE, we were the smallest project, and the shortest. We were a 6-month job, 2 weeks from completion; representing an upgrade effort to a component of a 5-year contract that was going on its 10th year (and, I believe, just started its 11th year last month). - oh, it
      • Re: (Score:3, Funny)

        Managers don't really do much of anything. If you have minimal people skills then you should have no trouble acting as a manager

        Indeed, that's why every manager, on the first day, gets a private meeting with Dr. Spaalzbad and his faithful assistant, Gorky, who proceed to remove his brain and replace it with shredded paper from Legal. Thus the new manager can becoming overtly concerned over the mundane, stupid and non-existent, say the most moronic things, and possess no evidence of intelligence.

      • Re: (Score:3, Insightful)

        by jessecurry ( 820286 )
        Very true... to be a "good" manager one just has to have general people skills and a list of deadlines/tasks. To be a "great" manager requires one to do a lot more, to actually motivate others to do better. In any event there are so few great managers that anyone that isn't a total choad should be just fine in a management position.
        The only caveat: as a manager you have a lot more freedom to goof off... don't hang yourself with that freedom.
    • by Tackhead ( 54550 ) on Tuesday August 28, 2007 @06:58PM (#20391423)
      > A comb for the pointy-hair on the sides of your head and wax for the shiny top.

      Do whatever the little white dog tells you to do.

      Actually, I would Scott Adams' "serious" books: The Dilbert Principle and Way of the Weasel are pretty good explanations of why managers act the way they do. Your typical PHB usually has very good business reasons for the stupid things he does, but since he's technically incompetent, he'll attempt to achieve these valid business goals by means that are unlikely at best, and impossible at worst.

      Witness our earlier Slashdot thread about a judge not knowing that "storing" logs in RAM is fundamentally different than "storing" logs on disk. She's got a good legal reason to expect that when someone is told to "turn over the logs", that they turn over all the logs. But because she's an idiot, she's very angry and confused when she finds out that RAM just. doesn't. work. like. that.

      Your advantage is that you've got the technical background; the Adams books will explain good (techie) management skills in language that you can use with fellow PHBs. Tell your fellow managers "I make sure my employees can leave by 5pm", and they'll wonder why you're harboring a bunch of slackers. But if you phrase it as "if my employees can't get their work done by 5, then the fault is with our management/scheduling/business processes, so let's, as managers, figure out how to improve those processes", and all of a sudden the PHBs love it.

      PHBs are funny that way. As soon as it sounds like it's their idea, they love it. Your job, as a non-pointy-haired boss, is to make sure that the ideas your fellow PHBs "love" will be good ones.

      • by jskiff ( 746548 ) on Tuesday August 28, 2007 @07:09PM (#20391569) Homepage
        But because she's an idiot, she's very angry and confused when she finds out that RAM just. doesn't. work. like. that.

        She's not an idiot. She's just not technical. There is a big difference between the two.

        Your advantage is that you've got the technical background

        For now. You have a technical background for now. I used to be an engineer, and a pretty good one at that. I was certainly one of the top technical people at the company when it came to understanding and solving customer problems. I've been a manager for two years now...and my technical skills are shot. I know enough to keep up with conversations, but ask me to do any real down and dirty troubleshooting and I'm back to being a babe in the woods.

        It's not that I dislike the manager role; it presents some interesting challenges. But don't rely on your technical skills to save you when you're flailing as a manager, because within a month or two your former co-workers and now underlings will be passing you by.
        • by Anonymous Coward
          Context matters.

          Someone who isn't technical would be your grandmother, to whom RAM doesn't matter; nor does her idea of how RAM works really matter to anyone. (Other than to simply annoy you when talking about computers with yer grandma.)

          A Federal Judge who has no interest in stopping by even their local mom and pop computer shop to learn about something she so obviously knows nothing about, when the livelihood of people is at stake, is an idiot.
        • by Roger W Moore ( 538166 ) on Tuesday August 28, 2007 @08:03PM (#20392159) Journal
          She's not an idiot. She's just not technical. There is a big difference between the two.

          Yes but the difference is that an intelligent, non-technical person will know that they are beyond the area of their expertise and stop and ask a technical person about it whereas an idiot will happily charge in without a clue. Hence she is an idiot.

          More on topic my advice to a new manager would be the above: do not be afraid to stop and ask questions from your underlings. You might be worried that it makes you look ignorant but it is far, far worse to not ask questions and do something really stupid like the aforementioned judge. Think about it: would "Judge Asks for Technical Advice from Expert" make Slashdot headlines (assuming Zonk is on holiday :-)?
          • by Otter ( 3800 ) on Tuesday August 28, 2007 @10:55PM (#20393661) Journal
            Yes but the difference is that an intelligent, non-technical person will know that they are beyond the area of their expertise and stop and ask a technical person about it whereas an idiot will happily charge in without a clue. Hence she is an idiot.

            In fact, the judge made a perfectly reasonable order which all three of you have completely misunderstood before happily charging in without a clue.

            So, who are the idiots?

            Getting back to the original question, this exchange certainly demonstrates why managing developers (and IT people in general) is so difficult. I don't think there's any other field where people have such disproportionately inflated assessments of themselves and so much misplaced contempt for others.

        • by ahbi ( 796025 )
          Judges have huge ego issues.
          They can't stand to be told that they are wrong. When they are told that they cite you for contempt.
          You have to understand that the courtroom is the last vestige of unfettered "aristocratic" power in America. They are Kings ... pretty much literally in their courtrooms. They can't have you killed but they can have you locked up ... indefinably. They can ruin the lawyer's livelihood. They can ruin you financially. They can restrict where to go and what to do.

          And contempt ord
      • by Fred Ferrigno ( 122319 ) on Tuesday August 28, 2007 @08:10PM (#20392215)

        Witness our earlier Slashdot thread about a judge not knowing that "storing" logs in RAM is fundamentally different than "storing" logs on disk. She's got a good legal reason to expect that when someone is told to "turn over the logs", that they turn over all the logs. But because she's an idiot, she's very angry and confused when she finds out that RAM just. doesn't. work. like. that.
        The judge is a lot smarter than you think. The law is outside Slashdot's realm of expertise, so you get a horribly inaccurate summary and tons of +5 posts making jokes about putting a stick of RAM in the mail. All that was decided is that storing an entry in RAM constitutes making a record, even if it's of the most temporary variety. The law doesn't give a damn whether you store that information in RAM, on your hard drive, or on a piece of paper. On a judge's order, you can be compelled to keep records that would otherwise be destroyed, even if that means positive action on your part to create a permanent copy.
    • ECT (Electro Convulsive Therapy) aside from the sudden increase in pay has a few other positive side effect like those nice pointy hair spikes.
  • by Anonymous Coward on Tuesday August 28, 2007 @06:43PM (#20391225)
    "How to Win Friends and Influence People"...it's a cheezy title, but an awesome book!
  • BEWARE (Score:5, Insightful)

    by TheSHAD0W ( 258774 ) on Tuesday August 28, 2007 @06:44PM (#20391237) Homepage
    Ever heard the saying "people are promoted to the level of their own incompetence"? Unless you're comfortable with a management job I would strongly recommend you *NOT* take it. You're right in doing some research and self-education before accepting the job, but while you study up keep asking yourself "do I REALLY want to do this?"
    • Re: (Score:2, Funny)

      by C0y0t3 ( 807909 )
      But.. but... the Money!
    • No, it's easy to be a good manager. The most important thing is to start projecting your power right away. If the sheeple see you as a weak leader, not using your authority, your reputation is lost forever (yes, it's even OK to be an incompetent leader as long as you come out "strong" and can lead them somewhere)
      • Re: (Score:3, Interesting)

        by daeg ( 828071 )
        It's often better to lead someone confidently off a cliff than meandering and starving through a jungle.

        At least with a cliff, the pain is short-lived and they can replace you quickly.
    • "do I REALLY want to do this?"

      Key to that is what does the company expect from you and what is the managerial style of your would-be-boss? If you are going to be in charge of people who's jobs you know how to do well, and your would-be-boss is more team leader than dictator in their approach they you will probably be fine. Just delegate all the work, then facilitate the work being done in your department. The best managers I've ever worked with (I'm freelance, I've worked with alot of different types) hav
    • by mce ( 509 )

      The saying is true, but often misunderstood and misused.

      Having gone through a similar transformation about 4 and a bit years ago (and something similar but less extreme about 14 years ago), I can only say that I'd be very scared of an (ex-)techie who, when he turns manager, feels comfortable from the start, or even before he accepts the offer. That person may have been overlooked as a talent and his promotion hence long overdue, but that woudl be a (frustrated) exception. More likely than not such a person

  • Word Processor (Score:2, Flamebait)

    by Grishnakh ( 216268 )
    In my opinion, your most important resource is your word processing program (hopefully OpenOffice). Using that, you can polish up your resume and find a better job doing what you're trained for and have experience in, instead of allowing yourself to be promoted until you fail.
    • by Zeebs ( 577100 )
      Of course because trying is the first step to failure.
      • Re: (Score:3, Insightful)

        by Grishnakh ( 216268 )
        You seem to be implying that he should try it first.

        My response is "why?"

        Have you ever tried a career as a hair stylist? Why not? You never know, you might be really good at it.

        You probably haven't tried it because you're not trained for it, you never studied for it, and most of all, you weren't interested in it. (My apologies if you really are a hair stylist, but given this forum's nature, I think it's a pretty safe assumption you aren't, so it should be a good example.)

        It's the same with this guy's new
        • Re: (Score:3, Insightful)

          by tftp ( 111690 )
          You seem to be implying that he should try it first. My response is "why?"

          You never posted on /. until you did. You never drove a car until you tried. You never worked as a programmer until you got hired. Those, and millions more, are examples which make your question unnecessary.

          A comparison to a hair stylist is useless because there is no transfer of skill from a programming job, for example. However an artist could do very well in hair styling, it pays well at the top.

          Basically, a good coder knows

  • by khasim ( 1285 ) <brandioch.conner@gmail.com> on Tuesday August 28, 2007 @06:45PM (#20391243)
    It will come from the people to manage.

    Always listen to them and hear what they're telling you.
    • Re: (Score:3, Insightful)

      by bhmit1 ( 2270 )

      It will come from the people to manage.
      A good mentor would also be important. Start having lunch with an old boss that you really liked.
      • Re: (Score:3, Informative)

        by KanSer ( 558891 )

        It will come from the people to manage.

        A good mentor would also be important. Start having lunch with an old boss that you really liked.

        This is the best advice in the topic. Your job is to optimize the output of the people below you, often by making their jobs easier. (It's no use paying someone lots of money to order pens and paper from Staples, etc...) They will tell you what they need, you just have to listen and empathize (DIFFERENT THAN sympathize, managers often have to make some very un-sympathetic decisions). A great manager is one who balances those needs with the needs of his/her bosses while making both parties happy.

        I highly re

  • by DrRobert ( 179090 ) * <rgbuice@macCOUGAR.com minus cat> on Tuesday August 28, 2007 @06:45PM (#20391245) Homepage
    1. Treat others as you would expect to be treated
    2. Never assume that anyone has nothing to add to a conversation
    3. Keep your shit together; be organized.
    4. Realize that even if you follow the above rules there will be politics and CYA that will make you miserable from time to time.
  • Running shoes.... (Score:5, Informative)

    by GuyverDH ( 232921 ) on Tuesday August 28, 2007 @06:47PM (#20391261)
    Seriously though, once you've semi-transitioned into a management position, don't expect to have any time to do any other work during normal hours.

    You'll spend 120% of your time in meetings, doing paperwork, reporting on issues to upper management, delivering managements responses to underlings and never have a moment to yourself.

    You'll find yourself doing your own tasks after that, so that a normal 40 hour week will become a normal 60 to 80 hour week, and you'll still feel like you're falling behind.
    • "You'll spend 120% of your time in meetings, doing paperwork, . . ."

      . . . exaggerating percentages until engineers laugh at you, . . .
  • a red stapler, a flashlight, and some bug spray.
  • by jimboinsk ( 802789 ) on Tuesday August 28, 2007 @06:49PM (#20391287)
    Take some time to reflect on the managers you've had experience with. List the good and bad traits they had. Think about the hard decisions they made well and the ones they made poorly. Then see how you think your style of management can benefit from those lessons. (This assumes you have already thought about your style of management, otherwise that is step one.)
  • Your employers may just be interested in getting you to train up your replacements. Now would seem to be the time to set up your own company and become a consultant/contractor. In this situation I'd be wanting to write a book to raise my profile.
  • by John Hasler ( 414242 ) on Tuesday August 28, 2007 @06:49PM (#20391301) Homepage
    > Aside from 'Become a manager in 2 days' type books, what resources would you recommend I
    > look to for guidance in this transition?

    The above captioned book has everything you'll need to know.
  • What did your previous managers do? Do what they did except improve on the issues that you thought were lacking.

    Depending on your organization, I would generally say that a managers job is to make sure her people are happy and productive. That includes kicking them in the ass when the need it, insulating them from corporate BS and finally, making sure they have the resources they need to get their jobs done.

  • My favorite bit of wisdom of a superior:

    "Gripes go up, not down, always up."

    No matter how dumb an idea is from upper management, try to put a positive spin on it to your employees, but if it's truly stupid then gripe like hell about it to your boss!
  • by raydobbs ( 99133 ) on Tuesday August 28, 2007 @06:51PM (#20391321) Homepage Journal
    As a convert from the front lines of IT (Mainframe operation and network engineering) to management, there are a few things that will help. One, remember - management is more about people skills than technical expertise. This is NOT to say that you will not be amiss to keep your development skills up to snuff. Being able to speak engineer will make you a more suitable manager, as that will be one less barrier for you to cross that other management types will have to scale.

    Leaping in does work for some people - but if your company has tuition reimbursement, I would seriously recommend taking management courses in a college environment. While a lot of people seem to think that management is a snap - there is things that seasoned professionals and professors can teach you that will keep you a step ahead of common pitfalls of entry-level managerial work.

    If you really MUST do it solo, you could look into obtaining a list of books used in a Business Administration program and seek to study them in your own time. Many have valuable insight into little encountered tid-bits that might not seem valuable at the time - but can crop up at the strangest times and places.

    And remember - it's an art as well as a science. A good rounded education will allow you to relate to the more human aspect of management versus the technical part of the development career path you held.
    • Re: (Score:3, Insightful)

      by nine-times ( 778537 )

      One, remember - management is more about people skills than technical expertise.

      I would say that it's very important to remember that the skills needed to do a job aren't the same as the skills needed to manage people doing that same job. One of the most important things to remember, IMO, is to stay cool-headed. Try not to get rattled. If you're frustrated, annoyed, scared, or confused, then try not to let it show.

      As a manager, it's your job to keep your peers and superiors informed about anything tha

  • Mentoring (Score:5, Informative)

    by bobdehnhardt ( 18286 ) on Tuesday August 28, 2007 @06:51PM (#20391325)
    Find managers who have styles that you like and respond well to, that have teams that are regarded as highly effective, and that have good reputations with other management types. Talk to them, learn from them, as them for advice. When I transitioned from desktop support to management, I talked to my father (who worked his way up in the glass industry from apprentice to Executive VP, and knew nothing about computers). Learned a ton, and it's helped me greatly.

    Also, don't be afraid of asking your upline for guidance and direction. He/she will know that this is your first foray into management, and if they're any good at all, will expect you to ask questions. It's not a sign of weakness to ask when you don't know something.

    Finally, think about the bosses you've had over the course of your career. Do the things you liked them doing, avoid the things you didn't like. This is one of the best ways to find what your own management style is.

  • Took a training course in this quite a while back:

    http://www.chimaeraconsulting.com/sitleader.htm [chimaeraconsulting.com]

    Also, knowing those ENTJ, INTP etc personality types
    and how to work with different personalities and
    workstyles (including your own), is useful.

    Basic leadership principles like consistency,
    taking responsibility, listening to concerns, and
    giving people real reasons to be motivated and happy
    to come to work.
    Learning to let go and trusting that your team really
    does amplify your own work output if you let them do
    the t
  • Good Topic (Score:4, Insightful)

    by Carcass666 ( 539381 ) on Tuesday August 28, 2007 @06:53PM (#20391353)

    I'm going through something similar myself. I've found that I've had to readjust my up-front goals. As a coder, I was more interested in how to accomplish something and, in point of fact, getting it accomplished.

    As a manager, I've found it becomes just as important to demonstrate progress (not just results), and to make sure that what has been asked of me is achievable, measurable and makes business sense for the company.

    Also, don't underestimate the importance of compliance stuff (SOX if you are with a public company, HIPAA if with a medical organization, PCI for credit cards, etc.). It all seems like a big waste of time but getting through audits and such is critical.

    And, for those who say "don't take the management job, ignore them." When they have to move out of mom's basement, they will be more sympathetic to you.

  • Sun Zi (or Sun Tzu), seriously, it is a big hype in the management world but it is a great work on strategic thinking, really.

    Disclaimer: IANAManager, just someone who studied Classical Chinese at University, and from that point of view I would say get this [google.com] not that [google.com]. Or maybe on of the million Sun Zi for manager/marketing/whatever books, but then you got the hype.

  • what resources would you recommend I look to for guidance in this transition?

    Your spouse and your confidence.

    One, you will screw up eventually. Two, screw ups build character and experience. And, three, every CEO has bags of regret he carries with him at all times as a reminder, no matter his formal training or degree. In other words, time, patience, and a good shoulder to lean on. My brother is a VP with Rockwell Corporation. He will tell you the same.

    Probably not the answer you were looking for, but,

  • Look into certs (Score:5, Interesting)

    by squarefish ( 561836 ) * on Tuesday August 28, 2007 @06:55PM (#20391389)
    Project+ [comptia.org] and CAPM [pmi.org] are geared towards your need, with the PMP [pmi.org] focused more towards very well-seasoned project managers.

    I just recently became a lead and know from the projects I've worked on, that I would be a better manager. So I'm finally doing something about it and pursuing the project management path. I just picked up the All-in-One CAPM/PMP exam guide and the recommended study path for the CAPM is a month. As with most jobs you'll learn the bulk from doing it, but the cert won't hurt and may give you the jump start and mind set to help you get started.

    some folks love certs and some hate them, but I've never had issue with getting them and I've always learned a few things along the way no matter how well I thought I knew a particular topic.
  • I'd look at what I know, so look at your current boss, look at his characteristics, if he is being promoted fast, copy what he does, if you boss is useless try learning from his mistakes. Your own experience will always teach you more than some book.
  • Don't Ask Slashdot. All you'll get are a bunch of tired old rehashed snarky crap responses, half of them from people probably too young to even be working anyway. Ask a manager you respect. If you don't know any that you respect, you probably won't like the job anyway.

  • Don't manage. (Score:2, Insightful)

    by AVee ( 557523 )
    "The first myth of management is that it exists. The second myth of management is that success equals skill."

    Remember that, always.

    Now ask your self, do you want to be a good manager, or a succesfull one?
    If you want to be successfull, don't manage unless you absolutely have to. Allways do as the boss asks you to do and allways have someone else available to blame when it fails. Make sure the someone is not in a rank above you, make sure it's not a friend of the boss or his wife. In short, success depen
  • Well number 1 is "people skills" - now I'm assuming that you have them already but you need to identify + reflect on your strengths & weaknesses in this area. I strongly recommend Emotional Intelligence + Working with Emotional Intelligence [amazon.co.uk] - this is 2 books in 1 - the 2nd having case studies & examples. Remember you can't be what you are not but you need to gain a little more insight into yourself in order to be on top of others.

    On the intellectual side ? Move away from "perfect" solutions- beg
  • by kbob88 ( 951258 ) on Tuesday August 28, 2007 @07:04PM (#20391513)
    I've been in and out of management over 20 years in technical work. I don't think it's mysterious or complex, but it's not easy either.

    Good resources for you:
    • The people you manage. Ask them and listen. They'll appreciate it, and probably give you good feedback. Remember to filter their comments, especially based on what you know about their personalities.
    • The people you report to. Follow the advice above.
    • Courses at a local college. I wouldn't overdo this, but if you could find a good course on organizational politics and power, that might help. Or it could really suck. Ask around.
    • Slashdot. Ok, maybe not. But other discussion groups might help. Plus you'll be fairly anonymous, and won't have to censor your questions as much.

    Some tips:
    • Listen more than you talk.
    • Determine what makes the people above you tick and stay on their good side. To them, you need to appear committed, competent, friendly, and loyal, but not fawning and flattering. And don't bug them too much.
    • Cultivate good, friendly relationships with your staff, but..
    • Set guidelines for your people and stick to them. You've got to enforce the rules. In the end, you're the boss.
    • Be organized and take good notes. It'll save your ass someday.
    • Develop relationships outside your group and those above you. You need to know what's going on so you don't get blindsided.
    • Set metrics and reward achievement.
    • Hire good people and ensure they stay. Can't emphasize this enough. And it's really tough to do.
    • Don't be afraid to get rid of bad people. Not only is their performance bad, but they're lowering everyone else's performance too. You can't be nice to all the people all the time. If you can't do this, you should just be an architect.
    • Raise issues early. Don't be afraid to deliver the bad news. Don't try to hide it. But you've got to have a solution or path forward. As one of my old bosses said: "Come to me with choices not problems."

    YMMV, and good luck!
  • Well, firstly, I wouldn't ask Slashdot for advice. I mean, you must be desperate.

    Secondly, I would buy a thick book of management jargon. If you cannot say "prioritize" and "going forward" and "methodologies" and stuff like that, how will you ever go forward with the right management priorities and the possibility of blaming someone else?

    Thirdly, I would attend a big management course. Now I happen to be selling one right now....

    My advice? Go back to the coding now, before they swallow you alive. Alive, I t
  • My advice:

    1. Don't completely count out good management books. A few good read-while-you-commute-or-fall-asleep books are: The One Minute Manager, The Essential Drucker and Getting Things Done.

    2. Absolutely, as you know, stay on top of good software architecture design patterns and UML. Even if you don't type a single line of code ever again, make sure you can discuss all aspects of an enterprise application using design patterns, SDLC and good practices.

    3. Learn Visio (or similar Apple / open sourc
  • One should never be surprised by a promotion into management. If you are surprised, then it means they haven't been giving you things to do to build up your management skills. For example, being a technical lead where you don't have any reports, but lead the development on a product. Or an intern to mentor (complete with an intern project), if your company has interns. Or give you one or two people to manage at first. And of course, management training courses.

    If you're not groomed into the role, you
  • Peopleware (Score:2, Informative)

    by therus121 ( 536202 )
    ...is really the only resource you need as an entry to management. As they say in the book it should be mandated that all managers read is annually (or anally, if they deserve it).

    Can't recommend it enough really - it helped me plenty.

    http://www.amazon.com/Peopleware-Productive-Projec ts-Tom-DeMarco/dp/0932633439 [amazon.com]

  • You know that tired old saw about the importance of communication? Well, it's going to feel real relevant real quick. You'll be constantly communicating with your employees, prospective employees, management, the internal "clients" for your department, the clients of the company, marketing, the front office, auditors, and God knows who else.

    Therefore, I recommend as starters:
    • The Elements Of Style - Strunk and White
    • The Visual Display Of Quantitative Information - Tufte
  • You have two ears and one mouth. Listen more than you talk.
  • I find the idea of being a manager uninteresting and a downgrade in title. You take on more responsibilities and increased legal liability (bet you didn't know managers have certain federal and state legal obligations both for criminal and for civil courts). The pay difference does not offset this liability, in my opinion. And in some cases the pay for managers is less than top tier engineering positions. The thing is, not everyone can be a top tier engineer. But there are plenty of management jobs to go ar
  • Rands in Repose (Score:2, Informative)

    Good advice all around in the posts above. A site I've found to be pretty insightful is Rands in Repose [randsinrepose.com]. He's also a new book titled "Managing Humans" [managinghumans.com]. Check it out—I'm a fan.
  • Learn to make hard decisions, even if they make you unpopular. It's what seperates plebs from management, the ability to do unpopular things for the common good.
  • If you want to manage then you'll have to forget everything you know about the technical side of your former job. You don't have time for it now, and there are people who do that for you.

    Get used to meetings. That's your life now. You'll have meetings inside of other meetings. You'll be in two meetings at once in two different rooms. I wouldn't make this up, you know.

    Remember those times when you were on call and had to work the occasional weekend? You still do that, only it's all the time now. Any

  • There are plenty of management books out there -- it's hard to go wrong when learning the basics -- and they all pretty much emphasize the same things: effective communication, appreciate where your employees are coming from, demand respect for others in the workplace, lead by example, don't be a pushover, and foster a culture of openness so your employees aren't afraid to tell you what's wrong. If you're not sure how to effectively do any of the above, then The First-time Manager [amazon.com] is a decent read. But if
  • Advice? (Score:3, Insightful)

    by rlk ( 1089 ) on Tuesday August 28, 2007 @07:37PM (#20391839)
    1) Your people come first.

    2) Support your people, come hell or high water.

    3) See #1.

    4) Keep any distractions that aren't absolutely necessary away from your folks.

    5) Don't sign up for any critical technical work (you'll just slip the project).

    6) Oh, in case I forgot to mention, fight like crazy for your people.

    7) If your people are working overtime/weekends for more than a well-bounded, short term crunch, it's a sign of a problem, not a good sign at all. Kick your folks out and figure out what's going wrong, and fix it.

    8) Don't constantly look over everyone's shoulder.

    I'm no fan of Microsoft, but there's a book published by Microsoft Press by Steve Maguire or Steve McConnell (whichever one of them didn't write Code Complete) about technical management. It's actually very good indeed.

    The combination of manager and architect sounds like a very dangerous one to me. It's going to be very difficult for you to get honest technical feedback from people who report to you, and architects need that kind of candid feedback. An architectural error that goes unchallenged for political reasons is bad news. When I was a manager, I once led a software integration team (a more suitable role for a manager), and even that caused some tension. Not with the person who happened to report to me -- she had no trouble pushing back when needed -- but with another engineer who found it uncomfortable when I had to go around and get commitments from people. I was actually selected for that role because initially no one on the team reported to me (I was the one leadership/management role who didn't have an interest in a particular component within the project), but things change...
  • by geophile ( 16995 ) <jao@NoSpAm.geophile.com> on Tuesday August 28, 2007 @08:04PM (#20392169) Homepage
    I've been "stuck" at the architect level for 10 years now. Several years ago, I was considering going into management, to eventually become a VP of engineering. But I really enjoyed the hands-on work, and really loathed the management work -- schedules, resources, reviews, hiring, .... I thought about this for many months. I finally talked to my boss about it. He made a very good point that decided the issue for me once and for all. He pointed out that if I didn't really enjoy being a manager, I would be awful at it, and that would make me miserable.

    I realized I have something I'm good at and really enjoy doing. In the interest of not spoiling a good thing, I decided to stay a techie and I've been very happy with my choice.

    Are you really sure you want to make this transition?
  • by blackcoot ( 124938 ) on Tuesday August 28, 2007 @08:13PM (#20392249)
    first off, i don't envy you --- i found myself in a somewhat similar situation recently where i suddenly became responsible for squeezing useful results out of three different subcontractors.

    as for resources, first, and most important: it's been mentioned elsewhere, but finding a good mentor (preferably more than one) is going to be crucial. think of them as "man pages" for people.

    second: i don't know what your personal organizational style is, but you're about to start juggling not just your own personal assignments, but all tasks of your entire team, plus all the "overhead" tasks of tracking progress, planning, etc. if you're not used to juggling about 5000 balls at once, get yourself the tools you need to help keep yourself organized. in my case, this meant a giant whiteboard with a matrix of tasks cross referenced to people and due-dates which i updated once a week after a brief status meeting.

    third: start looking at your local community college's certificate / continuing education programs in business development / leadership development. in addition to more "standard" management classes, i would strongly encourage you to take a class on interpersonal communication, because you're going to discover quickly (if you haven't already) that people communicate very differently with management than they do with their peers. similarly, more junior employees have different communication styles and attitudes about communication than more senior / seasoned employees do.
  • Rands and Joel (Score:4, Interesting)

    by OutlawDrake ( 219223 ) on Tuesday August 28, 2007 @08:45PM (#20392583) Homepage
    As an engineer / architect who has had to deal with some frustrating management (most of it indirect, fortunately), I've found these two blogs to be both enlightening and useful for feeding to managers. Rands especially, as a developer who moved into management with a purpose, has some very insightful commentary. He's also recently published a book, which I'm planning on giving to some of my favorite managers (who despite their sincere desire to treat us well, sometimes have a hard time understanding the geeks they herd.)

    Rands on Management: http://www.randsinrepose.com/cat_management.html [randsinrepose.com]
    Rands's Book: http://managinghumans.com/ [managinghumans.com] (Direct to Amazon: http://www.amazon.com/Managing-Humans-Humorous-Sof tware-Engineering/dp/159059844X [amazon.com])

    Joel on Software: http://www.joelonsoftware.com/ [joelonsoftware.com]

    Good luck! It's great to hear about people who care enough to want to do it right.
  • by alexhmit01 ( 104757 ) on Wednesday August 29, 2007 @08:23AM (#20396713)
    As a coder, your job is to take technical requirements and turn them into code that meets those requirements. Those analytical skills will directly translate into management, but a bit of rethinking is required. Instead of needing to make the compiler produce the results you are looking for, you need to make the people produce them.

    As far as retraining, see what Universities near you offer evening or weekend executive MBA programs. Unlike the Day programs that are geared for teaching management consultant grunts to be better management consultant grunts, the executive ones offer a lot of things for mid-level people that are actually in management. In an exec MBA program, you should cover Leadership, Financial Accounting, Managerial Accounting, plus basics in other areas like marketing and finance. An MBA, particularly in an executive format that has fewer elective options, tends to focus on "general management," it's like a liberal arts degree, it isn't specialized, but it designed to give you an overview. You won't become the company's expert on accounting or marketing, but you'll understand the jargon and big picture, so you won't be blown away when doing budgets, etc.

    Subscribe to the Wall Street Journal, print or online, and try to read it a few days/week. This was what a friend with a technical background that got a job at McKinsey said she did to catch up on business jargon fast. A few weeks/months, and you'll find yourself less lost in business jargon, because you'll be reading things in the current jargon in context.

    Some basic tips:
    1. Your primary responsibility is to keep "the suits" from interfering with your team. If you have filled your team with good people, they'll get the job done, but if you let the top people meddle in your team, you will fail.
    2. Understand boundaries with your staff... you have to balance a line between being "one of the guys" and being the "boss". Err too much on the former and you won't have the respect necessary to make the decisions, they won't appreciate that sometimes you have to make decisions that aren't up for debate... Err too much on the latter, and you won't get the honest feedback that you need to make decisions.
    3. Use meetings regularly, usefully, and short. Long meetings annoy people, but you need some meeting time to keep everyone on the same page. Do NOT become the information funnel to avoid meetings. You need to know everything, but not be responsible for relaying messages. It's not the 1950s where everyone's secretary types memos to send up the chain or down the chain.
    4. Build cross-functional teams wherever possible. Setting up a monthly meeting with your technical lead, someone from marketing, and someone from customer service to go over features, for example. If you meet with other leaders and get your technical people together, decision making will be stronger and you'll do better things for the company. Those that show leadership are more likely to move up the ladder.
    5. Know where your time goes and why it is work. It is sometimes frustrating, because as a "code monkey," when you pulled an 80 hour week, you know what you did. You have some functions/classes/bug-fixes implemented. As a manager, your primary responsibility is keeping track of what is going on and communicating. This seems trivial to technical people, but is a lot of hard work and get be frustrating. If you spend a solid week in meetings with your team, superiors, and colleagues in other departments, it often feels like you did nothing, but that's your job.
    6. Informal meetings are a great way to keep abreast of things, but don't disrupt people. Learn to have task lists. One of the worst senior managers I worked with had a tendency to call people whenever he had a question. I was trying to manage a small team AND do some technical work, and he'd blow my concentration constantly with calls e
  • by HikingStick ( 878216 ) <z01riemerNO@SPAMhotmail.com> on Wednesday August 29, 2007 @01:35PM (#20401113)
    Dickens' comes to mind here. You're at the door of a tremendous opportunity, but there's an equally unpleasant chance for failure. Number one, you've recognized that you're not feeling ready for the management role. To me, this is a great indicator that I think you'll surprise even yourself in the months ahead. The fact that you're worried about it shows you're not an ego-centric moron who thinks he's God's gift to project development. That said, I'll offer a few bits of advice for you to consider.

    If the position is already settled, then go to HR and get connected with one of their senior specialists who works in training, development, or mentoring. Let him/her know that you're willing to step up to the plate, but that you are looking for some additional insight and help as you make the transition. Make it clear that you're looking for support, not some remedial "How to manage in 30 days or less" type material. S/he may be able to hook you up with another, more experienced manager in your firm who can help you during your first few months.
    My second point really depends on WHO you will be managing. Will this be your current peer group, or a completely new set of faces? If your current peer group, I'd want to know what your relationships are like right now. Do they respect you? Do they come to you for help? If so, you'll probably fare better than some. If your peers don't think kindly of you, a malestrom could be ahead of you. If a completely fresh set of faces, only time will tell. Remember that your empoyees are going to want to feel you out as much as you are going to need to feel them out. My advice? Sit down with your new team on day one (or before). Give them your background and let them know what strengths you bring to the table (in some ways, this is like a final, non-binding interview). I would tell them that this is your first foray into management, and that you expect you'll make some mistakes along the way, but that you trust them to be open with you so that you may improve. Then (if feasible), announce that you'll meet with each individual briefly to get to know them better (this can be out of the "norm" for most men, but believe me that it goes a long way to establishing a good relationship). Keep those meetings short and light. Talk about the employee's interests and strengths. Many employees long for management changes with the hope that a fresh set of ears may be willing to listen to their dreams and aspirations. Try to learn the employee's preferred communications and learning styles (either by asking, or through observation). Ask them what was best about their last manager, or what they believe makes a good manager. Take note of what they say (mentally, or on paper)! You may not be prepared to provide the type of management they want, but having that list of expectations will give you a good starting point for your mentor discussions, or your time with your HR rep.

    Okay. Enough from me. Best of luck to you in your new position. I would love to see an update from you in a year, to tell us what worked and what didn't.
  • by javabandit ( 464204 ) on Wednesday August 29, 2007 @05:07PM (#20404357)
    I've been a development manager for five years now after holding architect, software development, and software consulting positions for a decade. Here is a list of things that new development managers will learn the hard way -- regardless of how perceptive or proactive someone thinks they are:

    1) Your first priority is doing what is right for the company. If you are just trying to always "be the great guy" to your team, you are a horrible manager and horrible for the company. Do the right thing for the company and the rest will follow.

    2) You are not an architect anymore. - Let the architects and software developers design and write the software. Your job is to ensure that the team has what they need to do their job.

    3) You are not a coder anymore. - Put practices in place which allow the software developers and architects to keep code quality high.

    4) You are not an individual contributor anymore. - Your own achievements are solely based on the achievements of your team. You did your job well if you team did a good job.

    4) You have to give negative feedback. - People need to know when they are screwing up. If somebody has body odor, you need to tell them to clean it up. If somebody is consistently late, you have to tell them to get their asses in on time. If somebody is a negativist, you have to tell them to get a better attitude. If someone is surfing too much, you have to tell them to stop. If some coder is going off in the weeds chasing butterflies and losing track of a feature, you need to tell that person to get back on task. The worst kind of conflict is ignored feedback.

    5) You have to give positive feedback. - When somebody does a good job, tell them. If someone kicked ass on a feature, tell them. If someone finds a hairy defect and fixes it, give praise. If someone works long hours one day, give them a free day off, or give them a gift certificate to take the family out. Whatever.

    6) The "open door" policy is lazy bullshit. You have to have frequent informal one-on-one meetings. - People need to venue to vent, ask questions, voice concerns, et cetera. All people. Even the quiet ones. Be proactive and give your team a predictable place to do that. You will offset a lot of potential risks this way.

    That's all I can think of off the top of my head. I was a shitty manager at first. Over the years, I have learned each one of the above lessons -- usually after a serious screwup.

    Good luck to you new software development managers. I truly believe it is the hardest job in software engineering. But stick with it. Once you get good at it... it can be very fulfilling.

Things are not as simple as they seems at first. - Edward Thorp