Slashdot Mirror
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."
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.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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.
Step #1: Sell out. That is all.
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.
A manager need to learn about the psychology of people at work and in groups. That not all people work the same. Some are inherently more efficient and productive working in one manner while others are more efficient and productive when working in a different manner. Some can get by with headphones in a noisy open environment, others require a quiet office to themselves. Some do well bouncing around from one part of a program to another, a breadth first sort of traversal of the code. Others do well drilling down into more and more detail in a single part of the program, a depth first sort of traversal of the code. In short, they need to learn that there are no universal answers. No universal manner in which to measure productivity. No shortcut for managers, that management is hard and you have to put in a lot of work to do it right. A manager also needs to develop an increasingly better understanding of other departments in a company or organization. How do the accountants look at this project? How do the marketing people look at it? How do the executives think it fits (or doesn't fit) into their objectives? Are any of the preceding or other interests in the company failing to properly understand a project and it value? How do I persuade them? Well the first step in persuading them is to understand their perspective and concerns. Then you can address these concerns in a manner that they understand, from perspective they have. Management is hard, you not only need to possess a deep understand of the specialty of the people you directly manage but you need to have a working understanding of the specialties of other people in unrelated departments. Again, there is no shortcut. Its hard work.
... but now you can better understand and communicate with other people in the company or organization. You can be more effective and persuasive at representing the perspective and interests of your specialty. You are a geek that can communicate effectively with an executive if need be.
On recurring theme in all the case studies of real businesses and project that you will study, regardless of area or topic (engineering, marketing, managements, etc) is that most failure are human in nature. That people were in the wrong position, used in the wrong way or were just plain unfairly treated. People both inside and outside a team, and inside and outside a company. A lot of this came from the arrogance and overconfidence of a manager. Hint at what not to do.
So where does one learn more about the psychology of leadership, the psychology of people at work and in organizations, how to motivate, how to persuade, etc. Well that is what MBA programs teach. MBA programs are not about bean counting, finance and accounting. MBA programs are about taking a person with deep understanding of one part of an organization and providing them with a working overview of all the other classic parts and functions of an organization.
Yeah, I said it, an MBA. MBAs are not like other Master's degrees where you delve deeper into a specific topic in your field of expertise. It is an overview of a complete organization. Statistics, organizational behavior (a bit of the psychology stuff I mentioned), marketing and sales, consumer behavior, product development, accounting and finance, management, strategy, operations, information technology, business law, negotiations (which is not limited to contracts, convincing others to see your perspective, to persuade them is a negotiation), etc. Basically you leave an MBA program the same as you entered. If you were a scientist before you are still a scientist, an engineer still an engineer,
Roughly 1/3 of my MBA class were scientists and engineers. Less than a quarter accounting and finance people. The classes I took were often very interesting. Personally I was constantly amused at how misinformed I had been. I had the classic engineer's disdain for anything business and marketing, thought marketing was just snake oil and misinformation for example. I was pleasantly su
Yeah - sorry dice - dressing pretty to become a boss just shows how stupid people who want to be bosses are.
And that's why competent people hate them.
Clothing does not reflect ability. I'm quite sure I can code far better naked than someone who thinks spend two or three grand on an Armani overhaul can.
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
Back when programmers were hippies like the Woz, they made great managers.
Today programmers (especially foreigners and to a lesser extent American) are micromanaging manboys, the brains clogged with hubris.
95% of programmers have no place in management.
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.
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
Managing engineers has been unfavorably compared to herding cats, both tasks are all about effective communication and (benevolent) manipulation. Engineers generally don't have these skills unless they have had some other life experiences such as (say) bartending at a busy pub. Having said that, most programmers can recognise a good manager if they are lucky enough to encounter one.
Disclaimer: 56, turned down the boss's job a couple of years ago - been there, done that in my late 30's, learnt a lot but ultimately not worth the aggravation at my age. If you don't have a niche, you won''t get good money at any age, in any industry. People who have a marketable niche know what it is, if you are caught in a dying niche...well...maybe you should have been paying more attention earlier?
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
I think the trouble most geeks have with management is that in the end it is just varying degrees of bullying. Yes, there are visionary people who can lead by inspiring others, but these are extremely rare and most companies have a mild to severe bullying culture in their management. The trouble is that bullying works very well on many people, and is easy for unskilled people to do, so it survives. I think that until you accept this and start learning how to deal with it you will always find management hard.
The key thing to remember is there are roughly three types of bullies:
- Those who only do it only when required. These people are fine and sadly you need to learn how they do this too if you want to be an effective manager. The reality is that sometimes you just have to bully people a bit for their own good. This is totally not PC, but until you have tried to deal 'nicely' with someone difficult and been totally burnt as the problem balloons out of control, you'll probably not understand. A small amount of bullying on certain types of people at the start of a potential problem can save everyone from a big mess.
- Narcissistic bullies. These are in my experience the most common (and all too common). Basically they are almost always reasonably skilled people with a massive inferiority complex in a particular area. This has created a personality defect which manifests itself as a giant ego on the one hand, and an aggressive defence mechanism on the other if they ever feel under threat. They will attempt to destroy you if you trigger the defence mechanism, even if you don't realise you have done so (this catches lots of people out). The key thing to remember with these people is that the narcissistic response is automatic. It is like buying drinks from a vending machine, and they can't control it. Once you figure out how they tick you can manage them by selecting what you want from the vending machine to suit your needs. This sounds nasty and controlling but the reality is that if you try to 'fix' their narcissism with logic you will just end up in a giant fight you don't want to be involved in and from which nobody will win. Figure out their triggers and then work around them, and as soon as you can, avoid working with them at all.
- Sociopathic bullies. Okay these guys are the cream of the bullying crop. Unlike the narcissists who's character flaw is automatic, sociopaths are in many ways super-humans, because they lack humanity. The narcissistic will bully you out of irrational fear (which you can use to your advantage), while the sociopath will calmly bully you because he has meticulously analysed you to figure out how best you can be controlled. The reality is these guys are quite prevalent at the top of the food chain, but are not so common in general, so hopefully you will never have to deal with one. If you do, then your options really are to just ensure that their goals align with yours. You can rationalise with them and if you can both win from a situation then a useful partnership can be struck. But you must never try to challenge these people or they will destroy you. Honestly you cannot beat these people if you have to work with them. Even if you are smarter than they are, they will just drag the conflict down until it is a race to the darkest corners of humanity, because they will know they can go to places your emotions/morality won't allow you. I repeat you cannot beat these people. If you really want to take them on the only way is to have a very good game plan and jump ship to another company where you can attack their goals from the outside.
This all sounds very negative, but remember that there are a lot of great people out there. They want good bosses, but the trouble is that if all the good people who could be their managers shy away because they can't deal with the bullies, then the bullies take over. If you feel you can contribute in management then do it, but just realise it is a jungle with some crazy animals the further up you get. The key to doing well is to put the same sort of effort into understand these people as you would into learning a new framework. Even better find a company with good managers (even if it means a big pay cut) and learn from those people before jumping back into the fire.
Talented engineers may see managing a team as the next step to growing their careers
why waste programming talent? lock them to the keyboard.
now we need to go OSS in diesel cars
Being a manager - a *good* manager - requires just as much training and work and learning as it does to be a good programmer. If you are considering making that move, be prepared to take some courses and read management journals and blogs just like you read programmer stuff today. It's a skill and an art, too.
Also, don't give up programming. Keep your fingers in the pie, give yourself some of the project tasks (make sure they're not critical-path jobs!), keep up with languages and trends. You'll get more respect and support from your team, you'll make better management decisions, and you'll be more effective at communicating the issues with upper management.
In the end, it can be just as rewarding as being a straight programmer, but your rewards will come from seeing your team members achieving great things and knowing that you helped them be great.
of programmers. They reflect a belief that managers know nothing but arrogantly act like they do and that they are the more important than the programmers; while the programmers know they actually do know everything and are truly the most important people in the company.
The reality, of course, lies somewhere in-between. There are bad managers just as there are programmers who never seem togged the message their job is to ship code that works, not spend a lifetime creating their one great masterpiece. Assuming everyone falls into one of those two camps is a recipe for failure; the reality is you are in it together.
One piece of advice I'd give aspiring managers is to make friends with sales. They can help you understand what the company needs to make to be successful as well as broaden your perspective beyond doing a product. You can help them understand what the product can and can't do and that helps them make sales. Managing is as much about building a network so you can anticipate needs and deliver results as it is about shepherding a project to completion.
Also, make sure your team understands the direction and end game for what they are developing. They are in the trenches and can see problems and solutions and offer advice to make the project successful. Recognize their contributions and ensure they get credit when deserved.
I'm a consultant - I convert gibberish into cash-flow.
(At least in the US). The people who get recognized and promoted are the ones who are best at the "interfacing with senior management" part of the job, and are good at presenting PowerPoint slides in front of a roomful of people. I'm not denying that these are nontrivial skills.
But the managers who could actually move the company forward are those who are serious about advancing 1) the company's product and his/her share of the code base, and 2) the technical and management potential of his/her team. And not have a couple of personal favorites who get all the visibility and recognition at the expense of everyone else. It's like being the head coach of a basketball or football team. That's very different from the first skillset.
Then there's a third type, that are combination architect/managers who make all the calls as far as the technical stack is concerned. This may or may work out from the company's perspective, but it usually makes maximum use of only one person's talents, plus one or two trusted subordinates.
The fact that there are (at least) three types makes it challenging to discuss "what makes a good engineering manager"? It's not black and white (no race ref intended). But category #2 - those who think of their roles first and foremost, as analogous to the coach of a sports team - have a chance to be excellent leaders. The other two types, not so much.
Offshore vs. onshore, FT vs. Contractor, all day long like it was actually producing results. That's all any manager I've ever seen do on a daily basis...
In order to be a successful manager of a development or I.T team, you need to have an outstanding track record of making the right decision, foreseeing when other decisions will cause problems down the road, be a good judge of character, and have the ability to work with (or deal with) personalities that normally would drive you crazy. These are things that you can't really accomplish in a few years. Just like auto-dealerships should never promote their best salesman to management, software companies should never promote their best developers to management. Most of them will be miserable anyways. There's a certain type of developer that makes a great manager. But they are few and far between. Also, the few very talented developers make more than their managers do anyways.
Most of us get sucked into management, like a poor Millenium Falcon into the Death Star's tractor beam. More useful would be an article about how to refuse such offers, keep getting raises and offers for programming jobs as we grow older, and so on.
You will get promoted to management, at least to team lead, just by not sucking.
And in my own experience at least, in the healthcare industry, there are plenty of gray-haired technical people. And when I was helping to hire another programmer, I was hoping for a graybeard, not because of agism, but experiencism.
You can't get MBA's pay if you avoid meetings like a techie. You can have the freedom to work on what is interesting to you only when you are an academic working for wages far below prevailing industry wages.
If you have some skill/talent where programming/coding acts as force multiplier, you are set. You can be techie all your life. If your only skill is generic programming, be prepared to ward of the young and unwashed masses gunning for your job, try to move out of the way to management.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
One thing that always bothers me, is why the hell software engineering requires only younger people ? As a software engineer, I always ask this question.
I got my first degree in Architecture, and ended up working for company that makes steel frames blueprints for construction industry (another name - steel detailing), and in fact, company I worked for, was responsible for making blueprints for some of the major buildings in NY - One World Trade Center(Freedom Tower), Hearst Tower, BP Pedestrian Bridge (By Frank Gehry), and a lot of other projects. Later on, I got CS degree and switch profession.
Majority of world renown architects, became well known way past the ripe age - in their 60-70's. Excellent structural engineers I have met were in their 60's. Top Engineers was 70's. Founder of the company was in his 90s and was still capable of working. If I ever needed a good answer, I would talk to older engineer.
In the meeting with other companies and in the company I have worked for, I never meat as single MBA. Never seen management pushing half-ass finished design (unfortunately, all the engineering projects can end up as a disaster) or broken design.
I came to two simple conclusions:
1. If you responsible for people's lives and your project can end up killing innocent people, you most likely will be doing a good engineering job and engineer will be proud of his work.
2. If your work will last 30-60 years (sometimes beyond your death), you will be doing a great engineering job.
(Fortunately) Majority of software are not responsible for Mission Critical Systems that will last for 60 years and will not kill bunch of people.
programmers interested in breaking into management
DON'T DO IT!
Just...don't.
Ten years of podcasts, articles, and fora about how to become and remain an effective ethical manager.
Actionable advice, down to wording and other behaviors, on how to realize that wonderful combination of "relationships" and "results" (both your own and those of your direct reports) which makes well-done management so worthwhile.
I got into it from their first podcast "Solutions to a Stalled Technical Career"
and have used insights from the podcasts for multiple software-development projects over the past ten years.
Highly recommended!
http://www.manager-tools.com/
I would very much like some information from you on this.
I have a B.S in Compy Sci, I worked in programming for several years, then I jumped into the management track.
I have kept up the programming for fun (Write flash games, taught my kids to code, etc.).
My company is doing a "reorganization" and my position is being eliminated (My entire department is). I'm getting severance for years put in, and having my accumulated leave paid out. That covers me for quite a while, my car is paid off and I have less than 5 years left on my mortgage, no other debt and a ton of savings. I was toying with the notion of being self-employed as a programmer (As in, a friend has some actually good ideas for apps that haven't been made yet, I can code them).
How is coding as freelance? How do you do your taxes? Did you set up your company at your house, or a P.O. Box?
Thanks
How does a programmer get into management?
First take everything you know about logic and reason, and flush it down the toilet.
Next start doing things a manager does. Like posting vague opinions on bug updates and reminding people of schedules. Your boss's boss will eventually notice this and you'll have a nice little chat about the splendor of being a manager.
It helps if you're a white male, but that isn't absolutely necessary anymore.
His name was Lew Platt. This happened because Bill Hewlett and David Packard were in some ways naive persons. Like Jelzin as a naive person. Like Gorbachev who believed all the rose-tainted propaganda from the west.
Packard apparently bought the MBA school bullshit rope and sinker. "Good managers can manage anything" and so on.
Here is the truth: Companies like HP and countries like Russia need to be run by real men, real engineers, real officers. Like Putin, Jobs or Ellison.
The MBA guy Platt killed himself on the job by means of chain-smoking. Running HP was simply above ANY MBA's skills.
All the kids of Hewlett and Packard were raised under some pinko-liberal-new-age-california-crap memes. None sweated time in the R&D labs and on the shop floor like their fathers. Little wonder they are clueless, too.
Compare that to Putin, he was on the front in Dresden and knew all the statecraft bullshit first-hand.
Unfortunately this most likely won't get seen because the news feed has moved on, but here goes...
The pressure in most companies is for more experienced workers to move into management. However, think about the last awful boss you had. Unless they were an MBA (the corporate equivalent of a commissioned officer, who didn't actually do the job before and was just appointed fresh out of business school,) that person most likely was an individual contributor. People who are great workers often get promoted, and that's where the problem begins for a lot of them.
The skills that make a successful tech worker absolutely do not translate to management. It's a completely different job. You go from making machines and code do what you want to politics and constantly begging people to do things. This is similar to project management - it also boggles my mind why a techie would want to be a project manager. There, you get secretary duty that also involves all the politics and begging with no authority. Unfortunately, most large companies' HR frameworks aren't set up to reward techies with a career progression that doesn't involve management. I work in one that does, but you are still expected to have some supervisory duties as you get further up the chain.
I currently have a "senior lead" position in a very small team, and I have made it very clear to my boss that I have no desire to go any further into management. Corporate politics is toxic, and personally for me it is a very hard shift from doing my best and getting my own work done to being judged by the quality of others' work. People are not predictable, and any attempts to control their actions will brand you for life as the "evil boss." And to dispel one myth, yes, there are horrible bosses who do nothing, but that person who sits around all day and does meetings instead of work is usually shielding you from everyone else's crap so you can get work done...at least that's how I work, and I have to do part of our team's work in addition.
Personally, I'd recommend making yourself as technically valuable a possible, getting a huge broad skill set, and becoming a consultant if you have no desire to work with people. You'll save a lot of people headaches who would have to work with you as a manager. If you hate your job, it will translate over to your personal life and you will end up miserable even if you make slightly more than a regular worker.
#1: Be a shitty and incompetent programmer.
Technical skill and seniority does not translate into managerial aptitude. In fact, the better you are at your technical role right now, the worse off you will be as a manager. And it gets worse: If you are an awesome hacker, chances are you will not only suck at management, but you will also hate it with a passion.
Some of the core challenges:
The zone: Banned for life.
As a developer, you need long, undisturbed periods of time in order to concentrate on the problem at hand. Your best, most productive time is when you are in 'the zone'. Management time, by contrast, is highly fragmented, allowing little unbroken, focused time.
Feedback loops: Error 504, forever.
Seeking out short feedback loops is instinctive for developers. It is fundamental to our productivity and helps keep us in the zone. Management feedback, by contrast, is biased towards very long-running, indirect and actually most often, non-existant.
Communication: Nobody will understand a word you say.
Every time you have to communicateas a software developer, there is a standard which serves to strip away subjectivity, reduce the signal to noise ratio and improve the consistency and quality of the shared understanding of that information. UML, use cases, flow charts, DFDs, ER diagrams - even code itself. These are the standard tools of trade for a developer and we like the certainty they provide. Managers on the other hand have to deal with nuance, audience awareness, bias, sensitivities, personal context, etc etc etc - all the things that developers try to remove from their communication.
Decisions: Striving for average.
One of the most challenging aspects of moving from software development into management is that it involves a fundamental, religious shift in your personal values and motivation - from objectivity to subjectivity. One example of this is that as software developers, we strive constantly towards a commonly defined and accepted 'best' possible solution. In management, there is no such thing. By virtue of the fact that you're dealing with a group of people, you will always get a diverse set of responses to any decision you make. And the kicker is that if everyone likes a decision you've made, it's probably a mistake.
You can move to management.
But you've to leave your conscience behind;
I currently have the luck of having a pretty good manager. I've been trying to pin down why he's so good and I've figured it's probably one of the following:
- He knows what we do. Anything we do, he can do, albeit a bit slower. The man knows the field and can make good estimations and can actually help us achieving our tasks from a technical standpoint. He's our technical lead as well as our manager. That doesn't mean he knows all the nitty-gritty details, but he's aware of all the higher-level issues.
- He understand office politics and how to shield us from it.
- We're loyal. He wants our department to build, improve and help the company grow. We want the same. Somehow he has co-opted that impulse to achieve and add to the world into a common direction.
- He has a goal/strategy beyond merely keeping stuff running and delivering. Growth and improvement are expected on a personal and professional level.
And he's one of the 'true' ICT people. At my (Compsci) education there were those that simply had an education and moved on. A select set, however, would build servers, mainframes, software, webservices and installations in their free time because it was just fun. He's one of that last group. The man loves technology even though his education was communication and business.
So, eh, in short:
- Love tech
- Can think beyond tech and understands humans/communication/company goals/department goals and how these interact.
- Be considered capable by those you (want to) manage.
- Can align goals of a diverse set of people.