Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Businesses Programming IT

The Programmer's Path To Management 125

snydeq writes: The transition from command line to line-of-command requires a new mind-set — and a thick skin, writes InfoWorld's Paul Heltzel in a tips-based article aimed at programmers interested in breaking into management. "Talented engineers may see managing a team as the next step to growing their careers. So if you're moving in this direction, what tools do you need to make the transition? We'll look at some possible approaches, common pitfalls — and offer solutions."
This discussion has been archived. No new comments can be posted.

The Programmer's Path To Management

Comments Filter:
  • by rsilvergun ( 571051 ) on Tuesday June 30, 2015 @12:32AM (#50016693)
    At least in America if you don't move into management you're dead meat by 40, 50 tops (unless you're some sort of genetic freak). Around that time it becomes impossible to put in the 50+ hour work weeks at a moments notice let alone compete with cheap H-1b labor. It's not even age discrimination. They don't care that you're old, they care that you either can't or won't put in tons of overtime they don't pay you for.
    • Yep, unless you're in some niche market where H1Bs don't have the skill that you got. So that's the name of the game - have unique and difficult to find skills (which you should have by that age).

      That means following latest and greatest tech is good objective when you're without experience; but later not much so.

      • by NoNonAlphaCharsHere ( 2201864 ) on Tuesday June 30, 2015 @12:56AM (#50016743)
        Once you hit 45, you had better have moved into management, or be a white-bearded wizard with some kind of obscure language/system (MATLAB, SSA, SPSS, COBOL, DB2, etc.); otherwise, if all you know is stuff like Java/C/C++, you're going to be unhireable after the age of 50. This is the voice of experience speaking.
        • by faway ( 4112407 )
          Programming means constantly learning, period. Get used to it!

          Management means constantly failing, period.
          • Managing engineers has been unfavorably compared to herding cats, both tasks are all about effective communication and (benevolent) manipulation. Engineers generally don't have these skills unless they have had some other life experiences such as (say) bartending at a busy pub. Having said that, most programmers can recognise a good manager if they are lucky enough to encounter one.

            Disclaimer: 56, turned down the boss's job a couple of years ago - been there, done that in my late 30's, learnt a lot but u
            • It's incredibly taxing to see the number of senior programmers/engineers/researchers/etc. get moved into management who completely lack the appropriate skill set. Definitely agree though that food service and retail management experiences generally give people the correct skill set. For a variety of reasons, those industries better train and prepare management as well as filter the crap. White collar offices tend to lack effective management training and let's not even get into the whole university MBA f
          • Well, it sounds like management is heaps easier to do and a lot less work...

            Remind me why again it's also much better paid?

            • by Dog-Cow ( 21281 )

              It sounds like you're ignorant. Remind us why you're paid at all?

              Engineering (any discipline) and management (of people) are completely different skills. There are good and bad in both fields. The good do a lot of work and are productive, the bad don't. It doesn't matter what field they're in.

            • Remind me why again it's also much better paid?

              Well gee, I believe it's because management sets the salaries.

              The easiest job in the building seems to be HR. You just act like a cancer, and they shower you with money. It's the American HR Society model.

          • I see you failed math, you need to find a new career now.

            Unless there is a class you can take to take actual years off your age.

            Listen to the question before blurting out the answer, and stay off my lawn !

          • by MikeMo ( 521697 )
            It would be nice if knowing the language and job were all that is required to get hired today. The truth is that 50+ people don't get hired as programmers, period. It doesn't matter what you know, as you won't even get an interview, and your resume ends up in the trash as soon as they figure out your age.
            • Dear employer,

              I'm actually 30, I just look old!

            • by RingDev ( 879105 ) on Tuesday June 30, 2015 @09:31AM (#50018259) Homepage Journal

              I find this notion interesting.

              I am a manager. I have hired people over 50. On my team right now I have 3 people within 3 years of full retirement. One of whom I hired within the last year. I also have two that are within spitting range of 50, one of who I hired less than 6 months ago.

              When I'm bringing someone on board in the 40+ category with 20+ years of professional experience, I have drastically different expectations than what I'm looking for in a 24 year old kid who's on his first salary gig out of college.

              I'm looking for someone who understands corporate structures, workflow analysis, generalization. I'm looking for someone who says, "When you boil this down, it's an asset management system, and I've worked with half a dozen different vendors and 4 different home grown systems that do the same thing". I want someone who can sit down with users, look at what their doing and not just imagine up a new piece of software, but understand the business process to the point where they can make truly business impacting recommendations with a realistic grasp of what it would take to accomplish. I want someone who will pull the young bucks aside and explain to them the merits of simplicity and maintainability, someone who can do code reviews without being a pretentious dick, someone who can help guide that next generation of developers into the future engineers and architects I need.

              People over 50 absolutely have a place in the development arena. But if you're 50 years old and still expect to have the same responsibilities as a 24 year old kid, you will be sorely disappointed.

              -Rick

              • Hallelujah and Amen brother!!! As a Solution Architect "within spitting distance of 50" You've just described why I get out of bed in the morning. Last week some of the 24yo college newbies finally worked out that they weren't even born when I started my first programming job; and that they were still mewling and puking in nurses arms, when I was making the stupid mistakes that I'm trying to prevent them from making.
          • The problem with being a software developer at 45 or 50 is that when you learn Node.js or CoreOS or whatever the new hotness is and a 28 year old learns the same technology, a lot of HR managers will think they can get 10 extra hours of quality work per week out of the younger man (or younger woman) for 20% lower compensation. That belief is often wrong because 40 hours of quality work from you trumps 60 hours of quality work from most people 20 years younger, but it's a common belief nonetheless.

            Conversely, there are three good things you can do as a manager that used to be a software developer for fifteen or twenty years:
            1. You can manage from experience, with a real understanding of the work your employees are doing. My best managers have all been former developers - or in some lucky cases, people that get to do half management, half development.
            2. You can make informed decisions about what technology stacks to use or to avoid and what priorities matter. At my last job I turned down a management role repeatedly, and I was pleased with my choice until the person who took the management role drove me out of the job with poor decisions.
            3. You can understand that a development manager's most important job is running interference between skilled employees and the rest of the company. Yes, it's less fun than developing. But you'll gain respect, trust, and productivity from your team if you point them to the target and then spend your own time leaving them alone, keeping them out of wasteful meetings, and trying to remove any obstacles that would slow them down. My current manager does that, and she's awesome.
            • "Experience is the name everyone gives to their mistakes" --Oscar
              • I forget where this quote comes from, but it's a favorite of mine: "Success comes from good judgment. Good judgment comes by learning from your mistakes. Mistakes come from bad judgment."
        • if all you know is stuff like Java/C/C++, you're going to be unhireable after the age of 50

          Hu... I'm safe using PHP!

        • Nonsense, old people with heavy industry experience (insurance, trading, e-commerce) who know the Java or C++ can make serious coin.

          Also former pure developers who can bridge development and operations and architecture can make big money; that's what I'm doing and I'm over 50. Yes you have to keep current.

        • I'm over 45, and have absolutely no problems getting hired. But then again, I don't just sit on my butt thinking the stuff I knew 20 years ago is highly relevant either. Always learning new stuff, always pushing the boundaries of what I know. Be the best, or die trying.

      • have unique and difficult to find skills (which you should have by that age).

        Firstly, if you can learn these magic skills then so can other people - so you won't be unique.

        Secondly, it's very difficult to predict what will be hot in a few years time, and even if you could your workplace might not use it.

        • Some skills (actually, most of the ones worth having) take time to practice to actually be useful. Something that can't be done when the skill is needed NOW.

          For reference, see Cobol programmers and their salaries in the years before y2k.

    • we need to up the min pay level for no ot to something like 70K+ COL.

      • You get paid what you are worth. If you aren't, go elsewhere. If you can't find an elsewhere, you were getting paid what you were worth, and you think too much of your skills.

    • by MrKaos ( 858439 )

      They don't care that you're old, they care that you either can't or won't put in tons of overtime they don't pay you for.

      Since people work for free the expectation is there but it can't be put into a contract, so ultimately it is still a choice. At issue is whether or not someone can maintain their productivity if they consistently work back.

      I think it is the social norm that should change. People seen staying back and working overtime used to be seen as the 'go-getters' when people worked a normal 8 hour day. Now most people do it for no other reason than they are too spineless to buck the trend and actually *be* productive

      • by Viol8 ( 599362 )

        Unfortunately there are plenty of managers around who think that the person who knocks off at 5.30 is not a "team player", regardless of whether they get their work done. And they'll reflect this moronic point of view in their review of the employee. Now you probably won't get fired for not working the hours, but you certainly won't be getting much of a bonus or promotion either in most large AND small companies if you don't.

        Sadly this sort of long hours office culture is so well ingrained in the USA and UK

        • by MrKaos ( 858439 )

          Unfortunately there are plenty of managers around who think that the person who knocks off at 5.30 is not a "team player", regardless of whether they get their work done. And they'll reflect this moronic point of view in their review of the employee.

          So true, they don't take into account that some people know when it is time to go home instead of become a hollow shell of a being.

      • "Now most people do it for no other reason than they are too spineless to buck the trend and actually *be* productive as opposed to looking productive."

        Why should it be any other way?

        Time and again experience shows there's more profit in looking productive than actually being productive -and arguably, being experienced in looking productive more than being productive will help you climbing the corporate ladder once you go into management.

        • by MrKaos ( 858439 )

          Why should it be any other way?

          Well, I think some people do the work do it because they want to be good at it and, they enjoy it. They pursue challenges for the skill sets and visa versa. So being genuinely productive is a way to acquire new skill sets for yourself so everything is under control.

          That's why the best IT professionals rarely work big hours, they don't need to.

          Time and again experience shows there's more profit in looking productive than actually being productive -and arguably, being experienced in looking productive more than being productive will help you climbing the corporate ladder once you go into management.

          I've noticed. For me though, I'm not doing a role just so they can get something out of me, I have my own objectives otherwise I wouldn't even be there. Acquiring tal

      • This is a problem across all industries, and it's not as bad in software as elsewhere. I've been writing software for fourteen years and I was only asked to work long hours once, for one week. My employers won't insist on it because I'll leave, and I'm not easy to replace and even if they find someone just as skilled it takes a few months to ramp up for productivity. I'm sure it does happen, of course. But if my boss asked me to work a 50 hour week I would quit today - and probably be back to work wit
    • by Bengie ( 1121981 )
      We have a few Software Engineers in their 60s and 70s. Some of them didn't know what SFTP is, but when it comes to what they're good at, they're awesome. They're still useful and they make decent bank. Our average software engineer is around 35.
    • Why then, at 40, do I still get weekly contacts from recruiters looking to fill local development positions? Is it possibly your comment applies to a local market, possible in Silicon Valley, but not to the Midwest? Or is it possible that every one of these recruiters is just trying to fill a quota of prospects despite the fact that the employer they're hunting for couldn't afford me?
    • At least in America if you don't move into management you're dead meat by 40, 50 tops (unless you're some sort of genetic freak). Around that time it becomes impossible to put in the 50+ hour work weeks at a moments notice ... It's not even age discrimination. They don't care that you're old, they care that you either can't or won't put in tons of overtime they don't pay you for.

      Genetic freak checking in. I'm 52, still a senior systems programmer/administrator and can still work 36 hours straight when needed - though I seriously try to keep those sessions from being needed. I've been asked many times if I want to move into management, but always decline as I'd rather shoot myself in the head than attend meetings, do budgets and write reports, etc... So far, I've also managed to avoid daily scrum and other process meetings (which are a complete waste of time, or my time anyway,

  • Don't Do IT! (Score:4, Insightful)

    by Anonymous Coward on Tuesday June 30, 2015 @12:39AM (#50016707)

    As someone who transitioned from Jockey to ShitMover I can assure you the move isn't worth the headaches. I used to work with a great bunch of like minded people who where interested in creation. Now i work with a bunch of egotistical idiots who just want to push stuff they know is garbage over the line just so they can get ticks against their name and get out before it blows up.

    • by dens ( 98172 )

      You nailed it! I became a programmer because I like programming and I'm good at it. After 25 years of doing it, I'm better than I've ever been. Why would I waste that hard earned skill and experience for spending all day in meetings?

      • Because the company can hire TWO 27-year-olds (or FOUR Indians) for what they have to pay you? Because of the "perception" that you're an old fart who's hopelessly unhip and not into the latest and greatest thing? Even though you're right, things should be done maintainably rather than fashionably?
        • Re: (Score:1, Informative)

          by faway ( 4112407 )
          27-year olds are 1/10 as effective as a 45-year old.

          Indians... forget about it. They code horribly.
          • Re:Don't Do IT! (Score:5, Insightful)

            by NoNonAlphaCharsHere ( 2201864 ) on Tuesday June 30, 2015 @01:35AM (#50016861)
            I know that, but MBAs don't recognize the truth of it.
            • by RingDev ( 879105 )

              Which is part of the point of getting more developers to move into managerial roles ;)

              -Rick

              • by lq_x_pl ( 822011 )
                I suppose the company I work for is in the minority. For R&D management, they pull exclusively from the trenches. If you don't have at least a couple years of development under your belt, you aren't going to be managing anything.

                The great thing about this is that your manager spends more time advocating for you than "putting the screw" to you. It also means b.s.ing about timelines is nigh impossible. All-in-all, it is a pretty fantastic setup.
            • by unimacs ( 597299 )

              27-year olds are 1/10 as effective as a 45-year old.

              Indians... forget about it. They code horribly.

              I know that, but MBAs don't recognize the truth of it.

              I would expect that there are quite a few MBAs that are smart enough to realize that age and ethnicity aren't reliable predictors of effectiveness. There are also plenty of organizations where MBAs aren't making IT related hiring decisions.

              My advice is to quit worrying about MBAs, H1-Bs and people that are younger than you. The best you can do for your career is to make sure that you are effective now and still will be 5 to 10 years from now. You can't depend on your company to make sure that will be the

          • You know, I know, but managers don't. Personally I think it's a bit of the good old "people think as they are" mentality, and hence they consider everyone a trained monkey whose experience is worthless, so they can be replaced by someone cheaper any time.

            With the only reason they themselves can't being that they'd have to be the ones doing it.

          • Protip: when you see a word you don't understand (in this case it was "perception") don't just ignore it - ask your mom what it means or look it up in a dictionary.

            • The reply is not responding to the sentence with "perception" in it. It's replying to the prior sentence.
          • And I get paid for cleaning up the mess.

            The out-sourced Indians I've worked with can code well: the time spent training them to spend the time and put in tests, and to assume edge cases and sanitize data, costs time and money that usually isn't in the original project estimate.

          • Yes, yes, and yes. If only the managers of the world could figure this out....

          • Generalization ain't good.
            I know a lot of 25-30 year old dudes who code awesomely. I also know a few 40-50 years old who code like shit.
            Agree on the Indians, thing, mostly, with an amendment: it's all about the culture. Indian people can code well, as long as the code is used and maintained by them exclusively. The problem is team mixing, or rather culture mixing. A team of 6 coders, 3 Indians and 3 Europeans (for example) would yield horrible results no matter how good each one is, individually. They simpl

        • Re:Don't Do IT! (Score:5, Insightful)

          by Darinbob ( 1142669 ) on Tuesday June 30, 2015 @01:48AM (#50016891)

          You have to make sure that 2 or 4 young/cheap programmers can not replace you. It's not like programming is the only skill for programmers. You have to understand the product you're making, how the team works together, how the different parts work together, etc. Become indispensable. Work for a company that doesn't do the latest and greatest fad (getting involved with fads is a short road to a short career). If all you do is know how to tie together different libraries and understand the syntax, then yes, you'll lose your job to the cheapest one out there.

          There are more types of things to be in the career other than just junior grunt and elite manager.

          The good jobs are the ones with actual job requirements listed, things other than "$x years with $new language". Experience is highly valuable. You can't take a recent grad willing to work for beer and hot dogs and have them design the next system. Chances are they're going to be hunting down your experienced staff for help on how to debug something simple.

          Because if they're going to toss away a good programmer in order to replace with cheaper workers, then believe me they will also toss away the good managers too and replace them with cheaper ones. If you can't find a job as a 50 year old programmer then chances are you're going to have much difficulty finding that 50 year old management position (especially when all the CEOs are 20 something Harvard dropouts who don't think old people are relevant anymore).

    • Re:Don't Do IT! (Score:5, Interesting)

      by anchovy_chekov ( 1935296 ) on Tuesday June 30, 2015 @02:33AM (#50016979)

      As someone who transitioned from Jockey to ShitMover I can assure you the move isn't worth the headaches. I used to work with a great bunch of like minded people who where interested in creation. Now i work with a bunch of egotistical idiots who just want to push stuff they know is garbage over the line just so they can get ticks against their name and get out before it blows up.

      Absolutely agree with the AC here. I made the move to management about 10 years ago and consider this a lost decade. Moved back to coding as a freelance and loving it.

      If you must, then at least learn some of the disciplines around management. Take some time to read up on management systems that actually work (e.g. Toyota Production System) and don't lose sight of your analytical past. I found the skills developed as a coder - being able to break a problem down into smaller parts, using empirical techniques to determine whether an approach would (or did) work... using logic and evidence - were of paramount importance to succeeding as a manager.

      On the flip side, I found a lot of magical thinking on the part of other managers - refusing to believe what maths or reason made self-evident. That's where people skills come in - getting people over the hump of their own prejudices or wishful thinking. Get the mix right and you'll shine.

      Good luck in any case.

    • There are many kinds of people, but for the purposes of this comment there are only two: those who went into programming because they love programming, and those who went into programming because they heard it paid well. Those people should go into management (or marketing) where they can do less damage.

  • Step #1: Sell out. That is all.

  • by bangular ( 736791 ) on Tuesday June 30, 2015 @12:52AM (#50016735)
    The stories about jobs and careers are getting so tiresome. I realize Dice bought Slashdot to datamine the comments (free focus group!), but it seems like half the stories are a variation on the same these days.
    • Lighten up, it's rude to make fun of the incompetent. Dice is the home for people who don't have the skills to work anywhere else.

    • by tlambert ( 566799 ) on Tuesday June 30, 2015 @01:54AM (#50016905)

      The stories about jobs and careers are getting so tiresome. I realize Dice bought Slashdot to datamine the comments (free focus group!), but it seems like half the stories are a variation on the same these days.

      It's the non-engineers.

      They have this misconception that people used to dealing with the intricate semantics of programming languages are going to be unaware of the intricate semantics of English. Therefore, if they ask a question once, and do not get an answer they like, they will repeatedly ask the same question in different guises, hoping to obtain the answer they wanted to hear.

      This really comes down to who is more patient than whom.

      I usually attempt to buffer my answers in order to soften the blow, but you can ask the same question as many ways as you want, and the answer will likely not change, so long as it is fundamentally the same question. And I usually have the patience of Job. However, there was one incident where I was up against a deadline, and was being asked to "just cobble together something that works, and we'll (read: you'll) fix it (read: in a binary compatible way) later. Which was an impossibility (I was working on some very complex database code written in C++ which did subschema definitional enforcement on an upper level database schema, and the semantics had to be correct for the data stored in the binary backing store to be usable going forward, when we did the next update). The code had to be *right*, as opposed to *right now*, and the time difference was important.

      We had a UI person who was in a management position, and they brought her over to argue their case that immediate was better than correct (correct would fit under the deadline, but only if everyone left me alone to finish the code). The UI person was constantly revising the UI in each release, and each release was practically a full rewrite. And she did not understand why I could not write my code the same way she wrote hers. Finally having had enough, I explained "It's OK if your code is crap; you are going to rewrite it in the next release anyway. My code has to work now, and it has to continue to work going forward, and therefore it needs to be correct. I understand that you are feeling the approaching deadline. So am I. However, while your code can be crap, mine can't be because I have to maintain it going forward. Now if you will get the hell out of my office, I will be able to finish the code by the deadline."

      Needless to say, there were some ruffled feathers. The director of engineering sided with me. I completed the (correct, rather than expedient) code by the deadline, and the product didn't turn into unmaintainable crap vis-a-vis the update process going forward.

      What's the moral to this story?

      Well, with specific regard to DICE:

      (1) Repeatedly asking the same question in different ways is not going to get them a different answer, if the first answer was correct. Any other answer than that answer would be incorrect, for the question asked.

      With specific regard to the current topic:

      (2) Engineers who actually reliably, repeatedly, and consistently deliver what they are asked to deliver, within the timeframe that was agreed upon, can, and often do, wield more authority than the managers nominally set above them in the food chain, so it's not like going into management is going to give you any more real authority than you already have by way of your relationship with the team, and their trust of your judgement.

      A management path can be a good idea if:

      (A) You want more perks (stock options, etc.), although in a good company, if you are a great engineer, you will get those anyway

      (B) You are tired of doing engineering for a living (which probably means you didn't qualify as "great engineer" under option 'A' anyway)

      (C) You feel you would be more useful and/or happier in such a position (but if your happiness is based on power, don't expect it will necessarily follow)

      (D) You

      • A very thoughtful answer, which they will promptly ignore.

        Having actually read some of the article, I notice that they confuse management with leadership. Any idiot can management - managers wouldn't be able to otherwise - but leadership is harder. Perhaps it is best expressed (accidentally) by an appalling manager I once had: "Managing engineers is like herding cats". What he meant was simply that he found it impossible; but without realizing it, he also showed that he hadn't understood leaderhip.

        To the ty

        • All in all, I don't think a real engineer will see management as a step up, except in terms of pay, but many engineers can become good leaders in the real sense.

          Thus encapsulating much of the hubris and disdain in the comments. Managing, like engineering, is about figuring out how a system works and solving problems to het it to work like you wanted. Except, instead of dealing with things you are dealing with people; in a system that is infinitely more complex and challenging. That is a real engineering problem that not all engineers can solve. Programmers are even worse than engineers because people don't follow a prescribes set of rules like a program does.

          • Thus encapsulating much of the hubris and disdain in the comments. Managing, like engineering, is about figuring out how a system works and solving problems to het it to work like you wanted.

            Are you not displaying exactly that hubris and disdain here, which you criticise? You may have heard what I said, but you didn't listen. Most managers are simply managers: they eaderly lick the spittle off the faces of their superiors and do as they are told without really knowing all that much about things. Like you they don't listen to the people they manage, which is why a Dilbert-like situation arises, where engineers do what they know is right, if they care, and don't if they don't. The pointy-haired b

    • It's not like you need a job if you can stay forever in your mom's basement.

  • by perpenso ( 1613749 ) on Tuesday June 30, 2015 @01:09AM (#50016785)
    A manager need to learn about the psychology of people at work and in groups. That not all people work the same. Some are inherently more efficient and productive working in one manner while others are more efficient and productive when working in a different manner. Some can get by with headphones in a noisy open environment, others require a quiet office to themselves. Some do well bouncing around from one part of a program to another, a breadth first sort of traversal of the code. Others do well drilling down into more and more detail in a single part of the program, a depth first sort of traversal of the code. In short, they need to learn that there are no universal answers. No universal manner in which to measure productivity. No shortcut for managers, that management is hard and you have to put in a lot of work to do it right. A manager also needs to develop an increasingly better understanding of other departments in a company or organization. How do the accountants look at this project? How do the marketing people look at it? How do the executives think it fits (or doesn't fit) into their objectives? Are any of the preceding or other interests in the company failing to properly understand a project and it value? How do I persuade them? Well the first step in persuading them is to understand their perspective and concerns. Then you can address these concerns in a manner that they understand, from perspective they have. Management is hard, you not only need to possess a deep understand of the specialty of the people you directly manage but you need to have a working understanding of the specialties of other people in unrelated departments. Again, there is no shortcut. Its hard work.

    On recurring theme in all the case studies of real businesses and project that you will study, regardless of area or topic (engineering, marketing, managements, etc) is that most failure are human in nature. That people were in the wrong position, used in the wrong way or were just plain unfairly treated. People both inside and outside a team, and inside and outside a company. A lot of this came from the arrogance and overconfidence of a manager. Hint at what not to do.

    So where does one learn more about the psychology of leadership, the psychology of people at work and in organizations, how to motivate, how to persuade, etc. Well that is what MBA programs teach. MBA programs are not about bean counting, finance and accounting. MBA programs are about taking a person with deep understanding of one part of an organization and providing them with a working overview of all the other classic parts and functions of an organization.

    Yeah, I said it, an MBA. MBAs are not like other Master's degrees where you delve deeper into a specific topic in your field of expertise. It is an overview of a complete organization. Statistics, organizational behavior (a bit of the psychology stuff I mentioned), marketing and sales, consumer behavior, product development, accounting and finance, management, strategy, operations, information technology, business law, negotiations (which is not limited to contracts, convincing others to see your perspective, to persuade them is a negotiation), etc. Basically you leave an MBA program the same as you entered. If you were a scientist before you are still a scientist, an engineer still an engineer, ... but now you can better understand and communicate with other people in the company or organization. You can be more effective and persuasive at representing the perspective and interests of your specialty. You are a geek that can communicate effectively with an executive if need be.

    Roughly 1/3 of my MBA class were scientists and engineers. Less than a quarter accounting and finance people. The classes I took were often very interesting. Personally I was constantly amused at how misinformed I had been. I had the classic engineer's disdain for anything business and marketing, thought marketing was just snake oil and misinformation for example. I was pleasantly su
    • Management, and even more so management theories, need to take the human factor into consideration. Every time you get to hear some bullshit "how to manage" story, you can't help but sit back and wonder whether they ever heard of something called human nature.

      Generally management and management theories treat humans like some kind of fungible mass. Like any human is identical to anyone else. Sadly, humans are not. By no means. What's worse is that managers think that everyone under their "control" thinks th

      • by jwymanm ( 627857 )
        You really just have something against mountain climbing... that sounds like an awesome boss to me.
  • Yeah - sorry dice - dressing pretty to become a boss just shows how stupid people who want to be bosses are.

    And that's why competent people hate them.

    Clothing does not reflect ability. I'm quite sure I can code far better naked than someone who thinks spend two or three grand on an Armani overhaul can.

    • Yeah - sorry dice - dressing pretty to become a boss just shows how stupid people who want to be bosses are.

      And that's why competent people hate them.

      Clothing does not reflect ability. I'm quite sure I can code far better naked than someone who thinks spend two or three grand on an Armani overhaul can.

      You are correct that clothes do not reflect ability; but then in a not so subtle ironic statement you claim that because someone dresses nicely that you are more competent than them.

      Dice's advice is spot on. Appearances do count as you move up; coding ability, OTOH, becomes less valuable. I don't pay managers to code, that's why we hired programmers; I need them to actually manage the project and make it successful. If they are busying coding either we have made the wrong person manager or we need to fire

  • Back when programmers were hippies like the Woz, they made great managers.

    Today programmers (especially foreigners and to a lesser extent American) are micromanaging manboys, the brains clogged with hubris.

    95% of programmers have no place in management.
    • Micromanaging manboys with brains clogged with hubris? That's basically the dictionary description of manager.

  • by Sivaraj ( 34067 ) on Tuesday June 30, 2015 @01:31AM (#50016849)

    I have been a programmer for all of my career, and had management roles in the past 10 years to varying degrees. Over this period, I have also mentored other technical team members in transitioning to management roles. The toughest part of that process is in learning the ability to delegate. This is especially tough for talented programmers.

    You often feel that it is easier for you to do a particular task yourself rather than delegating. It may be true that you might finish the work in tenth of the time it takes someone else to do, and you may be spending more time in explaining it to others. But at some point you have to stop doing it, start trusting others to deliver, and don't meddle with their work too often. Once you learn how to do it, you are well on your way to becoming a successful manager.

    • by chipschap ( 1444407 ) on Tuesday June 30, 2015 @01:45AM (#50016883)

      Learning to delegate is one of many necessary skills, but the biggest thing a new manager has to learn that being a manager is not about YOU, it's about your staff. Your job is to do what it takes to enable them to get their jobs done, to empower them, to remove roadblocks, and to make sure things work for them.

      The minute you forget this, you're done, because as a manager you are NOTHING without your staff. They're the ones who are going to make you look good or look bad.

      Yes, managers set direction, make policy, make decisions, all the stuff you hear about, but if they ignore the needs of the staff while doing so, they fail as managers.

      I was a manager for a good part of my career (after having been a technical person). I am glad I had good mentorship and learned what managing was really all about, which is empowering people to do their jobs.

      Side note: I was once myself mentoring a new manager, who said, "Well, what if I'm having a bad day?" My response: "You're the manager. You don't get to have bad days. Your staff needs you doing things for them every moment of every day, and YOU are not the one who's important."

      So if you're a programmer (or other technical person) aspiring to be a manager, fine, but keep in mind that the minute you become the manager, your role changes drastically, and if you're into satisfying your own needs, think twice about taking on a management job.

  • I think the trouble most geeks have with management is that in the end it is just varying degrees of bullying. Yes, there are visionary people who can lead by inspiring others, but these are extremely rare and most companies have a mild to severe bullying culture in their management. The trouble is that bullying works very well on many people, and is easy for unskilled people to do, so it survives. I think that until you accept this and start learning how to deal with it you will always find management hard

  • Talented engineers may see managing a team as the next step to growing their careers

    why waste programming talent? lock them to the keyboard.

  • Being a manager - a *good* manager - requires just as much training and work and learning as it does to be a good programmer. If you are considering making that move, be prepared to take some courses and read management journals and blogs just like you read programmer stuff today. It's a skill and an art, too.

    Also, don't give up programming. Keep your fingers in the pie, give yourself some of the project tasks (make sure they're not critical-path jobs!), keep up with languages and trends. You'll get mo
  • of programmers. They reflect a belief that managers know nothing but arrogantly act like they do and that they are the more important than the programmers; while the programmers know they actually do know everything and are truly the most important people in the company.

    The reality, of course, lies somewhere in-between. There are bad managers just as there are programmers who never seem togged the message their job is to ship code that works, not spend a lifetime creating their one great masterpiece. Assumi

  • In order to be a successful manager of a development or I.T team, you need to have an outstanding track record of making the right decision, foreseeing when other decisions will cause problems down the road, be a good judge of character, and have the ability to work with (or deal with) personalities that normally would drive you crazy. These are things that you can't really accomplish in a few years. Just like auto-dealerships should never promote their best salesman to management, software companies shoul
  • by Art3x ( 973401 ) on Tuesday June 30, 2015 @09:45AM (#50018333)

    Most of us get sucked into management, like a poor Millenium Falcon into the Death Star's tractor beam. More useful would be an article about how to refuse such offers, keep getting raises and offers for programming jobs as we grow older, and so on.

    You will get promoted to management, at least to team lead, just by not sucking.

    And in my own experience at least, in the healthcare industry, there are plenty of gray-haired technical people. And when I was helping to hire another programmer, I was hoping for a graybeard, not because of agism, but experiencism.

  • Any career choice is a bundle of pros and cons. Choose the one that suits your temperament and talent.

    You can't get MBA's pay if you avoid meetings like a techie. You can have the freedom to work on what is interesting to you only when you are an academic working for wages far below prevailing industry wages.

    If you have some skill/talent where programming/coding acts as force multiplier, you are set. You can be techie all your life. If your only skill is generic programming, be prepared to ward of the y

  • programmers interested in breaking into management

    DON'T DO IT!
    Just...don't.

  • Unfortunately this most likely won't get seen because the news feed has moved on, but here goes...

    The pressure in most companies is for more experienced workers to move into management. However, think about the last awful boss you had. Unless they were an MBA (the corporate equivalent of a commissioned officer, who didn't actually do the job before and was just appointed fresh out of business school,) that person most likely was an individual contributor. People who are great workers often get promoted, and

  • Technical skill and seniority does not translate into managerial aptitude. In fact, the better you are at your technical role right now, the worse off you will be as a manager. And it gets worse: If you are an awesome hacker, chances are you will not only suck at management, but you will also hate it with a passion.

    Some of the core challenges:

    The zone: Banned for life.

    As a developer, you need long, undisturbed periods of time in order to concentrate on the problem at hand. Your best, most productive time is

  • You can move to management.
    But you've to leave your conscience behind;

I have a very small mind and must live with it. -- E. Dijkstra

Working...