The Programmer's Path To Management

snydeq writes: The transition from command line to line-of-command requires a new mind-set — and a thick skin, writes InfoWorld's Paul Heltzel in a tips-based article aimed at programmers interested in breaking into management. "Talented engineers may see managing a team as the next step to growing their careers. So if you're moving in this direction, what tools do you need to make the transition? We'll look at some possible approaches, common pitfalls — and offer solutions."

Comments

Um.. we don't see it as advancing our career

[rsilvergun]

At least in America if you don't move into management you're dead meat by 40, 50 tops (unless you're some sort of genetic freak). Around that time it becomes impossible to put in the 50+ hour work weeks at a moments notice let alone compete with cheap H-1b labor. It's not even age discrimination. They don't care that you're old, they care that you either can't or won't put in tons of overtime they don't pay you for.

Re:Um.. we don't see it as advancing our career

[NoNonAlphaCharsHere]

Once you hit 45, you had better have moved into management, or be a white-bearded wizard with some kind of obscure language/system (MATLAB, SSA, SPSS, COBOL, DB2, etc.); otherwise, if all you know is stuff like Java/C/C++, you're going to be unhireable after the age of 50. This is the voice of experience speaking.

Re:Um.. we don't see it as advancing our career

[BVis]

While Japanese and German companies tend to build up a good relationship with their workers and try to keep them at the company until retirement

Why do you hate America? Employees are the enemy. The more experience the worker has (especially domain knowledge specific to the company) the more they're going to want to get paid. More pay means less profit. So, fire them and replace them with H1-Bs or much younger workers who don't have families to feed or a mortgage to pay for, and you save a ton. Never mind that their work product is total shit, nobody cares about that. After all, corporate profits are far more important than any concern the employee might have.

which means the average worker is more skilled and productive and needs less management.

Problems with that:

1) Needing less management means fewer managers. Hey, that second summer cottage isn't going to buy itself, managers need jobs.
2) More skills mean the greedy goldbricking lazy shits want to get paid more. What a pain in the ass.

Is it in the more creative sector an advantage to be more experienced? Or is it better to have more new and young blood with new idea's?

New ideas? Ain't nobody got time for that. No, you will do what you are told, don't question management. Either that, or managers will steal ideas from the lazy fucks that do the actual work. The only time more experience is useful is when the C students in HR are checking boxes to try to find "good" candidates (when the truth is that a laundry list does nothing to assess the real potential of a candidate). But, you have to be careful. If you have too much experience, you're "overqualified" and you won't get the job, since you might leave for a better offer. Companies hate that. Most would chain you to your desks given the chance, so the fact that their employees can leave (which is the only real right American workers have, something about slavery being illegal) is an insult to our Corporate Masters.

Re:Um.. we don't see it as advancing our career

[RingDev]

I find this notion interesting.

I am a manager. I have hired people over 50. On my team right now I have 3 people within 3 years of full retirement. One of whom I hired within the last year. I also have two that are within spitting range of 50, one of who I hired less than 6 months ago.

When I'm bringing someone on board in the 40+ category with 20+ years of professional experience, I have drastically different expectations than what I'm looking for in a 24 year old kid who's on his first salary gig out of college.

I'm looking for someone who understands corporate structures, workflow analysis, generalization. I'm looking for someone who says, "When you boil this down, it's an asset management system, and I've worked with half a dozen different vendors and 4 different home grown systems that do the same thing". I want someone who can sit down with users, look at what their doing and not just imagine up a new piece of software, but understand the business process to the point where they can make truly business impacting recommendations with a realistic grasp of what it would take to accomplish. I want someone who will pull the young bucks aside and explain to them the merits of simplicity and maintainability, someone who can do code reviews without being a pretentious dick, someone who can help guide that next generation of developers into the future engineers and architects I need.

People over 50 absolutely have a place in the development arena. But if you're 50 years old and still expect to have the same responsibilities as a 24 year old kid, you will be sorely disappointed.

-Rick

Re:Um.. we don't see it as advancing our career

[DuckDodgers]

The problem with being a software developer at 45 or 50 is that when you learn Node.js or CoreOS or whatever the new hotness is and a 28 year old learns the same technology, a lot of HR managers will think they can get 10 extra hours of quality work per week out of the younger man (or younger woman) for 20% lower compensation. That belief is often wrong because 40 hours of quality work from you trumps 60 hours of quality work from most people 20 years younger, but it's a common belief nonetheless.

