5 ms·

Perhaps I like being a coder/doer too much, but there's an assumption that the ideal to strive for is to move up the chain into management as quickly as possibl

Perhaps I like being a coder/doer too much, but there's an assumption that the ideal to strive for is to move up the chain into management as quickly as possible. What fun is that?

gaius 17y ago
It's an insidious problem, because ultimately in most organizations hiring decisions are made by people who do believe that (i.e. they control the budget), and believe that doing so counts as "success". Which is why you can be a 40-something with 20 years experience as a hands-on programmer and can't get hired, because you are viewed by these people as a "failure" for not having made it into management in your 20s.
- BigZaphod 17y ago
  Sometimes I dread getting older for political reasons... I'm 30 now and have not had (or wanted) a "real" management position. I guess I'm doomed.
  - gaius 17y ago
    Staying hands-on is pretty difficult in other industries. A good friend of mine is a research scientist. She loves what she does and is good at it and wants to go on doing it. But now she as been offered two choices, she can go for a Fellowship and spend her time writing grant proposals and mentoring students or... Well, no-one really talks about option B. And no-one who's taken option B is around the lab to ask. Same in banking, you might be able to stay a trader, if you're good. You couldn't stay an analyst, it's up or out. Or in engineering, you don't get to actually design machinery or chips or whatever for long, again, up or out, gotta make room for the fresh intake of graduates. This might not be the best way to work, but it's the norm, and a programmer who really can stay hands-on their whole career is fortunate indeed. My own strategy in this area is to stay hands-on but do less work directly, spend my time automating common tasks and developing tools to make junior members of my team more productive. We'll have to see how that plays out...
    - blackguardx 17y ago
      Most of the top people in electrical engineering at any company will be in their 50s. These aren't managers, these are very senior engineers who design from a system level. It is hard to become a system architect without many years of experience under your belt.
  - Kadin 17y ago
    At least in software, I don't think this is nearly as much a problem as in other industries. I know a lot of very good developers who are in their 30s and 40s (not too many who are in their 50s, although I'm sure they exist and there will be more in the near future!) and have no desire to stop coding and become management. In some cases it's a very conscious lifestyle choice: you can maintain much more flexible hours and even do telework if you are writing code, while someone in a management role has to be physically present more often. The idea that everyone should move into management is poisonous, both to developers who want to remain developers and feel pushed, and to management, which gets filled with people who don't really want to be there. Some of the better places I've worked have recognized that some people want to get into project or staff management, and other people would prefer to perfect their craft and work independently. They link salary not to progress along a "ladder," but to actual value to the organization -- which often leads to developers who are making more than their project managers. This strikes me as totally appropriate, and it surprises me sometimes that not all companies are like this. A company that pushes its best developers into management positions they're not thrilled about (either through 'career planning' or by making that the only way to get raises) is shooting itself in the foot in the long run.
    - gvb 17y ago
      John Dugan put it well, in a sad sort of way. http://coroutine.com/blog/3-The-Promotion-Problem http://coroutine.com/blog/3-The-Promotion-Problem "Traditionally, programmers are offered two career paths. They can become managers (a CTO track) or senior programmers (an architect track). The problem is both tracks terminate in roles that many programmers don't want. One path leads to pure management, the other to systems design work. Where do programmers who actually want to program go? "Elsewhere."
      - deleted 17y ago
        [deleted]
- alanthonyc 17y ago
  I think it's even more than just an institutional bias, but a byproduct of the typical corporate organization structure. I worked for a company who specifically made it clear that "rising up in the ranks" was not the only way to progress. People could stay out of the managerial ranks and theoretically still advance. However, this is not how it worked out in practice. The sense that managers were somehow better than the non-managers still pervaded. I think it's a result of it being the managers' job to tell non-managers what to do, schedule their time, etc. Managers, by definition, exert control over the time and lives of non-managers. I think this affects the interpersonal relationships between the groups. It might also have been affected by the perception that people outside the organization had. Managers have titles that confer on them a leadership position, so outsiders automatically gravitate to them as persons in charge. Perhaps it was a failure in execution by our organization to control expectations of our clients and customers, but I don't think so.
