Slashdot Mirror
Ask Slashdot: Transitioning From Developer To Executive?
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?"
just buy a bullwhip. Easiest way to interact with us mere mortal programmers. And get a cat.
Yes, I'm left. You have a problem with that?
(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!
Ack!
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.
I'm a consultant - I convert gibberish into cash-flow.
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.
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.
It must be one hell of an attitude if he can let it loose.
First of all, read "The Mythical Man Month" 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.
Hack your mind out of its sandbox.
looking forward to the user comments!
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!
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.
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
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
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.
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.
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!
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!
It'll tell you all you need to know about how successful (or not) you're going to be in your new role.
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
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 WHILE YOU STILL CAN.
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.
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!
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.
Do your homework already. Go read _The Essential Drucker_ at minimum. Or grow pointy hair and get the lobotomy for free. Your choice.
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
I love the comments about finding a good mentor. Highly recommended. Next, pick up Mythical Man Month, The First 90 Days, Switch, Behind Closed Doors: Secrets of Great Management and FruITion. Especially the 90 days book. You aren't just a dev with new responsibilities - you are learning something brand new. Imagine that you are now being asked to build apps in a language you've never seen. Mostly remember that your
I don't read a lot of management books but there are two I would recommend:
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.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
start from the beginning
http://ars.userfriendly.org/cartoons/?id=19971117&mode=classic
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.
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.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
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.
You can't handle the truth.
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.
Take a blow to the head and start growing pointy hair.
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".
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.
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
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.
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!
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.
Do not look at laser with remaining good eye.
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.
D.O.U.O.S.V.A.V.V.M.
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.
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.
no, I don't have a sig
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
...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.
Loading...
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.
Join the Slashcott! Feb 10 thru Feb 17!
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.
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.
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.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
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
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.
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.
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.
-Styopa
Trust.
Delegation.
Foster an environment in which people feel they can empower themselves.
Trust.
You don't get it from reading, you get it by thinking about the people who you liked working for the most, the organisations you felt most valued by.
If you haven't already, read Peopleware: Productive Projects and Teams which will teach you that, as a manager, the most important thing to you is your people and your respect of said people. The book is a must-read. Seriously.
As the one responsible for your company's tech strategy, you need to understand your company's business. That's most likely a major change of focus. You'll also have to change how you keep up with the tech side of things, have a broad understanding of the technology out there, and try to understand what changes you can expect in the next few years ahead:
- Depending on your company's size/type, a mini-MBA may be useful. (take a formal course program, certain specific courses, or self-study). The goal 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.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
I highly recommend Being Geek 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.
Nothing is really work unless you'd rather be doing something else. -James Barrie
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.
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!
Do what you can, with what you have, where you are.
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"
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.
Having to work for a living is the root of all evil.
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
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?
Step 1: Report to surgery to have 50% of your brain removed (half the time they'll manage to get the part that governs common sense and ethics and you won't be handicapped in your new roll by that thing called a "conscience").
Step 2: Repeat "Knowing how to do the job isn't important - that's what we hire and fire people for" until you believe everyone under you is as replaceable as you are irreplacable.
Step 3: Register for every ridiculous vendor hand-out, symposium, or whatever. Vendors are your new friends. The more business you can hand them, the bigger YOUR empire becomes, and the more new-found allies you have.
The bonus:
Step 4: Remember all those jokes you made about incompetent management, because it'll make it easier for you to pry the keyboards from your former co-workers dead bodies when you realize that they're now saying the same thing about you.
The first thing I'd recommend is not to ask for executive advice from the Slashdot crowd.
Jeez, how'd you ever get promoted?
-dZ.
Carol vs. Ghost
If you want to avoid being the PHB, then don't read a bunch of management books or go to management seminars or get your MBA. Avoid taking a lot of the advice that you'll be given.
Really, it can be helpful to read about management, but the main source of PHBs is that it's some guy who has been thrown into management without being comfortable with it, and his response is to latch on to whatever random management self-help book he read. He reads something about how to motivate people or how to manage an IT department, and instead of thinking critically and applying his own experiences, he follows the quick-fix methods that he read about.
There's plenty to learn and plenty to study, but use your head. There's no metric to replace knowing the people you're managing. There's no procedure to replace good judgement. There's no magical workflow that replaces knuckling down and doing your job.
As a manger or group leader, you are only as good (or successful) as your group. Take responsibility for your group’s successes as well as failures. 1. Learn how to listen 2. Use ‘we’ not ‘I’ 3. Learn how to communicate to a wide range of audiences (technical, business, management). Make sure your group see’s the bigger picture and understands their importance. Be prepared to answer the question “Why?” 4. Set both realistic and stretch goals 5. Value differences and skill levels 6. Learn to motivate and reprimand effectively 7. Learn about SWOT analysis and how you might use it to your group (or projects for that matter)
One of the first things you have to realize is that you're making a transition out of your comfort zone, and that some of your strong suits as a developer (and certainly many of the tasks and initiatives) with which you've been successful need to be left behind. Take a look at The Leadership Pipeline for some ideas on the changes you may need to make.
Most "good" managers I've met are not good because of skills or training, but from simply being personable, intelligent, and able to solve problems (real world problems, generally very different from the types of problems programmers face). It takes a minimal amount of training to get a good manager, as long as you start with the right person, who possesses those innate abilities.
As someone who recently graduated from business school I have to disagree with respect to "minimal amount of training". The more formal training the better. Especially since the poster seems to indicate an executive angle not just tech management. The MBA stuff would really help out since it offers a good overall understanding of all the pieces of an organization. Business school and MBAs are not what most around here think, I was just as guilty. One of the things that made business school lots of fun for me was seeing just how ignorant and biased I had been with respect to management, marketing, etc.
Read 'Rapid Development: Taming Wild Software Schedules' by Steve McConnell:
http://www.stevemcconnell.com/rd.htm
I would _start_ with reading chapters 3 ("Classic Mistakes") & 11 ("Motivation")
Also, read these other books by Steve McConnell.
"Software Estimation: Demystifying the Black Art." A comprehensive set of tips and heuristics that software developers, technical leads, and project managers can apply to create more accurate estimates.
"Code Complete 2. A practical handbook of software-construction practices." Updated for web development, object-oriented development, agile practices, and other modern construction issues.
PMI will help you out quite a bit. It'll even help developers, but the knowledge gained from obtaining it will benefit a manger even more.
Read your Machiavelli. Read Sun Tsu. Whatever works. Clown suits work (see Miyazaki).
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
By making this decision you have chosen the dark side. A side effect is that your hair will immediately start to stand on end, resulting in pointy clusters. Good luck.
and stop reading slashdot.
There arent enough engineers with MBA degrees. It might be hard to believe, but you do learn things in majors other than engineering. Plus it will help you in the long term.
Lots of derogatory remarks towards managers. Not so easy to be in a position of orienting others be it for educating, leading, organizing, inspiring, managing or whatever else. I myself despise jobs coporations and management -do all kinds of things but never accept jobs anymore. But if you want to do anything bigger, you need more people, and you need organization. Whatever you do, whether it is open source coding, protesting, having a big party, or a small company, you will have people, jobs, money, decisions, time, deadlines, projections, taking risks, evaluating, persisting...
In fact I think a lot of things, democracy, neighborhoods, families, small businesses, open source projects, don't move along better just because the population has no training in how to work together. Even though lots of people work their ass off, there is no coordination, so everyone is pushing in opposite directions.
Of you really want to learn about managing people and projects, join a bunch of grassroots and other small projects where everyone is basically doing and saying what they want.
Build your own energy sources from scratch. http://otherpower.com/
Seriously, treat them as you would treat day laborers if you picked them up in the morning to work on your yard: Give them clear instructions about what's expected, give them clear feedback (good and bad) about how they're carrying out your instructions, and stay out of their way if they're doing what you want them to.
A lot of bullshit has cropped up around management techniques, especially among geeks, and it's cruft that needs to be cleared away. Devs are like everyone else: They want to know what they're supposed to do, if they're doing it how you want it done, and to be left alone to do it. If you get that part of the work relationship right, the rest is window dressing.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
One major thing that you'll have to get accustomed to is being hands off with the technical implementation. Set your expectation of what needs to happen, bring your team about to help make decisions on what direction you want to go in, but when it comes to putting word into form... stay away. It's far too easy for past developers to turn into micro-managers at the implementation level, which will definitely cause issues for your team going forward.
On the plus side, you have a much greater foundation with which to make value judgments of how well your team is performing. You should be able to staff a great team, given what you know about the technical end of things. The worst of the worst, when it comes to managers, are the ones who allow themselves to trust anyone with anything... and end up getting hoodwinked by the vocal incompetent.
You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
Go to Manager Tools (www.manager-tools.com).
There, you will find everything you need to become a good, maybe great manager.
to be a brain donor, unless you prefer to let it rot in its place or be fully conscious while you are sucking...
"Unfortunately for all parties involved, software engineering and management are two completely separate skills"
So the correlation between being a good manager and a good software engineer is 0? I would guess that they are both correlated to general intelligence. Likewise I would guess managing software engineers has some correlation to understanding what they do, what your company's code-base looks like, and what your company does. (Likewise I would put a medical professional in charge of a hospital. Surgeons rarely even want to be administrators, but many hospitals give those jobs to nurses and are happy with the results..)
So based on that, I would think the good software engineers of your company is a good pool to try to select good managers from. (Just as best sales people, best accounts are good pools to look at) Now, that doesn't always mean make the best engineer the manager. You should look at other things, such as ability to handle many things at once, ability to work with others, etc.
You say a great managers ignore the politics. But a great careerist most certainly does not ignore those things. I have observed that a great engineer is more likely to look past the politics and focus on goals and rational resource deployment. And a great salesperson is more likely simply sell themselves, meaning that they will focus politics.
Democracy Now! - your daily, uncensored, corporate-free
You recognize that you're not infallible and that you don't know everything - this is 80% of the battle of being a Good Boss.
I'll skip the "read this book" stuff, and go straight to the obvious points.
The hardest part of the transition from individual contributor to manager is to avoid falling back into your comfort zone. Managers primary must solve people problems: motivation, communication, cooperation, team dynamics. New managers are often unfamiliar or inexperienced with these types of problems. When faced with people problems and technical problems, the tendency is to address the technical ones first. This provides them with the sense they're making a contribution. But your job as a manager isn't to solve technical problems. Your job is to build a team that can do this. Letting go of those tasks which are your core compentency is very hard and many fail to make the transition.
... for roughly 18 months now, and quite successful at least in the aspect that people working for me kept telling that they are quite happy with how I do things compared to what was before I took over. So far, so good. I'm still not dead. ;)
Main lessons I learned:
* Learn to delegate. Fast. Don't ever ever do things yourself (speaking about solving tech issues). If you have worked with the same people before, they will frown at you for not "working" anymore for roughly 3-6 months. Ignore it. Justify it. If you are good at keeping their backs free, they will see why you do it. Reason: if you do things yourself (meaning: tech solutions), you will have to fix them. Everybody will play the "he did that" game, and you will drown. Even if you want to support the guys, help out... don't. As much as possible.
* Be rightful, honest, truthful. Never hide your own mistakes or gains from anybody. People will see, and learn to be truthful to you - because of respect, as opposed to be afraid. You need to know what's going on in your team, so this is a key part!
In other words: be the *good* guy. In every respect. Taking blame, and hand down compliments as well as negative stuff.
That will lead to people standing behind you when things get ugly, and they WILL get ugly at some point, because you are responsible for whatever goes wrong. Things have a tendency to go wrong.
* Trust is earned, not given away. You need to earn the trust of your guys as well as the big hats!
* And while taking about it, possibly the worse part, which is dealing with bosses: basically, the same rules apply. Be rightful, truthful, and try to justify things on reasoning, not emotions. Try to think FOR your people, not against them. Never blame something on a person. It's your fault for not forseeing this could happen. Keep in mind that you will suffer when your people loose faith, because you can't deliver without them. Watch out for structural issues in the company that will keep you from delivering; say, you don't have a QA department at hand or miss critical infrastructure. There goes your capability to deliver. It's about keeping those things in mind.
* Development methods don't matter. Structure does. Wrap your team around your issues, not vise versa.
* Oh, and I always wear heavy motorcycle boots, just in case somebody needs some kicking.
I made the shift from technical worked to management almost 15 years ago. I didn't want to make the move, I enjoyed the technology and keeping things running smoothly, optimizing not only code but processes. My manager and I had a series of discussions around this as she was inviting me to the "dark side". What opened my eyes and helped me find the challenge was when she pointed out that people, like machines, have optimal configurations and they differ for each system. What motivates an individual, what is their capacity at a given time, what external influences are operating on them, what is broken or in need of being upgraded? Once I understood that I could apply what I enjoyed about technology to people, I was interested in making the move. That said, you have to commit to it. You need to learn about yourself and what kind of person you are. What are your strengths and weaknesses and how do you compensate for them. Myers/Briggs and all those personality tests can help. Just like you know a technology or programming environment inside and out, you have to make the same commitment to learning the people environment. And it has little to do with being social. You have to learn about the different types of leadership and how/when to apply them in various situations. You have to learn about understanding what motivates people/groups and how to motivate them. You have to learn how people (and personality types) relate to each other and how to build a diverse team. You have to learn how to lead from behind, but also to be there to take the bullet for your team - they get the credit, you take the blame.
If you don't want to do your part to become the best leader you can, then don't make the move. You'll be giving up your technical skills and if you're doing this right, you'll keep just enough information to be a check/balance against your team. As you move up the ladder, you'll be exposed to different groups and you need to understand how they work and what their needs/motivations are - development, operations, networking, security, etc.
Find a manager you want to be like and ask them to mentor you while you're learning.
This will seem odd - but the Boy Scouts of America offer leader training for their volunteers. You'll have to get cursorily involved in Scouting to participate. One is called Woodbadge and to take it you need to complete some initial training (Scoutmaster Leader Training, Intro to Outdoor Leader skills). These classes are usually available locally. There is also a training center located in Philmont (north eastern New Mexico) that offers training on the national level. I have attended several management training classes through the different companies I have worked for, some costing thousands of dollars, as well as the scout leader training and it is definitely comparable and in some ways better. Helping a teenager learn to manage his peers and watching their struggles has taught me a lot about managing and directing a team of "professionals".
.. pa-ra-bo-la, pa-ra-bo-la, 2 pi R, 2 pi R, where's your latus rectum, where's your latus rectum, 2 pi R
Avoid pointy hair? LOL, ain't no way! You're already 1/2 there...
No matter what, as the boss you are going to be the bad guy at least once in a while.
No matter what, you are going to be less familiar with the technical details of the work being done and the issues involved than the guys in the trenches.
With that said, you can avoid the worst behaviors of the PHB. With your technical background, if you keep it up, you will be able to know which developers are BS'ing you and which give advice and information you can trust. Cultivate those whom you can trust and respect their judgment. Using your own knowledge and what you learn from your team, represent your team to your superiors and peers and protect your team from the political turmoil as much as possible.
Good luck.
I started my career as a systems administrator / systems programmer on Unix systems. Over the last 20 years, I went from a "hands on" role to a leadership role. I'm now the "CIO" of a small university (we don't have the title "CIO" at this campus, but that's basically my job.) Some of those transitions to a larger role were easy, others were more difficult.
I strongly recommend you read the essay "Taking on a new role" (PDF) from MOR Associates. In short, the essay gives this advice:
I like do to the SWOT profile (see #4) without actually using the terms "Strengths, Weaknesses, Opportunities, and Threats." I find it's easier to start with a "plus/delta" profile. If you haven't done that before: Draw a vertical line on the whiteboard. On the left, label it "plus"; on the right, "delta". Draw a horizontal line across this, making 4 quadrants. Above the horizontal line, label it "now"; below the line, "future".
Now you're ready for your team to identify what's working well (plus) right now, and what's going to be a benefit to them after another 6-12 months. They can also help you identify what needs to be addressed/fixed/changed/improved (delta) right now, and what can wait for another 6-12 months. Congratulations, you've built a SWOT profile:
I find the SWOT helps me to identify the key issues to focus on. What you must do is identify a plan to address the right-hand column (deltas) that leverages what you have on the left (plusses). Your team is critical to help fill out the SWOT, and the great thing about this exercise is that it helps the team to identify with you on your new level. But while your team helps you with the SWOT, you must build your own strategy to respond to it; that's your job as a new leader.
If you're having trouble picking out your top priorities (see #7) you may also consider doing an "affinity" exercise with your team. You can do this in different ways, but here's what I find works best for my team:
You can now identify (by score) what are your top priorities. Maybe you have 5 or 6 "top" priorities. Or maybe you only have 4 top priorities, and there's a big gap (in score) between #4 and #5.
I made this transition myself around 2001 and more-or-less successfully managed a team until 2007. It was a great experience, and the right move for me (and IMO for the company). While there's a lot of challenges you'll have to work through, there's only one major thing I look back on that I regret:
I wish I had spent more of my time selling and promoting my team's work to the rest of the company.
I had a great team of people and we accomplished a lot of amazing things. We mostly built internal tools for employees to run the company with high efficiency. I thought that our contributions would be automatically appreciated. I also thought my time was best spent in the trenches with my people getting the maximum amount of stuff done. Looking back, I think I was wrong on both counts.
The people making decisions in the company didn't interact with us that much directly, nor did they interact that much with the people who were benefitting from our work. So it wasn't clear to them how much value we were bringing. That ended up leading them to undervalue our contribution when they planned things, and undermined respect for my team. My team and the whole company would have been better served if I had periodically set aside time to present to the various department managers and the board exactly how what we were doing drove the company and each department forward.
To summarize: perception can trump reality. Developers tend to focus on the latter. Tools tend to focus on the former. A great manager delivers on both.
Cheers, and good luck!
You'll need to practice increasing your range to piss on more people beneath you.
I swear to God...I swear to God! That is NOT how you treat your human!
Find something you can believe in until it kills you.
this:
http://ars.userfriendly.org/cartoons/?id=20111002
If you are seriously asking THAT question on /. perhaps your employers made the wrong choice. The first thing you need to know is that your subordinates are going to tell you what they want in a boss, not what a manager needs to know to run a successful project.
Subscribe to the "Manager Tools" podcast and listen during your commute. You'll arrive at work energized every day.
Heres my advice to you - its not cheap, itll take a lot of effort, but it will be worth it.
Find an executive MBA program (you know the type where you go to 4-5 day long seminars instead of studying full time). There you will learn the terminology and way of thinking of the "other" managers. Respect that management is also something that people go to school to learn. People often confuse inate leadership abilites with management skills. They are not the same.
Peopleware
Behind Closed Doors
Making Things Happen
Management 3.0
Personal MBA
Working with Emotional Intelligence
Also, check out the reading list on Personal MBA and follow your interest as you go.
Apologies for posting anon. Slashdot seems slashdotted today and I can't create a user.
I made the transition from developer to manager about 2 years ago. At first I thought the activities that got me promoted were what would make me successful as a manager. As the previous posters have said, your new job is completely different from your old job. If you don't get out of the details, start trusting your people to make the right decisions and start being satisfied with "good enough" (by your own very high standards), you will drive your people crazy. I say this from experience.
After about 6 months of making it up as I went, I found Manager Tools, a podcast started in 2005/06 by two management consultants with a lot of experience (one of which used to be a developer and made the transition to management). I haven't listened to all the casts and I haven't followed all their advice, but I feel this podcast has put me on the right track toward being an effective manager.
Their approach is that successful management is all about behaviors, both yours and your direct reports'. It isn't about feelings or impressions or intent, it is about behavior. They give great advice (some of which will seem very simplistic) on how to behave like a manager. I can't say I've followed everything they say to the letter (I started off doing weekly, 30 minute one on ones with each of my directs and then backed off to once every 2 weeks), but after a year of following their advice, I don't feel like I'm just pretending to be a manager anymore.
Specifically, they give instructions for how to:
1. Setup one on ones with your people for the purpose of building relationships, understanding what is going on with them and understanding what motivates each person. Before I started these, I'd find out about problems a month after they started. Now, if something is bugging someone, I'm no more than a week or two away from hearing about it.
2. Give timely and effective feedback. "Feedback should be like breathing, and most managers walk around holding their breath all the time." At first, I found it very hard to give effective feedback (especially "corrective" feedback), but once I learned a method for doing it, it became much easier. I also found that most of my people really want honest feedback on what they are doing that is working well and what can be improved. Their model is dead simple and takes about 10 seconds to deliver.
3. Setup and run effective meetings. Before I listened to Manager Tools, I wasn't running weekly staff meetings with my team and I wasn't communicating nearly enough with them about what was going on with the rest of the business. One word of warning on this one. Once you learn how to run effective meetings, all the ineffective meetings you go to will feel 10x worse.
4. Coach your people to improve them and move them to the next level.
I strongly encourage anyone making this transition to start with their "basics": http://www.manager-tools.com/manager-tools-basics
The podcast is completely free. I ended up signing up for a subscription because I know I get more than $15 a month in value to my work and career from these guys.
Other than that, I like Peter Drucker who approaches management as a professional discipline, not just a necessary evil of organizational life. I'd suggest "The Effective Executive" (which was a recommendation from Manager Tools).
Best of luck.
Or maybe http://www.dilbert.com/ where you will find out how the true professionals do it.
Sent from my ASR33 using ASCII
While you will undoubtedly need to grow into the new position, you probably already have either, the necessary skills or equivalent skills you can bring to bear. Here are some key points to consider: 1: Make sure you understand what your new job is, in other words, what is expected of you by management, most likely your new job is to make sure the finished product gets done on time, budget and spec. Once you realize this is your job, find a way to make sure this happens. The reason I've seen people fail to make this type of transition is because they lose sight of what is expected of them, I had a coworker who used his new position to tell management personnel that they were stupid and were unreasonable in their treatment of employees. He was demoted within a couple of weeks. 2: Your job is to make sure things get done, some people are good a doing this by being "slave drivers", some do it different ways. you've probably have had good bosses in the past, do what they did. If you have a good relationship with other managers there, talk to them and ask for advice on how to deal with the day to day challenges of your new job, you might not always agree with their advice but you'll at least get some good advice to get you started in the right direction. 3: Its just a job, meaning, all you have to do is learn how to do it, whoever tells you that you have to be born with it has a very poor opinion of himself at the least. here is the skill set: *Planning *Getting people to do what you say (very hard for some people, easier for others) *Time management *Getting things done (or making sure things get done) *Being able to spot pitfalls from a mile away *interoffice politics (Hardest thing for some people to learn how to do, but like Dylan said, swallow your pride, you won't die, it's not poison" 3: Most importantly, are you comfortable telling people what to do? when the time comes, can you fire somebody? Are you able to not care what other people may think of you? (meaning you wont do things just so people think you're a "good guy" can you be a PHB?) Hope this helps!
I'm always right, except when i'm not.
What should I be learning, reading, thinking about in order to make this transition successfully and avoid growing pointy hair?
So many answers to this question it would be impossible to give a full list, so I'm going to assume that the obvious management strategy / leadership skills books will be covered. I'll just add one suggestion:
The Wisdom of Crowds, by James Surowiecki
What you should be learning is how to talk to people, how to read people, how to motivate them, as individuals, and, very importantly, how to appraise their progress. For the latter I'd suggest regular (though not necessarily very frequent) individual meetings, a piece of paper, a pen, and an open honest conversation.
Have you looked at some MS programs that help with transition?
Some of the major issues you will encounter are:
communication with the Business (they will have language barier)
selling technology to business
Budgets
Politics
Managing teams
There are great programs that will help. For example in NY you can attend:
http://ce.columbia.edu/Technology-Management
http://www.stevens.edu/sit/development/schools/Howe-School-of-Technology-Management.cfm
http://www.poly.edu/amot
Disclaimer: I am not a manager right now, I only dabbled in it a few times in my previous career in consulting. I will also say that in my own judgement I did not do a good job.
One pointer that I am missing from this thread is to start learning about project management methodologies like PMI (http://www.pmi.org/) or PRINCE 2 (http://www.prince2.com/). If possible, attend a course. I have had some key insights from the one I went to (can't remember which one, sorry).
Here is what I learnt: Put some effort into the creation of the project plan (schedule). But keep in mind that its main purpose is to have something that you can deviate from (!). Every non-trivial project will see unexpected events. So it is not enough to just pad the estimates that the initial schedule was built from. Instead, try to identify potential problems and then come up with ways to deal with them. This is a continuous process throughout the project's lifetime. The recommendation is to involve the whole team into it. In my course the presenter said that he usually held weekly risk management meetings with the team. He would challenge everyone to come up with new risks and ways to deal with it. All possible scenarios and ways to deal with them are documented in a risk register which is updated as the project progresses.
When it comes time to step up, it should be out of necessity and not motivated by looking for a bigger paycheck, title or corner office. First off I admire you for voicing your questions and asking for feedback. That is a great tool and shows you will be a good manager/leader. Not everyone knows everything. Even ants can show you a thing or two (if you take the time to watch them walk and form a pathway). So good for you! You are off to a good start. Hopefully you have been working in some capacity already leading others through your example and hard work if not in title and overall power position in the company. Influence and power can be gained in many ways some direct (title, position, evil deeds, evil politics) and many others indirect and subtle that take months if not years to cultivate and create your own world within the group you reside that gains you trust and respect. If you are shifting groups or being thrust into a very different group or path like quitting smoking from one day to the next, expect headaches and difficulties as everyone adjusts to the new variable (you) in the mix. If your life changes little and you are able to continue to build on existing relationships within the company given a slightly more formal voice and more decision making power, then you are in the right place. If it feels good it is good. It doesn't take someone with a title of VP to effect change in an organization. The engineers also have amazing energy and ideas and if given a voice can enable change like no other. Your new role is to guide all that raw energy to a fruitful end. A new equation would be P = E*I where Product = Energy * Ideas where your input and your leadership is the multiplication operator (which you overload and make into your own operation) and the energy and ideas are that of you and your team. The end result will be a product that when delivered to the operations department (Sales, Marketing, etc.) will result in O(P) = M where O is operations acting as a function on your product P resulting in M or money where the company sees profits and you will all have succeeded. On a side note once I asked a friend of mine who is the VP of software development at a medical device company what is fulfilling about her role given the number of meetings, phone calls, emails and organizational headaches she faces daily. She answered me with a question: “Do you have children?” I answered Yes. She asked another question: “Are you happy when someone gives your child a present?” Yes I replied. “I am very happy when someone gives my child a present. I feel and can see their happiness very directly.” She replied, “That is what a manager’s role is. Enabling your subordinates to succeed and relishing in their success and happiness.” “That,” she said, “Fulfills me.” Does it mean if you don’t have children you will be a horrible manager? No, you just need to learn that your new role will not have as many individual successes (as you did when you were an engineer) but rather group success based on other’s achievement guided by you in your new role. Good luck.
and they will be many. I'm going through the same transition at a start up and it isn't easy. The biggest thing I'm finding is that even though you are supposed to be a strategic thinker and solve business problems, you will be asked to get back into the weeds and do what your last job required. While you are playing super hero to your technical comrades you will be testing the patience of those who expect something different. Don't throw in and help and you could be seen by those constituents as not being a team player. Knowing when to do that can be tricky. Eventually you would think that hiring over time will mitigate that but it may be a long tough slog. The other thing I'm running into is finding that delicate balance of where my ability to take charge and own things and stepping over my boundaries are. While I'm dithering wondering if I'm going to piss someone off, someone else is unhappy as I'm not meeting their expectations. So there are macro changes to deal with, that being telling people what to do and expecting them to perform and micro that are more subtle where you have to take some chances and learn from the bumps and bruises you will get when you are wrong. So keep an open mind, you are no longer the expert in this arena, surround yourself with people who do know and can help you, be humble and take lessons to heart, and one thing I never see managers do very often, learn your craft, the promotion is only the beginning.
The government's view of the economy could be summed up in a few short phrases: If it moves, tax it. If it keeps moving,
http://www.youtube.com/watch?v=CR3KTg3jhFk
http://manager-tools.com/
Go there and start learning.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Understand that those you manage are professionals. When you delegate a domain of responsibility for a project (or part of a project), always give the level of authority to the individual contributors that they need to proceed confidently to giving their professional best. Be crystal clear in your communicating to them both their domain of responsibility and the scope of authority they have to carry it out. Authority commensurate with responsibility gives them the right to lay their own professional reputation on the line and say, within their domains, "This is right for us— this is best," and have that decision accepted by the team. There will always be someone on the team, quite likely you, who will have reservations about some of their decisions. Discuss your reservations with them but don't argue. If you vehemently disagree or don't trust them with those decisions, then don't keep them around trying to micromanage them into doing things your way: fire or reassign them. Replace them with someone you do trust. If you're going to keep them, then feel free to ask questions, make suggestions, or point out resources they might have missed, in a spirit of collegiality. Hold them to filling the overall project requirements. Provide them with resources to improve their craft and the time to take advantage of them. Other than that, keep your mouth shut. They won't do things exactly the way you would... in fact they're often going to do them better than you would, but as the "boss" you're in danger of not realizing it. Frequently remind yourself that you're not better at what they do than they are— as a manager you have many higher-level things on your plate, while they spend all their time and energy thinking about their domains. You can't compete with that, so don't try. Your job is to remove obstacles from their path and properly set the expectations of upper management. Then, step back and let them run.
Understand Accounting, Cash Flow, Marketing, Sales, People Management, Psychology, Contract Law and more but I'm very tired, HTH.
My ism, it's full of beliefs.
Look - this is a tough step. There's lots of stuff in the management literature about this, that and the other skills you need. But the biggest is a change in mindset. Read "What Got You Here Won't Get You There" - this is the book I buy everyone when we promote them.
I've been following the Manager Tools forums and podcasts for the last 2-3 years. It's why I've improved in my position as team lead and helped me in better handling my own small business and volunteer leadership. Core to these are insights and experience from well-respected management/executive coaches Mark Horstmann and Michael Auzanne.
Hit http://www.manager-tools.com/manager-tools-basics to get started. Very actionable, very clearly based on what can be observed, especially around relationships and how to be effective as a manager (a stepping-stone to being effective as an executive).
remember you are leaving the world of personal achievement and entering the world of listening to gripes and complaints, which you are powerless to effect change
I have a few rules that might help:
Good luck.
Every rule has more than one consequence.
As someone who made the switch from lead developer to team leader and project manager I would say the biggest thing to make sure you are aware of is your Emotional Intelligence and your ability to Influence other people. This is the hardest part of the transition. As a developer you are in complete control over what you do. As a manager you no longer have that control. And to try to control the reigns too hard can piss people off and get feelings hurt which yes, sadly, you now have to care about.
My biggest advice would be to concentrate up-front on your soft skills because the managerial tasks of project management will come to you fairly easily. The harder part will be negotiating plans with the business and influencing architecture and design with head-strong engineers. If like me you work in a global environment where you are managing teams in your native country and abroad in different continents being aware of how people react to your style is very important. I've been told after the fact that I made people really upset over the phone without being able to tell that was the case during the conversation.
I highly recommend you research and read up on the concept of "Emotional Intelligence" or "EQ" for short. The thought goes that you are promoted because you have a high IQ. But if your EQ is low you will not get that far. This is where most engineers fail when trying to move to management. I also recommend researching on Influencing styles and skills. It is important to recognize how others posture themselves in conversations to be able to properly influence them. While you may have the best idea in the world, if your attitude causes them to put up a wall and they are important to your success you won't get that far.
1) Find a manager that is successful in your company and is generally admired. Get to know him/her and learn what they do right, what they do wrong, and what they know about the culture of the company. When you know them well and know their secrets well, find the next one.
2) Find a very successful manager that runs a similar department to yours in an excellent company reknown in your industry. Get to know them, figure out what they and their teams do right, what they do wrong, and how the culture of their company works and differs from theirs. Fix yours that way or have good enough relationships to join theirs. When your group is better than that group, find the next one.
3) Find out how your company makes money . . . really makes money -- what do they make, what do they sell, who do they sell to and how much of each thing do they sell to whom and how. Figure out how your department fits into that and how you can best fit those goals. Do those things. Figure out what doesn't make money (or worse wastes money at) -- aggressively try to eliminate those things.
4) Figure out what your team is good at and what it is bad at. Cross that with the results from #3. Focus on getting your team better at things that help the company make money and getting rid of things that make it lose money.
5) Respect people -- even those you don't like. You can learn something from _everyone_. Even if it is to just avoid making the foolish mistakes they make. Have enough respect for those people who work hard and pull things through for the company to let go those who slack off and basically leach off of their coworkers. Help those who aren't good at things, but really, really want to get there. Consider everyone's skillset as they are and reward each achievement and each step forward for people at their level.
6) Have a plan. From the details of #3, and the development of #4/5 and the examples of #1,2 figure out what goals get you closer to achieving those ideals in the the next 3, 6, and 12 months. Every quarter, reassess where you are and tune up your goals so they stay relevant and you measure your progress.
7) Measure your progress -- success or failure -- at every turn. How well do you work and how well do you create product? How good are the things you make and how good are your processes/tools for making them? Use your comparative analysis with external and internal teams to figure out how they operate as well and figure out how to measure it and improve it. Don't be a slave to numbers but don't be ignorant of them. If you pick the wrong metrics, then you learned that you need better metrics.
8) Act like the manager you wish you had. Don't be a jerk, and don't gossip. Talk to people face to face and act with integrity. Your group and peers are you community - treat them that way and build the community stronger.
9) Build your self and your group. Figure out what you all are weakest at (that matters) and get training and practice at getting better. Make it a quota to do this at least annually.
10) Manage yourself and your own stress. Have a todo list of the next top 3 most important things to do at all times -- do those next. Take care your health, sleep well, eat right and learn to leave work at the office enough to not bear the burden of your whole team's worries when you go to bed at night.
Some helpful basics to understand are Maslow's Hiearchy of Needs and the idea of Forming, Storming, Norming and Performing. Study up on those and they will give you some basic ideas of how people function which will then help you solve or, at least understand your people better and team dynamics. Also, never take sides with one of your employees over another unless it is something very blatant. I've had people come to me because they were new and they complained that the other programmers/technicans, etc. weren't cooperating with them. I knew that it would just take time for everyone to get comfortable with each other. Had I jumped in immediately it would have just made it worse. However, if you have someone who is simply an ass and it is tearing down a good team over an extended period (couple months) then you have to do something. Also, know that firing someone is not as easy as it sounds. Keep a bottle of Xanax and Jack Daniel's at the ready. Good luck!
If you have not been keeping up with trends in software development and management, you are probably doomed. It would also be helpful if your team was aware of trends in software development. If they look puzzled when you mention the waterfall method or XP as development models, well it sucks to be you. If your upper management is content with a "hack the shit out of it till it works" methodology, you are also doomed.
I had a brief taste of management responsibilities early in my career and decided to stay in development. I was asked to fire somebody who was doing a great job simply because he didn't fit in with upper management's concept of when employees should show up for work, never-mind he was working 12 to 16 hour days 6 to 7 days a week. If you don't think you can handle such a situation, stay in development. Even the best managers will encounter this at some point in their career.
If you want to be a good manager, try to look at your job as providing your team with what they need to excel in their work. You really want to use the carrot more than the stick in motivating people. Don't be afraid to wade in and help with technical issues (if you really understand them and admit it when you don't). Stay late and help with drek work when you can. The managers I've had that I liked were willing to stay way past 5pm and help do data entry (enter values into data structures) if it was going to let a team member go do productive design or coding.
The kind of management you will probably be doing will require a delicate balance of technological and political skill. If you don't feel up to that, don't make the move. You will be miserable as will the folks who work for you.
Mark
Talk to the CFO, constantly. Establish an on/off-line communication channel. Get the CFO on your side. Many IT departments are seen as cost-centres and viewed as commodity skill set custodial services. Get the CFO buy-in before any executive level presentation. The CEO, a good one, will have already met with the CFO before the meeting and will politely listen to you. If you pay attention you will see the CFO-to-CEO cues.