Conversely, there are three good things you can do as a manager that used to be a software developer for fifteen or twenty years:
1. You can manage from experience, with a real understanding of the work your employees are doing. My best managers have all been former developers - or in some lucky cases, people that get to do half management, half development.
2. You can make informed decisions about what technology stacks to use or to avoid and what priorities matter. At my last job I turned down a management role repeatedly, and I was pleased with my choice until the person who took the management role drove me out of the job with poor decisions.
3. You can understand that a development manager's most important job is running interference between skilled employees and the rest of the company. Yes, it's less fun than developing. But you'll gain respect, trust, and productivity from your team if you point them to the target and then spend your own time leaving them alone, keeping them out of wasteful meetings, and trying to remove any obstacles that would slow them down. My current manager does that, and she's awesome.

Don't Do IT!

[Anonymous Coward]

As someone who transitioned from Jockey to ShitMover I can assure you the move isn't worth the headaches. I used to work with a great bunch of like minded people who where interested in creation. Now i work with a bunch of egotistical idiots who just want to push stuff they know is garbage over the line just so they can get ticks against their name and get out before it blows up.

Re:Don't Do IT!

[NoNonAlphaCharsHere]

I know that, but MBAs don't recognize the truth of it.

Re:Don't Do IT!

[Darinbob]

You have to make sure that 2 or 4 young/cheap programmers can not replace you. It's not like programming is the only skill for programmers. You have to understand the product you're making, how the team works together, how the different parts work together, etc. Become indispensable. Work for a company that doesn't do the latest and greatest fad (getting involved with fads is a short road to a short career). If all you do is know how to tie together different libraries and understand the syntax, then yes, you'll lose your job to the cheapest one out there.

There are more types of things to be in the career other than just junior grunt and elite manager.

The good jobs are the ones with actual job requirements listed, things other than "$x years with $new language". Experience is highly valuable. You can't take a recent grad willing to work for beer and hot dogs and have them design the next system. Chances are they're going to be hunting down your experienced staff for help on how to debug something simple.

Because if they're going to toss away a good programmer in order to replace with cheaper workers, then believe me they will also toss away the good managers too and replace them with cheaper ones. If you can't find a job as a 50 year old programmer then chances are you're going to have much difficulty finding that 50 year old management position (especially when all the CEOs are 20 something Harvard dropouts who don't think old people are relevant anymore).

Re:Don't Do IT!

[anchovy_chekov]

As someone who transitioned from Jockey to ShitMover I can assure you the move isn't worth the headaches. I used to work with a great bunch of like minded people who where interested in creation. Now i work with a bunch of egotistical idiots who just want to push stuff they know is garbage over the line just so they can get ticks against their name and get out before it blows up.

Absolutely agree with the AC here. I made the move to management about 10 years ago and consider this a lost decade. Moved back to coding as a freelance and loving it.

If you must, then at least learn some of the disciplines around management. Take some time to read up on management systems that actually work (e.g. Toyota Production System) and don't lose sight of your analytical past. I found the skills developed as a coder - being able to break a problem down into smaller parts, using empirical techniques to determine whether an approach would (or did) work... using logic and evidence - were of paramount importance to succeeding as a manager.

On the flip side, I found a lot of magical thinking on the part of other managers - refusing to believe what maths or reason made self-evident. That's where people skills come in - getting people over the hump of their own prejudices or wishful thinking. Get the mix right and you'll shine.

Good luck in any case.

Re:Don't Do IT!

[Hognoxious]

You can't take a recent grad willing to work for beer and hot dogs and have them design the next system.

Hey, Dice! Are you listening to this?

So...tired...of job... stories

[bangular]

The stories about jobs and careers are getting so tiresome. I realize Dice bought Slashdot to datamine the comments (free focus group!), but it seems like half the stories are a variation on the same these days.

Toughest part in transition

[Sivaraj]

I have been a programmer for all of my career, and had management roles in the past 10 years to varying degrees. Over this period, I have also mentored other technical team members in transitioning to management roles. The toughest part of that process is in learning the ability to delegate. This is especially tough for talented programmers.

