Why business analysts and project managers get higher salaries than programmers?(programmers.stackexchange.com)
programmers.stackexchange.com
Why business analysts and project managers get higher salaries than programmers?
http://programmers.stackexchange.com/questions/45776/why-do-business-analysts-and-project-managers-get-higher-salaries-than-programmer/45814#45814
Whether project managers get higher salaries than programmers and business analysts at all exist as a class depends squarely on the software world you live in.
70 comments
Because programmers don't ask for more money often enough.
Seriously.
Here's the three minute version of doing it:
1. Work hard on tangible stuff, document and claim credit for doing it, and notify people with what benefit the work provides. This sounds maybe stupidly obvious, but a lot of non-technical people don't understand the value in something. So, "Upgraded XYZ so our website loads faster, which is proven to make customers more likely to buy according to ZYX paper" - I know, what a waste of time, right? Wrong! It's going to make you a lot of money. Tell people what you did.
2. Before you go to ask for more money, prepare a BATNA (Best Alternative to Negotiated Agreement) - if they say no, what will you do? You need to know this. Having other offers is obviously good. Savings are good. You don't even have to mention your BATNA, but you need a Plan B. Most people don't make one of these, so if their first attempt doesn't go swimmingly, they're in trouble.
3. Go in and stress how much more you'd like to do going forwards. This is huge. Do not mention what you've done in the past, except in the context of how it proves how much more you can do going forwards. So go in and say, "Hi boss, as I mentioned in all my various weekly reports, I've been learning new stuff and kicking massive ass. [that was step one] Recently I've picked up some new skills, and I've been getting recruited for a bunch of projects [step 2], but I really like working here. Actually, I think I can deliver even more value here, if I take on new responsibilities. I'd like to train a successor to gradually take over my current role, while I do ABC-stimulating-enjoyable-task that will bring the business new money. I don't even want to be compensated much more for it - I'm going to be bringing in lots more value/assets/sales/cash/whatever, but a moderately small raise is enough for me because I like working here so much." Then lay out what you're asking for.
Business people learn how to do this. You're leaving lots of money on the table and not getting a chance to work on cooler stuff that you'd like to do if you don't do this.
1. Regularly update with the work you completed, and the benefit it provides.
2. Decide what you want, and what you'll do as Plan B if your current company won't give it to you.
3. Go stress that you'd be able to produce more value if you transition your role to a more highly paid and enjoyable one. Be friendly and complimentary. Whenever possible, try not to ask for more money for the same role from the same company - people hate price increases, so it's better to expand your role to something that's also more enjoyable and produces more in their eyes. If you want a raise for doing the same exact work, it's probably good to start looking outside the current company as well for other offers.
Seriously.
Here's the three minute version of doing it:
1. Work hard on tangible stuff, document and claim credit for doing it, and notify people with what benefit the work provides. This sounds maybe stupidly obvious, but a lot of non-technical people don't understand the value in something. So, "Upgraded XYZ so our website loads faster, which is proven to make customers more likely to buy according to ZYX paper" - I know, what a waste of time, right? Wrong! It's going to make you a lot of money. Tell people what you did.
2. Before you go to ask for more money, prepare a BATNA (Best Alternative to Negotiated Agreement) - if they say no, what will you do? You need to know this. Having other offers is obviously good. Savings are good. You don't even have to mention your BATNA, but you need a Plan B. Most people don't make one of these, so if their first attempt doesn't go swimmingly, they're in trouble.
3. Go in and stress how much more you'd like to do going forwards. This is huge. Do not mention what you've done in the past, except in the context of how it proves how much more you can do going forwards. So go in and say, "Hi boss, as I mentioned in all my various weekly reports, I've been learning new stuff and kicking massive ass. [that was step one] Recently I've picked up some new skills, and I've been getting recruited for a bunch of projects [step 2], but I really like working here. Actually, I think I can deliver even more value here, if I take on new responsibilities. I'd like to train a successor to gradually take over my current role, while I do ABC-stimulating-enjoyable-task that will bring the business new money. I don't even want to be compensated much more for it - I'm going to be bringing in lots more value/assets/sales/cash/whatever, but a moderately small raise is enough for me because I like working here so much." Then lay out what you're asking for.
Business people learn how to do this. You're leaving lots of money on the table and not getting a chance to work on cooler stuff that you'd like to do if you don't do this.
1. Regularly update with the work you completed, and the benefit it provides.
2. Decide what you want, and what you'll do as Plan B if your current company won't give it to you.
3. Go stress that you'd be able to produce more value if you transition your role to a more highly paid and enjoyable one. Be friendly and complimentary. Whenever possible, try not to ask for more money for the same role from the same company - people hate price increases, so it's better to expand your role to something that's also more enjoyable and produces more in their eyes. If you want a raise for doing the same exact work, it's probably good to start looking outside the current company as well for other offers.
I find that in practice, it's a lot easier to do steps 1 and 2, then simply take one of those offers to work someplace else. Your value as a developer increases so fast early in your career that you'll literally double your market rate during the course of your first job after college.
There's simply no way that you can convey to a company that they need to pay you twice as much as they did when they hired you 3 years ago. They simply won't believe it. Sadly, the only way is to demonstrate it for them by actually accepting a job somewhere else for twice the money.
The key is to remember that you're in this game for yourself first. It's nice to work for a good company with a good environment and a fun team, but at the end of the day it's not worth leaving tens of thousands of dollars on the table just to stay there.
There's simply no way that you can convey to a company that they need to pay you twice as much as they did when they hired you 3 years ago. They simply won't believe it. Sadly, the only way is to demonstrate it for them by actually accepting a job somewhere else for twice the money.
The key is to remember that you're in this game for yourself first. It's nice to work for a good company with a good environment and a fun team, but at the end of the day it's not worth leaving tens of thousands of dollars on the table just to stay there.
It's widely held that the best programmers are orders of magnitude better than the worst ones. [1] This also goes for you x years ago versus you now. Why this isn't reflected in pay everywhere is beyond me. While people exploit these inefficiencies (exhibit A:startups) I'm surprised that the market still allows things like this to exist. Perhaps it's because there isn't such a large disparity for the vast majority of other professions?
[1] http://www.paulgraham.com/gh.html
[1] http://www.paulgraham.com/gh.html
No, it's more likely the idea of "you don't get rich by writing checks" at work.
I think most programmers dislike the idea of what they see as kissing their boss's ass so much, that they'd rather start their own startup to get what they want (more interesting work, potentially higher pay, more amenable working conditions, etc). I can't say I blame them.
I think most programmers dislike the idea of what they see as kissing their boss's ass so much, that they'd rather start their own startup to get what they want (more interesting work, potentially higher pay, more amenable working conditions, etc). I can't say I blame them.
"There's simply no way that you can convey to a company that they need to pay you twice as much as they did when they hired you 3 years ago."
You can at smart small companies. My salary tripled in the 5 years I spent at my first programming job. I admittedly took a really small salary because I hadn't finished school and had no real world experience.
You can at smart small companies. My salary tripled in the 5 years I spent at my first programming job. I admittedly took a really small salary because I hadn't finished school and had no real world experience.
While I agree that programmers don't ask for more money often enough, this is overly simplified and doesn't account for a lot of cases that are important to a lot of programmers.
Firstly, a lot of work that programmers like to work on really is invisible to pointy-haired types. I run an infrastructure group, and when I do my job well the CEO hears less about my work because there are no problems. It's much more difficult to sell the benefits of never hearing about my code than pointing to changes I made to a website that directly affects conversion rates, or something similar.
On a related note, your point 3 assumes that a) the developer wants to change roles and b) that change is going to be to something that can be justified through revenue. Again, there is a lot of work that is interesting to programmers and very valuable to a tech company that doesn't directly drive revenue. These changes are very difficult to sell unless the CEO understands the benefits of these sorts of changes, in which case you probably don't have to sell them anyway.
In my personal case, I've gone as far as pointing out that every single thing that our company builds, when deployed, is critically dependent on my code and the code that I am responsible for working - and it does work, every time. It's still amazingly hard to get sales people to value that.
Firstly, a lot of work that programmers like to work on really is invisible to pointy-haired types. I run an infrastructure group, and when I do my job well the CEO hears less about my work because there are no problems. It's much more difficult to sell the benefits of never hearing about my code than pointing to changes I made to a website that directly affects conversion rates, or something similar.
On a related note, your point 3 assumes that a) the developer wants to change roles and b) that change is going to be to something that can be justified through revenue. Again, there is a lot of work that is interesting to programmers and very valuable to a tech company that doesn't directly drive revenue. These changes are very difficult to sell unless the CEO understands the benefits of these sorts of changes, in which case you probably don't have to sell them anyway.
In my personal case, I've gone as far as pointing out that every single thing that our company builds, when deployed, is critically dependent on my code and the code that I am responsible for working - and it does work, every time. It's still amazingly hard to get sales people to value that.
This point hasn't been stressed enough ... it is hard to get people to pay you for making things work flawlessly ... really hard.
Either they let you go and have an 'oh shit' moment as your replacement flounders ... or they just won't take you seriously because the stuff you do isn't visible to them ... you have to make a detailed and provocative case, basically outlining what happens if you leave, to get what you want.
Either they let you go and have an 'oh shit' moment as your replacement flounders ... or they just won't take you seriously because the stuff you do isn't visible to them ... you have to make a detailed and provocative case, basically outlining what happens if you leave, to get what you want.
If you have the sort of job where you can directly observe the financial benefits of what you do, and claim credit for them, then you are probably already earning more than PMs and BAs, or likely doing what they do as part of your wider software development responsibilities.
Most programmers, working together with BAs and PMs simply don't have access to the information that says how their efforts contributed to the bottom line. And they work in teams that often include those BAs and PMs, so even if they could make a direct link to increased company earnings etc, then it would be hard to justify claiming credit over anyone else in the team.
And in some cases a good PM deserves more than a programmer.
Most programmers, working together with BAs and PMs simply don't have access to the information that says how their efforts contributed to the bottom line. And they work in teams that often include those BAs and PMs, so even if they could make a direct link to increased company earnings etc, then it would be hard to justify claiming credit over anyone else in the team.
And in some cases a good PM deserves more than a programmer.
To get rich you need to get yourself in a situation with two things, measurement and leverage. You need to be in a position where your performance can be measured, or there is no way to get paid more by doing more. And you have to have leverage, in the sense that the decisions you make have a big effect.
http://www.paulgraham.com/wealth.html
http://www.paulgraham.com/wealth.html
However, I've read that as a boss, you may not want to entertain giving raises for those that ask for it, even though you may think you're cultivating the go-getters. It ends up that people feel like only those that are rewarded are those that cozy up to you, and politics will ensue.
According to the article, when asked for a raise, the best thing is to say they have to wait for their review like everyone else, and that's when you'll take note of performances.
According to the article, when asked for a raise, the best thing is to say they have to wait for their review like everyone else, and that's when you'll take note of performances.
This analysis assumes that your manager is not in a position to appreciate your work's value. The solution to that problem is to work for someone who does appreciate your work. That simple change will increase the quality of your work life; if salary is something you value highly, that will increase too.
Negotiation and business analysis skills are all helpful, but if you find yourself needing them to be duly recognized for your contribution, your work situation is fundamentally flawed.
Of course, here I am making assumptions of my own, e.g. you are a top talent in your field with the freedom to pick your employer.
Negotiation and business analysis skills are all helpful, but if you find yourself needing them to be duly recognized for your contribution, your work situation is fundamentally flawed.
Of course, here I am making assumptions of my own, e.g. you are a top talent in your field with the freedom to pick your employer.
This is excellent advice, having been someone in a very similar situation, I wish I had read this about a year ago.
What about asking for more stock options? Is this an acceptable thing to do if you feel you are in a strong position to do so? Any advice for how to do this?
I think it's a good idea to encourage everyone to try to get paid more, since (a) corporations make massively disproproportionate wealth relative to employees and (b) programmers are bad at the type of social and interpersonal skills that are required for negotiation.
That said, as someone who has been through this, I think your advice is a naively optimistic oversimplification of the forces that hold programmers back from getting paid more and, for the most part, people who follow your advice will still end up getting paid less than business analysts and project managers for cultural reasons expressed by some of the answers on that page.
The only difference is, with your approach, they may feel as if they have done everything they could, rather than suffering in quiet resentment (and, from a psychological perspective, this is not to be underestimated).
That said, as someone who has been through this, I think your advice is a naively optimistic oversimplification of the forces that hold programmers back from getting paid more and, for the most part, people who follow your advice will still end up getting paid less than business analysts and project managers for cultural reasons expressed by some of the answers on that page.
The only difference is, with your approach, they may feel as if they have done everything they could, rather than suffering in quiet resentment (and, from a psychological perspective, this is not to be underestimated).
(a) corporations make massively disproproportionate wealth relative to employees...
Depends on the corporation. Walmart only makes about $10,700/employee in profit, for example (about $6/hour if all employees work 35 hours). Since walmart typically pays $10-12/hour at minimum, employees are capturing about 2/3 of the value they create.
http://www.advfn.com/p.php?pid=financials&symbol=NYSE:WM...
Of course, the numbers will be wildly different at a software company. Most programmers don't capture anything like 2/3 of their created value.
Depends on the corporation. Walmart only makes about $10,700/employee in profit, for example (about $6/hour if all employees work 35 hours). Since walmart typically pays $10-12/hour at minimum, employees are capturing about 2/3 of the value they create.
http://www.advfn.com/p.php?pid=financials&symbol=NYSE:WM...
Of course, the numbers will be wildly different at a software company. Most programmers don't capture anything like 2/3 of their created value.
That undermines my assumptions. Thanks for the link. I'm very surprised a company of Walmart's size has such low profit per-employee. I would have assumed some accounting tricks were responsible but maybe it's the nature of their business.
Walmart is the canonical example of a low-margin / high-volume business. Especially during their growth phase, every time they would find a way to reduce costs, they would funnel that savings into lower prices, rather than taking the savings in the form of a higher profit margin.
Very true, Walmart is a bit of a loaded example.
But I found data more useful to the tech industry. If MS or GOOG pays their employees $200k/year, then employees are capturing about half of the value they create [1]. Worse than Walmart, but not that bad.
http://royal.pingdom.com/2009/05/14/congratulations-google-s...
[1] This is actually a fallacy, since it assumes all returns are due to labor, not capital.
But I found data more useful to the tech industry. If MS or GOOG pays their employees $200k/year, then employees are capturing about half of the value they create [1]. Worse than Walmart, but not that bad.
http://royal.pingdom.com/2009/05/14/congratulations-google-s...
[1] This is actually a fallacy, since it assumes all returns are due to labor, not capital.
To address the fallacy: Just state that labour and capital get half the returns each. We don't need to decide who or what creates value to make that statistic interesting.
It's a retail business - they are inevitably tied to the price they get from the manufacturer, and compete extremely strongly with a million other places, big and small. That really limits the margins they can make. Some retail businesses can get slightly higher margins due to exclusivity or just general scarcity, but overall the vast majority of profit is probably due to either 1. Cost Savings or 2. Economies of Scale such that you can eek some additional padding out of your vendors (WalMart is notoriously aggressive with vendors).
you literally just changed my world view, thank for showing me this.
[deleted]
I was going to challenge the assumption in the question but it seems that it might actually be correct: PMs and BAs do seem to make a bit more, on average. [1, 2, 3] At least, if one trusts salary.com's figures-- I can never decide if I should or not.
Nonetheless, I don't think the salary differences there are huge, or unreasonable. While I'm passionate about the importance of excellent engineering, I think excellent project management (and to a lesser extent, business analysis) is just as crucial to a business' success. Coders (myself included) tend to focus on the technical challenges of a project to the exclusion of the "why" behind it. As an illustration, I'm reminded of the frequent articles here and on proggit about programmers who built some awesome sprocket, only to later realize that there wasn't a market or need for the sprocket.
There's also a lot of truth to lionhearted's point that programmers often aren't the best negotiators. His advice is awesome and of the best variety: encouraging folks to make themselves more valuable by actually generating more value.
[1] http://swz.salary.com/salarywizard/Programmer-V-Salary-Detai... [2] http://swz.salary.com/salarywizard/Business-Systems-Analyst-... [3] http://swz.salary.com/salarywizard/Project-Manager-III-Salar...
Nonetheless, I don't think the salary differences there are huge, or unreasonable. While I'm passionate about the importance of excellent engineering, I think excellent project management (and to a lesser extent, business analysis) is just as crucial to a business' success. Coders (myself included) tend to focus on the technical challenges of a project to the exclusion of the "why" behind it. As an illustration, I'm reminded of the frequent articles here and on proggit about programmers who built some awesome sprocket, only to later realize that there wasn't a market or need for the sprocket.
There's also a lot of truth to lionhearted's point that programmers often aren't the best negotiators. His advice is awesome and of the best variety: encouraging folks to make themselves more valuable by actually generating more value.
[1] http://swz.salary.com/salarywizard/Programmer-V-Salary-Detai... [2] http://swz.salary.com/salarywizard/Business-Systems-Analyst-... [3] http://swz.salary.com/salarywizard/Project-Manager-III-Salar...
This isn't always the case. I don't feel comfortable disclosing my salary today, but for some reason I don't mind telling you my salary 4 years ago :)
At the time, I was a developer doing mostly web stuff, with 7.x years professional experience, in a low COL market, at $80k plus bonus.
My girlfriend was a "Jr. BA" (she held an MBA but little experience) and her wage was $45k. I doubt her salary would be doubled if she had a few more years experience.
At the time, I was a developer doing mostly web stuff, with 7.x years professional experience, in a low COL market, at $80k plus bonus.
My girlfriend was a "Jr. BA" (she held an MBA but little experience) and her wage was $45k. I doubt her salary would be doubled if she had a few more years experience.
I'm also pretty sure this is why software houses run as widget factories will produce sub-standard solutions. The hierarchical structure gives more weight to the ideas of the people managing. This works if the manager is an expert (or at least as knowledgable as their reports) in their field but with software it results in the most informed opinions being ignored or devalued especially if the costs/benefits are not immediate, so lots of technical debt. If you are managing a team of good developers your role is one of administration and occasionally cat herder (someone has to call time on yak shaving arguments).
I've seen a bunch of government software contracts go down this road, they all try to use the same "tried and trusted" solution even when the assumptions that underpin it have changed wildly (developers are just looking to play with fancy toys and so can't be trusted). They hire based on cost, 3 developers being paid 20k are worth as much as one developer being paid 60k and generally won't fight to retain staff. I find this incredibly ironic since government projects are often challenging and novel, they are dealing with scales or activities that businesses (mostly) don't touch. It always struck me that the area crying out for a creative, original solutions implemented by a film crew team.
I've seen a bunch of government software contracts go down this road, they all try to use the same "tried and trusted" solution even when the assumptions that underpin it have changed wildly (developers are just looking to play with fancy toys and so can't be trusted). They hire based on cost, 3 developers being paid 20k are worth as much as one developer being paid 60k and generally won't fight to retain staff. I find this incredibly ironic since government projects are often challenging and novel, they are dealing with scales or activities that businesses (mostly) don't touch. It always struck me that the area crying out for a creative, original solutions implemented by a film crew team.
Apple is a widget factory run by an expert. When Jobs left the company, it took a nose-dive. He came back and immediately things started improving. The man is a dictator, but he knows his stuff. However, if I were an apple shareholder, I would be very worried about his medical condition. Because when he leaves, apple will dive again.
If he's not stupid he would have prepared for this contingency, and arranged for competent lieutenants who know how to do things "the Jobs way" to take over when he kicks off.
Of course the thing about power-mad dictators is that power-madness interferes with the ability to seriously consider transfers of power.
Of course the thing about power-mad dictators is that power-madness interferes with the ability to seriously consider transfers of power.
It really depends on how your departments runs. A lot of times the gathering of requirements for BAs is by far the hardest, most time consuming, most frustrating task on the project. They have to travel, deal with users / clients, play political games, etc. If the programmers are more of code monkeys in the organization: in that they get tech specs with pseudo code and just transition it to real code, then they do not necessarily deserve to get paid more.
I have been a support analyst, programmer, software architect, and BA (and worked with several PMs). You really can't have one blanket generalization in this area because it completely depends on structure and job responsibilities.
I have been a support analyst, programmer, software architect, and BA (and worked with several PMs). You really can't have one blanket generalization in this area because it completely depends on structure and job responsibilities.
Exactly. The answer offered here is surprisingly ignorant and one-dimensional. The reality is that there aren't two types of software development companies, there are a spectrum of them.
At our company, because we don't sell products, client interaction, requirements gathering, coaching, politicking, etc. are all extremely important functions. It's really, really hard to find people who get our industry and can do this well. Often because of this they command a high salary.
On the flip side, we pay our developers above-market rates, and again it depends on their skill level and interaction with our clients and even with each other. Scrum Masters will earn more than developers (in most cases, not all). Senior developers will earn good money too. An entry-level developer will earn about the same as an "analyst" or product manager.
At our company, because we don't sell products, client interaction, requirements gathering, coaching, politicking, etc. are all extremely important functions. It's really, really hard to find people who get our industry and can do this well. Often because of this they command a high salary.
On the flip side, we pay our developers above-market rates, and again it depends on their skill level and interaction with our clients and even with each other. Scrum Masters will earn more than developers (in most cases, not all). Senior developers will earn good money too. An entry-level developer will earn about the same as an "analyst" or product manager.
I believe it's because it's far harder to find people with good people skills than find people with good technical skills.
If you talk to people who hire/interview and manage people as their primary role, you will often hear them say that the candidates attitude/people skills is more important than their technical ability.
If the candidate has good attitude/people skills, they can be taught (or will pick up on their own) good technical skills. But if they only have good technical skills, but lack a good attitude, that is something that is very difficult to teach/improve.
If you talk to people who hire/interview and manage people as their primary role, you will often hear them say that the candidates attitude/people skills is more important than their technical ability.
If the candidate has good attitude/people skills, they can be taught (or will pick up on their own) good technical skills. But if they only have good technical skills, but lack a good attitude, that is something that is very difficult to teach/improve.
I don't think good people skills are that rare, at least no more rarer than really good technical skills.
I think this perception is due that if you are hiring someone with experience in software, you already perform a selection on who will apply, you'll typically get people with "some" technical skills so the people you'll see with people skills are the ones with some intersection of both.
Also good technical skills aren't that easy to discriminate in the length of an interview. Its much easier to discriminate people skills since you are putting people in a stressful situation that is all about dealing with people.
Finally, a lot of the people with both technical skills and some people skills will avoid widget factories type of environments. If they started out of college, they probably got a programming job in a widget place, their perspective is the lowly ranked employee, its unlikely they appreciated the experience in comparison. Once they found a more enjoyable position, they probably won't go back to that type of environment. They won't even apply.
I think this perception is due that if you are hiring someone with experience in software, you already perform a selection on who will apply, you'll typically get people with "some" technical skills so the people you'll see with people skills are the ones with some intersection of both.
Also good technical skills aren't that easy to discriminate in the length of an interview. Its much easier to discriminate people skills since you are putting people in a stressful situation that is all about dealing with people.
Finally, a lot of the people with both technical skills and some people skills will avoid widget factories type of environments. If they started out of college, they probably got a programming job in a widget place, their perspective is the lowly ranked employee, its unlikely they appreciated the experience in comparison. Once they found a more enjoyable position, they probably won't go back to that type of environment. They won't even apply.
> I believe it's because it's far harder to find people with good people skills than find people with good technical skills.
I disagree emphatically. Good people skills are far more common than good technical skills. However, it is incredibly rare to find someone with both the technical skill and the people skill to be a technical manager.
I disagree emphatically. Good people skills are far more common than good technical skills. However, it is incredibly rare to find someone with both the technical skill and the people skill to be a technical manager.
Yes if you are taking about the general populace, I absolutely agree good people skills are far more common. However we're talking about BA/PMs in a technical company (at least that is my assumption given the original question) in which case there is already a pre-filtered environment of basic technical familiarity/knowledge. In this environment, good people skills and more specifically 'attitude' is a lot rarer than technical skills.
It sounds like we agree except on the semantics. My point is:
people skills = easy to find
technology skills = more difficult to find
technology skills + people skills = incredibly tough to find
people skills = easy to find
technology skills = more difficult to find
technology skills + people skills = incredibly tough to find
Personally, I don't think you can ever teach "good attitude" often times I doubt the candidate will ever be receptive to your attempts to change their attitude.
All else being equal, BA's and management are making higher level decisions which have more potential than developers to create stakeholder value. All else being equal, they are therefore worth more as measured by the potential return their work brings to stakeholders.
Unfortunately, those higher up in the decision tree aren't necessarily more competent than those lower down doing the actual work - often quite the opposite (maybe because these types of people are driven by different motivations). So the reverse situation can occur - developers can create a brilliant product which succeeds despite the best efforts of management.
I have a great deal of respect for genuinely good leadership, vision and management skills. Personally I find such things as quantum mechanics and reasoning about complex distributed systems far easier.
Unfortunately, those higher up in the decision tree aren't necessarily more competent than those lower down doing the actual work - often quite the opposite (maybe because these types of people are driven by different motivations). So the reverse situation can occur - developers can create a brilliant product which succeeds despite the best efforts of management.
I have a great deal of respect for genuinely good leadership, vision and management skills. Personally I find such things as quantum mechanics and reasoning about complex distributed systems far easier.
Not anywhere I've ever worked.
Hmmm, makes me wonder about this meme...
Hmmm, makes me wonder about this meme...
1. Ask why a myth is true.
2. Discussion ensues.
3. The mythiness gets lost and is accepted as a given.I second this. I'm the product person at a startup w/ 5 devs. I know for a fact that rails developers in NY generally command a higher salary than I am making. I can't speak about their equity situation.
My responsibilities are to decide what we build and why. I'm also the shit umbrella for the developers, and end up having to speak with clients. Ultimately it's me who is held responsible for the success / failure of the product.
The myth of project / product people being paid more may be true in LargeCorp, Inc. but in Startup LLC., the developer is king.
My responsibilities are to decide what we build and why. I'm also the shit umbrella for the developers, and end up having to speak with clients. Ultimately it's me who is held responsible for the success / failure of the product.
The myth of project / product people being paid more may be true in LargeCorp, Inc. but in Startup LLC., the developer is king.
I third it. Actually in every company I've worked at -- startup, midsized, fortune 500 -- a pm or analyst makes less than an engineer at the same experience level. It's always much harder to find good engineers, especially now a days.
The confusion might come from large companies where PMs tend to be more senior to a lot of the development team. But once a engineer matures and gains experince they will pass them. I my experience, it's very common to make more than the person who manages you.
The confusion might come from large companies where PMs tend to be more senior to a lot of the development team. But once a engineer matures and gains experince they will pass them. I my experience, it's very common to make more than the person who manages you.
+1. At all of the companies I've worked (where I've been privy to compensation numbers), the PMs consistently earn less than the engineers.
From my experience - I'm basing this on approximately 80 positions at 4 different companies - PMs are paid $55k - $80k while engineers/developers are paid $75k - $140k.
From my experience - I'm basing this on approximately 80 positions at 4 different companies - PMs are paid $55k - $80k while engineers/developers are paid $75k - $140k.
[deleted]
It's a lot to do with risk ownership and the fact it can be a genuinely hard role to fill as a BA / PM. Yes, programmers make it happen, but in an organizational context, the bookends of a BA on the front and PM on the back make sure it happens in a context that provides business value and a tangible outcome.
I've known plenty of brilliant programmers in a corporate setting that while technically excellent couldn't get a real project completed to save their life. They're often a different breed from people building things in startups. They're almost robotic in their following of the prescribed scope and you have to hammer them to bring things in on time or in a controlled way.
Additionally if the whole project collapses in on itself or delivers something of little business value, it's not going to be the programmer that gets hung for it.
Note, this is just in a corp / large org structure setting. As mentioned, I find guys in startups and small shops much more competent and scope definition and management. Just don't underestimate how unbalanced the skillsets can get in some fields.
I've known plenty of brilliant programmers in a corporate setting that while technically excellent couldn't get a real project completed to save their life. They're often a different breed from people building things in startups. They're almost robotic in their following of the prescribed scope and you have to hammer them to bring things in on time or in a controlled way.
Additionally if the whole project collapses in on itself or delivers something of little business value, it's not going to be the programmer that gets hung for it.
Note, this is just in a corp / large org structure setting. As mentioned, I find guys in startups and small shops much more competent and scope definition and management. Just don't underestimate how unbalanced the skillsets can get in some fields.
I believe the following answer is the best of the bunch:
http://programmers.stackexchange.com/questions/45776/why-do-...
TL;DR - companies will get away with paying as little as possible.
http://programmers.stackexchange.com/questions/45776/why-do-...
TL;DR - companies will get away with paying as little as possible.
Geesh. Was it me, or did that explanation run on for a long time?
I can say that because I was going to give a similar explanation, but I think it's even simpler than all of that. People get compensated more the more social IQ they have.
The real question is: why do we have roles? The answer to that question involves the film school and widgets and such, but as far as the simple issue of money, people skills beat technical skills.
I love coding, and I love being a code monkey. There's something about solving problems that I find very relaxing and rewarding. But I learned a long time ago that anything you do with more than 2 people quickly elevates social skills to a critical point -- something we coders hardly ever talk about. We're all off on SO reading articles about dependency injection while somebody else already knows dependency injection and is learning how to communicate with people who have different primary channels and personality types. Many times we find such training "fuzzy" or "fluffy" or somehow of dubious value. So somebody else becomes the code monkey who can do both and we become the person they are trying to help. That means the other person is more valuable. Life is not a intellectual test. It's a social game played by groups of people.
(Lionhearted is right too. Lots of times it's just there for the asking. But knowing when this is true and when it is not, knowing how to negotiate your rates, knowing how to ask -- we're right back to social skills again)
I can say that because I was going to give a similar explanation, but I think it's even simpler than all of that. People get compensated more the more social IQ they have.
The real question is: why do we have roles? The answer to that question involves the film school and widgets and such, but as far as the simple issue of money, people skills beat technical skills.
I love coding, and I love being a code monkey. There's something about solving problems that I find very relaxing and rewarding. But I learned a long time ago that anything you do with more than 2 people quickly elevates social skills to a critical point -- something we coders hardly ever talk about. We're all off on SO reading articles about dependency injection while somebody else already knows dependency injection and is learning how to communicate with people who have different primary channels and personality types. Many times we find such training "fuzzy" or "fluffy" or somehow of dubious value. So somebody else becomes the code monkey who can do both and we become the person they are trying to help. That means the other person is more valuable. Life is not a intellectual test. It's a social game played by groups of people.
(Lionhearted is right too. Lots of times it's just there for the asking. But knowing when this is true and when it is not, knowing how to negotiate your rates, knowing how to ask -- we're right back to social skills again)
Project managers either deal with the money and set the wages or they hang out with the people who deal with the money and set the wages.
The further away you are from the money, despite how important your role is, the less you will be paid.
The further away you are from the money, despite how important your role is, the less you will be paid.
TL;DR
Simple answer: people who knows how to negotiate a better deal often be able to negotiate a better salaries.
Now tell me who is a better negotiator: business analysts or programmers? (I skip project managers because quite a lot of them were programmers one point)
Or put it this way, if those programmers feel that this is not good and continue to work in a company like that, it would be their own problems since they either couldn't change the situation, or they don't know how to express that to who pay them.
Not to mention if the company itself also makes even more money in some cases.
Simple answer: people who knows how to negotiate a better deal often be able to negotiate a better salaries.
Now tell me who is a better negotiator: business analysts or programmers? (I skip project managers because quite a lot of them were programmers one point)
Or put it this way, if those programmers feel that this is not good and continue to work in a company like that, it would be their own problems since they either couldn't change the situation, or they don't know how to express that to who pay them.
Not to mention if the company itself also makes even more money in some cases.
Here's my twocents:
I think BAs and PMs are for the management side of the industry. Currently with big payout, however plateaued.
While programmers are on the innovation path, who will eventually (co-)create a really great startup. In the longrun, a really huge payout.
Though most programmers I know tend to jump from one company to the next, they target small tech-companies as the churning is acceptably high without the usual non-compete clause, and ask for higher salaries in each company. It is, apparently, a very good strategy, albeit opportunistic(?).
I think BAs and PMs are for the management side of the industry. Currently with big payout, however plateaued.
While programmers are on the innovation path, who will eventually (co-)create a really great startup. In the longrun, a really huge payout.
Though most programmers I know tend to jump from one company to the next, they target small tech-companies as the churning is acceptably high without the usual non-compete clause, and ask for higher salaries in each company. It is, apparently, a very good strategy, albeit opportunistic(?).
Business Analysts and so on tend to have face to face interactions with many external/internal people, so they have to have good people skills and good negotiating skills in meetings and so on.
Programmers sit at their desk all day and work as part of a team, with little or no outside contact.
Businesses value people-skills more than anything IMO, that's why BAs and so on get a lot more money.
Programmers sit at their desk all day and work as part of a team, with little or no outside contact.
Businesses value people-skills more than anything IMO, that's why BAs and so on get a lot more money.
Because the more real, tangible work you produce, the less need you feel to sell yourself as an employee. Programmers think their work should speak for itself. It doesn't.
Hopefully this comment won't get lost and I can get some contrary views. Everything IMHO; I'm trying to formulate my own views on this top. Be kind. :)
Among other things, I think open source and free software has devalued software and programming in the eyes of business owners. The root cause for this is that a culture of self-employment doesn't exist in the programmer community.
All of us are looking to polish our resumes and make them look good. The easiest way to do that is to clone some existing idea and make it open source so that it can be reviewed by a prospective employer.
IMHO, no other profession gives away their crown jewels for free like we programmers do.
Among other things, I think open source and free software has devalued software and programming in the eyes of business owners. The root cause for this is that a culture of self-employment doesn't exist in the programmer community.
All of us are looking to polish our resumes and make them look good. The easiest way to do that is to clone some existing idea and make it open source so that it can be reviewed by a prospective employer.
IMHO, no other profession gives away their crown jewels for free like we programmers do.
Pay structures are stupidly hierarchical but who enforces that? The managers enforce it by threatening to quit if they discover someone below them on the org chart is being paid more. Sure, some managers are replaceable so let them quit, but the organization has to weigh the cost of disrupting an entire branch of the org chart, and perhaps losing a talented manager, vs. just giving them the raise (plus pile more work on their plate to justify it)
Programmers can be managers too by volunteering to lead new initiatives that will require new staffing. The key to being seen as a an effective manager is to manage down (relate and motivate your direct reports) and manage up (relate your team status and exciting initiatives to your boss) To continue up the org chart you must volunteer to take on more responsibility at every opportunity until you don't go home at night at which point you have to ask is this really worth it?
Programmers can be managers too by volunteering to lead new initiatives that will require new staffing. The key to being seen as a an effective manager is to manage down (relate and motivate your direct reports) and manage up (relate your team status and exciting initiatives to your boss) To continue up the org chart you must volunteer to take on more responsibility at every opportunity until you don't go home at night at which point you have to ask is this really worth it?
This is a beautiful answer, which thoughtfully explains what makes the difference between "big entreprise java coding monkeys" and "startup rockstars". I love it.
The difference between "widget factory" and "film crew" explains also most of the differences between Java (archetypal "widget factory" tool) and dynamic ( or lesser known) languages, too.
The difference between "widget factory" and "film crew" explains also most of the differences between Java (archetypal "widget factory" tool) and dynamic ( or lesser known) languages, too.
I don't get your point. The choice of a language determines how a company will be run? No startup would ever use Java to create their product? Java is a bad language because it's used in large companies? What was your point exactly? Or is it that there is no point and you just felt the need to bash Java a little?
Many Java features are tailored to allow splitting a project in many submodules, and distribute tasks among a lot of coders with a spec. Many dynamic languages features are made to allow the quickest development by only a handful of developers.
Working in large teams with Ruby is harder than with Java. Getting a web app online in a week at 2 people is easier with Python than with Java.
Don't you agree that different languages are more or less adapted to various workflows, teams, applications, or environments?
Then about taste : passionate programmers learn by themselves. They may learn any language, Java, Python, C or Delphi. However the kind of people programming without passion mostly use Java, or C#, because the only matter of choice is language marketability. Therefore there many more poor, bland Java programmers than Python, Perl or Ruby programmers. There are many more Java programmers anyway :)
Working in large teams with Ruby is harder than with Java. Getting a web app online in a week at 2 people is easier with Python than with Java.
Don't you agree that different languages are more or less adapted to various workflows, teams, applications, or environments?
Then about taste : passionate programmers learn by themselves. They may learn any language, Java, Python, C or Delphi. However the kind of people programming without passion mostly use Java, or C#, because the only matter of choice is language marketability. Therefore there many more poor, bland Java programmers than Python, Perl or Ruby programmers. There are many more Java programmers anyway :)
I'm going to ignore all the "social" aspects of the supposed pay difference in my analysis. I think they are valid and accurate, but don't paint the full picture. This is coming from the perspective of a programmer turned PM. Note, however, that I haven't actually observed any pay difference - in the current startup/tech climate, good engineers are in high demand and are commanding super-high salaries. The best engineers are often the highest paid (cash-wise) in the company.
The reason good PMs are paid highly is because they use leverage to create more value across the organization than they can provide as a single contributor. A great BA or PM guides the whole project and the whole team, making a group of people more efficient by properly prioritizing their work and getting more value for each hour worked. A great PM measures these results, and shows the difference they make. A great PM tunes the product to the customer.
Great PMs are held accountable for the product and its success in the marketplace. Great PMs can't do their jobs without great engineers and respect that fact.
You only need one great PM for every 5 great engineers, so you can be more discerning about who you hire and how much you pay them. Since great PMs are accountable, they command high equity value, and should accept that instead of higher salaries (like salesmen take commission).
If this isn't true where you work, you should work somewhere else where it is.
The reason good PMs are paid highly is because they use leverage to create more value across the organization than they can provide as a single contributor. A great BA or PM guides the whole project and the whole team, making a group of people more efficient by properly prioritizing their work and getting more value for each hour worked. A great PM measures these results, and shows the difference they make. A great PM tunes the product to the customer.
Great PMs are held accountable for the product and its success in the marketplace. Great PMs can't do their jobs without great engineers and respect that fact.
You only need one great PM for every 5 great engineers, so you can be more discerning about who you hire and how much you pay them. Since great PMs are accountable, they command high equity value, and should accept that instead of higher salaries (like salesmen take commission).
If this isn't true where you work, you should work somewhere else where it is.
Consider the possibility that PM/BAs are not paid more because they are perceived to add more value but instead as a safeguard against them destroying more value.
If you purchased a chainsaw and you had £10 left to spend on accessories, which would you rather purchase, a guard that protected against lethal chain breaks that happen 20% of the time or a more comfortable handle?
A bad developer will slow a project but in almost all cases will not destroy it. A bad PM can totally destroy a project and many, many BAs have specced projects that are at best irrelevant and at worst destructive.
In most businesses, the risk is not that a project will only deliver 100% of expected value it is that the project will fail. Given that avoiding failure is the primary goal, investment should follow accordingly and so we are willing to spend more to avoid a bad PM/BA than we are a bad developer.
If you purchased a chainsaw and you had £10 left to spend on accessories, which would you rather purchase, a guard that protected against lethal chain breaks that happen 20% of the time or a more comfortable handle?
A bad developer will slow a project but in almost all cases will not destroy it. A bad PM can totally destroy a project and many, many BAs have specced projects that are at best irrelevant and at worst destructive.
In most businesses, the risk is not that a project will only deliver 100% of expected value it is that the project will fail. Given that avoiding failure is the primary goal, investment should follow accordingly and so we are willing to spend more to avoid a bad PM/BA than we are a bad developer.
As a Project Manager who has worked in Investment Banking for most of their career, I would say the risk is greater for a project manager.
I have quite often seen Project Managers "let go" when a project fails, but rarely do the developers on the team suffer the same fate.
Ultimately, in a corporate environment, the buck stops with the Project Manager.
Having said that, for esoteric technical skills (quant level programming, advanced risk stuff) the pay is probably higher for a developer.
I have quite often seen Project Managers "let go" when a project fails, but rarely do the developers on the team suffer the same fate.
Ultimately, in a corporate environment, the buck stops with the Project Manager.
Having said that, for esoteric technical skills (quant level programming, advanced risk stuff) the pay is probably higher for a developer.
There's a lot of assumptions in that question: 1. that programmers are paid less than business analysts and project managers, and 2. that "programming is much more difficult than creating documentation or even creating Gantt chart and asking progress to programmers".
I would like to see some real-life numbers about point #1, and #2 is clearly biased. How can you compare two things that have so little in common? For one thing, you can't reduce BA/PM to this, and regardless of if #1 is true or not, the salary is not just based on skills. If having a good PM means that the project will be delivered on time and that it makes a big difference for the company, they might deserve more than the people who made the product. If the insights from a business analyst means that the product is exactly what the market wants, they might deserve more too.
It's very easy to imagine two products that require the same technical abilities but one being very well-defined and on-target, while the other misses the mark. The programmer's work in both cases would be the same. The work done by BA/PM makes the difference. (in that particular imaginary example)
And, of course, it's very easy to imagine the same product requirements being a great success or a fantastic failure, depending on the dev team that implements them...
TL;DR it's not as simple as that. And check your assumptions first.
I would like to see some real-life numbers about point #1, and #2 is clearly biased. How can you compare two things that have so little in common? For one thing, you can't reduce BA/PM to this, and regardless of if #1 is true or not, the salary is not just based on skills. If having a good PM means that the project will be delivered on time and that it makes a big difference for the company, they might deserve more than the people who made the product. If the insights from a business analyst means that the product is exactly what the market wants, they might deserve more too.
It's very easy to imagine two products that require the same technical abilities but one being very well-defined and on-target, while the other misses the mark. The programmer's work in both cases would be the same. The work done by BA/PM makes the difference. (in that particular imaginary example)
And, of course, it's very easy to imagine the same product requirements being a great success or a fantastic failure, depending on the dev team that implements them...
TL;DR it's not as simple as that. And check your assumptions first.
reposted from the other dupe
This is the best advice I got about this subject when I was a wee programming padawan:
Your skills are worth what you're getting paid. No more, no less.
As much as we'd like to say we create more value than other branches of the company, we don't. Value is determined by the buyer, not the creator. It's simple-much of the working world values the work of managers and analysts more than the work of the programmers. Therefore, they are paid more. Value is malleable so as you increase your perceived value, your pay will increase accordingly.
This is the best advice I got about this subject when I was a wee programming padawan:
Your skills are worth what you're getting paid. No more, no less.
As much as we'd like to say we create more value than other branches of the company, we don't. Value is determined by the buyer, not the creator. It's simple-much of the working world values the work of managers and analysts more than the work of the programmers. Therefore, they are paid more. Value is malleable so as you increase your perceived value, your pay will increase accordingly.
[deleted]
I think it's purely confidence.
I just got a new fulltime job last week. I wasn't happy with the salary they offered, it was much lower than my previous fulltime job. I made it clear that salary would not work from the first conversation with HR. At no point did I change my stance.
I even suggested we should be creative asking if I could work from home twice a week so I could play hockey with some ex-pro's I'm in with (Stephen Yelle is my center...). I didn't even try to conceal why I wanted to work from home - I was straight up saying it was a quality of living issue.
They gave me the job and the two days off; they even came up halfway on the salary, going 8k above what they said they would ever pay for this position.
Bottom line: you have to ask for what you want; if you do that with confidence and a strong reason you can heartily defend you just may get everything you are asking for. It doesn't always work out this way, but I've never stuck to my guns so thoroughly before either and I gotta say, I am definitely going to always try to be creative when I negotiate now.
I just got a new fulltime job last week. I wasn't happy with the salary they offered, it was much lower than my previous fulltime job. I made it clear that salary would not work from the first conversation with HR. At no point did I change my stance.
I even suggested we should be creative asking if I could work from home twice a week so I could play hockey with some ex-pro's I'm in with (Stephen Yelle is my center...). I didn't even try to conceal why I wanted to work from home - I was straight up saying it was a quality of living issue.
They gave me the job and the two days off; they even came up halfway on the salary, going 8k above what they said they would ever pay for this position.
Bottom line: you have to ask for what you want; if you do that with confidence and a strong reason you can heartily defend you just may get everything you are asking for. It doesn't always work out this way, but I've never stuck to my guns so thoroughly before either and I gotta say, I am definitely going to always try to be creative when I negotiate now.
It takes people a while to figure it out (it took me almost 10 years in my career) - bosses pay more money to people they respect. Having standards is a respectable thing.
I think about this a lot. A great pm can be a huge help to senior devs. However in the cases Ive seen senior devs end up doing most of the pm's thinking.
+1 to what lionhearted wrote -
Because programmers don't ask for more money often enough.
In particular, Programmers never focus on 'ensuring they get what they deserve'. Other people take advantage of the fact that programmers never focus on this part.
Because programmers don't ask for more money often enough.
In particular, Programmers never focus on 'ensuring they get what they deserve'. Other people take advantage of the fact that programmers never focus on this part.
Because the ability to deal with and lead people is, always has been, and always will be, the most valued skill anyone can possess.
Higher compensation level for Managers has little to do with negotiation skills.
The real reason is that replacing average manager with good manager adds more value to the company than replacing average programmer with good programmer.
The reason for that difference is that good manager improves output of the whole team, while good programmer improves mostly single person output .
In order to attract and keep good managers companies are willing to pay more.
The real reason is that replacing average manager with good manager adds more value to the company than replacing average programmer with good programmer.
The reason for that difference is that good manager improves output of the whole team, while good programmer improves mostly single person output .
In order to attract and keep good managers companies are willing to pay more.
Here's an answer counter to the conventional wisdom, which feels a little too self-serving.
What if ideas are things that need to be worked on and hammered out as well? After all, isn't that why working on a startup is more rewarding? The programmer isn't just a programmer anymore, (s)he's also the PM and analyst all rolled into one. Of course, the person in charge has to be good at it all in order for it to work out. Startup people have to "pivot".
I have friends at Apple and Google, and they tell me engineers are encouraged to work on their own ideas. Analysts have shown that those companies have fairly high productivity per worker. One of my closest friends at Apple does all the mockups for her team's features, despite officially being a programmer. It feels as if the role of PM is spread out amongst a number of programmers, who aren't exactly brain-dead with regards to what a polished product should be.
Now in most companies where PM is in charge, it feels as if the toolchain has been optimized to deemphasize the importance and reliance on good programming, hence PM/analyst becoming more proportionally value-dense (whether this is a good approach or not I will not debate).
What if ideas are things that need to be worked on and hammered out as well? After all, isn't that why working on a startup is more rewarding? The programmer isn't just a programmer anymore, (s)he's also the PM and analyst all rolled into one. Of course, the person in charge has to be good at it all in order for it to work out. Startup people have to "pivot".
I have friends at Apple and Google, and they tell me engineers are encouraged to work on their own ideas. Analysts have shown that those companies have fairly high productivity per worker. One of my closest friends at Apple does all the mockups for her team's features, despite officially being a programmer. It feels as if the role of PM is spread out amongst a number of programmers, who aren't exactly brain-dead with regards to what a polished product should be.
Now in most companies where PM is in charge, it feels as if the toolchain has been optimized to deemphasize the importance and reliance on good programming, hence PM/analyst becoming more proportionally value-dense (whether this is a good approach or not I will not debate).
I can think of one valid reason why managers get more than programmers. Jobs don't pay people based on the value they're providing the company. They pay based on supply and demand. The best managers are ones who have been programmers before. Now how do you incentivize programmers to be managers? One possible way is to give them more money.
The referenced article is not even wrong.
Take the pool of qualified people who can do a job, order it by most able to least able. Now intersect that line with demand for people who can do the job. From the intersection point to the top you will see a gradual rise in salary with a sharp peak in the top 1%, below the line you will find unemployed folks.
Has nothing to do with vision, widgets, or films. The question is can you be replaced by someone who will be as productive as you are, for the same salary? Then you're on the short list. If you can be replaced for less salary, you will be.
Caveat the presence of an external force which warps the economics.
Take the pool of qualified people who can do a job, order it by most able to least able. Now intersect that line with demand for people who can do the job. From the intersection point to the top you will see a gradual rise in salary with a sharp peak in the top 1%, below the line you will find unemployed folks.
Has nothing to do with vision, widgets, or films. The question is can you be replaced by someone who will be as productive as you are, for the same salary? Then you're on the short list. If you can be replaced for less salary, you will be.
Caveat the presence of an external force which warps the economics.