- cturner 17y ago
  I don't think the problem exists as you describe it. If you're a 50 year old programmer, and go to interview with the same enthusiasm for discussing the projects you're working on and your problem-solving approaches as someone twenty five years younger than you, I expect you'll get the job on the basis of your experience. You may get asked, "so you never thought about management?". But you can rehearse a response to that. It's like the one about when you've been in a difficult situation. Example, "In a way I was managing" - you worked on this project, planned it this way, made these decisions. Or you could describe aspects you liked about the pace or type of work you were doing. Talk about the problems that would have been easier if you had been leading strategy, and about the mechanisms you instead had to use to influence strategy, and the reason why the tradeoff worked for you better than if you'd been managing. Use the question as an opportunity to highlight particular technical skills that you brought to the team and mention the rule of comparative advantage. A great thing about IT is that the tools are so cheap now that anyone who wants to prove themselves can run a home project at virtually no cost to demonstrate their strengths.
  - gaius 17y ago
    If you get far enough in the interview process. You might not even make it past HR's "overqualified" screen (that's what that means, has been technical for too long). And then even if the hands-on programmers think you're great, the young hotshot manager might not be comfortable managing someone old enough to be his father, who has likely seen it all before. This is called "not a cultural fit". Ageism in IT is very real. This is just one of the mechanisms by which it operates. The other side is the (youngest) programmers who haven't yet grown out of language fanboyism and dismiss your experience of last year's technology as irrelevant. Fortunately they're rarely in positions of hiring authority. The IT industry takes about 10 years to cycle through fads. Someone I consider experienced has been through at least one cycle. I want people who can say XML? Oh yes, well I've never used XML but in the 90s I was doing EDI... (insert tech of choice)
    - sabat 17y ago
      I suppose you could be identified as "overqualified" if you don't limit entries on your resume. Actually asking for an age or birthdate is illegal in the U.S. At my previous company, where I began in the startup stage, we had lots of people older than 40 and 50 in IT. We had a QA guy who had to be at least 60. I suppose it all depends on the company (and probably the geographic subculture) but this "ageism" stuff is out of my experience -- I'll hire someone who knows what he's doing and is motivated to do it, period. Stupid shit like "but he has a wrinkle" is moot.
dabent 17y ago
I think it also leads to people rising to their level of incompetence. You might be a brilliant coder, but really not be good at handling a managerial post at all. Heads-down coding and management are two very different things, yet one is often treated as a reward for doing the other well.
nostrademons 17y ago
Here's one way of putting it that HN readers may identify with more: Treat every job as if it were your own startup. If you're the founder of a company, you need to understand every nuance of the business, how it fits into its market niche, and the technology it uses. You have to convince other people to work for you; you have no implicit authority based on your title. Your effectiveness is based on how well you understand your mission as a company, and how well you can enable and motivate others to help you with that mission. Those are all crucial skills in the corporate world as well. They're also not necessarily mutually exclusive with being a coder/doer as well. All of the best managers I know come from a software engineering background. But it's about recognizing that other people can code & do just as well as you can, and leveraging what they're good at to help you and your organization achieve goals that neither one of you could do on your own.
- fake_pg 17y ago
  Treat every job as if it were your own startup. This statement is dangerous, especially for those just starting their careers. Clearly, employees are bound to perform their duties as defined in their employment contracts. That's all. Employees should not have the mentality that they need to work plus sixty hours a week because you have to "treat every job as if it were your own startup." At my first programming job, I, along with many others, fell into this fallacy. Briefly, we were constantly fed this bull -- the more your worked, the more you were valued. (But it didn't matter if you had the skills to actually complete your tasks as long as you billed as much as possible.) This type of propaganda is great for employers, but not so much for employees.
