We have to admit that programming is much more difficult than creating documentation or even creating Gantt chart and asking progress to programmers. So for us that are naives, knowing that programming is generally more difficult, why do business analysts and project managers get higher salary than programmers? What is it that makes their job a high paying job when even at most times programmers are the ones that go home late?
Excuse my ignorance, from some of the response it seems that the reason why BAs and PMs gets higher salary because they are the ones that usually responsible for the mess programmers make. But at the end of the day, it is programmers that get their hands dirty to fix the mess and work harder. So it still does not make sense.
Because in our societies, we still think the salary is bound to the position in the hierarchy.
The analysts or project managers are higher in the hierarchy, so they should be paid more.
Let me tell you a real story that illustrate why this is a problem.
A good friend started as a programmer in a big hospital. Thanks to his hard work and dedication, he quickly became Oracle DBA, which was a critical position in a company where data is both sensitive and valuable.
The hospital worked with levels. Levels are bound to your position in the hierarchy, legacy and diplomas.
My friend got a proposal to become DBA in another company that didn't use salary levels. His salary could be increased a lot. Because he liked and respected the hospital he worked for, he decided to talk to the boss, asking for an increase.
The boss refused. It was impossible because of the levels and the unions would not let that happen.
My friend left.
The hospital eventually hired an external consultant (not bound to levels) and posted a job on their website. The consultant did not know anything about the infrastructure in place, so his learning curve was huge. The hospital lost lots of money because of that.
The hospital did lose a lot more. The external consultant was paid as much as 5 times what my friend asked for, and they couldn't find a qualified employee to replace him.
That was almost three years ago. My friend is still at his new place and climbing the hierarchy ladder very fast doing what he loves.
The hospital is still paying 5 times more.
IMHO, salary should be relative to the value you provide to the company.
UPDATE: When you move higher in the hierarchy, there is the leverage effect occurring. So in fact, you are paid for the value you bring. But brilliant programmers that are 10x more productive should be paid 10x more, regardless their position in that hierarchy (usually at the very bottom). That's what I wanted to highlight.
I think your whole basis for this question is flawed.
Management must be paid more than their subordinates. Seniority in a company is generally based on salary, and there's no way a junior employee can have the means to command their seniors.
Leading people is a specialist skill. Not everyone can be a project manager (PM). The task is more and more difficult as the number of staff increases. In a technical PM role, the PM needs to have a good grasp of the technology to effectively lead - or they will not have the respect and support of their subordinates.
Programming may be more difficult by some measure, but it's also more pleasant. You just sit there and solve the nice programming puzzle while managers deal with all kind of crap between their subordinates, their clients, their own bosses and stakeholders. That's why so few sane people actually want to be managers, so you have to compensate for that by paying more.
Programming is more difficult, but managing sucks more.
One way to think what's someone's value to a company is to imagine what it would be like if that person left the company. Usually managers turn out to be more valuable in that sense than programmers. James Gosling, the creator of Java, recently left Oracle. One could think it's a huge loss, but guess what? Actually it doesn't matter. It hardly has any effect on Java or on Oracle. Dogs bark, but the caravan goes on.
By the way, I (seriously) think that dustmen and cleaners should be paid way more than programmers. Cleaning other peoples' litter is a job that sucks and is indispensable.
The rationale is that a project manager's area of responsibility (often) is to deliver the whole project on time, with acceptable quality, within a planned budget. There's often a lot of money at stake, so naturally good project managers often have higher compensation than programmers.
However I don't feel that business analysts, on average, earn a significantly higher salary than programmers. And it's my feeling that it is becoming less common that salary level in a company is determined by hierarchy and not by an employee's value.
They take more risks than programmers do. They have to make decisions based on whatever information we gave them, and then face the stakeholder's harsh criticism when their expectations aren't met. Part of the pay package compensates for this risk.
Another factor may be the years of experience needed to prepare a project manager who can plan, estimate and mitigate properly. In some sense, a nuanced project manager is trained through failures, making it an expensive-to-acquire skill. Once reached the level of seniority, a company may not be willing to let go of such valuable personnel.
There are more kinds of risks than financial or physical harm. For example, consider the risk of being reprimanded by the manager or the customer. Although no actual harm is done, it is still undesirable enough that we adapt our behaviors in order to avoid this kind of outcome. However, managers have to make good decisions all the time, and has to balance different kinds of risks in the interest of the company, not according to personal preference.
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.
A simple answer to this question would be "because in our societies, we still think the salary is bound to the position in the hierarchy." But this answer whilst reflecting the fact that people are paid based on their perceived value doesn't explain why PM and BA are on top of the hierarchy in many software organisations and why the management goes for hierarchy in the first place as a structure of choice for software project team. These are the two questions that seems to be really worthy asking.
Broadly speaking there are two categories of software making organisations. I will call them Widget Factories and Film Crews.
Widget Factories are born out of management school of thought revolving around motivation Theory X proposed by McGregor: rank employees are lazy and require constant control and supervision, jobs are held in the name of a pay check, managers are always able to do their subordinates' jobs to the higher or, at least, same standard. This thinking lands to a natural idea that the entire team can easily be replaced with and represented by the manager alone - after all everyone else on the team is either easilly replacable or there just to enhance manager's ability to complete tasks. Hence the hierarchy as a structure and rather horizontal job roles.
Widget Factory management operates on the assumption that software can be manufactured out of a specification prepared by a business analyst through a clearly defined process run under the close supervision of a project manager. The manufacturing is taken care of by staffing the project with enough qualified yet interchangeable programming and testing resources. Work is driven by a prearranged budget based on the initial business case prepared by PM and BA.
Management that runs a Widget Factory is easy to spot just by paying attention to the way these people talk. They are likely to be on about resources (including when referring to team members), processes, operating efficiency, uniformity, repeatability, strict control over use of resources, clear-cut job roles and defined process inputs and outputs. They'd casually mention the actual factory metaphor when trying to convey the image of the ideal software development operation as they see it.
Then there are Film Crews. They are based on the notion that people are intelligent, self-motivated, work really hard and enjoy their jobs as much as kids enjoy playing. Film Crews recognise that due to specialisation individual contributor abilities may by far surpass the abilities of people organising, co-ordinating and directing the work. Since manager can no longer substitute for everyone the hierarchical structure just doesn't work that well - people have to co-operate within a much flatter and complex formation to get things done. Jobs roles themselves tend to be much more vertical - start to finish - and involve a broader variety of skills. This management thinking is underpinned by McGregor's Theory Y.
A director of a Film Crew knows that her vision for a piece of software can only come true should she be able to assemble a great crew, fascinate the imaginations and help the team to gel and work together. Her role is to inspire, guard the vision, provide direction and focus the efforts. Every single person matters because "director" believes that software results from combination of worldviews and abilities of all participants and a unique way the group carries out the work together. Everyone recognises from the onset the importance of getting the stars to join the crew â€“ star performers increase every chance for success. Vision drives budget and attracts funding.
When it comes to compensation Widget Factories deem that the most value is derived from the work done by project manager and business analyst who reside on the top of the hierarchy and have to be compensated accordingly, the rest of the team doesnâ€™t matter that much as long as theyâ€™ve got the right qualifications to convert requirements into working code. PM and BA work hard to maintain their position on top of the pack by restricting free access to the sources of project information to the rest of the team. Without formal access to the primary info sources the team struggles to make any value judgements or come up with good solutions, programmers are relegated to taking orders from above and working on the problem as defined by PM and BA. This situation further reinforces the Widget Factory notion that programmers are akin to factory shop floor workers only capable of mechanically carrying out though technically complicated, but nonetheless standard tasks.
In a stark contrast Film Crew acts as a more egalitarian formation; members are given unrestricted access to primary information, encouraged to form value judgements and are free to select a course of actions to fulfil and contribute to the vision. Leadership structure is based on ability rather than a specific role within the team. Compensation reflects how desirable getting a specific person to take part in the project, it often tied to the perception of how much more valuable the end result will become if that person can be convinced to devote their energy to creating that piece of software. In this environment the role of a project manager becomes less prominent as he is unlikely to be the creative leader; the role comes down mostly to administrative support and external relations. Business analystâ€™s duties are partly replaced by the role of visionary (I called her earlier â€œa directorâ€) and partly absorbed by other team members.
Now, it wonâ€™t come as a surprise that most in-house software development teams and some consultancies are run as Widget Factories relying on a process to produce consistently boring software; it is these environments where project managers and business analysts are routinely paid more than programmers based on the assumption that they bring the most value with the environment structured accordingly making it difficult for programmers to prove the management wrong.
Successful software companies tend to adopt Film Crew viewpoint, any other philosophy would hinder their ability to attract great people that they rely on so much to produce great software. Itâ€™s unlikely youâ€™d ever see a business analyst role in that setting and project managers are less prominent and routinely get paid less than great programmers.
Most companies make the salaries reflect the amount of responsibility you're undertaking, which is a level of risk. In my experience, a good (project) manager is worth their weight in gold, and increases the productivity of everyone working with them.
On the other hand, paying them just based on the position title is silly, as I've tended to run into more poor (project) managers than good ones.
For a programmer, a good manager or PM is an umbrella that you don't realize was there until it isn't anymore. Then you're cold, wet and left wondering what the heck happened!
Yes, there is value to a good manager or PM, but I'm not sold on that meaning that a rockstar programmer shouldn't be paid what they're worth, even if that means it's more than the manager. There would be nothing to manage, no product to release if a software company didn't have those incredibly special and talented people releasing fantastic code for them.
I'm currently a development manager at a large retailing company in Canada. Our business is retail, not software development. Unfortunately due to the fact that our programmers, though talented, aren't the "product" that also means that I can't pay them salaries that match productivity or value. I have a set of rules and a hierarchy to abide by with levels, much the same as most other large non-software companies. So, I guess what I'm saying is, it all depends on the business you're in as well.
If you're at a software company, a talented developer IS the product. That company should recognize and pay comparatively.
It's arguable of course, but a significant reason behind this is that they carry the responsibility of the project if it fails, not the programmers. They might give you a earful for cocking something up, but they face criticism from even higher powers. They're the ones in charge of planning and estimation.
Managing requires a very multi-faceted skill-set: people skills, leadership, ability to estimate costs and time. To do all this they also need to still be in touch with your side of the things (ie have some clue of what you're doing, technically speaking) or be very good judges of character.
If requirements were not defined correctly, it's their fault.
If test plans were not defined correctly, it's their fault.
If you go on vacation or break your leg or get wasted on a Saturday night or leave without giving enough notice and they have to find a replacement or <some reason here> and you cannot get to do your work and the product doesn't get delivered (on time or at all), it's still their fault.
Also note that when I mean they carry the responsibility, it impacts people above and below them. If they screw things up, it might be your team's jobs that are on the line. That's also the kind of pressure you get paid for.
PS: Plus, I don't know if I would say that programming is harder than doing Gantt charts (to reuse the example you mention). I don't know about you, but I find programming (in general, for 80% of the stuff you need to do in the industry) fairly easy. If you screw something up, you can fix it. If your boss screws up his gantt chart or his cost estimation, now that's going to be a much bigger issue than inverting a
!= null for a
== null. Small mistakes matter on a wider scale for them. Most of the time, of course if you screwed up a test like this in an embedded medical application that went live, that's also a big problem. But they'll get more problems than you!
Everyone here is focused on the negatives. I've never met a programmer that likes office politics and good managers shield you from that sort of garbage. Having interacted with a lot of people at our main client, half of them are insane and I'm glad to have my PM there to soak up that insanity for me. If they pay them a lot, that's fine. He or she needs it for the inevitable therapy.
Reducing management to creating charts and writing documentation is like saying that programming is typing.
To each their own, but for me programming is much easier than managing people.
I don't know how many times the Gantt Chart knowledge need to be updated in a year. But doing programming you need to update yourself with new technologies which will not be so easy with your age.
Learning a new technology need hours of sweat, that if you smart enough to absorb.
The skill gained in years doing programming is not valued much in the current company culture.
Comparing newly graduate programmers salary with one with over 10 years of experience is a bit sad story.
Comparing a new PM with a 10 years PM is a great story, the PM might become Director after 10 years of experience.
So why are still so many people want to learn IT in the university? I don't understand. Are they been properly informed?
I do not understand how people value the skill nowadays.
Try to translate tech language from developers to business language and explain business language to developers and you will see that it's not much about gant diagrams or writing letters, or drinking coffee in meetings.
And more money do not motivates people for better work (not talking about simply physical work), look at http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=feedlik
Supply and demand is an economic model of price determination in a market. It concludes that in a competitive market, the unit price for a particular good will vary until it settles at a point where the quantity demanded by consumers (at current price) will equal the quantity supplied by producers (at current price), resulting in an economic equilibrium of price and quantity. The four basic laws of supply and demand are:
In this case, one reason is that there are too many developers.
I'm in finance, and I think the mentality is similar in most non-tech outfits:
Pay is proportional to career risk
Barring a complete dismissal of a group or team, the low-level programmers always keep their jobs. It's the nature of the job, and programmers go into it knowing full well that they are taking zero risk. If there's a bug, its not their heads on the chopping block.
At higher levels, if something screws up, you are the first to go. I've had many experiences with a subordinate who made a small typographic error which led to us losing money, and I took the heat for it (not the actual programmer who made the error).
Quite simply, the pay is commensurate with the risk. Programmers, on the other hand, dont necessarily have any skin in the game, so to speak.
In many professions, a core skill is the ability to sell something. And to sell something will, you need to sell yourself. You need the buyer to trust you and value the product or service you provide as much as you intend it to be. This skill is completely transferable to salary negotiations.
Programmers don't put salary as the highest priority (Assuming it is at a reasonable rate.). Imagine two job offers where one has a higher salary, same time commitment, but requires technical support, strict business hours, dress code, writing user documentation, dealing with legacy code in an antiquated language you were hoping you never had to use again, how much more salary would you require?
My experience might be different (or I'm living in an different universe with distorted laws of physics), but most business analysts and project managers (not program managers, but project managers or PMPs) positions I've seen are at or slightly below the average salary of programmers.
The salary gap begins to widen more when compared to the average salary of software engineers (on the software engineer's favor). The gap is even more when compared to senior EE or senior software engineers. Almost no senior business analyst or senior PMP will make the same as a senior EE or senior/principal software engineer.
A program manager, however (which is not the same as a PMP), that person will make a lot more than anyone else (and the reasons should be obvious.)
The thing that bugs me the most when I see these complaints about salaries is that as programmers (specially as junior/entry level programmers in the enterprise), we are (or were not) that special. There is nothing really in an entry level programmer right out of school that deserves a rocket scientist salary. No.
All of us that work on software started from zero. We all did.
And IF we are really honest, we know well that we didn't know crap. Being able to complete our undergrad CS course load is just the starting point. It does not make us that special or ZOMG!!!! uber-Einstenian. Really, NO!
And yet (and thanks to the ill-fated period of the dot-com bubble), we expect to make not just more, but a lot more than another university-educated person just because OH WOW, we are programmers and they are just business analysts and PMPs.
Can you spell arrogance? Newsflash - for most programming tasks in the enterprise, you don't even need a 4-year degree. Really, is that serious.
Put the time on the grind and build the experience to transition from programming to software engineering (or engineering for that matter) at the senior level. Then you can demand to make much, much, pero mucho mucho much more than a business analyst and PMP.
Get it over with - some of us are (or were) overpaid. Period.
Rant aside: reasons for a business analyst and/or PMP to make salaries close or similar to programmers that have not yet accrued the necessary time and expertise to be mid/senior software engineers (or that have still not developed expertise in a highly demanded niche area):
A business analyst is the liaison between software and systems folks and business people/business processes (which are the ones that justify the existence of your paycheck, not the other way around.) They are the ones responsible for breaking down business processes in methodical, analytical manners, as input amenable for forming requirements, the stuff you work on. They make sure that you spend most of your time programming and not dealing with the minutia of business.
Many of you think business is easy shit. If you really think that's true, God help you.
A project manager is the person in charge of juggling multiple projects (whereas you only have to juggle with one or two at the most at any given time.) He's your umbrella, and he's the one that has to do the dirty job most of the remaining unwashed masses don't want to do - to chase people down making sure they do their jobs or removing impediments to your job.
He's the one that will ask you "what are you working on? is what you working on helping moving the project along? do you have problems with your work? what are your obstacles, what do you need? who can give it to you?"...
and then he'll go to others asking the same hard questions, making sure that obstacles are removed, and making sure that you are pulling your weight on the project (if necessary.)
The number one problem I've seen in many failed projects is a lack of PMPs or a disrespect towards PMPs (specially from developers.) It is rare that I see projects fail because of incompetent PMPs, and yet one has to wonder why many programmers are more than eager to say that is the case.
If you work for a company that respect programming, math, problem solving, whatever skills, then you may earn more for two things:
Just because a Hospital doesn't pay their skilled DBA much (see the example in the first answer) doesn't mean that this is the same in every company.
Because less people has skills to be a project manager or business analyst than programmers. Simply, more good programmer exists than good project managers. I estimate the difference about 10-20 times.
Think about it this way, the number of skilled managers is less than the number of skilled programmers, therefore managers are more "valuable" to companies.
I don't think you can say that programming is automatically much harder than being a good business analyst/PM. I personally don't envy that job position and I think that it has to be pretty difficult, not in terms of technical know-how and sheer logical intellect, but because you have to be able to play both sides of the fence so-to-speak. A business analyst has the unenviable duty of trying to please everyone, but is usually liked by nobody. They have to get the project requirements almost as close to perfect as possible (which is impossible) and be able to make management feel warm and fuzzy about what they're doing and also not piss off the programmers too much. Most of these people get to sit in long, horrible meetings, with tedious corporate types that make you want to gauge your eyes out with a fountain pen, only then to get to talk to a bunch of developers that hate their guts almost instantly. I think the sheer stress of the job is probably worth an extra couple of bucks per week!
These days though, at least in my organization, we got rid of these types of people because often they were a drain on productivity. We adopted more agile methods of development and forced developers to get out there and actually interact with users instead of relying on a third-party to act as a go between and try to pin down every single process in the business and reduce it to a series of impressive looking charts and documents that nobody will ever really read. I'm sure there are really excellent business analyst-type people out there that really know how to handle the situation elegantly but the ones I have worked with looked like they were seconds away from hari cari.
Programming people, which is what they do, is really hard. Harder than programming machines.
By all means, write code to automate them out of that job and you will have a great deal of money. I was told that, in seriousness once, and I found out.
Start here: It's much harder to do that job than you think. People are hell to work with.
I've shifted between developer and PM roles throughout my career. I have developers on my project making twice as much as I do and others who are making half. The high wage earners are being paid what they are because: A) They are "rockstar" developers. B) They interact with the customers, explain the product in a way that is easy for the customers to understand, and are personable. C) They direct teams of developers who work on multiple projects. D) They are always available and eager to please.
They perform the roles of a developer, PM, and BA in varying capacities. Generally, if you're spending 90% of your time heads down, cutting code then you're not incredibly valuable and likely are easily replaceable. If you want to make more money then you need to take on more responsibility... and probably have to find another company that will pay you more.
If your question had been "why do X and Y get higher salaries than programmers at my company" I might have answered "you may work at the wrong company."
The success of a company in the software business depends more on the abilities of its programmers than anyone else. Companies that don't recognize this are automatically at a disadvantage vs. those that get it. Hiring the best programmers and taking good care of them is your best bet. The difference in the work of the great programmers vs. the rest is enormous; way bigger than the difference in salary they command. But if you insist on underpaying your programmers, you'll get what you pay for.
That said, every other role in the business is important. The great managers have a huge impact. A lot of that is by getting great programmers and keeping them happy. Something similar can be said about business analysis, marketing, sales, testing, and support.
If you are a great programmer and you're not being handsomely rewarded, go somewhere else. Then again, you may not be a great programmer. Unfortunately if you're not great it's hard to see why. If you knew why, you could change and be great, right?
I have been a programmer and I have been a people manager. I worked with a lot of great programmers, but only a few great managers. When I was a manager I was not great, but at least I knew it. My people got more raises than I did, which they deserved.
All right I am slightly surprised with the answers, so here it goes. But before that, I will just like to clarify that I am a Programmer and there is nothing I like more than Programming. That said I have a healthy regard and respect for competent PMs and BAs. I realize that many of us resent PMs and BAs because unlike programming it is possible to excel in them without the required level of competency (office politics, nice suits etc).
However both Project Management and Business Analysis are critical components of the software development.
Whenever we think of software development many of us have a tendency to focus only on programming to exclusion of everything else. Yet there is more to it than coding.
First aim of development, which is to create a software which actually addresses and solves customer's issues. This implies first actually figuring out the customer's requirements (as customer may not be really sure what he wants), this is only possible by a detailed analysis of domain in which customer operates and structure of the various artifacts (whether it be people, technical infrastructure or process), and afterwards develop suitable business solution (and its integration with technology) to address those requirements.
Similarly any project of significant size absolutely can not work without effective management. Now I don't know how it is in other places, but so far my experience has been that PMs are usually promoted from ranks of programmers, so they do have some idea about what it takes to organize and execute the project.
To summarize both BAs and PMs are abstraction layer to development.
I have thought about this very same thing in the past. It drives me nuts, basically. I came to the conclusion that it has to do with incentives and the principal-agent problem. They are being paid more because they are not supervised, it is a form of efficiency wages. You can read more about this in my blog: http://www.climbingthecorporatebladder.com/who-guards-the-guardian/229
I started one month ago with my first project as a PM. Before I worked as a programmer. (by the way, I get the same money as before.)
I found out that being a good PM means being a good programmer with a wide experience. You should be able to go from one team member to another and discuss the problems they have using your practical experience to help them to understand the problems by providing a different point of view. Your task is, besides other, to manage the interfaces. A PM is like a conductor. You can have the best musicians but if you don't have a good conductor who knows how to play the meta-instrument orchestra well, you get only a mess.
The counterpart is the specialist. This is the programmer who is able to solve difficult problems because he has a deep knowledge of the problem domain. These experienced people often also high paid if they are good enough in negotiation. Unfortunately specialists are often nerds and not so interested in money or good in making a good deal...
Tricky but valid question. My school of thought is a little different though I'm a programmer myself. In the IT field, we have many positions ranging from devs to BA's to PM's to QA's. Each role has a set of tasks to perform in order to deliver the product. And each role gets paid by virtue of its importance. Yes, they all have to go hand in hand. BA's role is important since they understand the specifics of the domain and help the customer to come out with detailed requirements. Programmers convert these requirement into reality. Managers look at the bigger picture and ensure that we are shielded from the day to day management related activities which are important from the higher management perspective. QA's ofcourse ensure that a quality product reaches the customer.
In all this, you can see that we cannot debate who is more important or who does more work. Its just roles that different people need to play.
Also remember that as you grow in an organization, you'll slowly transition from a programmer to a lead dev and so on. This will make you almost equally paid or better paid than a manager. A Programmer is considered as an individual contributor where as a dev lead is managing a team of programmers.
Another hypothetical thought (apologize if my data is incorrect): Have we thought why an eye surgeon gets lesser paid than a say ..orthopedic surgeon? All are important parts of the body to us right?
But at the end of the day, we still do what we do coz we love it!! I love getting to work every day and churning out some whacky lines of code!
In my world (in my country, or the environment I'm used to be working in), a System Architect and a Project Manager is the same person. Once he designed the system, he should plan the development, do charts, monitor what's happening, etc. He shouldn't get involved into programming.
Right now I am playing this exact role, though the system we're making is rather simple. What I observed when I was hiring, is that most developers (of the ones I came across), to my dismay, can't see the big picture. Hell, they can't even comprehend a whole, but separate, small task.
I am being paid more than them, because they constantly ask me about things they don't understand, or bugs they can't find. And because I have to describe the tasks in such a way, that the programmer wouldn't find anything to understand in a wrong way. I write tons of code, in English. My correspondence is about 20% in size of the total project code size.
I am also the bearer of the responsibility on this project. Every time the project is late, I get to be punished. And I also ensure the final quality of the whole system.
And I think it's fair. I see the big picture, they don't. I tell them what to do, in small tasks, so that in the end something good would come out. I solve the most complicated problems that occur.
If you feel you are in no way worse, then it's the company's fault that you still haven't got a promotion to something bigger than a developer.
A simple developer must be that person, that can do small individual tasks, in a way he is asked to do them. A simple developer must not be that person which understands more, and participates in the project at another level.
It's absolutely not fair if a person who just plans and constantly checks for progress, gets paid more, than those who actually do something for that progress. This exact situation is at the heart of the slowly rotting company.
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.
Many people said here, that programming is more difficult and that is why it should earn more. That is a very romantic view. The truth is, that in a normal, healthy company the payment is according to the responsibility, that means to the added value of that person and also the risk.
The risk will often be forgotten. Normally if the programmer fails in his hard-to-do job, there might be some increased costs, but nothing more. Not like 10% of the workers will lose their job or something like that. The risk is quite low.
Also I want to disagree with the idea, that most business people earn more. I bet the normal business guy earns less then most Bachelors of Science/Engineering will earn. For example as a undergrad holiday coder I earned nearly the same as some full time business stuff workers in the same company.
And last but not least, why is the project manager not an engineer? Normally the project manager is a guy with many years at the front in the topic of the project he manages, meaning in programming jobs it will be an experienced programmer who is the project manager.
There are corporate environments in which either the command and control pattern or the hub-and-spoke communication pattern dominates. In these organizations, the manager and the chief communicator are often the same person. This makes the manager a single point of failure - any dismal effects of miscommunications or lost-in-translations are amplified. Hence these environments require persons with extensive technical backgrounds as managers to ensure accuracy.
Better organized teams usually appoint a chief communicator to offload this responsibility. Organizations which practice knowledge management do not have any single point of failures in communication. In these organizations, the managers and chief communicators solicit for information and facilitate discussions. These information will be captured and processed for internal sharing. A different set of social skills is required.
Likewise, business analysts are often the single-point-of-contact between the customers and the company's technical staff.
in general the project managers must see the general picture while programmers only do their own specific task,
you can run a successful web business with average programmers but rarely with average managers
if you are a manager you need to do the finance math, you need to work on the personnel issues and trust issues, have a say in the recruitment matters etc.
For the exact same reasons that a CEO can make 263 times as much as their average worker.
It has little to do with skills and work, I mean little in the economy is tied to how much people deserve to make.
Deserving to make more money is an ephemeral idea, everyone believes they deserve to make more money.
While it may not be fair, managers make more money simply because the business owners trust them more. Managers often get higher salaries, simply so they won't take a new job out of the blue at an inconvenient time.
Project Managers, manage upwards. Programmers manage downwards.
A Programmer's job is to write bug-free code that delights customers as quickly and cheaply as possible. A Programmer manages there code (downwards), thus if they do a good job there code is happy. The code does not pay there wages and those that do, do not understand the code.
A Project Manager's job is to predict schedules and help the programmes (e.g. make project run faster) A Project Manager spends little time doing anything to help the programmers (managing downwards), and if the project is late they blame the programmer. By isolating the programmer from the upper-management/customers they are able to manage the upper-management/ customers, thus influencing these with the money (managing upwards). They may enrage the programmers, but this does not matter as the programmers are not paying them.
This is not always the case. When I worked for Computer Sciences Corporation (CSC), most managers made less than the "people who produced something useful". In the case of CSC, I think this was the case was because the company had been started by a group of programmers.
At the time (1970) there was another software company in LA whose name I forget with an interesting salary schedule. Programmers got paid $25,000/year and support staff got paid $15,000/year. The idea was that if you were the worse programmer there you should not be surprised to get replaced.
You think your language/compiler is finicky? Managers deal with self-aware complex-state compilers called programmers, and the good managers even get them to produce software.
Seriously, I like the widget factory vs film school answer, which I think is probably the best answer in thread, but there's a meta-level discussion it doesn't really address: no matter which kind of organization you're building, you're building an organization from material as capricious as people, and that's work that's often hard to do well. You can make a solid argument that it's weird that these positions often pay better than the programmer's when a significant chunk of analysts and PMs and PHBs are not in fact doing a good job, but the fact is that there is a job out there that involves building organizations that get things done, and it's a skillset that's arguably more difficult to master than building software systems that get things done.
I've gone through every post, and I dare to say that most of them are trying to compare apples and bananas.
First of all, I believe that someone who says that 'manage is piece of cake' never had to manage anything further than his own schedule. On the other hand, say that 'anyone can code anything' is silly (and is in the wrong forum, for God sake!).
I specially liked rwong and luis.espinal asnwers, although I believe there are other facts that needs to be noticed as well.
I don't believe hierarchy as an answer - not nowadays - although it fit perfectly for the last 10.000 years. We lived for centuries in a society where the higher your profits, the higher your power (and vice-versa). I don't believe it applies for our world, in the way it is (specially in our area).
Back to the main question, I believe that managers usually earn more because they're more valuable to a company not because he's higher on hierarchy, but he's higher because of
In my opinion, the leadership factor is the main reason for the higher salaries, because it generates a huge long-term result for the company and for everyone who's around the leader.
BTW, I had only a few experiences as a team leader (far from being a project leader!) and as much I know what a leader does, as much work I realize I have to do.
Edit: Forgot to highlight: communication skills aren't a strong point for most of us, but is a must for a leader. Besides, I'd like to share a very good post at Coding Horror, related to good programmers and communication skills -> http://www.codinghorror.com/blog/2011/02/how-to-write-without-writing.html
Management doesn't always make more than the engineering staff. The senior level engineering staff should be actively involved with business level analysis and decision making and charting the technical roadmap for the company. When this is the case, the senior technical staff can make quite a bit more than the business managers they work with everyday.
One of the popular myths of business is that the manager should be paid more then the people he/she manages. IMO, you find this notion more deeply entrenched in buracracies than in functional, agile teams.
To put it another way: compensation is supposed to reflect the value of a person's contribution to the company. There are stellar business managers and average managers, and there are stellar engineers and average enginers. If you have a stellar engineer that cranks out money making technology and has deep knowledge of the company's technologies, isn't it in the company's best interest to compensate this person more aggresively than an average business manager who happens to be managing this stellar engineer? What is the opportunity cost of losing that engineering expertise and skill set because you neglected this valuable resource?
Business Analysts and Project Managers have more access to managers up the chain. That's the main reason why they can get paid more. Not all do. There are also organizations that pay really poorly for business analysts but they risk a very high failure rate due to the most expensive form of bug - a requirements bug.
Programmers who demonstrate the capacity to effectively gather business requirements and or manage a project get paid more than all three of the choices you've listed. It's important to remember that technical services are in service of business needs in most organizations and people tend to trust and value people that they feel understand their needs.
I think the answer is very simple. Managers have to justify their high salaries by placing greater importance on other managers. If they see to it that the managers below them are earning hefty salaries then that ensures they have an even larger salary.
Managing people is harder than managing code. And good managers have the unique ability to find good programmers.
My theory is that jobs that are closer to the money get more of the money. (excepting cashiers)
That depends how you define 'difficulty'. Even though, I wonder if you do know what Project Management is about and what Business Analysts should be doing. I read much frustration from your question, so I think you have some bad experiences. Never the less, I want to try to answer your question.
Project Managers and Business Analysts are usually 'older' when they fulfill those positions. Where developers start their career very young (around their 20s), most project managers and analysts are near the age of 30 (which already creates a difference in payment just by age alone). They are also the ones that face customer exposing, which means they have to travel onsite, spend hours of torture to listen to the customer (especially when a project goes dead wrong) and enlist their wishes/needs. They have to be careful what they promise and especially within what scope (time-to-deliver). Even though from your perspective that what they do is only documenting, business analysts are educated to analyze the needs for the business, and project managers are guarding the planning of projects.
They act as a firewall between the customer and the developers. A technical perspective is something different than a sales perspective. Most business analysts and project managers are also facing a large variety of customers - they are exposed and therefor have 'leads'. Their network consists out of decision makers and therefor companies prefer to keep people with such networks within reach; after all a sale is a sale.
Regarding difficulty? Start a company, have ten developers and try to manage a project. The headache comes with it for free. Do this for a year and then look at your answer again. For BA's? Go for such an opportunity. Sit down with customers who have an AIX machine from 1974 and the designer of that system is dead/retired/dying/alzeheiming and the developer needs to know if a certain value is generated or has some mystical formula. Try to convince 20 people with a powerpoint about your solution within 3 days time. If documenting was that 'easy', Linux would've pwned the world in 1997 already. Really, try writing a technical white paper every month for non-technical people (the ones that think that Facebook is a revolution in computing).
I am a sales engineer. Which means, I develop but my specialism is for prototypes and demonstrations. And I earn more than a business analyst or a project manager. Not because I have a network (I do, though), but because I left the attitude and focussed more on the business perspective, got myself certified and taught myself some soft skills. And the experience to learn that 'no' is also answer, when it comes to overtime.
I've my own little software enterprise and I'm both the programmer and project manager, so I can give you both points of view.
Your initial assumption is not true. Let me write it down:
Project Management & Software Analysis =
Creating documentation or even creating Gantt chart and asking progress to programmers.
If you really think that's all Project Management and Software Analysis is about, it's no wonder that you think that programming is harder.
But that's a ridiculing, unfair and non-realistic way to define those professions. It concentrates on merely visual aspects, as if the they didn't give value.
How would you feel about this other definition?
Sitting in front of a computer and punching keys.
If programming is defined like that, PM & SA look much more difficult, even by your definition (which isn't correct).
Those professions are better paid because they are, indeed, more difficult than programming.
If the project managers that you work with just do powerpoints, they are not doing their jobs correctly. And that's sad.
I think you will not really understand why project managers earn more than programmers until you meet a good project manager.
Simple answer: They're more valuable to the company than programmers.
Why? Because they ensure that projects get completed, even if they're not doing the programming themselves. That means their value (purely in monetary terms to the company) is more than an individual programmer. The company doesn't believe that unmanaged programmers are productive, and therefore valuable... It's only the manager that makes them so.
Sucks, and we may not like it, but that's why the company pays them more.
Their position (as others have pointed out) comes with drawbacks, though: If they fail to get a project completed by a certain time, it's their fault, not the programmers. They shoulder more responsibility, and are highly likely to get fired for failing (unless there's some BS company nepotism going on).
So, really, they're not allowed to make mistakes, have more pressure on them, and have a much more volatile job... but don't get confused: This isn't why they're paid more -- a company doesn't give a rat's ass how much pressure you're under, how volatile your position is, anything like that. They only care what value you bring to the company. Period.
That's capitalism, folks.
I disagree with the premise that programming is more difficult than writing documentation. Programs are read by computers. Documentation is read by people. I think most people here would agree that getting a computer to understand what you are trying to say is often far easier than getting a person to understand what you are trying to say.
Because bosses let managers to recruit programmers, so managers decide programmers' salary. As a result, candidates' salaries cannot be higher than interviewers'.
While it may be true that on average managers salary is higher than a programmers one, what may be of a personal interest is that some programmer are paid better than some managers. If you want to get a higher salary, you can be a great manager, if you want, but another option can be to become an excellent programmer.
If you really want to understand why managers get more than programmers on average, you should try to understand how economics works, as economics is the science describing prices, money and things like that.
As other replies have already told you, salary (like almost anything in real life economy) is not "fair" in the sense more effort gives you more money, it is a result of free market. If you ask why managers get higher salary then programmers, you should also ask why actors or football players are paid better than scientists or miners.
All business analysts/project managers do not make more than all programmers.
There are other factors which are more important, such as industry/sector, level of domain knowledge, specialization, and the nature of the business you work in.
I know plenty of highly specialized developers who do contract/consulting work and pull in double or more what most BA's do.
It's all about business value, and if you bring that value, you'll get whatever the market can afford to pay.