Forgot your password?
typodupeerror
Businesses Education IT

Ask Slashdot: Transitioning From Developer To Executive? 229

Posted by timothy
from the oh-just-grow-the-hair-it's-cool dept.
First time accepted submitter fivevibe writes "I'm about to switch from a position where I did hands on development to one where I will be building and managing technical team. I will be responsible for designing and implementing the company's overall tech strategy. I am excited about this move but also nervous. It will require a different focus than I had up to this point, different skills, and different orientation. What should I be learning, reading, thinking about in order to make this transition successfully and avoid growing pointy hair?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Transitioning From Developer To Executive?

Comments Filter:
  • learn? (Score:5, Funny)

    by polar red (215081) on Monday December 19, 2011 @07:21AM (#38422784)

    just buy a bullwhip. Easiest way to interact with us mere mortal programmers. And get a cat.

    • Re:learn? (Score:5, Insightful)

      by yog (19073) * on Monday December 19, 2011 @10:07AM (#38423378) Homepage Journal

      Yes, I've seen several people "promoted" into a manager or VP of Technology type of position who were simply unprepared for the transition. It was felt by the (foolish, ignorant) top execs that the candidate would make a good manager since he was already such a good programmer or architect. The predictable result was catastrophe; the former star programmer became a stupid git who was hated and despised by everyone, and eventually was shown the door after having caused incalculable damage to the organization.

      Unfortunately for all parties involved, software engineering and management are two completely separate skills. It's like saying a good surgeon would make a good hospital administrator--where do you pull that out of? They are unrelated and often oppositional jobs. Shoot-from-the-hip, cowboy programmers as well as "team player", 9-5 coders are equally unqualified to manage others, with the team players being slightly better simply because they're less likely to piss everyone off right away.

      I've found in my professional experience, as have many others, that really great managers are born, not made. Some people seem to have instinctual abilities to see through the fog of war and focus on the goals, marshal their resources rationally, and avoid letting petty emotions, vindictiveness, oneupmanship, and all the politics that come with human interaction get in the way. You can call them out, tell them to their face that they're full of crap, challenge their assumptions, and they will calmly roll with the punches and adjust accordingly. Their bosses will lean on them, change their priorities, threaten them, etc., and they will push back, educate their superiors, win the time and money they need to achieve the objectives.

      It's like sales. Great sales people seem to have an innate ability to close the deal, while crappy sales guys (the majority in the world, I think) piss off the customer, display their ignorance, and basically fumble the ball more often than not.

      So, op, proceed cautiously. You are about to step off the cliff and hope you enjoy a soft landing. A few make it, but most don't. I would say, if you're pretty good technically, you should just stay in the tech field where you know you have a good future. But, if you want to learn from bitter experience, be our guest and delve in. Get back to us in a year and let us know how it's going.

      • Re:learn? (Score:5, Insightful)

        by Anonymus (2267354) on Monday December 19, 2011 @10:32AM (#38423480)

        Most "good" managers I've met are not good because of skills or training, but from simply being personable, intelligent, and able to solve problems (real world problems, generally very different from the types of problems programmers face). It takes a minimal amount of training to get a good manager, as long as you start with the right person, who possesses those innate abilities. There is plenty of management material to be found among software engineers, programmers, IT, etc. The problem is that, like you said, execs will often just assume someone good in one position will do fine managing that position, and promote them without any management training.

        The truly unfortunate thing is that it generally takes much more skill and training to be a good software engineer than it does to be a good manager, and yet management pay generally BEGINS where every other job maxes out. My biggest problem with about 90% of all management I've worked with in my life is that I (or many other people I know) could do their jobs better than them with a week or two of training, and yet they're making twice what I make. At the same time, most of them also face less stress and work fewer hours.

        • Re:learn? (Score:5, Insightful)

          by Tiroth (95112) on Monday December 19, 2011 @11:17AM (#38423642) Homepage

          Well, I think it is hard to generalize the way you have and be correct. I'm sure there are shops like the one you described - managers making much more than the devs, worrying more about their golf handicap than the project timeline. There are plenty of places though where the dev and manager payscales have quite a bit of overlap, where you'll find all of the senior devs making (much) more than the junior managers. I think this is right. At well-run companies there will also be quite a lot of pressure and stress put on the manager, simply because the manager is responsible for the success of every person on the team - so take all the things that can go wrong on the dev side (hit a snag and have to refactor, sick time, etc.) and multiply that by the size of the team. Good managers are also taking the heat for making the inevitable tradeoffs - "yes, we know big client X wants feature Y but we need to keep the release on track." Dealing with VPs several levels up trying to pull the project in different directions is also less than enjoyable.

          Managers are also much more vulnerable to politics than individual contributors. You can be a great manager and still get canned if new upper management rolls in and doesn't like you or doesn't think you're the right person for their new policies - or if you get a tough project that doesn't go well and someone needs to be blamed. So, I think part of the compensation difference is because the job is simply riskier.

        • by perpenso (1613749) on Monday December 19, 2011 @01:53PM (#38424610)

          Most "good" managers I've met are not good because of skills or training, but from simply being personable, intelligent, and able to solve problems (real world problems, generally very different from the types of problems programmers face). It takes a minimal amount of training to get a good manager, as long as you start with the right person, who possesses those innate abilities.

          As someone who recently graduated from business school I have to disagree with respect to "minimal amount of training". The more formal training the better. Especially since the poster seems to indicate an executive angle not just tech management. The MBA stuff would really help out since it offers a good overall understanding of all the pieces of an organization. Business school and MBAs are not what most around here think, I was just as guilty. One of the things that made business school lots of fun for me was seeing just how ignorant and biased I had been with respect to management, marketing, etc.

          • by s73v3r (963317)

            No. The more formal the training, the more likely the person is to do something unbelievably short sighted and stupid for short term gains.

            • by perpenso (1613749)

              No. The more formal the training, the more likely the person is to do something unbelievably short sighted and stupid for short term gains.

              That is precisely the sort of ignorant and biased statement that I would have made prior to going to business school. Business school actually teaches you to avoid such traps and to stay away from potential partners who are doing as you describe.

      • by Surt (22457)

        You have to be careful of going to far the other direction as well. The hospital administrator is a good example. Do you want to pick someone for that job who has never worked in a hospital, and therefore has no idea the impact of their decisions? Neither pure professional management, nor pure technical advancement into management is the right path. The ideal manager is going to be a skilled technician who happens to have a natural talent for and interest in management. Which should be followed up with

      • "Unfortunately for all parties involved, software engineering and management are two completely separate skills"

        So the correlation between being a good manager and a good software engineer is 0? I would guess that they are both correlated to general intelligence. Likewise I would guess managing software engineers has some correlation to understanding what they do, what your company's code-base looks like, and what your company does. (Likewise I would put a medical professional in charge of a hospital.
        • by marnues (906739)
          I think you missed the point about politics. A great manager doesn't ignore politics, they work with and around them. A good engineer generally creates politics. We don't have to, but we're also not usually very good at smoothing over responses or giving in to business demands. We're not good at setting other's expectations nor making other people work for us. These are all skills good management needs and most engineers disdain. It took me several years to realize that being straight-forward is not a
      • Re:learn? (Score:4, Interesting)

        by carnivore302 (708545) on Tuesday December 20, 2011 @04:46AM (#38431876) Journal

        You're generalizing; there are plenty of people I know up close who were great developers and now great managers. One of them is my boss and I'll tell you what he did to get my utmost respect.

        First of all, this guy was a brilliant developer. Both design and coding were always rock solid. Then when the boys from the board asked him to become a manager, we (the grunts) didn't really notice a lot. Sure, he started coding a lot less, and within half a year stopped doing that entirely. Often we wondered what he was doing all day, until one day I spoke to one the founders of the company and he was saying the guy was a bit of a pain in the ass for them. Turns out his day job was nothing less than constantly defending us, making sure we could do our job without being harassed by upper management, and creating support for any of the ideas we (the developers) came up with. In short, instead of being a manager to report to upper management, my boss focuses on ways to make us as productive and happy as we can be.

        I can't thank him enough for that.

    • Re: (Score:3, Insightful)

      by jeffporcaro (1010187)

      I recently had to make a similar change - from being in training to becoming one of two cardiologists running a private office, which means I'm responsible for employees.

      Making technical decisions is the easy part - managing people is the hard part. You're simply treated differently when you have the ability to make decisions that can change people's livelihood and lives. The best resources I found on this were "Getting to Yes" and "Getting Past No," both touchy-feely pop-style books, but both with semi-use

    • by jvin248 (1147821)
      While that's all fun and excitement. If you want your company to succeed, you need to learn one thing. You will be successful only if those working in your department are successful. Take your shiny new organizational pyramid and turn it so your point of the pyramid is at the bottom of the page. You're the worker for this whole group, and the output of your department only gets made by that row of workers along the top.

      Then of course you should also consider delayering so span of control goes from the
  • by stove (38601) on Monday December 19, 2011 @07:29AM (#38422804)

    (Probably not the sort of ignorance you're thinking of, though.)

    Start practicing saying "I don't know." You know a lot of technology right now, but in 5 years you'll know less, and in 10 the young kids will roll their eyes when you talk about how it "used to be." Set a big organizational goal ("double our storage space for next year") and then ask the technicians how to make it happen. Resist the urge to do anything more than "suggest" things or vaguely hint at solutions. Know how little you know.

    What you shouldn't ever forget is how technology "really works." You know, "fast right cheap pick 2." If your company wants to go with a cheap solution to their problems, make sure you've prepared properly for it.

    All the successful technician-to-manager folks I've worked under have suggested solutions, listened when technicians explained problems and tried to get managerial roadblocks out of their way. On the plus side, the best managers I've worked for were promoted techies. Good luck!

    • Absolutely .....remember you pay analysts to figure out how to do things ....let them do them do that and you decide the best solution from what they come back with.....I hate when an executive makes an implimentation decision without listening to the people who have to build the.system.

    • by dbIII (701233) on Monday December 19, 2011 @08:27AM (#38423050)
      Keep on reading those journals to know what is possible and ignore those losers that call themselves "Architects", "Engineers" or even "Gurus" without some professional group of peers that think they deserve the title. You don't have to have earned one of those titles, go with what you have earned and keep in touch with it enough so that no amoral contractor can bullshit their way into robbing you blind. You don't have to be a cutting edge expert but you do need to keep up enough to tell one from a confidence trickster.
      It doesn't all stop when you leave school or even the "shop floor".
    • by radtea (464814) on Monday December 19, 2011 @01:25PM (#38424244)

      All the successful technician-to-manager folks I've worked under have suggested solutions, listened when technicians explained problems and tried to get managerial roadblocks out of their way

      My mantra as a manager is, "Trust your people." In one of my first management positions I took over a team that was having a really hard time (they'd been leaderless for a year, had political issues with senior management, etc) that was in the midst of shipping a major new release. Things were chaotic and the urge to micro-manage was intense. Fortunately I knew how technically proficient they were, and was able to discipline myself to trust them across the board on technical issues while I started the (ultimately successful) process of dealing with the political and people issues.

    • Lots of derogatory remarks towards managers. Not so easy to be in a position of orienting others be it for educating, leading, organizing, inspiring, managing or whatever else. I myself despise jobs coporations and management -do all kinds of things but never accept jobs anymore. But if you want to do anything bigger, you need more people, and you need organization. Whatever you do, whether it is open source coding, protesting, having a big party, or a small company, you will have people, jobs, money, d

  • Some tips (Score:5, Insightful)

    by Registered Coward v2 (447531) on Monday December 19, 2011 @07:29AM (#38422808)

    1) find a mentor you can use to get advice and bounce ideas of of

    2) contact some counterparts and see what professional pegs the belong to and join them and go to local meetings

    3) and now the hardest part. While the developers are your friends you now have new responsibilities and may have to make some tough decisions. Be fair, but make the tough calls. If you don't, your team will suffer and do will you.

    • Re:Some tips (Score:5, Insightful)

      by Anonymous Coward on Monday December 19, 2011 @07:56AM (#38422922)

      This is probably the best post here, unfortunately Slashdot isn't a great place to ask this question as half it's membership are too young to have made it to this level succesfully and the other half are grumpy old gits who are bitter that they never made it to this level.

      As such "Go ask peers who are already at this level" is about as good advice as can be given here, otherwise you'll just get a long wishlist from people as to how they wish their bosses would be from their inexperienced viewpoint, rather than how their bosses actually need to be to get the job done.

      You don't have to become a jackass, but the people who don't get to this level are the ones who don't understand why you're making decisions that to them, seem stupid.

      • by bolthole (122186)
        Eh... there's still something very positive to be had, from engineers who can rightfully say, "my most useful/helpful/... boss did (this) on a regular basis"
      • " the ones who don't understand why you're making decisions that to them, seem stupid."

        It should never get to that point. A key component of managing knowledge workers is communication. You must communicate the why of your decisions or the people you are supposed to lead will resent those decisions and cut you out of the loop. Not a problem if you are managing people who do not want to know (laborers), but knowledge workers must be a part of the loop.

        Study evidence based management. This is a must read for

    • Re:Some tips (Score:5, Insightful)

      by nine-times (778537) <nine.times@gmail.com> on Monday December 19, 2011 @10:36AM (#38423504) Homepage

      While the developers are your friends you now have new responsibilities and may have to make some tough decisions.

      This reminds me of something: understand that you might not be able to be friends with the people you're managing. You can be on friendly terms with them, but in my experience, friendships are pretty hard once that power imbalance exists. As their manager, at some point, you might need to call them on some kind of bad/irresponsible behavior. If you're like me, you won't really want to, but it'll be your responsibility.

    • Re: (Score:3, Insightful)

      by delcielo (217760)
      Think of the managers you have respected, and analyze what made them great managers for you. Some common things that have served me well:

      1. Don't try to change your people. They are who they are. Work with their strengths. If you can't deal with who they are, you'll need to work on getting them off your team.
      2. Pay attention to your employees' careers. You should be training them to see the broader aspects of what they're working on. You should have a career path in mind for them. Some may want to
  • by zr-rifle (677585) <zedr@zedr . c om> on Monday December 19, 2011 @07:36AM (#38422834) Homepage
    First of all, read "The Mythical Man Month" [wikipedia.org] by Fred Brooks, if you haven't already.
    Be realistic and conservative on your delivery dates. Defend them to the death.
    Avoid micromanaging people, if possible, and insist on clear communication and concise documentation.
    My personal suggestion: don't give up completely on being a developer. Keep a small, but important task to yourself. You will gain an even better view on how your team is working.
    • by Intron (870560) on Monday December 19, 2011 @08:34AM (#38423072)

      Awesome list. I'll just add one more: block "minor enhancements that shouldn't affect the schedule" no matter who suggests them.

      • by Andy_R (114137)

        Alternatively, *charge* for "minor enhancements that shouldn't affect the schedule".

        Pay the money out as a bonus to the employees who have to accommodate the change if they don't let the schedule slip. This stops you appearing to be an asshat to your customers (while reminding them that your department's work has value), and shows the workforce you're fighting their corner, and appreciate their workload.

      • by Surt (22457)

        So in the end you can deliver something that doesn't do what the client needs?

        If a 'minor enhancement that shouldn't affect the schedule' is a big deal to you, you have a serious process problem. It's probably time to learn something from the agile development folks.

    • by kbdd (823155) on Monday December 19, 2011 @09:38AM (#38423304) Homepage
      The comments above are very good indeed, that is exactly what I was able to do for a long while.

      I did the same thing many moons ago and recently went back to being an engineer (with great satisfaction).

      The issue is: while it is relatively easy to describe what a good engineer is, in abstract, in a way that will work for most companies, it is much harder to define what a good manager should be because it all depends on the expectations (and the organization) of the company you work for.

      In my case, I believe I was doing a fine job for 10-15 years of it as a manager (while still being hands-on on some aspects of the job) under the old definition, and having fun in the process, at least some of the time.

      Then the company was acquired and the definition of what was a "good" manager changed. A "good" manager was not to do technical work, just to generate schedules and budgets, do personnel management (reviews, hiring), make sure processes were followed and go to meetings, lots of them, many off-site. Engineers need not apply.

      These were not the favorite parts of my old job, but under the former organization, I was able to do that because it was not full time and I still had the technical side to keep me interested. However, under the new definition, I was no longer a good manager (or even an acceptable one) and I was utterly miserable. However, because I had been able to not stop being an engineer, I was still a pretty good engineer, so I was able to go back as an engineer

      There are many managers meeting that description in that company and some of them do not have strong technical background and yet are apparently doing the job. It is my opinion that those that were strong technically and have been put in these positions do not enjoy their jobs very much, but it is just my opinion. I certainly did not. In many regards, I otherwise consider this company to be enlightened compared to most, they have done many of the right things for the right reasons so there is absolutely no bashing here. I just want to highlight the differences between what many perceive their job to be, and what management expects.

      I was fortunate that while I was struggling as a manager under the new definition, this company developed a reasonable technical ladder as an alternative to the management ladder, so going back as an engineer had no downside on my salary or prospects.

      So my recommendation is: while you should strive to do what is expected (and I cannot tell you what that is), don't completely abandon the technical aspect and let your skills go stale because if you are any good at it (and you probably are since they offered you this opportunity) that is something you can always fall back on. If you are expected to not do any technical work at all, think twice before taking the job, you probably won't be happy.

      Also, in your new management responsibilities, you will have an opportunity to make sure that the company has, or develops, a technical ladder so that good engineers are not offered the choice of either becoming managers (where they may suck) or go somewhere else. That may be you :)

      And one more thing: do not abandon your values. If you believe something is wrong, it is wrong. It does not matter if you wear the engineer's hat or the manager's hat. You will be the most visible technical person in the organization, that comes with responsibilities. Speak your mind in a respectful way, be yourself and represent the interests of your staff and the customers. You will be under a lot of pressure to cut corners and push your better judgement under the rug in order to meet impossible deadlines and budgets. Honestly try to make the best of it. Make friends in the management structure. You will need them one day. You were made that offer because you are smart, never forget it. You have an obligation to speak the truth.

    • remember what you already know
    • acknowledge what you don't
    • talk to the specific interests of both business and technical staff
    • be honest

    It's a pretty exciting time to be able to doing what you're doing - lines are blurring all over the place between the artificial divisions within organisations. I'd be reading as much about Lean Management as I can (as the wellspring from which Agile comes), but only if it makes sense in your context.

    Good luck!

  • Simple (Score:2, Funny)

    by Kagetsuki (1620613)

    1. Don't piss off programmers. Make them comfortable.
    2. They are being paid, make sure they do the work they need to by the time it needs to be done. Stick to schedules. I can not stress how important it is to stick to schedules. If a programmer can't meet targets you feel were set fairly then you may have to fire him/her. If they claim it just takes them longer and you can deal with that then offer them lower pay - in the end results matter and you're on a budget.
    3. Listen to advice from your developers ca

    • Re:Simple (Score:4, Interesting)

      by sclark46 (969374) on Monday December 19, 2011 @08:13AM (#38422990)
      I have found it is a very good exercise to let the programmers tell me how long it is going to take to get the job done. We do it in a group setting with all the peers involved. The programmers don't want to look bad among their peers so they usually set realistic dates and work hard to meet them. Each week we review progress in a group setting. This seems to work very well.
      • I've met few programmers who could estimate their time-frames so well. Of course I would and do take their voices into account if they worry about missing deadlines, but usually if it looks like they will not meet a deadline or critical pass that just means adding or changing out programmers or picking up the slack myself.

        • by olau (314197)

          If you programmers can't estimate how long it takes, that's because they aren't breaking the task down properly. Either that, or you don't have a time tracker so people actually know how much time they're spending. It can very well happen that you spend two days and get 6 hours of programming done.

          Estimation is a really annoying thing to do, so if people aren't forced to do it and held accountable to what they say, it's obvious that people will just botch it.

    • Re:Simple (Score:5, Insightful)

      by Kjella (173770) on Monday December 19, 2011 @08:55AM (#38423136) Homepage

      2. They are being paid, make sure they do the work they need to by the time it needs to be done. Stick to schedules. I can not stress how important it is to stick to schedules. If a programmer can't meet targets you feel were set fairly then you may have to fire him/her. (...)
      4. Designate a planner. This will probably be you. The planner takes the goal and the design and makes it into a step by step development cycle programmers can follow. (...)

      You may not know it, but the people working for you probably think you're a lousy manager. You're the traditional project manager coming up with an estimate based on how hard it sounds like doing without taking any input from the ones actually working on the code, then drive people hard to meet your imagined schedule. From the "watch every commit" it sounds like you're trying to be the supercoder micromanaging everything everyone under you is doing. Chances are that if you're trying to do that much at once, your quality will turn to shit too even if you could outperform any one of them individually. Particularly if you're doing any part of the managing bit, making sure all your people are productive, clearing roadblocks, dealing with recruitment/staffing/budget issues, management reporting and so on. If you're serious you should get out of management, quick.

      • I set up schedules with the programmers, but we need to fit those schedules into client time frames so sometimes I do have to make assumptions or harder schedules. As for watching commits it's not about micro managing so much as making sure everyone is keeping up and looking out for developers straying from the design. When different modules are developed separately and need to be put together at later points you really need to make sure they are built in a way they will fit together. You could say it's my

    • by radtea (464814)

      Watch your repositories!

      This is all really good advice. The one thing I'd add is: "Make progress visible". I use various metrics to measure progress (tests passed, features implemented, bugs fixed, a sum over developer's own progress reports) and generate an imperfect but meaningful "progress" value that I chart on a paper chart stuck up in a visible place, so everyone can see we're on track or falling behind (I've never seen "ahead of the game" but I hear it can exist.)

    • by Surt (22457)

      2 is dangerous advice. It leans towards metrics that will tend to reward behavior that you may not want to encourage. Better to understand why targets aren't being met. Does your best developer take on the highest risk assignments, and frequently overshoot optimistic estimates?

      4 discourages team buy-in. Everyone should be involved in the plan in order to encourage commitment to the result. The further you get from direct development work, the worse are the chances that you'll formulate the most effecti

  • Hints (Score:5, Insightful)

    by mseeger (40923) on Monday December 19, 2011 @07:42AM (#38422854)

    Hi,

    A difficult thing will be: you have to trust people doing the job, even though you know that they are not good as you. You will get back solutions, that are not the same you would have delivered or may even not be up to the standards you expect. You must take a step back and ask "Does it suffice?" and not "Do i like it?".

    There are two big dangers:

    a) Trying to do your previous job in addition to be a manager. This will kill you. The result will be abysmal performance in both jobs.

    b) Having no reserves in your schedules to talk to people. This will get you disconnected and you may not realize problems until they bite you in your posterior.

    The most difficult thing for me was, that i learn things about people i never wanted to know. You have tragedies (child/husband/parent dying of some illness), relationship problems (both sides being in the company more often than you think), all kind of quarrels (If n is the number of persons you manage, the number of conflicts is O(n)) and so on.... You have to develop a thick skin concerning this. If you cannot, step back. Otherwise it will break you.

    Another lesson learned: If you make a decision, never postpone it. Pull it through with max burn ;-).

    After 8 years i had enough of that job and went into sales....

    Good luck, Martin

    • Re:Hints (Score:4, Interesting)

      by dbIII (701233) on Monday December 19, 2011 @08:33AM (#38423064)

      Trying to do your previous job in addition to be a manager. This will kill you. The result will be abysmal performance in both jobs.

      School Headmasters (among many others) have managed to do that in a lot of places over the last couple of centuries and leading craftsmen over a much longer period than that. The answer is not to do it as two full time jobs but one job with many elements.

      • by mseeger (40923)

        School Headmasters (among many others) have managed to do that in a lot of places over the last couple of centuries and leading craftsmen over a much longer period than that. The answer is not to do it as two full time jobs but one job with many elements.

        In my school there was a fixed ratio between the two jobs and the headmaster had two full time secretaries.

        While there may be special cases, doing two different jobs is usually a bad idea.

        Yours, Martin

      • And those kinds of jobs are professions.

        They come with corresponding formal residency like programs. Training is formally built into the job.
        They come with... shall I say greater goals. Doctors take an oath to help the patient. Teachers as well have professional duty to teach.
        Both have formal quality and legal controls.
        Neither generally operates as a 'general' worker under a corporation.

        I can't under-emphasize these points.

        Could software be a profession or craftmen like guild? Yes!
        Could we engage in 'do

  • I'm about to switch from a position where I did hands on development to one where I will be building and managing technical team. I will be responsible for designing and implementing the company's overall tech strategy. I am excited about this move but also nervous. It will require a different focus than I had up to this point, different skills, and different orientation. What should I be learning,

    I think you should have asked this question a bit earlier me thinks :)

    Having said that, there are things that you need to learn:

    1. The basics of project management if you don't understand them already. I'd say buy Steve McConnell's "Software Project Survival Guide".

    2. Software estimation if you don't have a good grasp of that already. You can start by reading Spolsky's "evidence based scheduling" http://www.joelonsoftware.com/items/2007/10/26.html [joelonsoftware.com]

    3. Learn to delegate.

    Also, be aware that you will lo

  • It'll tell you all you need to know about how successful (or not) you're going to be in your new role.

  • Congratulations! (Score:3, Insightful)

    by porsche911 (64841) on Monday December 19, 2011 @07:47AM (#38422888)

    Welcome to a whole new world. Get Michael Lopp's "Managing Humans", start thinking about the business value of what you are doing instead of just the technology, and at some point you may want to read Peter Senge's "The Fifth Discipline". You have 3 priorities you need to keep in balance: 1) your financial responsibilities to the company, 2) taking care of your people, and 3) doing the right thing for the customers.

    Good luck,

  • by ratbag (65209) on Monday December 19, 2011 @07:53AM (#38422910)

    After 13 years as a systems guy/programmer, I ended up as manager of 12 similar people. The University had gone through a restructuring and a few resignations and I thought it would be the right thing to do, since I was recognised as the most capable in the team (no false modesty here!).

    Four years later, I left the University to go back to being a systems/guy programmer, working for a small Swiss proprietary fund (my current employer). Reasons:

    1. Meetings. Endless. Bloody. Meetings. I'd been to fortnightly team meetings as a programmer. As a manager there was at least one sort of meeting with someone in the University every other day. Protestations that email or other collaborative software would save everyone time, mileage and money were met with indifference - other managers seemed to enjoy the stupid things.

    2. Stress and Responsibility - two sides of the same coin. When you're in charge of a group, the buck stops with you. This can wear you down after a while. It certainly did with me. Whilst I was immensely proud of the team and what we accomplished, occasionally things do go wrong and for some reason the customers never remember the good times.

    3. Health issues. My underlying, but previously unobtrusive OCD was exacerbated by 1 and 2 above. I grew afraid (shaking, uncontrollable fear) of meetings, eventually getting to the stage where I would leave them mid-way, or invent excuses not to go in the first place, or just not turn up. Whilst my managers were sympathetic, I became unhappy with the way I was doing my job, which of course reinforced the "bad thoughts"-side of my OCD. I was off sick from work repeatedly, sometimes for days at a time. I received professional help and medication for the OCD and got back on a somewhat even keel, but realised that I would never be happy in my job. When the opportunity to get back to programming and systems work arose, I took it enthusiastically.

    Now obviously your mileage may vary and my comment may be utterly useless. I guess the point is that a good programmer may not be a good manager. A person who enjoys working directly on problems may not enjoy giving the problems to others to solve. And a person with any sort of mental issues may find them more exposed when working as a manager!

    • by fartrader (323244)

      Mod this waaaaay up. To 11 on the dial.

      • by ratbag (65209)

        Nice idea. But 30 minutes! Ha. 3 hours was a typical scheduled duration for inter-departmental meetings. They didn't have a problem keeping to that timescale, but the idea of brief meetings was anathema to the layers of management above mine (I was three layers down from the pro-vice-chancellors, i.e. the day-to-day bosses). They'd taken the time to dictate the agenda and detailed notes to their PAs, and dammit they were going to make sure we all enjoyed their prose and oration at length.

        I've been back to t

    • by Alomex (148003)

      Meetings. Endless. Bloody. Meetings.

      It helps to have a set time for them, say 30 minutes in duration and hold fast to it. You will be surprised how many petty objections get dropped when people see there are ten minutes left and for items to go before we get to their pet issue.

    • " And a person with any sort of mental issues may find them more exposed when working as a manager!"

      Lock, stock, and barrel. I often wondered how some eccentric freaks ended up being promoted as managers or directors. They weren't that way before they were promoted, they grew into that disposition. Power corrupts. [v. to alter for the worse; debase.] While you have the opportunity to express the best of yourself, the worst parts of you will sneak to the surface.

  • Remain as you are (Score:4, Interesting)

    by eulernet (1132389) on Monday December 19, 2011 @07:59AM (#38422938)

    Here are some advice:

    1) Read the Theory of Constraints, and use it to organize your team
    2) Read about Emotional Intelligence
    3) Do not try to do everything, find what has value for your position, and concentrate on this
    4) Do not micromanage. If you don't know agility, try to follow a Scrum certification, I know it's dumb, but the concepts are very important. The aim is to let people self-organize, and your role is to verify their throughput.

    Your role as a manager is to be sure that the work is delivered, and help the team to do that.
    It means:
    - communicate to your team and to your hierarchy. Everything should be clear for everybody. If it's not clear, you aren't doing your job.
    - focus on your work. Stop trying to command people,. If they don't know what they have to do, it means that you didn't communicate clearly.
    - remove all possible impediments to the team (you need to protect them from your hierarchy)
    - be tough but fair with your team (do not let people abuse you)

    Try to use the following values:
    - clarity (everybody must know what they have to do, not how to do it, also act transparently)
    - feedback (if something goes wrong, fix it as soon as possible. For example, detect bugs or specification inconstencies ASAP)
    - trust (trust your team, let them do as they prefer, but check that the work is done correctly and in the time they promised, do not force your planning on them, let your team decide how they want to be organized, help them if they don't know)
    - responsibility. Make people feel responsible about their work. If you take all the responsibility, your team won't care about your project. If you take no responsibility, the team will feel that you don't do anything for them.

  • I love the comments about finding a good mentor. Highly recommended. Next, pick up Mythical Man Month, The First 90 Days, Switch, Behind Closed Doors: Secrets of Great Management and FruITion. Especially the 90 days book. You aren't just a dev with new responsibilities - you are learning something brand new. Imagine that you are now being asked to build apps in a language you've never seen. Mostly remember that your
  • I don't read a lot of management books but there are two I would recommend:

    1. It's Your Ship: Management Techniques from the Best Damn Ship in the Navy [amazon.com] by D. Michael Abrashoff (Captain, U.S. Navy, retired)
    2. The Book of Five Rings [amazon.com] by Miyomoto Musashi

    That latter is literally a book on sword fighting and military tactics from c.1640, but I understand modern Japanese businessmen study it. Read broadly it contains insights into leadership and adapting to ever-changing events. I've seen it in the management section

  • After the operation, you likely won't remember anything of this anyways. You want to put some reminders around your world about what concepts were important to you.

    Your brain function will be less, which will make it harder for you to relearn the lost concepts, but aim for at least a gentle understanding of them.

    You will be happier, once unbundled of curiosity, but may be frustrated by your new found limitations. At least you won't remember how you were.

    Good luck.

  • by Lumpy (12016) on Monday December 19, 2011 @08:43AM (#38423096) Homepage

    1 - give yourself a major head injury, you need to go from a educated professional to a brain damaged "visionary" who has "forward thinking" and "Paradigm Shift"
    2 - buy a book on buzzwords and use them all wrong, typically in the wrong spots. "WE need to Empower the diversity of the SQL server! That way we can Achieve a Sea Change OF Spin up!"
    3 - learn how to golf.

    That is pretty much it.

  • by Kr3m3Puff (413047) * <me@kitson k e l ly.com> on Monday December 19, 2011 @08:44AM (#38423098) Homepage Journal

    First off, while I don't know exactly your situation, it does seem that you aren't going to be moving as far away as you might have thought. I have gone from "developer" to "architect" over the first 15 years of my career and now I have moved onto what is clearly senior management, but I am part of a large organisation which means that I still am not that close to the top. I would be considered a CTO of a medium sized company though. I have full P&L responsibility for more than one area and am responsible for about 150 people and about £10 million in budget per annum, 1/2 of that being hardware/software. I have been doing the management role for about 2 years now and I can say, for me, I won't go back.

    I think my people, mostly, don't think of me as PHB. That is in part by remembering your roots, but more than not it is building up trust that you are going to lead them the right direction and having proper "adult" conversations about risks and issues. As others have said, micro-management, especially in the West, is horrible. You have to delegate and trust your team, no matter how tough that can be at times. Respecting their professionalism, much as you would have expected in their place, is necessary. Do not shy away from tough conversations though. It is much better to be up front about issues and direct than it is to avoid the subject hoping that it just will take care of itself. I have seen many "good" people turned into "bad" because there was a minor issue that festered until it wasn't recoverable anymore.

    As far as the Technology, ask a lot of questions. Having a good inbuilt "bullshit" detector is a must for effective Technology management. Don't know every detail, but know when people don't know what they are talking about.

  • I have done it, and it worked well. I've moved back also, which was a lot harder.

    Developers want a boss who understands them and who thinks like them. So don't lose your developer mindset. Keep your knowledge up to date by sitting with a developer frequently and go through their code. You know that as a developer, you'd appreciate an executive to look at your code an actually understand it. For you as an exec, it'll keep you up to date, to a certain extent.

    Trust the developers you work with. This only works

  • ...an executive.

    Presumably you're being put in this position because you have at least some development experience that your compatriots in tech do not and the company thinks you also have leadership potential. Stop telling yourself you're an executive for one thing, you're a manager. In a few years, with a lot of luck and hard work (which includes stepping on the defenseless, the helpless, and the needy - usually) you may get to an executive position, but I doubt it.

    You're probably going to absolutely de

  • Lead, don't pull (Score:4, Insightful)

    by sl4shd0rk (755837) on Monday December 19, 2011 @09:13AM (#38423194)

    1) Do the sh*tty TPS report work yourself. Don't hand it out.
    2) If the printer is a continuing problem, GET ONE THAT WORKS
    3) Never, under any circumstance, take the stapler away from the mumbly Aspergers guy

    (seriously...)

    4) Keep the department a fun place to work. Good employees work best when they enjoy the workplace.

    5) Don't dictate. Lead by example. It's really crappy to see the Manager leave at 5:30 on a Friday while everyone else toils on a late project. Even if you can't help, let everyone know you're willing and making yourself available wherever you can help.

    6) Taking everyone out for lunch once a is a great appreciation strategy. Even if it means bringing in doughnuts. People appreciate managers going above-and-beyond once in a while.

  • be a shield (Score:4, Insightful)

    by l3v1 (787564) on Monday December 19, 2011 @09:18AM (#38423218)
    From my experience, the most important things a good manager needs to do are
    - listen to everyone, and make (and I mean do make) the decisions, and not based on past friendships, but on the merits of the ideas,
    - after the decisions, try to shield your team from everything that is above and/or beyond their work, they shouldn't know or care about administrative and or managerial stuff, you should do everything to provide a good working environment for them,
    - to an extent, you have to forget you were a developer, don't try to solve everything and don't always try to come up with solutions and decisions before you listen to your team, because 1. after a while you're not qualified anymore to decide on every technical issue and 2. if you still do so, after a while nobody will even try to come up with ideas for solutions since they will see you don't listen and/or care, and you'll easily demotivate them.
    There would be some more minor points, but I think the above are some of the more important ones.
    • by Lando (9348)

      This appears to be good advise. From my own management standpoint I would make the following basis to work from as a manager:

      -- Listen to your team, but understand you make the final decision.
      -- Don't feel that you are more important than those working under you, they have a job to do, you have a job to do, that's pretty much it.
      -- Working with technical people, you're most effective by clearing hurdles for them. Help to make sure their health care is taken care of, that upper management comes to you with

  • Good luck (Score:5, Interesting)

    by delphigreg (835826) on Monday December 19, 2011 @09:19AM (#38423224)
    Five years ago I was fed up with incompetent managers, silly requirements, unrealistic deadlines, and unending piles of bad decisions. I thought I could do better. This year I had enough and are doing the best I can so bring down the pointy hair.

    One key thing to understand is that right now you are great with technology, but management isn't about technology. It's about people. The people you manage, your peers and leaders in other areas of the organization. People can be a lot harder to figure out than technology.

    My advice is this.

    1. Read "Behind Closed Doors". Probably the best book I read as a new manager. Wish I had read it before I made the leap. http://www.amazon.com/Behind-Closed-Doors-Management-Programmers/dp/0976694026/ref=sr_1_3?s=books&ie=UTF8&qid=1324299173&sr=1-3 [amazon.com]

    2. The best part of my day was working with the techies I managed. Listen to them, make time for them, and stay as closed to what they are building as possible. But also remember you are their boss. You will have to force them to make bad technical choices to meet a deadline, and will have to ask them to work nights and weekends. Make sure it is mutual respect, but at the end of the day your word has to be final.

    3. Understand how the company makes money. Not just selling a product or service, but really learn this. Because at the end of the day, if a company doesn't make money it will cease to be. This is valuable to learn because the more you can translate how your team fits into the revenue stream, the better leverage you will have. For example, there are two ways to look at how a team "adds value". You will either directly participate in the revenue stream, being on a product team, e-commerce, etc. Or you will be involved with "cost avoidance", meaning the company is spending less because of your efforts. This can be either time savings or accuracy improvements. The later is not too hard to quantify. If you know how many hours are saved in a process you write, add up the salaries of those who did that process, subtracting the salaries of your team. For example, if you save 100 people an hour a day with your process, with each person making minimum wage ($7.25). There are an average of 260 work days per year. This translates into 100 * 260 * 7.25 = $185,000 in savings per year. If you have one full time employee supporting the app, at 80k per year, your application is saving the company ~ 100k per year. Now of course this does not include hardware, software, training, donut expenses. It's not intended to. It is intended to get people's attention, justify funding for your team, and facilitate you getting more in next year's budget.

    4. Keep good notes. You may become an Outlook operator in your new line of work. Be sure to keep important emails that record decisions. Send out your understanding of a meeting after the meeting to make sure everyone heard the same thing as you. Keep a notebook or tablet and take tons of notes in meetings. If you are in several meetings per day it can be very easy to forget who said what when. This can be important when decisions are questioned later on. Or if things go bad, accountability can be shared among the entire executive team and not focused as the new manager.

    5. Hire really good people. Know that interviews are about finding the right fit for a team as well as their technical abilities. If you do this right, the rest of your work-live is exponentially easier. Ask good questions, do quizes and tech screenings. Listen to the questions a candidate asks. But trust your gut instincts.

    Bottom line is remember to keep your sense of humor and humility. This can be one of the most challenging and rewarding things you will ever do, managing others. You are their boss, responsible for their work lives, and a major influencer of their personal lives and financial futures.

  • While I understand that in US business, the only way to a greater salary is climbing the ladder and that means management, the Peter Principle is nowhere more evident than in managers that were programmers.

    First: you are moving from a programming environment where your 'product' is entirely the result of your work, to a management environment where your 'product' is other people's work, meaning an ENTIRELY different skill set. Think working with Waldoes would be challenging? Try accomplishing anything wit

  • by Blade (1720)

    Trust.
    Delegation.
    Foster an environment in which people feel they can empower themselves.
    Trust.

    You don't get it from reading, you get it by thinking about the people who you liked working for the most, the organisations you felt most valued by.

  • If you haven't already, read Peopleware: Productive Projects and Teams [amazon.com] which will teach you that, as a manager, the most important thing to you is your people and your respect of said people. The book is a must-read. Seriously.

  • As the one responsible for your company's tech strategy, you need to understand your company's business. That's most likely a major change of focus. You'll also have to change how you keep up with the tech side of things, have a broad understanding of the technology out there, and try to understand what changes you can expect in the next few years ahead:

    - Depending on your company's size/type, a mini-MBA may be useful. (take a formal course program, certain specific courses, or self-study). The goal i
  • by Phoenix666 (184391) on Monday December 19, 2011 @10:04AM (#38423368)
    I made this transition ten years ago. It hasn't been a smooth ride. The skills you need to be an effective manager are human ones, not technical. The goal is to build a great team, work with them to define the technical objective, put your stamp on that, and then do what you can to help them work effectively with each other and run interference for them with the rest of the organization.

    There are so many politics involved with that; I guarantee you no one in sales, marketing, HR, finance, or anything else gives a crap about any technical goal or about what's best for the company or any of that sort of thing. They only know ego and the size of their Christmas bonus. So you have to deal with them strictly on that basis. But that's an entirely different discussion tangential to what you were asking.

    As far as motivating your team, the best summation of how to approach it that I've ever seen is this video. [youtube.com]

    The second and last gotcha to be on guard for with the transition you're making is to embrace the exercise of your own authority. Human groups need authority to function well. It's how we're wired (unfortunately). You have to get over your natural reluctance as a programmer to exercise it. If you don't make firm decisions and stick to your guns, the team will begin to unravel. Some members may start to undermine you, and that will make it impossible for the team to accomplish its goals, to everyone's detriment. It's very difficult to make this psychological shift and you may experience a lot of feelings of guilt and self-doubt and it can really tear you down if you don't deal with it well. You might want to have a occupational therapist or somebody like that on hand to counsel you as you go through it. Otherwise you won't make it or you'll go full evil in reaction when the programmers stop doing their jobs.

    Good luck!

  • different skills, and different orientation Learning to make a "O" shape with your mouth, I hear, is pretty difficult; but, I think you can do it. As for orientation, I'd say it is pretty much the same except you will be able to afford better knee pads.

    In all seriousness, your going to find that it is tradition to hate on you for being the boss no matter how nice you are; and your job as far as your boss is concerned, is to get shit done for as little as possible. Don't take anything personal from below

  • by JustNiz (692889)

    Don't think of it as a promotion. its not. As the OP identified, its a totally different skillset, therefore a totally different job.

    Don't be surprised if you're used to being a great developer, and therefore well-regarded, but find out you suck at being a manager, so start losing credibility fast.

    Money aside, I never understood why some developers want to become managers. Did you not choose to be a developer because thats what you like and want to do?

  • The first thing I'd recommend is not to ask for executive advice from the Slashdot crowd.

    Jeez, how'd you ever get promoted?

                  -dZ.

  • by nine-times (778537) <nine.times@gmail.com> on Monday December 19, 2011 @01:22PM (#38424190) Homepage

    If you want to avoid being the PHB, then don't read a bunch of management books or go to management seminars or get your MBA. Avoid taking a lot of the advice that you'll be given.

    Really, it can be helpful to read about management, but the main source of PHBs is that it's some guy who has been thrown into management without being comfortable with it, and his response is to latch on to whatever random management self-help book he read. He reads something about how to motivate people or how to manage an IT department, and instead of thinking critically and applying his own experiences, he follows the quick-fix methods that he read about.

    There's plenty to learn and plenty to study, but use your head. There's no metric to replace knowing the people you're managing. There's no procedure to replace good judgement. There's no magical workflow that replaces knuckling down and doing your job.

  • One of the first things you have to realize is that you're making a transition out of your comfort zone, and that some of your strong suits as a developer (and certainly many of the tasks and initiatives) with which you've been successful need to be left behind. Take a look at The Leadership Pipeline [amazon.com] for some ideas on the changes you may need to make.
  • Read your Machiavelli. Read Sun Tsu. Whatever works. Clown suits work (see Miyazaki).

  • By making this decision you have chosen the dark side. A side effect is that your hair will immediately start to stand on end, resulting in pointy clusters. Good luck.
  • Seriously, treat them as you would treat day laborers if you picked them up in the morning to work on your yard: Give them clear instructions about what's expected, give them clear feedback (good and bad) about how they're carrying out your instructions, and stay out of their way if they're doing what you want them to.

    A lot of bullshit has cropped up around management techniques, especially among geeks, and it's cruft that needs to be cleared away. Devs are like everyone else: They want to know what they

  • One major thing that you'll have to get accustomed to is being hands off with the technical implementation. Set your expectation of what needs to happen, bring your team about to help make decisions on what direction you want to go in, but when it comes to putting word into form... stay away. It's far too easy for past developers to turn into micro-managers at the implementation level, which will definitely cause issues for your team going forward.

    On the plus side, you have a much greater foundation with

  • You recognize that you're not infallible and that you don't know everything - this is 80% of the battle of being a Good Boss.

    I'll skip the "read this book" stuff, and go straight to the obvious points.

    1. The best job description I have ever seen for management (at any level) is "shit deflector". Your job is to make sure your people can do their jobs - which usually means getting between them and all the incoming stupidity. Make sure you have time in your schedule for this - it's easily the most important thin
  • ... for roughly 18 months now, and quite successful at least in the aspect that people working for me kept telling that they are quite happy with how I do things compared to what was before I took over. So far, so good. I'm still not dead. ;)

    Main lessons I learned:

    * Learn to delegate. Fast. Don't ever ever do things yourself (speaking about solving tech issues). If you have worked with the same people before, they will frown at you for not "working" anymore for roughly 3-6 months. Ignore it. Justify it. If

  • A few of these have already been said ...
    1. - Delegate and get used to it. Get your team used to doing what you tell them to do.
    2. - If you're managing people you used to work with as a peer, realize that the relationship has changed. You are not their friend. You are their boss. This doesn't mean that you can't be nice or understanding, but it does mean that you can't let anyone on your team get away with poor performance or bad behavior because they're "a friend".
    3. - Resist the temptation to jump in and help out
  • Avoid pointy hair? LOL, ain't no way! You're already 1/2 there...

    No matter what, as the boss you are going to be the bad guy at least once in a while.

    No matter what, you are going to be less familiar with the technical details of the work being done and the issues involved than the guys in the trenches.

    With that said, you can avoid the worst behaviors of the PHB. With your technical background, if you keep it up, you will be able to know which developers are BS'ing you and which give advice and informati

  • by Jim Hall (2985) on Monday December 19, 2011 @04:24PM (#38426430) Homepage

    I started my career as a systems administrator / systems programmer on Unix systems. Over the last 20 years, I went from a "hands on" role to a leadership role. I'm now the "CIO" of a small university (we don't have the title "CIO" at this campus, but that's basically my job.) Some of those transitions to a larger role were easy, others were more difficult.

    I strongly recommend you read the essay "Taking on a new role" (PDF) from MOR Associates. [morassociates.com] In short, the essay gives this advice:

    1. Share broad themes early: what general areas do you plan to address, what are your goals for the team, where are you headed?

    2. Read the landscape: what does the culture of the organization look like, not just in the team you work with, but at the leadership level.

    3. Build relationships: people who can help you in your new role, mentors, coaches.

    4. Create a "SWOT" profile with your team, to understand the Strengths, Weaknesses, Opportunities, and Threats.

    5. Assess the talent needed to get the job done: do you have the right people, and are the right people doing the right things?

    6. Understand your financial situation: this is often the most-overlooked by new leaders.

    7. Sketch out your priorities for the first 3-12 months: in particular, keep track of what you need to get done in your first 100 days.

    I like do to the SWOT profile (see #4) without actually using the terms "Strengths, Weaknesses, Opportunities, and Threats." I find it's easier to start with a "plus/delta" profile. If you haven't done that before: Draw a vertical line on the whiteboard. On the left, label it "plus"; on the right, "delta". Draw a horizontal line across this, making 4 quadrants. Above the horizontal line, label it "now"; below the line, "future".

    Now you're ready for your team to identify what's working well (plus) right now, and what's going to be a benefit to them after another 6-12 months. They can also help you identify what needs to be addressed/fixed/changed/improved (delta) right now, and what can wait for another 6-12 months. Congratulations, you've built a SWOT profile:

    • S = plus, now
    • W = delta, now
    • O = plus, future
    • T = delta, future

    I find the SWOT helps me to identify the key issues to focus on. What you must do is identify a plan to address the right-hand column (deltas) that leverages what you have on the left (plusses). Your team is critical to help fill out the SWOT, and the great thing about this exercise is that it helps the team to identify with you on your new level. But while your team helps you with the SWOT, you must build your own strategy to respond to it; that's your job as a new leader.

    If you're having trouble picking out your top priorities (see #7) you may also consider doing an "affinity" exercise with your team. You can do this in different ways, but here's what I find works best for my team:

    1. Give each team member a stack of Post-It notes, maybe 5 or 6 each. Have them write down what they think are the top priorities - but only one item per Post-It note. Not everyone can fill out 5 or 6 Post-It notes, and that's ok.
    2. When everyone has their notes, talk about them in front of the group. See if any overlap (or are the same) as someone else's note. Combine any that seem to match up.
    3. Then, pass them around the table. Each person at the table gives an independent score (0-10) for how important they think that item is to the team or organization. You aren't ranking them in a list, you're just giving them an independent score. Everyone gives their own score, and passes the note to the next person around the table.
    4. When every Post-It has been scored by everyone at the table (i.e. when a person gets their own Post-Its back) add up the scores for a total for each note.

    You can now identify (by score) what are your top priorities. Maybe you have 5 or 6 "top" priorities. Or maybe you only have 4 top priorities, and there's a big gap (in score) between #4 and #5.

  • I made this transition myself around 2001 and more-or-less successfully managed a team until 2007. It was a great experience, and the right move for me (and IMO for the company). While there's a lot of challenges you'll have to work through, there's only one major thing I look back on that I regret:

    I wish I had spent more of my time selling and promoting my team's work to the rest of the company.

    I had a great team of people and we accomplished a lot of amazing things. We mostly built internal tools for empl

  • You'll need to practice increasing your range to piss on more people beneath you.

  • by puppetluva (46903) on Wednesday December 21, 2011 @12:08AM (#38444300)

    1) Find a manager that is successful in your company and is generally admired. Get to know him/her and learn what they do right, what they do wrong, and what they know about the culture of the company. When you know them well and know their secrets well, find the next one.

    2) Find a very successful manager that runs a similar department to yours in an excellent company reknown in your industry. Get to know them, figure out what they and their teams do right, what they do wrong, and how the culture of their company works and differs from theirs. Fix yours that way or have good enough relationships to join theirs. When your group is better than that group, find the next one.

    3) Find out how your company makes money . . . really makes money -- what do they make, what do they sell, who do they sell to and how much of each thing do they sell to whom and how. Figure out how your department fits into that and how you can best fit those goals. Do those things. Figure out what doesn't make money (or worse wastes money at) -- aggressively try to eliminate those things.

    4) Figure out what your team is good at and what it is bad at. Cross that with the results from #3. Focus on getting your team better at things that help the company make money and getting rid of things that make it lose money.

    5) Respect people -- even those you don't like. You can learn something from _everyone_. Even if it is to just avoid making the foolish mistakes they make. Have enough respect for those people who work hard and pull things through for the company to let go those who slack off and basically leach off of their coworkers. Help those who aren't good at things, but really, really want to get there. Consider everyone's skillset as they are and reward each achievement and each step forward for people at their level.

    6) Have a plan. From the details of #3, and the development of #4/5 and the examples of #1,2 figure out what goals get you closer to achieving those ideals in the the next 3, 6, and 12 months. Every quarter, reassess where you are and tune up your goals so they stay relevant and you measure your progress.

    7) Measure your progress -- success or failure -- at every turn. How well do you work and how well do you create product? How good are the things you make and how good are your processes/tools for making them? Use your comparative analysis with external and internal teams to figure out how they operate as well and figure out how to measure it and improve it. Don't be a slave to numbers but don't be ignorant of them. If you pick the wrong metrics, then you learned that you need better metrics.

    8) Act like the manager you wish you had. Don't be a jerk, and don't gossip. Talk to people face to face and act with integrity. Your group and peers are you community - treat them that way and build the community stronger.

    9) Build your self and your group. Figure out what you all are weakest at (that matters) and get training and practice at getting better. Make it a quota to do this at least annually.

    10) Manage yourself and your own stress. Have a todo list of the next top 3 most important things to do at all times -- do those next. Take care your health, sleep well, eat right and learn to leave work at the office enough to not bear the burden of your whole team's worries when you go to bed at night.

Luck, that's when preparation and opportunity meet. -- P.E. Trudeau

Working...