zupatol 17y ago
It's generally a good attitude to try to see what problems need to be solved instead of just doing your best at what you're told to do. If you identify problems and suggest solutions, you will have more influence on the content of your job regardless if you want to move up the hierarchy or code cool applications. And if you get to implement a solution that you suggested, it will be much more fun than realizing other people's ideas. Being in a job makes it relatively easy to see processes which always need some improvement. I wish it would be as easy to see how to improve things on the level of the society or the country. I can see many things that are wrong, but I have no idea how to fix anything.
- gvb 17y ago
  "and suggest solutions" - that is key. There are plenty of people that bitch about problems, but precious few that can also propose solutions to alleviate the pain.
SandB0x 17y ago
A touch off topic: For people in a management role: what do you use to demonstrate that you're good at your job? If you're interviewing for another company, is it a steady record of promotion? Successful projects (but is that due to you or a good team)? If you're a coder and your job sucks you can at least build something to show at interviews or learn new languages on the side, but how can you do the same in management?
- paulbaumgart 17y ago
  The "former executive of a large famous company in the computer industry" made some interesting points about it: http://www.reddit.com/r/IAmA/comments/9t05i/i_am_a_former_executive_of_a_large_famous_company/c0eb6h1 http://www.reddit.com/r/IAmA/comments/9t05i/i_am_a_former_ex... (HN discussion here: http://news.ycombinator.com/item?id=875714 http://news.ycombinator.com/item?id=875714 )
- cturner 17y ago
  Do something to coordinate a voluntary organisation. Fundraise for your local dog protection society, and then when it's discussed at interview smile in a way that communicates you know it's a bit trivial, but show how you thought about the problem and how you were enthusiastic for the process of solving the problem.
- tobtoh 17y ago
  There are a number of ways to demonstrate 'success' as a manager. There are the 'hard numbers' - such as meeting your financial targets/cost figures, SLAs/performance targets, customer sat ratings, employee survey results/manager feedback results etc. Then there are the harder to quantify results but which mainly revolve in being able to explain how you achieved (or attempted to achieve) the hard numbers. A lot about being a good manager is seeing what needs to be improved and then actually making that improvement happen. It sounds pretty basic - but you will find most people do their job that they are hired to do and not much else. Many people know what is wrong with their area/company, are happy to complain about it, but won't go and work out how to fix the problem, and then put in the hard yards to make that happen. Alternatively, many people confuse putting in long hours with 'making a difference'. A good manager should be able to identify and implement fundamental changes to how the business operates that makes it 'better' (happier staff, more productive, great profit/revenue etc, less overhead/red tape). Being able to explain what you identified and implemented these changes is how I demonstrate how good (or not) of a job I'm doing.
edw519 17y ago
there's an assumption that the ideal to strive for is to move up the chain into management as quickly as possible This may have been true at one time, but not so much anymore, especially in IT. I prefer Michael Gerber's (of EMyth fame) description: there are three types of roles in a business, the entrepreneur, the manager, and the technician. If you run your own business, you better be all 3. But if you work for someone else, you can choose your path. Choosing the technician path is perfectly acceptable, and often preferable to the manager path. You get to focus on the critical path, do what you do best, and in many cases, earn more than your boss. Many programmers I know that made the switch to management are sorry they did; they miss the cool work and hate the meetings and bullshit. I made the switch back to technician. No one has ever questioned why.
halostatue 17y ago
I just got a promotion where I work; it's not the position that I really want (and management knows my goal), but it's the position that the organisation needs. I got this primarily because I stepped up and took ownership of a project when it needed to be done. I've made mistakes, I'll make more mistakes, but I'm not trying to be on the management track. However, it is important enough to me that I be involved in the decisions being made that this promotion is a good thing. What decisions? 1. How to arrange the office (we were able to partially remove the cubicles to give my team a much more open area to work with). 2. What we're working on and the technical direction that we should take in doing so (I am negotiating features and scope directly with our product managers). 3. When and how to recognise my team for hard work (small recognition; I have no direct control over pay raises). There's more, but it's really important to me that the people that I work with get the respect they deserve, and it's now officially my job to make sure that they get it. If they've got good ideas, I want to hear them so that I can be their advocate for those good ideas. Even though I've written very little code over the last year, I'm still developing software. I just have other people who write most of the code.