You often feel that it is easier for you to do a particular task yourself rather than delegating. It may be true that you might finish the work in tenth of the time it takes someone else to do, and you may be spending more time in explaining it to others. But at some point you have to stop doing it, start trusting others to deliver, and don't meddle with their work too often. Once you learn how to do it, you are well on your way to becoming a successful manager.

Re:Toughest part in transition

[chipschap]

Learning to delegate is one of many necessary skills, but the biggest thing a new manager has to learn that being a manager is not about YOU, it's about your staff. Your job is to do what it takes to enable them to get their jobs done, to empower them, to remove roadblocks, and to make sure things work for them.

The minute you forget this, you're done, because as a manager you are NOTHING without your staff. They're the ones who are going to make you look good or look bad.

Yes, managers set direction, make policy, make decisions, all the stuff you hear about, but if they ignore the needs of the staff while doing so, they fail as managers.

I was a manager for a good part of my career (after having been a technical person). I am glad I had good mentorship and learned what managing was really all about, which is empowering people to do their jobs.

Side note: I was once myself mentoring a new manager, who said, "Well, what if I'm having a bad day?" My response: "You're the manager. You don't get to have bad days. Your staff needs you doing things for them every moment of every day, and YOU are not the one who's important."

So if you're a programmer (or other technical person) aspiring to be a manager, fine, but keep in mind that the minute you become the manager, your role changes drastically, and if you're into satisfying your own needs, think twice about taking on a management job.

It's the non-engineers.

[tlambert]

The stories about jobs and careers are getting so tiresome. I realize Dice bought Slashdot to datamine the comments (free focus group!), but it seems like half the stories are a variation on the same these days.

It's the non-engineers.

They have this misconception that people used to dealing with the intricate semantics of programming languages are going to be unaware of the intricate semantics of English. Therefore, if they ask a question once, and do not get an answer they like, they will repeatedly ask the same question in different guises, hoping to obtain the answer they wanted to hear.

This really comes down to who is more patient than whom.

I usually attempt to buffer my answers in order to soften the blow, but you can ask the same question as many ways as you want, and the answer will likely not change, so long as it is fundamentally the same question. And I usually have the patience of Job. However, there was one incident where I was up against a deadline, and was being asked to "just cobble together something that works, and we'll (read: you'll) fix it (read: in a binary compatible way) later. Which was an impossibility (I was working on some very complex database code written in C++ which did subschema definitional enforcement on an upper level database schema, and the semantics had to be correct for the data stored in the binary backing store to be usable going forward, when we did the next update). The code had to be *right*, as opposed to *right now*, and the time difference was important.

We had a UI person who was in a management position, and they brought her over to argue their case that immediate was better than correct (correct would fit under the deadline, but only if everyone left me alone to finish the code). The UI person was constantly revising the UI in each release, and each release was practically a full rewrite. And she did not understand why I could not write my code the same way she wrote hers. Finally having had enough, I explained "It's OK if your code is crap; you are going to rewrite it in the next release anyway. My code has to work now, and it has to continue to work going forward, and therefore it needs to be correct. I understand that you are feeling the approaching deadline. So am I. However, while your code can be crap, mine can't be because I have to maintain it going forward. Now if you will get the hell out of my office, I will be able to finish the code by the deadline."

Needless to say, there were some ruffled feathers. The director of engineering sided with me. I completed the (correct, rather than expedient) code by the deadline, and the product didn't turn into unmaintainable crap vis-a-vis the update process going forward.

What's the moral to this story?

Well, with specific regard to DICE:

(1) Repeatedly asking the same question in different ways is not going to get them a different answer, if the first answer was correct. Any other answer than that answer would be incorrect, for the question asked.

With specific regard to the current topic:

(2) Engineers who actually reliably, repeatedly, and consistently deliver what they are asked to deliver, within the timeframe that was agreed upon, can, and often do, wield more authority than the managers nominally set above them in the food chain, so it's not like going into management is going to give you any more real authority than you already have by way of your relationship with the team, and their trust of your judgement.

A management path can be a good idea if:

(A) You want more perks (stock options, etc.), although in a good company, if you are a great engineer, you will get those anyway

(B) You are tired of doing engineering for a living (which probably means you didn't qualify as "great engineer" under option 'A' anyway)

(C) You feel you would be more useful and/or happier in such a position (but if your happiness is based on power, don't expect it will necessarily follow)

(D) You