programmers.stackexchange.com
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)
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.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.
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.
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.
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 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.
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.
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.
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.
Of course the thing about power-mad dictators is that power-madness interferes with the ability to seriously consider transfers of power.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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 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.
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).
The further away you are from the money, despite how important your role is, the less you will be paid.
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 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 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.
people skills = easy to find
technology skills = more difficult to find
technology skills + people skills = incredibly tough to find
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.
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.
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 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.
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.
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?
http://programmers.stackexchange.com/questions/45776/why-do-...
TL;DR - companies will get away with paying as little as possible.
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.
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...
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.
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.
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(?).
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.
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 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.
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.
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.
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 :)