Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Transitioning From Developer To Executive?

timothy posted more than 2 years ago | from the oh-just-grow-the-hair-it's-cool dept.

Businesses 229

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

Sorry! There are no comments related to the filter you selected.

learn? (5, Funny)

polar red (215081) | more than 2 years ago | (#38422784)

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

Re:learn? (5, Insightful)

yog (19073) | more than 2 years ago | (#38423378)

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? (4, Insightful)

Anonymus (2267354) | more than 2 years ago | (#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? (4, Insightful)

Tiroth (95112) | more than 2 years ago | (#38423642)

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.

Steps: (-1, Offtopic)

Tablizer (95088) | more than 2 years ago | (#38422788)

1. Sell your soul
2. Profit
3. ???

Re:Steps: (1)

jellomizer (103300) | more than 2 years ago | (#38423148)

Why do you say that.
Normally the problem with executives is they do not know what is going on in modern technology. Getting some one who has been working with tech into this position is usually good news. Because they may be able to bring some of the changes the department was looking for.

However you can't expect too much. As a tech goes into leadership he has to look at the organization differently. it is no Longer IT and your project is the only concern, there is a whole slew of concerns and actually most IT staff for the most part is self managing, and you need to make sure IT is playing the same game as everyone else.

Prepare to die (-1)

Anonymous Coward | more than 2 years ago | (#38422796)

You will need some kind of device that will let you affix your tie to a ceiling fan.

Start Being Ignorant Now... (5, Insightful)

stove (38601) | more than 2 years ago | (#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!

Re:Start Being Ignorant Now... (1)

modmans2ndcoming (929661) | more than 2 years ago | (#38422924)

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.

Engineers alternative (4, Insightful)

dbIII (701233) | more than 2 years ago | (#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".

Dev to Exec (-1)

Anonymous Coward | more than 2 years ago | (#38422806)

Welcome, I have tried that and was bored. I like tech, I do not like tackling peoples do's and dont's. You will loose the attitude during some years and start to request dashboards.

Re:Dev to Exec (1)

CubicleView (910143) | more than 2 years ago | (#38422832)

It must be one hell of an attitude if he can let it loose.

Re:Dev to Exec (3, Insightful)

jellomizer (103300) | more than 2 years ago | (#38423174)

What is wrong with dashboards?
They are fun to program (Compared to the other CRUD that you normally need to do), Management are human too and do not have the time to analyse all the data so dashboards give them a quick view on what is going on.
Now the smart managers will realize that these dashboards are mathematical models and you will still need to manage beyond that, some of those red spots are not so bad they are red for a reason, as well some of those in green may actually be more of an issue then the dashboard show.
The stupid manager will live on the dashboard and see it as the truth and manage strictly off of it. That is where problems occurred.

Some tips (5, Insightful)

Registered Coward v2 (447531) | more than 2 years ago | (#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 (5, Insightful)

Anonymous Coward | more than 2 years ago | (#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.

Re:Some tips (0)

Anonymous Coward | more than 2 years ago | (#38423922)

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.
There are also a lot of us that simply do not want to "make it" to that level. We enjoy doing things rather than having meetings about them. You don't necessarily have to be a "grump old git" to want to write code or tweak systems rather than manage.

Re:Some tips (1)

tburkhol (121842) | more than 2 years ago | (#38423158)

If you don't have a strong internal model of "leadership," try to learn one. Leadership in the sense of how you get people to happily do things that they may not want to, and how you get people below you to trust your judgment. I learned a lot of that in volunteer organizations - think Habitat for Humanity, not Toys for Tots - volunteers come in with varied skill levels and varied motivations, but you have to get them all working together, as a team, doing sometimes unpleasant work with people who may not get along. Watch how the leaders get that to happen, especially if you can find a group where the volunteers don't all leave after six weeks.

You have to trust your people. If they fail that trust, you have to be tough: rewards for success, penalties for failure. Small, but frequent.

Re:Some tips (4, Insightful)

nine-times (778537) | more than 2 years ago | (#38423504)

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:Some tips (1)

Anonymous Coward | more than 2 years ago | (#38423588)

Another vote for the OP here.

I have seen far too many techies promoted to management (and I've so far refused because of it) and then fail miserably. In almost all cases they were good people and didn't fail for their own lack of effort, but instead because of failures from their upper management to properly support and mentor them. Of course it's a self repeating cycle because those that survived and continued on then didn't know to (or how if they wanted to) mentor those that they promoted into management.

Like everything thing else, there are people that are right for the position and there are far more that "can do it".

In my opinion the worst situation you can be in as a new manager is to manage the people you were just working with. Not only will it be difficult for you to look at them differently, it will also be hard for them to treat you differently too.

Personally when I finally break down and accept a management role I'm going to look for a group that does something other than my skill set. I've seen too many techie managers promoted in their group and then when their staff isn't doing the job that is needed the manager just jumps in and does it rather than deal with their management duties in that case (a lot of that also comes from that friend/employee transition). My view is that you should know enough of the subject matter to know if you are hearing BS, but not being able to do it yourself will force you to focus on actually managing the team.

um..... (0)

Anonymous Coward | more than 2 years ago | (#38422818)

If you have to ask the you probably should not be moving up.

There is great risk that you are going to suck at it. You'll most likely go bald and develop pointy hair.

Re:um..... (1)

jellomizer (103300) | more than 2 years ago | (#38423200)

If you don't ask then you probably shouldn't be moving up.

The Stereotypical PHB are usually from people who just talk their way up, without proving themselves and do political tricks to get themselves up, they don't care what it takes to be a good manager, they just want the power to control people.

Most of the people who really fit the in PHB category are not MBA's or executives but Middle managers who act like they are.

Micromanage or you will be disappointed (0)

Anonymous Coward | more than 2 years ago | (#38422830)

Micromanage or you will be disappointed.
Coders often suck, especially at estimating effort of time and letting you know when there are issues.

After about 6 weeks, you'll know how much being a manager sucks and you can't really change anything due to the lack of budget you inherited. You've already missed the budget exercises for next year, so you have to wait until 2013 to get any thing extra.

You are not prepared for the first round of budget fights, so you won't get much next fall either. In some companies, you have to fight for salaries, not just computers and software, so you may find you have to let half your team go.

Get ready.

Re:Micromanage or you will be disappointed (5, Insightful)

somersault (912633) | more than 2 years ago | (#38422946)

Coders often suck, especially at estimating effort of time

It's not necessarily that those coders suck, it's more that it's impossible to estimate the time to do some non-trivial new task, because there may or may not be hidden depths.

Even Donald Knuth can't estimate how long it will take him to do something, and he has a lot of experience with algorithms and coding. I think the numbers were that he expected TeX to take two years to write, but it actually took ten.

I think it's better for the manager to pad the numbers but not let the engineers know. Hold them to a tight-ish schedule, assuming that they will over-run sometimes. It's good to feel a little time pressure to keep you focused, but not so much that you get despondent. Allowing for explicit maintenance/refactoring time on the code would be important too if it's a project that has grown and morphed over the years and needs tidied up.

I don't think micromanaging is the answer. If you ask me how long overall something should take I will be happy to give an answer - but I don't like giving a schedule of every thing that I will be doing, because I simply don't know in advance. Sometimes things move way faster than I expect, and sometimes I'm banging my head against a wall for a couple of hours because of an oversight in my design.

Re:Micromanage or you will be disappointed (0)

Anonymous Coward | more than 2 years ago | (#38423592)

Exactly wrong. It is much better to give a hard deadline and make people bust their ass to get a project done. Throw out anything non critical that will affect meeting the deadline and only do what is necessary, otherwise you will never ship a product. Ten years for TeX? People have started & created billion dollar companies like Facebook, Twitter, Groupon during that same time frame this guy was fucking around with TeX. As a manager, you need to define what you want based on requirements, get a estimate from the development team and then shorten that deadline throwing out the shit you really don't need. If you let developers set the deadline and schedule, they will spend 10 years working on TeX. This is what Steve Jobs understood. To get shit done, you have to light a fire under people's ass, otherwise, nothing will get done.

Re:Micromanage or you will be disappointed (1)

somersault (912633) | more than 2 years ago | (#38424038)

It wasn't that TeX wasn't usable before then, just that it took that long for the language to be "frozen". Many products are shipped quite quickly with a poor feature set and added to incrementally, as you point out.

If you're constantly lighting a fire under people's now busted asses, you're not going to retain much of your staff or have a working environment that people enjoy. You'll end up being renowned as a shitty place to work (Apple sounds like one of those places to me), and so you'll only get shitty developers. If you create the right working environment, people will be busting their asses getting things churned out just because they're enjoying their job so much, or as a matter of professional pride.

If Facebook, Twitter and Groupon are your ideas of good software.. sigh. Aside from the problems of scale, which have been solved and have open source solutions available, those sites are technically quite simple (as in, easy to replicate). It isn't technical achievement that makes these multi-billion dollar companies. It's marketing, publicity and luck.

Re:Micromanage or you will be disappointed (0)

Anonymous Coward | more than 2 years ago | (#38423340)

Coders often suck, especially at estimating effort of time and letting you know when there are issues.

Sometimes that's because the managers suck.

Example, say Manager asks Developer how long he will take to do XYZ. Developer says 5 days. Manager tells Developer to do XYZ. But then Manager asks Developer to do PQR as well. Meanwhile Manager is asked to attend a few meetings, Manager drags Developer (and team) in for those meetings too. And the Manager _still_ expects XYZ in 5 days.

So if the Developer is not stupid, the Developer will realize that the Manager sucks and the next time the Manager asks for an estimate the Developer will pad the figures immensely.

Good managers will know when a Developer is BSing or struggling with a task, and realize which Developers overestimate and which underestimate, and which can be nagged, which need to be nagged/threatened (I know a developer who said he needs to be threatened, otherwise he'll keep putting things off), and which don't...

And that's why the productivity of the exact same team could vary by magnitudes under different managers.

FWIW I'm not a good manager. But I think micromanagement is often counterproductive. What might help is requiring developers to submit weekly reports on what they are doing and what problems there are.

Re:Micromanage or you will be disappointed (0)

Anonymous Coward | more than 2 years ago | (#38423666)

> Coders often suck

Yeah but business analysts mostly suck, and suck worse. A bad developer can't hide (his mistakes are clearly visible to others), but a bad BA can easily hide (and mostly do) until its too late (wrong, incomplete, unusable requirements) with much more expensive mistakes. Only hire BAs with domain and technical experience. Closely check their work, have your customers validate their work, and ask developers to grade BA's work.

Give correct estimations (5, Insightful)

zr-rifle (677585) | more than 2 years ago | (#38422834)

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.

Re:Give correct estimations (4, Insightful)

Intron (870560) | more than 2 years ago | (#38423072)

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

Re:Give correct estimations (4, Insightful)

kbdd (823155) | more than 2 years ago | (#38423304)

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.

interesed as well (0)

Anonymous Coward | more than 2 years ago | (#38422836)

looking forward to the user comments!

Take the journey with your team (2)

ferrisoxide.com (1935296) | more than 2 years ago | (#38422840)

  • 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 (1, Funny)

Kagetsuki (1620613) | more than 2 years ago | (#38422852)

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 carefully. If their ideas are dramatically different than yours in ways you think would be detrimental to the project then they may not understand something. If their ideas are good integrate them. If you don't understand their ideas but they sound good ask the other developers in the pool - a lot of developers get the idea they can do something really cool with some random technology and it just ends up being them the only one that understands it and it never ends up working right.
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. Define critical passes and designate resources such that they come together well.
5. Watch your repositories! Each commit is a record of what a programmer thought. If they misunderstood something you should be able to see that they are going off course by looking at their code. Every day you don't catch this is another day wasted and probably another day it will cost you to bring the code back on course.

That's about all I can think of and all things I really wish I had known before handling teams of developers. Overall you just really need to remember to be focused on results and you really need to watch commits and source changes carefully so you can catch people going off course.

Re:Simple (0)

Alex Belits (437) | more than 2 years ago | (#38422980)

Worst. Advice. Ever.

Re:Simple (1)

Kagetsuki (1620613) | more than 2 years ago | (#38423168)

I'm sorry, on what points? Keep in mind this is just from my experience and the environments I've been in, I wouldn't expect it to apply to everyone.

Re:Simple (4, Interesting)

sclark46 (969374) | more than 2 years ago | (#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.

Re:Simple (1)

Kagetsuki (1620613) | more than 2 years ago | (#38423196)

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.

Re:Simple (4, Insightful)

Kjella (173770) | more than 2 years ago | (#38423136)

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.

Re:Simple (2)

Kagetsuki (1620613) | more than 2 years ago | (#38423302)

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 way of "making sure all your people are productive, clearing roadblocks". I don't deal with recruitment/staffing and there is no management reporting - I deal with a loose knit group of developers/designers/planners/creators mainly on paid OSS projects and I often am the one getting those jobs. I'm not in an office building and none of my developers are forced to come in on any project - they come in because they like to work with me and because I find interesting work for them.

Now if I were in a corporate environment I'd be a lousy manager, but not because I'm too strict but because I'm too lax. I once screwed up by not watching a coder closely enough - he ended up blowing about 2 months when he though he had a better idea of how to do something instead of using a library which I told him to use; which would have implemented the same functionality in a day. When I found out I actually gave him another month to fix things and he still didn't. That killed the project and cost me quite a bit of money - had I been stricter and micro managed more it would not have happened. Other times I've put a lot of time helping developers meet customer deadlines and not collected pay for my time. As you can guess developers really like that kind of management - but it's bad management and these are things you should avoid doing. To say the least I've made a lot of mistakes a "traditional project manager" would not have and those were the things I was trying to point out.

Hints (5, Insightful)

mseeger (40923) | more than 2 years ago | (#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 (3, Interesting)

dbIII (701233) | more than 2 years ago | (#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.

Re:Hints (1)

mseeger (40923) | more than 2 years ago | (#38423092)

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

Re:Hints (1)

scamper_22 (1073470) | more than 2 years ago | (#38423796)

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 'doing' and 'managing' ? Yes!

Can we do it while working under a corporation without any formal legal or powerful professional association? Nope.

Well (1)

luis_a_espinal (1810296) | more than 2 years ago | (#38422868)

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 lose some of your technical chops. You won't be in the trenches, but that doesn't mean you need to devolve into a pointy hairy boss. The closer you are to the developers, the more often you will need to get your hands dirty once in a while to understand their work and needs (and to keep your chops) - you will need to do that while never forgetting when and how to delegate.

It's too late now, but why? (1)

Anonymous Coward | more than 2 years ago | (#38422874)

Why should you? Why should your emloyer? If you are a good programmer, chances are good you are a lousy manager. Other way round, if you were the right person for the job, you would have hated programming and would have dabbled in strategies the whole time along.

Project/People/Organizational (1)

xarope (888793) | more than 2 years ago | (#38422880)

As someone who has been a successful "mustang" (helpdesk to CIO), in a nutshell my recommendations are:
  • project => learn how to manage projects (timelines, requirements, budgets).
  • people => build and harness interpersonal relationships. Doesn't mean you have to buddy-up to everybody, but realistically it's easier to get people's understanding and agreement or compromise, if/when you have to slip deadlines, reject requirements, push through radical changes to architecture, when people don't hate you!

  • organizational => have a big picture view as well as the ability to drill down. Nowadays the expectations are that executives also have to know the nitty gritty, not just wave a broad brush stroke. The ability to make quick decisions and commit in a board meeting, are what will separate you from the chaff who have no idea what's really happening.

Understand that the higher up you go, the more people you are "accountable" to... as a developer, you are just accountable to yourself and your manager (and if you have a conscience, your team members). As a CIO, I am accountable to every single person in the company, as well as the board, and shareholders.
Keep your technical skills current (I continue to be a member of the IEEE and ACM, not just read executive magazines, which are often just rehashes of already-known methodologies and thinly disguised consulting offers). This will allow you to make good, informed decisions. I've seen many technical managers let this lapse to their detriment, when they can no longer understand what is going on "below", and thus cannot relate said information "above".
Above all, enjoy this opportunity. Despite being quite successful in the technical track, and despite people being quite surprised when I accepted the opportunity to jump over to the management track, I can now actually make a difference, rather than whinging about what I would do!

Read up on the Peter Principle (1, Informative)

Viol8 (599362) | more than 2 years ago | (#38422884)

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

Re:Read up on the Peter Principle (1)

Anonymous Coward | more than 2 years ago | (#38422916)

Your ability to write comments on Slashdot is an excellent illustration of the Peter Principle at work.

Re:Read up on the Peter Principle (1)

Viol8 (599362) | more than 2 years ago | (#38423000)

Unless I'm about to be promoted to a slashdot editor I suggest you read up on it too so you know what it actually is before you get you crayons out in an abortive attempt to be witty.

Re:Read up on the Peter Principle (0)

Anonymous Coward | more than 2 years ago | (#38423402)

Sorry, I guess you prefer your humour spelled out, preferably with a laughter track to aid timing.

Zero qualifications, other than a keyboard and some fingers, are required to rise to the level of being able to comment on Slashdot, yet the intelligence required to make a useful contribution is far rarer. Bringing out the tired old Peter Principle idea every time someone says they've been promoted is lazy & uninteresting commenting. Someone asks Slashdot about his promotion and there's always some dick who wants to put down the idea because of the Peter Principle. Yawn.

I prefer the original embodiment of this sentiment in GP, but your comprehension / sense of humour failure mandates I be more specific.

By the way, I'd check your own source material. The fact you apply PP to someone's *first* promotion indicates you don't understand that it applies to someone's *eventual* position, not their earlier positions.

answer a question... with questions (1)

jds91md (2439128) | more than 2 years ago | (#38422886)

It's nice that you have the humility and curiosity to ask these questions and acknowledge that your new role will require different skills than you've used thus far in your career. How did you decide to make this decision, especially given that it seems outside of your comfort zone? In general terms, tell us about your company (big, small, sector) and what it needs from its tech team. Did you seek the job or did it fall to you when someone else left? And if you sought the position knowing it was outside of your regular skillset, why did you seek it and how did you think you would handle the issues you raised in your questions? What prep have you done? --JS

Congratulations! (3, Insightful)

porsche911 (64841) | more than 2 years ago | (#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,

RUN! (0)

superdana (1211758) | more than 2 years ago | (#38422892)

RUN WHILE YOU STILL CAN.

you're born a wolf, or a sheep (1)

Anonymous Coward | more than 2 years ago | (#38422894)

You're either cut out for it and you'll do fine, or you will fail regardless of any clever books you can find. Techies won't follow a weak leader and it comes down to your personality as much as knowledge. One thing to bear in mind, is that they will respect you for what you know, not your job title. You also need to be someone who makes their problems go away, instead of creating new ones. Level with them, be honest, show that you care about their issues and they will look up to you. - I made this transition 2 years ago, and this is my experience.

Consider whether you really want to do it (4, Insightful)

ratbag (65209) | more than 2 years ago | (#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!

Re:Consider whether you really want to do it (1)

fartrader (323244) | more than 2 years ago | (#38423052)

Mod this waaaaay up. To 11 on the dial.

Re:Consider whether you really want to do it (-1)

Anonymous Coward | more than 2 years ago | (#38423322)

Superior Jersey offers the highest-quality cycling jerseys [superiorjersey.com] , and we pride ourselves on superior customer service. Our products range from cycling bibs to shorts to jerseys and much, much more! We will ensure you are satisfied with your purchase, and will try to be of any assistance to you. Let us take care of all your riding apparel, so all you have left to do is strap on your shoes, hop on your bike and ride!Our products range from cycling bibs to cycling shorts to cycling jerseys [superiorjersey.com] and much, much more! Come find your favorite 2011 team jerseys, bicycle gear, cycling clothes, and racing jerseys

Re:Consider whether you really want to do it (1)

Alomex (148003) | more than 2 years ago | (#38423562)

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.

If you're asking this question on slashdot... (-1)

IrquiM (471313) | more than 2 years ago | (#38422914)

... clearly you arn't fit for purpose. Get some smaller project training before transition into a position like this.

Remain as you are (3, Interesting)

eulernet (1132389) | more than 2 years ago | (#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.

Yeah yeah (0)

Anonymous Coward | more than 2 years ago | (#38422948)

Do your homework already. Go read _The Essential Drucker_ at minimum. Or grow pointy hair and get the lobotomy for free. Your choice.

Differentiate between management and design (1)

Stonefish (210962) | more than 2 years ago | (#38422960)

Decide what you're best at, most managers are poor designers. Just because you're a manager doesn't mean you deserve control. Being a manager is understanding what the business desires & needs, using your skill to translate that through the talent that you've employed into a profitable outcome and marketing the end result. I would advise you to give your staff an IQ test and try to offload design to someone who scored well in this area, You then market their designs to management

Get a mentor and start reading (2)

CoryFoy (2254778) | more than 2 years ago | (#38422968)

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

Book Recommendations (1)

SirGarlon (845873) | more than 2 years ago | (#38422998)

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 of book stores even in the U.S.

The first step is the hardest.... (1)

mevets (322601) | more than 2 years ago | (#38423010)

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.

Watch "office space" (0)

Virtucon (127420) | more than 2 years ago | (#38423018)

And ask for meaningless reports from your minions that will drive meaningless metrics to show what a great job you are doing to your bosses. Also don't forget to cull the herd occasionally to keep everyone in line.

Surround yourself with smart people (1)

roman_mir (125474) | more than 2 years ago | (#38423038)

Surround yourself with smart people (who are also hopefully not assholes and are not completely lazy), that's the only real way to have things done.

practice ignoring... (1)

Anonymous Coward | more than 2 years ago | (#38423042)

practice ignoring those who will work under you. only do things that will increase/maintain your bonus... don't really care about anything that benefits overall/long term of the company.

Pointy-Haired Boss (0)

Anonymous Coward | more than 2 years ago | (#38423044)

Take a blow to the head and start growing [dilbert.com] pointy hair. [dilbert.com]

You WILL fail! It's the Peter Principle. (0)

Anonymous Coward | more than 2 years ago | (#38423070)

Read up: http://en.wikipedia.org/wiki/Peter_Principle

The fact that you were a good X (in this case: developer), is completely unrelated to how good of a Y (in this case: executive) you will be.
If anything, it will make you a worse Y.

Skills and or methodoligies to learn (0)

Anonymous Coward | more than 2 years ago | (#38423076)

I highly recommend you do the following training as a starting point;

ITILv3 ( intro at the very least)
PMI Fundamentals ( PMBOK based or go the prince2 intro route)
MBA or Mini MBA
Team Leadership training
Motivational and Team building training
Mediation Training

also you will need to learn to switch off after work so make sure you have some good hobbies etc.. to keep your work life balance in check

managing networks is easy so is writing and managing code but after 15 yrs in the trade i now know that managing people is far harder then anything else.

if you are wondering why i am recommending you do project management its because you need to think along those lines when you make requests, manage budgets, manage people and mentor others so you impart into them good practices by way of leading by example.

best of luck with the new gig

Re:Skills and or methodoligies to learn (1)

TooTechy (191509) | more than 2 years ago | (#38423520)

There have been many interesting posts throughout this stream, but no-one has as yet mentioned requirements analysis. Yes, you could say that you have engineers to perform this task, but perhaps you need to analyse from a different perspective, that of the business perspective.

So learn to ask "Why?" a lot and find the real objectives for a task. If you know the reasons, then you can prevent frustration in the ranks. So take a requirements analysis course.

So now you need to know.

What do you want us to do?
What is the issue?
What is the objective which the issue is preventing us from reaching?

And - How much will you spend?

If you compromise your soul only do it temporarily (1)

piekarski (67612) | more than 2 years ago | (#38423080)

Agile, Daily stand up meetings, determine sprint content with management and stakeholders, team lunches and drinking outings to let off steam after sprints. I made this transition and led an awesome team for 8 years. My boss, the owner of the company, slowly lost his mind during that time even as the company and my team continued to implement successful and profitable solutions. I took it for the team over and over behind closed doors but after his delusions went public and I started receiving public shaming for his hallucinations I started looking. Now Im 'just' a programmer on a small but key govt contract making the same money and loving life. I miss leading a team but I dont miss the stress.

DON'T DO IT! (0)

RichardCory (2533518) | more than 2 years ago | (#38423086)

Management sucks! Do you want to suck too? There's nothing more useless than an IT/Dev manager. You're going from a skilled job to something a Banobo can do. And there are a LOT of Banobos out there!

3 easy steps... (5, Funny)

Lumpy (12016) | more than 2 years ago | (#38423096)

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.

Been There, Done That... (2)

Kr3m3Puff (413047) | more than 2 years ago | (#38423098)

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.

Manager Tools (1)

Orion (3967) | more than 2 years ago | (#38423104)

Http://www.manager-tools.com

A life saver for me. Their very first podcast was on this exact topic (and, for that matter, every subsequent podcast). I can't recommend them highly enough.

be smart, be different, learn fast (2)

X10 (186866) | more than 2 years ago | (#38423140)

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 if they're smart enough. Delegate stuff to developers. I've always found it extremely useful to have decisions made by the person or people who are knowledgeable about the subject. If you make decisions, talk to one or two people you trust, ask their opinion, challenge what they say, then take their advice. At the same time, if the advice turns out to be wrong, don't blame them. Once you've adopted their advice and opinion, it's yours, and you defend it to your boss. You make friends when people know that they gave you wrong advice and you took the blame. It will never happen again, I can promise you that. It won't get you fired, unless your boss is stupid, in which case you want to get fired.

As an exec, you can get away with a lot, as long as you have your facts straight and you have an answer to every question. If you want to make a difference, be different. But then, you can only be different if you're strong enough to support it.

Know your facts, but know other peoples facts also. You can't talk to a marketing exec or a finance exec if you don't know their jargon. Read a book on business finance, read one on marketing. Talk to execs and listen carefully. What they talk about today, you should be able to talk about tomorrow. At the same time, don't make them feel threatened, as if you want to come into their area. Always keep saying "It's my opinion that everyone should do what they're good at, and leave everything else to experts".

Don't try to blend in to quickly. It doesn't hurt to dress a little different from the other execs. It's a sign to your team that you're still one of them.

As others have suggested, find a mentor. Someone senior who you know well and who you trust, and who doesn't have a conflict of interest with you in your new job. I've had a mentor, a woman who has been my boss for a year or so, we became friends, and while she moved to the top, she remained available to me as a mentor. She's been a great support to me for a period of about ten years.

Don't confuse being a manager with being... (1)

Assmasher (456699) | more than 2 years ago | (#38423188)

...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 detest management (unless you were a crap developer) because you lose the ability to feel like you actually did something constructive every day; so, my advice to you - don't divorce yourself from the tech entirely. Take the management position, stay a part of the architectural discussions (presuming you have the expertise, if you don't take part in the discussion with your mouth closed), give yourself a development task - usually the best thing you can do for your team is whichever aspect of the system is the most boring or intimidating (again presuming you have the skills to do this), basically whichever aspect they want to do the least...

90% of managers are crap because they don't treat the 'management' part of it like a job, they focus entirely on the reporting aspect of it (always looking upwards syndrome) where they are only worried about what their boss thinks of them as a manager - not their people. 5% of the remaining managers are crap because they develop an 'us versus them' philosophy where they cultivate a positive (at first) team spirit by making everyone else in the company the enemy and having the development team look out for each other. A great idea for about 2 months. The last 5% of managers are those who get the balance right, those who understand that companies have needs that sometimes outweigh the immediate happiness of its employees, and that employees have needs that sometimes outweigh the immediate happiness of companies.

Being that last 5% of managers is hard, because the effort you make for those below you rarely translates into reward with those above you and the efforts you make for those above you carry no value with those below you. You simply need to accept this and do the work (which is a lot) necessary to be a good manager. It's a lot like software engineering - you either have a predilection for it or you do not. If you don't, you're going to be miserable and likely do a bad job of it.

Oh, and there's not much you can do to prepare for it except try to be yourself (otherwise embrace misery.)

Good luck.

Re:Don't confuse being a manager with being... (1)

sempir (1916194) | more than 2 years ago | (#38423656)

an executive. All advice above...and below is good, well mostly! One bit more won't hurt: Take your staff for a piss up at least twice a year. Drunks tell the most awesome truths you will ever hear, really in your face truths. Ignore them at your peril. You also hear some really funny shit!

Lead, don't pull (3, Insightful)

sl4shd0rk (755837) | more than 2 years ago | (#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.

Mmmmm...jelly spine. (0)

Anonymous Coward | more than 2 years ago | (#38423212)

Read? No. Please do not read what somebody else's thoughts or opinions are on how you should do your job.

You're one step in the right direction though - you were a developer. Rather than some numbskull who doesn't know what CTRL+V does trying to manage you and your team, you're the one doing it. This means you know the job, inside and out, that's the absolute best qualification one can have for a management job.

Don't alienate your people, stand up for them. The minute they sense your spine has turned into peach flavored jelly because, "that's the best we can do right now," they will drop you like a bad habit. You might be their boss and control their day to day but your employees control your fate.

Make tough decisions and make sure they are the right ones. Do not cower and back down.

Help when you can and where you can but do not do both jobs. Manager primarily and develop secondarily if you need to.

Avoid "Being Successful in Business" workshops and groups in the local area. Why? See my first comment. This will also create a sense of the condition known as "jelly spine" throughout your team and thus will begin the habit dropping. Those meetings are typically filled with the pointy hair folks anyway - which you wanted to avoid.

Get educated (0)

Anonymous Coward | more than 2 years ago | (#38423214)

1) Look into attending some leadership classes. They can bring in a wide variety of material for you so you can learn faster. Many of the big universities have classes tailored for this already.

2) Be sure to have trust with your reports. If you don't trust them, they won't trust you.

3) Pick up a book. "First, Break All the Rules: What the World's Greatest Managers Do Differently" and "Crucial Conversations" are good reads.

4) Patience.

be a shield (3, Insightful)

l3v1 (787564) | more than 2 years ago | (#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.

Good luck (5, Interesting)

delphigreg (835826) | more than 2 years ago | (#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.

The first mistake you made was posting (0)

Anonymous Coward | more than 2 years ago | (#38423250)

If you want to be an executive, you need to be confident in yourself and find some trusted mentors to ask for advice. Posting a question about this on Slashdot was a serious mistake. If you aren't confident and you have to ask people what to do, then the people that work for you won't respect you and you will not last long.

Read Steve Job's Biography. Then read some books by other technology executives and learn how they succeeded and how they failed. Find some mentors that are also executives and some trusted mentors that are engineers and software testers. Quietly evaluate where you are going and don't be afraid to trust yourself.

Don't post a question like this on the internet ever, ever again.

Just my 2 cents.

prepare for challenges (1)

argStyopa (232550) | more than 2 years ago | (#38423262)

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 with waldoes that think for themselves, have fights with their spouses, and may or may not want to even be there.

Second, unless your firm is particularly enlightened, plan to have to constantly defend your management style. I'm of the belief (I think Scott Adams first said it) that managing programmers is much more like Beekeeping than anything else. It involves encouraging people to work in the direction that you want without pushing so hard you harm their enthusiasm or creativity.

Trust! (1)

Blade (1720) | more than 2 years ago | (#38423284)

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.

Re:Trust! (0)

Anonymous Coward | more than 2 years ago | (#38423856)

Trust, but verify everything little fucking thing. Ask detailed questions about every decision, inspect every little work product, check everybody's progress (not just status) everyday. If you don't do this you'll end with with a lot of "one week before the deadline I discovered we were actually 50% done instead of 99% done like they told me".

Read PeopleWare! (1)

olau (314197) | more than 2 years ago | (#38423288)

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.

Get to know the business (1)

JaredOfEuropa (526365) | more than 2 years ago | (#38423292)

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 is not to get a shiny title, and many (myself included) will argue that an MBA is a poor way of learning how a business should be run, but understanding how the business is run will greatly help you understand how IT can contribute to that. Knowing something about business administration comes in handy.

- Find a mentor amongst your fellow managers. Not someone who'll just vaguely promise to "yeah, I'll help you", but someone who can commit to actually spending time helping you when things get rough or when you need advice, and above all someone whom you can trust. It may be hard finding one, but if you can find a trustworthy, competent manager to coach you, he'll be worth his wweight in gold to you.

- Understand who your stakeholders are and where they sit in the organisation. Don't assume they'll come to you when they need you, and certainly don't assume anything about their needs and issues. Engage with the business on a regular basis.

- Your tech focus will probably shift from a limited set of products, skills, and technologies that were part of your day-to-day, to a broader but much less in-depth scope. Some of the publications that us techies like to laugh about like CIO magazine or Gardner reports can actually be very useful for understanding the broad tech landscape of today and the near future, and understand the trends. Don't base your decisions on those publications, though, and learn to separate news, opinions, sales talk, and bullshit. Use this info to find out what stuff is or may become relevant for your organisation, and then investigate further together with your team and come up with a strategy.

Being Geek (1)

b3njam1n (961420) | more than 2 years ago | (#38423300)

I highly recommend Being Geek [amazon.com] by Michael Lopp. He went through a similar transition and has some very good insight and practices to follow for effective leadership. A lot of it comes from the low-level programmer perspective, but he talks a lot as well about managing developers.

The Best Advice I Can Give (2)

Phoenix666 (184391) | more than 2 years ago | (#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!

Know what I mean? (-1)

Anonymous Coward | more than 2 years ago | (#38423392)

qba'g sbetrg lbhe ebbgf

Books (0)

Anonymous Coward | more than 2 years ago | (#38423440)

First book to read "Quiet leadership" by Rock if you have smart guys working for you (which you should...) and you don't want to be a pointy haired guy...
"The first 90 days"
"Red & Me"

Not so different. (1)

sgt scrub (869860) | more than 2 years ago | (#38423678)

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 and don't take anything too seriously from above. The successful boss keeps his/her crew under payed, out of the loop, and working hard enough they fall into that 1 degree above the boss screwing the crew completely. If you don't already know, that 1 degree is a percentage above what a normal crew produces in a normal situation.

Remember what team you are on (0)

Anonymous Coward | more than 2 years ago | (#38423828)

Now you are part of your manager's team, you are no longer a developer.

You are no longer a developer.
You are no longer a developer.

Being a manager is different than being a developer, even though you are still in IT, once you become a manager you are now part of the "business". The "business" live in shades of gray, and shifting priorities and shifting levels of risk.

Training:
Executive coaching
Facilitation

Why? (1)

JustNiz (692889) | more than 2 years ago | (#38423890)

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?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?