Perhaps I like being a coder/doer too much, but there's an assumption that the ideal to strive for is to move up the chain into management as quickly as possible. What fun is that?

gaius 17y ago

It's an insidious problem, because ultimately in most organizations hiring decisions are made by people who do believe that (i.e. they control the budget), and believe that doing so counts as "success". Which is why you can be a 40-something with 20 years experience as a hands-on programmer and can't get hired, because you are viewed by these people as a "failure" for not having made it into management in your 20s.

BigZaphod 17y ago
Sometimes I dread getting older for political reasons... I'm 30 now and have not had (or wanted) a "real" management position. I guess I'm doomed.
- gaius 17y ago
  Staying hands-on is pretty difficult in other industries. A good friend of mine is a research scientist. She loves what she does and is good at it and wants to go on doing it. But now she as been offered two choices, she can go for a Fellowship and spend her time writing grant proposals and mentoring students or... Well, no-one really talks about option B. And no-one who's taken option B is around the lab to ask. Same in banking, you might be able to stay a trader, if you're good. You couldn't stay an analyst, it's up or out. Or in engineering, you don't get to actually design machinery or chips or whatever for long, again, up or out, gotta make room for the fresh intake of graduates. This might not be the best way to work, but it's the norm, and a programmer who really can stay hands-on their whole career is fortunate indeed. My own strategy in this area is to stay hands-on but do less work directly, spend my time automating common tasks and developing tools to make junior members of my team more productive. We'll have to see how that plays out...
  - blackguardx 17y ago
    Most of the top people in electrical engineering at any company will be in their 50s. These aren't managers, these are very senior engineers who design from a system level. It is hard to become a system architect without many years of experience under your belt.
- Kadin 17y ago
  At least in software, I don't think this is nearly as much a problem as in other industries. I know a lot of very good developers who are in their 30s and 40s (not too many who are in their 50s, although I'm sure they exist and there will be more in the near future!) and have no desire to stop coding and become management. In some cases it's a very conscious lifestyle choice: you can maintain much more flexible hours and even do telework if you are writing code, while someone in a management role has to be physically present more often. The idea that everyone should move into management is poisonous, both to developers who want to remain developers and feel pushed, and to management, which gets filled with people who don't really want to be there. Some of the better places I've worked have recognized that some people want to get into project or staff management, and other people would prefer to perfect their craft and work independently. They link salary not to progress along a "ladder," but to actual value to the organization -- which often leads to developers who are making more than their project managers. This strikes me as totally appropriate, and it surprises me sometimes that not all companies are like this. A company that pushes its best developers into management positions they're not thrilled about (either through 'career planning' or by making that the only way to get raises) is shooting itself in the foot in the long run.
  - gvb 17y ago
    John Dugan put it well, in a sad sort of way. http://coroutine.com/blog/3-The-Promotion-Problem http://coroutine.com/blog/3-The-Promotion-Problem "Traditionally, programmers are offered two career paths. They can become managers (a CTO track) or senior programmers (an architect track). The problem is both tracks terminate in roles that many programmers don't want. One path leads to pure management, the other to systems design work. Where do programmers who actually want to program go? "Elsewhere."
    - deleted 17y ago
      [deleted]
