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.
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
programmers interested in breaking into management
DON'T DO IT!
Just...don't.
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
Wow. There are a few questions there. Let me see if I can answer a couple without going off tangent.
Coding as a freelancer has been pretty good. I get to work on interesting problems. I get to choose who I want to work with. I get to learn and grow as a developer and at a personal by engaging with people in different countries, different backgrounds.
My accountant looks after my taxes. It's not complicated, money comes on, money goes out. But he's the expert and I don't want to fuck things up. It's something I learned when I was managing. A book that I dug at the time was James Persse's "Hollywood Secrets of Project Management Success", which basically asks the question: what can project managers learn from the Hollywood system that manages to churn out film after film, year after year, generally on time and on budget. Seriously, they do. Not all of them make a return on investment, but the real shockers we hear about - where some "star" gets his/her own way and ruins a studio with a runaway pet project - are way off the norm. The vast majority of Hollywood films are delivered on budget, yet they have the same mix of technical and creative activities as IT project - and have to respond to change in an agile manner.
My takeaway is that Hollywood has been doing all this for over a century and have figured out that you basically need to (a) manage risk and (b) have the right people doing the right job. Two things we are spectacularly bad at doing in the IT. Ah, and there I go off tangent.
My point is, I let people who know what they are doing worry about the tax, the company structure, etc. I just do what I love, which is coding. Do a good job, opportunities seem to arise - though I'm sure there's more to it.
Yes, I work from home - if that's what you are asking. Don't have any use for a PO Box. Everything happens on the internet anyway.
You seem superbly set up to give working as a freelancer a go. I don't have the luxury of a small mortgage, which can be a stress when you're waiting for invoices to be paid and such. But is it what you want to do? You have an opportunity here. Maybe use it to figure out what you really want to be doing with your time on Earth.
This may be terrible advice, but maybe just hunt down what makes you happy. Wish I did earlier, instead of following a career train I thought was what you were meant to do as a "grown up" - and missed out on too much watching my own kids growing up.
Sounds like you got it sorted. Your heart has probably already made the choices you'll use your head to justify. Good luck.
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.
Packard apparently bought the MBA school bullshit rope and sinker. "Good managers can manage anything" and so on.
Maybe MBA schools taught that in the 1950s but in recent decades nothing could be farther from the truth. For recent decades MBA students have been taught that managers must have a technical understanding of the area they work in, that CEOs and other execs must have a technical understanding of their industry and profits.
Again, MBA programs are not what many engineers believe they are.
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;