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

Comments

learn?

[polar red]

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

Re:learn?

[yog]

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.

Start Being Ignorant Now...

[stove]

(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

[Registered Coward v2]

1) find a mentor you can use to get advice and bounce ideas of of

2) contact some counterparts and see what professional pegs the belong to and join them and go to local meetings

3) and now the hardest part. While the developers are your friends you now have new responsibilities and may have to make some tough decisions. Be fair, but make the tough calls. If you don't, your team will suffer and do will you.

Re:Some tips

[Anonymous Coward]

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.

Give correct estimations

[zr-rifle]

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.

Hints

[mseeger]

Hi,

A difficult thing will be: you have to trust people doing the job, even though you know that they are not good as you. You will get back solutions, that are not the same you would have delivered or may even not be up to the standards you expect. You must take a step back and ask "Does it suffice?" and not "Do i like it?".

There are two big dangers:

a) Trying to do your previous job in addition to be a manager. This will kill you. The result will be abysmal performance in both jobs.

b) Having no reserves in your schedules to talk to people. This will get you disconnected and you may not realize problems until they bite you in your posterior.

The most difficult thing for me was, that i learn things about people i never wanted to know. You have tragedies (child/husband/parent dying of some illness), relationship problems (both sides being in the company more often than you think), all kind of quarrels (If n is the number of persons you manage, the number of conflicts is O(n)) and so on.... You have to develop a thick skin concerning this. If you cannot, step back. Otherwise it will break you.

Another lesson learned: If you make a decision, never postpone it. Pull it through with max burn ;-).

After 8 years i had enough of that job and went into sales....

Good luck, Martin

Re:Micromanage or you will be disappointed

[somersault]

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.

3 easy steps...

[Lumpy]

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.

Good luck

[delphigreg]

Five years ago I was fed up with incompetent managers, silly requirements, unrealistic deadlines, and unending piles of bad decisions. I thought I could do better. This year I had enough and are doing the best I can so bring down the pointy hair.

One key thing to understand is that right now you are great with technology, but management isn't about technology. It's about people. The people you manage, your peers and leaders in other areas of the organization. People can be a lot harder to figure out than technology.

My advice is this.

1. Read "Behind Closed Doors". Probably the best book I read as a new manager. Wish I had read it before I made the leap. http://www.amazon.com/Behind-Closed-Doors-Management-Programmers/dp/0976694026/ref=sr_1_3?s=books&ie=UTF8&qid=1324299173&sr=1-3

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.