alanthonyc 17y ago
I think it's even more than just an institutional bias, but a byproduct of the typical corporate organization structure. I worked for a company who specifically made it clear that "rising up in the ranks" was not the only way to progress. People could stay out of the managerial ranks and theoretically still advance. However, this is not how it worked out in practice. The sense that managers were somehow better than the non-managers still pervaded. I think it's a result of it being the managers' job to tell non-managers what to do, schedule their time, etc. Managers, by definition, exert control over the time and lives of non-managers. I think this affects the interpersonal relationships between the groups. It might also have been affected by the perception that people outside the organization had. Managers have titles that confer on them a leadership position, so outsiders automatically gravitate to them as persons in charge. Perhaps it was a failure in execution by our organization to control expectations of our clients and customers, but I don't think so.
cturner 17y ago
I don't think the problem exists as you describe it. If you're a 50 year old programmer, and go to interview with the same enthusiasm for discussing the projects you're working on and your problem-solving approaches as someone twenty five years younger than you, I expect you'll get the job on the basis of your experience. You may get asked, "so you never thought about management?". But you can rehearse a response to that. It's like the one about when you've been in a difficult situation. Example, "In a way I was managing" - you worked on this project, planned it this way, made these decisions. Or you could describe aspects you liked about the pace or type of work you were doing. Talk about the problems that would have been easier if you had been leading strategy, and about the mechanisms you instead had to use to influence strategy, and the reason why the tradeoff worked for you better than if you'd been managing. Use the question as an opportunity to highlight particular technical skills that you brought to the team and mention the rule of comparative advantage. A great thing about IT is that the tools are so cheap now that anyone who wants to prove themselves can run a home project at virtually no cost to demonstrate their strengths.
- gaius 17y ago
  If you get far enough in the interview process. You might not even make it past HR's "overqualified" screen (that's what that means, has been technical for too long). And then even if the hands-on programmers think you're great, the young hotshot manager might not be comfortable managing someone old enough to be his father, who has likely seen it all before. This is called "not a cultural fit". Ageism in IT is very real. This is just one of the mechanisms by which it operates. The other side is the (youngest) programmers who haven't yet grown out of language fanboyism and dismiss your experience of last year's technology as irrelevant. Fortunately they're rarely in positions of hiring authority. The IT industry takes about 10 years to cycle through fads. Someone I consider experienced has been through at least one cycle. I want people who can say XML? Oh yes, well I've never used XML but in the 90s I was doing EDI... (insert tech of choice)
  - sabat 17y ago
    I suppose you could be identified as "overqualified" if you don't limit entries on your resume. Actually asking for an age or birthdate is illegal in the U.S. At my previous company, where I began in the startup stage, we had lots of people older than 40 and 50 in IT. We had a QA guy who had to be at least 60. I suppose it all depends on the company (and probably the geographic subculture) but this "ageism" stuff is out of my experience -- I'll hire someone who knows what he's doing and is motivated to do it, period. Stupid shit like "but he has a wrinkle" is moot.

dabent 17y ago

I think it also leads to people rising to their level of incompetence. You might be a brilliant coder, but really not be good at handling a managerial post at all. Heads-down coding and management are two very different things, yet one is often treated as a reward for doing the other well.

nostrademons 17y ago

Here's one way of putting it that HN readers may identify with more: Treat every job as if it were your own startup. If you're the founder of a company, you need to understand every nuance of the business, how it fits into its market niche, and the technology it uses. You have to convince other people to work for you; you have no implicit authority based on your title. Your effectiveness is based on how well you understand your mission as a company, and how well you can enable and motivate others to help you with that mission. Those are all crucial skills in the corporate world as well. They're also not necessarily mutually exclusive with being a coder/doer as well. All of the best managers I know come from a software engineering background. But it's about recognizing that other people can code & do just as well as you can, and leveraging what they're good at to help you and your organization achieve goals that neither one of you could do on your own.

fake_pg 17y ago
Treat every job as if it were your own startup. This statement is dangerous, especially for those just starting their careers. Clearly, employees are bound to perform their duties as defined in their employment contracts. That's all. Employees should not have the mentality that they need to work plus sixty hours a week because you have to "treat every job as if it were your own startup." At my first programming job, I, along with many others, fell into this fallacy. Briefly, we were constantly fed this bull -- the more your worked, the more you were valued. (But it didn't matter if you had the skills to actually complete your tasks as long as you billed as much as possible.) This type of propaganda is great for employers, but not so much for employees.

zupatol 17y ago

It's generally a good attitude to try to see what problems need to be solved instead of just doing your best at what you're told to do. If you identify problems and suggest solutions, you will have more influence on the content of your job regardless if you want to move up the hierarchy or code cool applications. And if you get to implement a solution that you suggested, it will be much more fun than realizing other people's ideas. Being in a job makes it relatively easy to see processes which always need some improvement. I wish it would be as easy to see how to improve things on the level of the society or the country. I can see many things that are wrong, but I have no idea how to fix anything.

gvb 17y ago
"and suggest solutions" - that is key. There are plenty of people that bitch about problems, but precious few that can also propose solutions to alleviate the pain.

SandB0x 17y ago

A touch off topic: For people in a management role: what do you use to demonstrate that you're good at your job? If you're interviewing for another company, is it a steady record of promotion? Successful projects (but is that due to you or a good team)? If you're a coder and your job sucks you can at least build something to show at interviews or learn new languages on the side, but how can you do the same in management?

paulbaumgart 17y ago
The "former executive of a large famous company in the computer industry" made some interesting points about it: http://www.reddit.com/r/IAmA/comments/9t05i/i_am_a_former_executive_of_a_large_famous_company/c0eb6h1 http://www.reddit.com/r/IAmA/comments/9t05i/i_am_a_former_ex... (HN discussion here: http://news.ycombinator.com/item?id=875714 http://news.ycombinator.com/item?id=875714 )
cturner 17y ago
Do something to coordinate a voluntary organisation. Fundraise for your local dog protection society, and then when it's discussed at interview smile in a way that communicates you know it's a bit trivial, but show how you thought about the problem and how you were enthusiastic for the process of solving the problem.
tobtoh 17y ago
There are a number of ways to demonstrate 'success' as a manager. There are the 'hard numbers' - such as meeting your financial targets/cost figures, SLAs/performance targets, customer sat ratings, employee survey results/manager feedback results etc. Then there are the harder to quantify results but which mainly revolve in being able to explain how you achieved (or attempted to achieve) the hard numbers. A lot about being a good manager is seeing what needs to be improved and then actually making that improvement happen. It sounds pretty basic - but you will find most people do their job that they are hired to do and not much else. Many people know what is wrong with their area/company, are happy to complain about it, but won't go and work out how to fix the problem, and then put in the hard yards to make that happen. Alternatively, many people confuse putting in long hours with 'making a difference'. A good manager should be able to identify and implement fundamental changes to how the business operates that makes it 'better' (happier staff, more productive, great profit/revenue etc, less overhead/red tape). Being able to explain what you identified and implemented these changes is how I demonstrate how good (or not) of a job I'm doing.

edw519 17y ago

there's an assumption that the ideal to strive for is to move up the chain into management as quickly as possible This may have been true at one time, but not so much anymore, especially in IT. I prefer Michael Gerber's (of EMyth fame) description: there are three types of roles in a business, the entrepreneur, the manager, and the technician. If you run your own business, you better be all 3. But if you work for someone else, you can choose your path. Choosing the technician path is perfectly acceptable, and often preferable to the manager path. You get to focus on the critical path, do what you do best, and in many cases, earn more than your boss. Many programmers I know that made the switch to management are sorry they did; they miss the cool work and hate the meetings and bullshit. I made the switch back to technician. No one has ever questioned why.

halostatue 17y ago

I just got a promotion where I work; it's not the position that I really want (and management knows my goal), but it's the position that the organisation needs. I got this primarily because I stepped up and took ownership of a project when it needed to be done. I've made mistakes, I'll make more mistakes, but I'm not trying to be on the management track. However, it is important enough to me that I be involved in the decisions being made that this promotion is a good thing. What decisions? 1. How to arrange the office (we were able to partially remove the cubicles to give my team a much more open area to work with). 2. What we're working on and the technical direction that we should take in doing so (I am negotiating features and scope directly with our product managers). 3. When and how to recognise my team for hard work (small recognition; I have no direct control over pay raises). There's more, but it's really important to me that the people that I work with get the respect they deserve, and it's now officially my job to make sure that they get it. If they've got good ideas, I want to hear them so that I can be their advocate for those good ideas. Even though I've written very little code over the last year, I'm still developing software. I just have other people who write most of the code.