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.
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.
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
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,
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.
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.
which is totally what she said
I have found it is a very good exercise to let the programmers tell me how long it is going to take to get the job done. We do it in a group setting with all the peers involved. The programmers don't want to look bad among their peers so they usually set realistic dates and work hard to meet them. Each week we review progress in a group setting. This seems to work very well.
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".
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.
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.
Live today, because you never know what tomorrow brings
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.
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!
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.
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.
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.
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
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs