Ask Slashdot: Transitioning From Developer To Executive? 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?"
Start Being Ignorant Now... (Score:5, Insightful)
(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!
Some tips (Score:5, Insightful)
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.
Give correct estimations (Score:5, Insightful)
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.
Hints (Score:5, Insightful)
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
Congratulations! (Score:3, Insightful)
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,
Consider whether you really want to do it (Score:5, Insightful)
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:Some tips (Score:5, Insightful)
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:Micromanage or you will be disappointed (Score:5, Insightful)
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.
Engineers alternative (Score:5, Insightful)
It doesn't all stop when you leave school or even the "shop floor".
Re:Give correct estimations (Score:5, Insightful)
Awesome list. I'll just add one more: block "minor enhancements that shouldn't affect the schedule" no matter who suggests them.
Re:Simple (Score:5, Insightful)
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:Dev to Exec (Score:4, Insightful)
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.
Lead, don't pull (Score:4, Insightful)
1) Do the sh*tty TPS report work yourself. Don't hand it out.
2) If the printer is a continuing problem, GET ONE THAT WORKS
3) Never, under any circumstance, take the stapler away from the mumbly Aspergers guy
(seriously...)
4) Keep the department a fun place to work. Good employees work best when they enjoy the workplace.
5) Don't dictate. Lead by example. It's really crappy to see the Manager leave at 5:30 on a Friday while everyone else toils on a late project. Even if you can't help, let everyone know you're willing and making yourself available wherever you can help.
6) Taking everyone out for lunch once a is a great appreciation strategy. Even if it means bringing in doughnuts. People appreciate managers going above-and-beyond once in a while.
be a shield (Score:4, Insightful)
- 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.
Re:Give correct estimations (Score:4, Insightful)
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.
Re:learn? (Score:5, Insightful)
Yes, I've seen several people "promoted" into a manager or VP of Technology type of position who were simply unprepared for the transition. It was felt by the (foolish, ignorant) top execs that the candidate would make a good manager since he was already such a good programmer or architect. The predictable result was catastrophe; the former star programmer became a stupid git who was hated and despised by everyone, and eventually was shown the door after having caused incalculable damage to the organization.
Unfortunately for all parties involved, software engineering and management are two completely separate skills. It's like saying a good surgeon would make a good hospital administrator--where do you pull that out of? They are unrelated and often oppositional jobs. Shoot-from-the-hip, cowboy programmers as well as "team player", 9-5 coders are equally unqualified to manage others, with the team players being slightly better simply because they're less likely to piss everyone off right away.
I've found in my professional experience, as have many others, that really great managers are born, not made. Some people seem to have instinctual abilities to see through the fog of war and focus on the goals, marshal their resources rationally, and avoid letting petty emotions, vindictiveness, oneupmanship, and all the politics that come with human interaction get in the way. You can call them out, tell them to their face that they're full of crap, challenge their assumptions, and they will calmly roll with the punches and adjust accordingly. Their bosses will lean on them, change their priorities, threaten them, etc., and they will push back, educate their superiors, win the time and money they need to achieve the objectives.
It's like sales. Great sales people seem to have an innate ability to close the deal, while crappy sales guys (the majority in the world, I think) piss off the customer, display their ignorance, and basically fumble the ball more often than not.
So, op, proceed cautiously. You are about to step off the cliff and hope you enjoy a soft landing. A few make it, but most don't. I would say, if you're pretty good technically, you should just stay in the tech field where you know you have a good future. But, if you want to learn from bitter experience, be our guest and delve in. Get back to us in a year and let us know how it's going.
Re:learn? (Score:5, Insightful)
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:Some tips (Score:5, Insightful)
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:learn? (Score:5, Insightful)
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.
Re:Start Being Ignorant Now... (Score:5, Insightful)
All the successful technician-to-manager folks I've worked under have suggested solutions, listened when technicians explained problems and tried to get managerial roadblocks out of their way
My mantra as a manager is, "Trust your people." In one of my first management positions I took over a team that was having a really hard time (they'd been leaderless for a year, had political issues with senior management, etc) that was in the midst of shipping a major new release. Things were chaotic and the urge to micro-manage was intense. Fortunately I knew how technically proficient they were, and was able to discipline myself to trust them across the board on technical issues while I started the (ultimately successful) process of dealing with the political and people issues.
Re:Some tips (Score:3, Insightful)
1. Don't try to change your people. They are who they are. Work with their strengths. If you can't deal with who they are, you'll need to work on getting them off your team.
2. Pay attention to your employees' careers. You should be training them to see the broader aspects of what they're working on. You should have a career path in mind for them. Some may want to do what they're doing for the rest of their lives. But you should be looking for the ones who will eventually want to move up or sideways, and you should help prepare them for that.
3. Remember that if you're successful, it's because of the work they do. Don't forget that. You aren't successful all by your little lonesome.
4. When you give them something to do, give them a result. Don't micromanage the way they do it. Certainly standards have to be applied, regulations complied with, etc. But as much as possible, let them work toward the goal.
5. Your authority is in your title. It's in black and white. You don't need to prove it all the time. You don't need to fear challenges to your authority: they're stupid and you can't lose them.
6. Finally, this one is tough, but be aware of the difference in your relationship now. There are some jokes that will not go over like they used to, because although you are still who you are, you are now also boss. Neither you nor they can forget that, and shouldn't. Otherwise what would be the point of making you boss?
Re:learn? (Score:3, Insightful)
I recently had to make a similar change - from being in training to becoming one of two cardiologists running a private office, which means I'm responsible for employees.
Making technical decisions is the easy part - managing people is the hard part. You're simply treated differently when you have the ability to make decisions that can change people's livelihood and lives. The best resources I found on this were "Getting to Yes" and "Getting Past No," both touchy-feely pop-style books, but both with semi-useful information in them.
Friends gave me management books, like "The Essential Drucker" and a subscription to the Harvard Business Review - I found all this stuff to be almost useless. I've found that if I spend a few minutes every once in a while checking in with people, and trying to listen to the answers, that things work out well.
good luck...
Re:Micromanage or you will be disappointed (Score:4, Insightful)
This is actually pretty common and any manager worth his spit aught to be able to tell the difference between "Effort" and "Duration" estimates and should have a rough idea of what percent of your time is targeted at the project.
For example, if you said it would take you 240 hours to complete the project (effort), and I know that you're only going to be able to put about 50% of your time towards the project, that the total duration is likly going to be around 12 weeks.
If I really need that project done in 8 weeks, it means I've got to find ways to get 50% of your non-project time removed from your plate. If that means getting someone else on the team to look at the network issue or finding ways to mitigate the impact of the move on you, so be it, but I, as a manager, need to find a way to get you up to 75% of your time as project time.
This is actually pretty challenging. By default, under best circumstances, assume that any average employee is only going to have 90% of their time available. The other 10% goes to checking email, answering phone calls, bathroom breaks, etc... Typically, I like to estimate 80%, especially for people who have to bounce between projects or are on user-centric projects as there will inevidibly be delays and thrashing.
Even with that 80%, you're going to lose some portion of it to meetings. Heck, most folks have atleast 2 hours of meetings a week for status updates, tech reviews, performance evals, planning, etc... Each two hours of meetings is another 6 1/4% off that 80% number.
So as another Sr Dev/Jr Manager individual, I'd say keep making sure that your manager is aware that your estimates are for Effort, not duration, and make sure he/she is knoledgable about your schedule and other responsibilities.
-Rick