Why do business analysts and PMs get higher salaries than programmers? | Hacker News Reader

Why do business analysts and PMs get higher salaries than programmers?

programmers.stackexchange.com

226 pointsAjJi175 comments

The top rated comment on this question asserts that the reason why programmers have lower salaries is because they are logical, intelligent individuals who refuse to play the politics game and thus are hated by executives. Not only it this incorrect (have you seen the politics in certain open source software projects ?) but it plays into a narrative that programmers want to believe: business people are corrupt and programmers are superior to them morally if not in compensation. You're doing yourself a disservice if you follow this line of thinking.

On the other hand, the top rated answer has a pretty elaborate and abstract theory about widgets and film makers. I make no assertion about the accuracy of this abstract theory, but I can summarize reality in a much simpler way: many programmers work in businesses where software is a cost center. If you want to make money as a programmer, you need to work at a company where software is a generator of profit and negotiate compensation aggressively after demonstrating your value.

The following is required reading if you'd like an algorithm for doing the above:

Don't Call Yourself A Programmer, And Other Career Advice http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...

Salary Negotiation: Make More Money, Be More Valued http://www.kalzumeus.com/2012/01/23/salary-negotiation/

"many programmers work in businesses where software is a cost center. If you want to make money as a programmer, you need to work at a company where software is a generator of profit and negotiate compensation aggressively after demonstrating your value."

This is right on. Looking back to when I was finishing my degree an older friend of mine advised that if possibly you shouldn't work for a company who's primary income stream isn't what you do. I still think this is a fantastic suggestion. Not everyone can be an important member of the R&D group for their employer, but if you've got the chops why shouldn't you be?

I find that doing that you get the best of both worlds. You're valued enough that you get shielded from most of the office prattle and politics, you usually report very high up the hierarchy ( I've never reported less than one level down from executive team, and usually its been directly to a C-level position), and these teams tend to be full of others who know their shit and will make you better. Of course the compensation is usually quite good too, and bonus you're unlikely to be held to a standard soul sucking 9-5 schedule, or God forbid have to be on call.

Actually, being in the R&D group pretty much guarantees that you aren't in the income stream. You are in the futuristic stuff stream. If costs need to be cut, guess what impacts current revenues the least?

I'll grant you that. If times get hard future revenue generation can often be sacrificed to make sure that the business can get through the "now" part. I think I'd likely look at that as a blessing, if things are going downhill for everyone at least you're lucky enough to know and get out early.

Also, I should mention that in my case the research generated is often used as an intelligence source for the current products. In the early days of my career my teams research resulted in a constant stream of snort rules, vulnerability discoveries, and bypass techniques that often made their way into the products/services of the company. Those 2-3 times a week updates being pushed down to client devices were a big part of the perceived value that the customers received.

Modern software and service driven models mean that there doesn't have to be much of a gap between research and deployment.

Everything is a cost center even sales until you start looking at larger chunks of an organization. As long as you can demonstrate an increase in profit you can easily justify a huge salary regardless of what part of an organisation you work for. 'I did X which generated Y cost savings' works just as well as 'I brought in X business at Y profit margin generating Z profit.'

edit: Typical examples include research and development, marketing and customer service.[1] http://en.wikipedia.org/wiki/Cost_centre_(business)

PS: I updated the data entry screen, increasing our call center's throughput by 3% creating 5 million in savings over the next 3 years.

Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, we've invented a narrative of moral superiority, and it's a seductive one.

I suspect programmers are less correct in their assumption than they would like to believe. Probably more correct than the other two groups of employees, but still less than correct. The sad fact is, most programmers (especially non-entrepreneurs) don't "get" what PM's and BA's do, the same way that most managers don't "get" what programmers do, but their role still provides value (if they're good at their job). The nature of their job often involves filtering crap for their programmers, so the better job they're doing, the more invisible they look.

The value PM's provide is enabling specialization of labor. They act as the interface between business stuff and tech stuff--translating business requirements to tech requirements for their programmers, and tech trade-offs into business trade-off for their stakeholders. It's something that programmers can do themselves (especially entrepreneurial ones), but taking that work off their plate lets them focus on technical matters.

Of course, the above is a perfect world, which is about as common as the mythical sufficiently-smart compiler. Which is to say, it never exists and never will. Nonetheless, there are such things as PM's that provide value. My experience is that ones with non-negative value are about one-in-four, ones with measurably positive value are less than one-in-ten, and if you find one you should pay what it takes to keep them around. YMMV.

----

That said, there are reasons why PM's are paid more than their value more often than programmers are. I agree with the majority of these, but I'm restricting my contributions to the portions of my opinions which aren't echoed throughout this thread.

> Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, we've invented a narrative of moral superiority, and it's a seductive one.

This is all true. However, you forgot this additional piece:

Managers and business analysts generally sit higher in the organizational chart than programmers, and thus have an advantage when negotiating salaries, presenting the programmer's relative value to the rest of the organization, etc.

> The value PM's provide is enabling specialization of labor. They act as the interface between business stuff and tech stuff--translating business requirements to tech requirements for their programmers, and tech trade-offs into business trade-off for their stakeholders. It's something that programmers can do themselves (especially entrepreneurial ones), but taking that work off their plate lets them focus on technical matters.

However, many would argue that translating abstract business requirements into technical requirements is a technical matter.

That said, the notion that programmers always make less is not universally true, and many organizations are more sane about paying commiserate with value generated.

commensurate

To commiserate is to share in someone's kvetching.

Thanks.

"Programmers tend to think that programming is the most important part of making software. However, managers think that managing is the most important part of making software, and business analysts think that defining business requirements is the most important part of making software. Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased. As you say, we've invented a narrative of moral superiority, and it's a seductive one."

I think I thought that way about 15 years ago or so, but by 10 years ago I realized that ... almost without exception, I can get the tech stuff done. Of course, I'd like to do it myself, but I can get others smarter than me at XYZ to do the tech stuff. While the tech stuff is sometimes hard, it's almost universally doable.

Have you ever had a project fail because you didn't know how to write to a file, take data input or query a database? I bet not. But... we've all had projects that failed because none of the people involved could accurately communicate what needed to be done (and in some cases, establish reasonable timelines for those needs). Communication is key, and PM/BA types are generally better at it than typical developer types. There are always exceptions, but the PM/BA types are perceived to be better at it, often because they're controlling the communication, almost by definition of their role.

So, while everyone thinks their part is the most important, they're pretty much all equally important, but the PM/BAs tend to be more visible on projects, rightly or wrongly.

I've had projects fail because we couldn't get the core algorithms working ...

Hell, most of my interesting failures so far have been "Okay, so computers can't do X (yet), or I'm too stupid to figure it out and don't know anyone smart enough to solve X"

A lot of my projects would sell like hotcakes, once someone figures out a practical implementation, or at least an impractical one.

I'd thought about that angle, and I've known a couple of those myself over the years (mostly second hand). But even in the cases I've seen, things might have gone much smoother had there been stronger communication about the specifics and what was (and was not) possible much earlier.

As soon as things look to be not possible, tell someone. If you're able to pull a rabbit out of a hat later on, great, but let people know that real hard limits (algorithm, processing speed, etc) are being hit. sometimes what someone was indicating was a hard requirement turns out to be a 'oh, it'd be nice to have that, let's move on' sort of thing.

So, while I get your point, I think overall there's still things people can do wrt communication even when there are fundamentally tech issues at stake.

That depends. Most of the projects I'm thinking about had Solve A Hard Problem at their core.

Granted, there might be a better way to solve it than devise some technology to do so that I never thought of.

> Have you ever had a project fail because you didn't know how to write to a file, take data input or query a database? [...] 10 years ago I realized that ... almost without exception, I can get the tech stuff done.

The examples of "tech stuff" you mentioned are very junior programming tasks. The "programming" the article talks about is all the non-PM/BA stuff: the overall technical design of the system, not just the file writing and database queries; the testing process from individual components to integration to customer involvement; the build and deployment processes, including impacts on existing systems and addressing security/privacy concerns, etc.

> I can get the tech stuff done. Of course, I'd like to do it myself, but I can get others smarter than me [...] to do the tech stuff.

Project managers and business analysts usually try to add technical skills to their resume by dabbling in some of the "tech stuff" of the projects they're managing. Usually this is the highest level stuff like architecture design or programming language selection or programmer analysis/selection: generally the stuff with the greatest impact on the success or failure of a project. You write "Of course, I'd like to do it myself" so I guess you're one of them. But those with PM/BA experience are the least able to do this project-critical tech stuff.

Project Managers get to dabble in this work because of their power in an organisation. They also try to keep their jobs by "creating" work and problems, just like middlemen everywhere. They stop technical people gaining too much power by splitting the systems into arbitrary projects. They give programming jobs to their mates in return for loyalty.

Despite their talk about being accountable for their results, in reality they cover their behinds in case they fail. When the tech stuff goes wrong, they leave behind a huge mess for programmers to clean up, usually with extra hours and overnight standbies. The business users get to do unit testing as part of their change acceptance process. The PM's go into recruitment and back into management somewhere else. A recruiter once told me "if I had a job like that on my books, I'd apply for it myself".

"You write "Of course, I'd like to do it myself" so I guess you're one of them."

Umm.... no, not really. I'm a developer who's gradually moved in to more business-oriented consulting over the last several years. I still do a lot of development (> 50%, certainly), but I've realized that for the majority of the projects I work on, the difficulties are not programming or tech skills/knowledge, it's making sure we all know what is to be programmed, and dealing with any changes that come up.

Everyone thinks they're stuff is unique/cutting-edge/hard/impossible/ground-breaking tech marvels. In some cases it is, but I'm finding those instances to be more rare the older I get. Why? My own skills are getting better (slowly), there's far more tools and libraries to tackle much larger problems better, and my own network of people I can tap has grown to include some insanely talented people.

"the testing process from individual components to integration to customer involvement; the build and deployment processes, including impacts on existing systems and addressing security/privacy concerns, etc."

I would posit those are far more in the realm of "communication" issues I brought up. Yes, you need to have a technical background to do them correctly, but you don't do that stuff in a vacuum. You do those things in concert with other people (customer, team, etc).

For example - the basics of build and deployment are known problems. One might even class them as 'junior' problems. How many times have you had builds fail because someone didn't know how to schedule jenkins properly? Or because an alert wasn't set up to notify someone of an issue? The mechanics aren't very hard, but deciding what the specifics of the processes should be is hard, because you have to communicate ideas/deadlines/responsibilities/etc with multiple people or teams. That's what I'm getting at.

They have failed though, because someone couldn't get security right.

Programming is the most important part of making software, programmers are right ... I am systems analyst

In today's economically rationalised world, almost every position in a company is important. If it wasn't, they wouldn't pay for it. Saying who is more important to the process is somewhat meaningless - wages are generally aligned to how difficult it is to replace a person's skillset.

The core activity of a band is making music. The bottom line can be helped a lot by marketing. Other roles may be very important to allow the musicians to focus. Sometimes musicians need to be kept sober or made to practice more, with which others can help. So other people can make value in a band and deserve to get paid. But take away the musicians, and you have absolutely nothing. Plenty of people have made good music without lots of managers over them. In that specific sense, musicians are the most important part of a band.

I think that's a flawed analogy, because the band is set up to sell the specific art of the musicians. Software companies are set up to provide a product using the craft of the programmers. It's a lot easier to keep the same flavour in your product if you have to replace a lead programmer instead of a lead singer. Programmers in companies don't do the equivalent of "I'm going to change tack and do a blues album this time".

Asking a room of programmers about the value of business analysts is going to result in feedback that is heavily biased.

We need not rely upon opinions here, we can be objective instead.

Let's ask how many business analysts without programming skills have made working software. Similarly, let's ask the same of the managers. And finally, let's ask programmers without any managerial or business skills how many pieces of software they've made.

My guess is that the numbers are 0, 0, and a lot. That's because programming is necessary to write software, whereas management and business analysis is only "nice to have". There is lots of great software that was not crafted by managers or analysts; Linux, Emacs, Google search, Facebook, and so on. Most of the stuff designed by product managers is one-off software that will have made no impact other than paying the team's salary for a while.

But in business you have to sell not just make.

That's because programming is necessary to write software, whereas management and business analysis is only "nice to have".

That is an interesting philosophy, but it has never been true in real life. Every major corporation in the world has added business analysts and PMs. Even the great technology companies you mention have many, many business analysts.

I love finding exceptions to rules, but I can't find an exception to the rule that if you want to accomplish truly great things with your company, you will eventually add business analysts and PMs.

Small companies will realize that the value of having a marketing professional over a "growth hacker" is when the marketing professional can call a major company and negotiate an ad deal due to their experience doing so. Or when a finance professional can help hammer out terms of a new round of debt financing that allow the company to grow without giving up equity etc.

As a business professional, I understand that hackers have value, but I also understand that even HR people have value. Just because I don't know all the value they have, does not mean it doesn't exist.

This is a cross-industry problem. As engineers, we are trained to find value in concrete products. We see it in software development, as well as in, for example, construction (ask any structural engineer about how architects are perceived)

We tend to forget that, not so long ago, "classical" engineers looked at programmers as lowly-technicians that only used their computers, which were the real valuable product.

But working software does not mean successful software. If it wasn't used, if it didn't helped people or solved a problem, how can it be considered successful?.

ALL of those products/projects you list did required managment and business skills to be successful.

If it wasn't used, if it didn't help people or solve a problem, how can it be considered successful?.

The team got paid. I've written a lot of software that nobody has ever used. It was fun so I consider it a success. Similarly, many clients have commissioned many silly projects that they paid for and never used. (I was once tasked with writing a fourm system for an insurance company's customers, where they could discuss their experiences in having that company's insurance. Despite the software being up to their spec, the project was cancelled because it was a terrible idea. I got paid nonetheless, which could be considered a success.)

ALL of those products/projects you list did required managment and business skills to be successful.

Where's your proof? I'd say that projects like Emacs and Linux are successful in spite of their leadership's social skills.

I got paid nonetheless, which could be considered a success.

Then that's the problem, we mean different things when we say "success". For me, and for a lot of people I believe, "successful software" does not equals to just "the team got paid".

Where's your proof? I'd say that projects like Emacs and Linux are successful in spite of their leadership's social skills.

So, are you implying that all the others were?

Business/Management != Social Skills. I'm not familiar with Emacs history as a product (and I'm not sure if it was "successful" under your criteria), but Linux did required incredible management skills, and a lot of business-savy people for spreading it in the comercial world.

The team got paid. I've written a lot of software that nobody has ever used. It was fun so I consider it a success.

The question that must be asked here is whether your level of fun should be the best indicator of success. It would seem to me that the entity paying the money should be the one to define the criteria for success, and I think it's quite logical to presume that they would not accept the developer team's level of fun as success criteria for what I hope are self-evident reasons. I believe it would also be self-evident why the entity paying the money should be the one to define the success criteria also. In your case's case, they'd probably say the project was an unfortunate failure and waste of money, but maybe worth the try anyway, so oh well (i.e. we were aware that there were risks, too bad the risks became reality).

For open-source projects, nobody is paying the money usually (as they're usually staffed by volunteers), so of course the developers can define the success criteria in those cases.

The team got paid. I've written a lot of software that nobody has ever used. It was fun so I consider it a success.

This sort of attitude is one reason why PMs and BAs get paid more than developers.

I agree. Good/Great programmers do it because they like to. They could go a million years and never make any money with the software they write (assuming they don't need to pay bills) because there is value in the process for them.

To the business, even in a software company where development is tier 1, and not a traditional "cost center" and bundled in with IT, development still needs to produce tangible business results. This requires skills that do not directly overlap with development skills.

Programmer: I can build it, I should get paid more

BA/PM: I can tell you what to build so we can attract paying customers and both get paid.

Software is needed. But so are customers. Getting customers is a more valued skill because its the blood of the business. Programming is necessary, but I'd say 95% of the problems needing to be solved are not technology problems.

What management and business skills does Emacs require?

The value PM's provide is enabling specialization of labor.

This right here should have been the top rated comment on StackExchange. And, everything else the parent said is dead on.

FWIW, I think the question should have been "Why do bad PMs/BAs frequently get paid more than good programmers?"

As far as I can tell, that question has traditionally been our motivation for inventing "a narrative of moral superiority". When you're faced with an ugly truth such as "it sucks that the world is not fair", you need something to make you feel better about it. That "something" is usually along the lines of "Yeah, but I am a better person!"

Theory X (people only work hard when figuratively whipped) and Theory Y (people only work hard when treated like professionals) are real things in HR management. But they've largely been superseded by Theory Z (both Theory X and Theory Y have value, but a bit of both works best).

I totally agree with this. I am a quant working at a bank writing trading strategies in C++. I have a colleague in "Infrastructure" (they call it) who sits two desks away from me and he writes C++ code that loads my code and runs it on a massive grid, does load balancing, interfacing and all kinds of cool stuff.

Yet he's in a "cost-center" and I'm in a revenue-center when, basically, without his work my code would be as useful as European politicians right now. This is insane but that's the sign of organizations that have hierarchies misaligned with what generates value for them. Basically, such organizations haven't figured out how to assign such "hidden" value a number while in my case it's simple to judge the value generated. (Actually, sometimes the ones in power are too afraid to admit they'd be useless without these guys).

Think about it, a programmer can very well exist without BAs/PMS etc but BAs/PMs can't exist without programmers.

> Think about it, a programmer can very well exist without BAs/PMS etc but BAs/PMs can't exist without programmers.

That's exactly the same kind of self-bullshitting your parent comment was arguing against. NONE of the parts of a business can really work effectively without the others. A bunch of super-smart skilled programmers with attitudes, no leaders and no clear requirements is going to produce a lot of efficient, scalable, well-designed code that represents a handful of sub-projects that can't be integrated and don't do anything useful to end users.

I realize this is an extreme case, but you should check out Valve's corporate structure. No one has a "title", everyone can move to whatever project that want to work on, and they still turn out excellent software.

...but not on schedule.

Nothing ever get's built on schedule or within budget.

http://en.wikipedia.org/wiki/Valve_Time#.22Valve_Time.22

Yes. But Valve is a bit of an extreme case.

Just extremely honest about it.

While I wouldn't necessarily disagree with that analysis, Valve time has more to do with announcing release dates and then going way over them than it does not shipping on internal deadlines.

>> Nothing ever get's built on schedule or within budget.

If anything, things always deliver on schedule and within budget. This is due to massive scope creep (scope reduction) and reduced quality.

Sorry, what schedule?

And I'd bet you that every one of their projects with more than 10 people working on it has people doing mainly what is clearly recognizable as project management or business analysis.

BAs and PMs can't exist without programmer because they can't build while programmers can exist without BAs and PMs because they can as well as any human find out what is to be done. Seen any freelancing PMs or BA?

"Seen any freelancing PMs or BA?"

Seen many.If you understand business domains, have experience dealing with lines of business, managers, executives, you can freelance. Not everyone needs to (or should) write code.

But a freelance BA or PM cannot produce software independently, whereas a developer can. A developer has all of the skills of a developer, and many of the skills of a BA/PM, the reverse is not true.

A developer can definitely produce software independently. I do that as well. But the question is about selling that software to the business users. This is where a good BA/PM comes in again. I have said before that in small setup such as startups etc which produce software as their core business, a developer can possibly wear all hats. But in large corporate settings, developers do not want to go through the pain of people management, bureaucracy, follow ups etc.

Only if you choose your definitions to support your preconceived result by counting anyone with any programming ability whatsoever as "developer", no matter their primary field of work and expertise.

> programmers can exist without BAs and PMs because they can as well as any human find out what is to be done

Many of them may be able to do some of that, but most will be really bad at one or more aspects of it. What exactly is the problem with having people who specialize in these things?

> Seen any freelancing PMs or BA?

Lots.

I'll counter that - even not-so smart programmers with enormous egos would be able to ship something clunky, partly broken, not feature-perfect etc. (case in point: Linux - do you think they required full-time BAs to manage this very nicely working, feature-rich product? They did the BA/PM work themselves with Linus and others as anchors).

A team of super-smart skilled BA/PMs will produce zero, zilch, nada if there are no programmers.

"super-smart skilled programmers with attitudes" would figure out their priorities and the needs of their architecture. That's why Valve said that the single most important task is hiring - if you don't have super-smart people who can put egos and politics aside in favor of actually shipping something great, then you need BAs/PMs.

It's only when "who's doing what" becomes a problem that BAs etc are needed. If programmers were willing to spend some time doing "BA-work" and are willing to be bombarded by customers with inane queries and are willing to ask them questions to elicit their needs, then there'd be no need for BAs/PMs.

The only reason BA/PMs exist is because there are only 24 hours in a day and programmers can't do the above.

You are being kind of vague in your definition of "BA/PMs".

Developing a business model is very different from doing customer support, planing and managing programming, and doing business inteligence/marketing.

You are confusing business analysts from management consultancies like McKinsey/BCG/Bain (or CEO-reporting groups like the SPG at American Express) with software BA/PMS (the people under discussion here).

Software BA/PMs have nothing to do with business models and strategic planning.

About Linux: Linus is the brilliant manager there. He invented git to be able to drive his development methodology. He pushes back and brutally steamrolls rogue features into submission.

Linux is actually a good example of how a manager who is technically adept can do wonders for a project. It is NOT an example of how you do not need PMs.

It's not self-bullshitting. In many smaller companies the programmers already have to play the roles of the BAs/PMs.

Can you say the opposite for BAs/PMs? These positions are introduced after an organization or project reaches a certain size. It's simple specialization, you don't want everybody to do everything. When this transition happens, some programmers might become BAs or PMs. Alas, what about the opposite? How people that started as BAs ever make the transition to programmer? There is an obvious trajectory here.

You're talking about tech companies where the business is basically programming. In a company that builds cars or medical devices or a bank, a programmer is about as likely to become a BA as the other way round.

As for project management, that's, well, a management position. Tends to have a better salary, prestige and career prospects than non-management positions. That fully explains why many people want to move into management and hardly anyone who's chosen it as their original career wants to move out of it.

> In a company that builds cars or medical devices or a bank, a programmer is about as likely to become a BA as the other way round.

This makes no sense to me, what makes you think that?

Because in those companies, a BA needs in-depth knowledge of the domain that is as hard and slow for a programmer to acquire as it is for a non-programmer to learn programming.

> Think about it, a programmer can very well exist without BAs/PMS etc but BAs/PMs can't exist without programmers.

I do a lot of programming, but I think I bring a lot more value in the programming I avoid (or otherwise stop from happening).

Code is always a liability. Functionality is often an asset.

A BAs/PMs can reach the conclusion that a private label implementation (or 3 of them, with some outsourced integration work outsourced to competent integrators) is a much better solution, whereas a programmer (with any ingrained survival instinct) is unlikely to say "you need to fire me and all my team, and outsource this", or even think that, regardless of how true it is.

So, BAs/PMs can exist without programmers, and often do.

The reason you are getting more money than your friend is that (a) he is easier to replace, (b) you - or at least people in your group - can demonstrate your worth to the company, and (c) if you go to work for a competitor, the knowledge that will leak through you is much more harmful to your current employer and helpful to your new employer.

"A BAs/PMs can reach the conclusion that a private label implementation (or 3 of them, with some outsourced integration work outsourced to competent integrators) is a much better solution, whereas a programmer (with any ingrained survival instinct) is unlikely to say "you need to fire me and all my team, and outsource this", or even think that, regardless of how true it is."

Ah, but that's management at a consultant-level - you can hire an external consultant to do that for you. A company (or at least I wouldn't) won't hire PM/BAs as permanent employees to do that kind of stuff - particularly when you need independent advice - BA/PMs also have survival instincts, you know - they will always insist on "project management" regardless of how trivial the task is - if their job is at risk.

(I think the quant vs developer example is an exception - the marginal returns for a bank investing in desk quants is more than that for investing in devs - although what's the critical ratio is something hard to determine)

Which is worse, builing something nobody will use or not building anything at all?

Long story short, PMs are closer to the money. When you're managing a project, you know you have a budget of X dollars to get it done. If you get it done in X-P dollars, you can take that to your boss and immediately show that you made, or saved, the company P dollars.

As a programmer or engineer, you may not even be directly aware of what the project's budget is, so it's harder for you to demonstrate how much value you're providing.

100% agree. It's always about how close you are to the money. The more direct value you provide, the more you get paid. This is why lawyers get paid so much, because firms know that for every hour they bill the firm makes $X dollars.

Programmers provide indirect value. If you architect a system that saves months and months of time later down the line, how do you value that?

with hugely inflated numbers that assume the best case scenario for time-savings, fancy charts and graphs, and perhaps even a buzzword laden powerpoint presentation during your annual review.

Accountants are even closer to the money. That does not make accountants to earn more.

My PM is on vacation this week and I've had to partially fill in. I have been getting frantic urgent emails from roughly 7 am till 1 am. If this is what the guy puts up with, he deserves a couple bucks.

For receiving emails?

sure. try to be the first point of contact for a massive project for anyone under the sun including fellow developers, business users, IT heads, business heads, internal consultants, external consultants, SMEs etc etc. If you can handle all their queries (email/in-person/phone call/video conference), you certainly sir do not need your BA/PM.

No, for making it so that the rest of the team doesn't have to deal with emails from 7am to 1am.

Part of the PM's or manager's job (at least if they're a good one, anyway) is shielding the rest of the team from administrivia, so that they can be productive.

I crossed over from Project Management into Engineering, and my experience was that as a PM my job was to be bothered from Sunup til Sundown and periodically in between. I was expected to know everything about anything that I was asked about, and I was responsible for a large number of people's output without having any authority over them.

It was horrible.

I think the issue with the SO question is simply the view that what PMs and BAs do isn't 'real' work. They might not write code, but sometimes they're the only ones making it so the engineers can.

What you describe is a dysfunctional organization, not a justification for PMs.

I think that is the right answer - a dysfunctional organisation is the justification for PMs and BAs

if the film crew \ theory x idea is right then an org aisation that is becoming dysfunctional hires more PMs

I suspect that they are symptom initially and then cause.

I disagree. A PM is an excellent communicator between engineers and the rest of the organization. It's not a matter of dysfunction, but a way of filtering what is important and what isn't.

I've been in both situations where a) I am in direct contact with the rest of the organization and b) where an intermediary is. I prefer B and that is what a PM is for.

Some large organizations may be able to eliminate the middle man, but I wager they've dug a ditch so deep they can't tell the difference.

My large organization has the managers of engineers, who are engineers themselves, act as the intermediary.

I've met very few PMs who know enough to filter anything.

Or a large, international organization with employees and clients all around the world, each of whom believe that their problem is the most important thing in the world.

I've worked for some of the largest corporations in the world, 3 of them in the fortune 100 one of which is a fortune 20 company.

I've seen it done well and done poorly at that scale. What the person I replied to was describing is a dysfunctional organization, not a functional large organization. Creating a large functional organization is just like creating good abstractions in software. You have to figure out how to structure things so that teams/business units can work together with minimal communication across teams.

At a job some years ago I got SMS messages from system monitoring almost continuously, around the clock. Most were spurious "this is an indicator that something might possibly go wrong" status messages, and I worked hard to smarten up the monitoring. Once I was only getting messages when something actually was going wrong, I worked hard to make the system more reliable so that I could get a good night's sleep. The more I continued down that path, the more time I had to make the system even more reliable and also add needed features.

This sort of approach is not limited to coding at all. It does require that you have some control over the issues that take up your time and energy. If your PM were to quit and you were to take up that position, I'd advise you to take an in-depth look at removing the problems that lead to frantic, urgent requests.

Most of them were due to an outage we had on a "legacy application" due to some sort of screwups with the VMs it was running on. This caused reps to hammer me with questions about our SLAs. Of course I had no answer.

Many more emails were from offshore devs from a project I'm not normally involved with who didn't understand our specs.

There were also a smattering of issues with reps getting calls that our app was down. Ask a few questions and it turns out the person is using it on a train in a tunnel in the middle of iowa type of situation. It's a web app.

Sounds like that's mostly outside the PM's sphere of influence, which is a good sign.

On my friend's company that's the role of customer support. To extract what people want and pass it to the workers that can provide it.

There is a great book called "Management by Baseball." The author of the book points out that baseball managers are typically former players, and they usually believe that the most important position on the team is whatever position they used to play. I doubt PMs regularly make more than engineers across all levels at all companies, but in general the outcry you are seeing about this isn't limited to engineers. In my experience, almost everybody at almost every company thinks the thing that they do is the most important.

I can tell you that I have worked in 4 major roles: - engineer - sales engineer - business development - CEO

In my experience, the pay is directly tied to the need of the position to manage uncertainty and ambiguity, and evaluate difficult risk/reward tradeoffs. As you move up the hierarchy, you do more of this.

You can form a baseball team entirely out of players. They might even play pretty well. You just can't form a baseball team entirely out of managers.

If the upper levels are in more uncertain and ambiguous situations, that makes it even harder to judge performance, which will give even greater weight to wild heuristic guesses in hiring, and more cover for things like nepotism.

There's a reason why we all aspire to be Rock Stars in our respective crafts and why the entrepreneur in us wants to hire the Rock Star.

Give me a business analyst who knows his marketplace inside and out. Who can break down the value proposition our business offers to 25 different demographics the same way John Madden breaks down a cover-two defense. Who can see where the market is going before the market knows its going there, and gets the team ready and motivated to get us there before any of our competition even realizes they're behind.

Give me a project manager who can see fires before they start; who can guide 30 people to do the work of 300 and can keep 300 people working efficiently toward the same goal. I want a project manager who craves efficiency in their process like an addict craves meth. Give me a project manager who obssessively clicks the refresh page on O'Reilly's website waiting for updates on books about continuous integration, issue tracking, and version control practices.

And give me a programmer who knows the entire stack like the back of their hand. Who can program Ruby, Python, Java, Haskell, Clojure, Objective-C, C++, C#, Go, Scala, and every kind of Javascript. Who understands what the different hardware constraints on a desktop application and a web application. Give me a programmer who writes elegant unit tests for all of his code, and evey algorithm is the minimum O. Give me a programmer who happily mentors every other developer in our shop and, like Michael Jordan, makes everyone else better.

Give me these three, and I'll change the world, and I'll pay each of them far more than my competition.

Your view of business roles is flawed. The programmer has to do those things but also know the marketplace better than the business analyst. the programmer has to guide the less capable and new programmers on the team. The BA can't. The programmer has to set up the Continuous integration server, issue tracking system, source control repository, and use all of these things that the PM is reading about with amazement. In fact these things are an insignificant afterthought to the programmer, who has learned how to set up administer and use multiple tools of each.

I think you're giving "programmers" too much credit or "project managers" not enough.

I'm the product guy at a small-ish company and my main dev-side pet projects are deployment/CI and development workflow, and I've implemented 95% of the solutions for these as well as architecting our overall system.

Some would just say I'm a programmer then, but I think what padobson was getting at is that good people in any of these roles get their hands dirty in optimizing their area of concern, even if that overlaps in other areas.

Those who are like what you describe above, are busy changing the world themselves. They are not interested to work for you.

Some of them think that they can change the world inside an organization that gives them the tools and power to do so - one of the best programmers I've met works for Microsoft, he loves Haskell and all that, but worked for the C# team and has moved around inside Microsoft, doing interesting work.

I don't think he'd be a good fit to try to change the world by himself, but he can buy a good vision (or a well-sold bad one maybe :) ).

What companies are these people working for? The ones I've looked at and the ones my friends work at pay their programmers significantly more than PMs and BAs.

For instance, for companies where programming and IT is not perceived as a core competency and asset, but a cost.

This; in my experience median compensation for programmers is comparable to PMs, and the high-end of programmer compensation is significantly higher than that for PMs.

A programmer high on the compensation scale will typically have decided to stay on the "Individual Contributor" track and top out as a "Distinguished Engineer" or similar title, but still be considered as a programmer. A PM who has advanced to a similar level, on the other hand, is likely to be some sort of VP or SVP and considered an "executive". That is to say the PM compensation track divergers, while the Engineer's stays the same

Let me be more clear: I'm talking about something like an MTS or Senior Engineer, rather than a Fellow or Distinguished Engineer (and FWIW, at many firms, a Fellow/Distinguished Engineer may very well have compensation comparable to a Director/VP).

Only if you are Bruce Lindsay and you invented Joins would it be comparable. Directors or VPs often get quarterly options

Correct. I run a software business. Our top coders are paid higher salaries than any "managerial" roles, by some margin. That said, the managerial roles have more upside in terms of bonuses, but that arises more as a result of how one goes about motivating people with rather heterogenous talents.

Aside: Yet another useful and thought provoking question and set of answers on SE shut down "because it's not a good fit for the format".

Yes this is getting annoying.

I think when a site reaches critical mass, the pedants and moderati (play on illuminati) start screwing it up. Wikipedia is another fine example of this.

I've stopped contributing to stack overflow now due to this (I accumulated 20k karma to give you an idea how much I thought the idea was promising)

It's not really as easy as you make it sound. Incorrect moderation will cripple a site and prevent people from contributing, but moderation is necessary to prevent the site from declining in quality. Without moderation, a site's quality will decline with its increased size. The default subreddits on reddit are a good example of what will happen without sufficient moderation.

I agree but both SE and Wikipedia suffer from moderators being picked based on karma. Karma is achievable easily despite any motives and personality traits which are bad. They should be picked by humans as they are a better and more objective judge of who is fit to moderating a site to the site's standards.

AFAIK, SE mods are not picked based on karma, you can nominate yourself to be mod, and users will vote according to many indicators, not karma only.

Elections: http://stackoverflow.com/election

While this is correct, I think his complaint is about the privileges that high-reputation users get. Most moderation is done by ordinary users, not by elected moderators.

Your assumption is correct.

That's not strictly true.

Full moderators are elected... but high-rep users take on a ton of moderation tasks.

It was closed after 2 pages of answers and hundreds of votes - not so problematic IMHO.

I disagree. Opinions change over time. Its a great place to observe that.

If there was no problem, why close it at all?

That's only due to the age of the question. If a similar one were asked today it would be shut down before it got 2 answers.

+1. But neither coding horror nor joel give a sh*t about that:

coding horror: http://news.ycombinator.org/item?id=4132668 - Basically says "If you're bitching about it, it's because it's working as intended"

Joel: http://news.ycombinator.org/item?id=4132020 - Says "Yeah, but look at the quality"

I just want a filter for high-activity closed SE Q/A's, that way I can read highly engaging and interesting topics.

create "mystackrunnethover.com" (or mystackoverfloweth.com) and just post those questions... use OSQA to keep the same format?

There's already a http://programmers.stackexchange.com/ but personally I find its answers woefully lacking compared to similar ones that happened on SO.

There seems to be a certain type of person drawn to a site dedicated entirely to program architecture which means the input from more practical programmers (and their sanity votes) gets lost.

Well, part of the funny thing about this story submission is that it's a programmers.se.com q/a that got still closed by mods.

Honestly, I don't think it is a useful or thought provoking question. As numerous people have pointed out, the entire premise is false. Intentionally or not, it's basically trolling for "programmers are great too!" type comments.

> Intentionally or not, it's basically trolling for "programmers are great too!" type comments.

Wow, this is not true at all. Just because you don't see the question as useful doesn't mean it isn't.

As an entrepreneur (and a programmer), I am genuinely curious about the situation. We don't pay our PMs as much as we pay our programmers. Does this mean we're doing something wrong? Did we decide this because of our technical bias and should we give our PMs more credit? Why do other companies do this?

This is the point; its a question based off of a faulty premise.

That's fine by me. IMO, Reddit (as an example) was a great site, until it became popular and the subject material moved to the lowest common denominator. HN would be ruined too if/when you can get away with posts that do not stay within the topics/style that the community was built up from (I would figure that's why politics/sports are explicitly disallowed, and I am happy that such topics are kept off here)

If programmers.SE is supposed to be a site for "professional programmers interested in conceptual questions about software development" and this question doesn't fit that description, turf it. Like I'd expect you to turf "Who are you voting for in the upcoming presidential elections?", no matter how popular that would be.

Here's that same false dichotomy again that was in the last StackExchange thread.

Listen, it's not a choice between "Let the moderators run wild" and "let the userbase run wild". It never has been. Those are the two silly extremes in an entire spectrum of possible policy choices.

StackExchange sucks because the moderation is too heavy.

r/programming sucks because the moderation is too light.

HN is somewhere in the middle but trending towards SE (if the number of good comments which were hellbanned are any indication)

I'm a little surprised that the top answers on Stack Exchange accept the premise that analysts and PMs get paid higher salaries. That is certainly not the case at my company (mid sized tech startup), nor I would imagine at most other tech companies.

this is the case for many larger organisations.

I'd argue that most programmers don't work at tech companies.

As a developer of 20 yrs I dispute the claim "Programming harder than project management". Pming is hard, stressful, and often thankless. And I've seen multitudes more good devs than good PM.

Finally, I'm not sure pms do get paid more.

This is a true statement for any industry with a highly skilled labor force, whether you write code, run excel models at a bank, or make jet engines.

From my observations/experiences, these three things are consistent (and it's mentioned throughout the thread):

1. Be closer to the money: There's a reason why sales people make more money than marketers. Look at Salesforce.com's operating statement and they spend >3x more money on sales and marketing than R&D.

2. Never be the best at making a widget or they'll have you make the widget forever: If you're the best at something highly technical, the management would be crazy to promote you to something more client facing or more managerial. There are some organizations that truly value technical skill on a meritocratic basis (think traders at a hedge fund or rockstar developers), but they are more rare.

3. If the boss/rest of the company doesn't know what you do, you won't be compensated for it: I wonder if the reason why Codacademy/Udacity is important is because it starts to teach non-technical people like me the value of good code. I have far more appreciation for my technical co-founder now that I've tried to code than I did before (and I thought I already had a lot).

In the end, my suggestion is to gain a broader set of skills that make you more marketable to your company or join a company that appreciates your ability.

This is a rerun on HN. It's also untrue - analysts and PMs don't typically make more than engineers, this is a bit of programmer urban legend. I actually took a paycut for my stint as a PM

I view the PM role akin the role a sweeper plays in curling. A good PM will clear the path for others on the team to do what they do best. Sometimes that's wrangling with devops so the developers can keep programming, or it's calling a meeting with stakeholders to brief them on potential issues before they get out of control.

A good PM is offensive, not reactive and thats why a lot of times it seems like they're just calling meetings. They're generally the only person that interacts with all the different teams (management, QA, dev, IT) and so they can see the upcoming roadblocks. IF they get those solved beforehand that's worth some $$$ :)

I always think of "hand-eye coordination".

Hand = Developers Eye = Customers, Marketing, C-staff (read: stakeholders) Coordination = Project managers

Just a tip, if you want to keep with your sports metaphors, and meant to say "a good PM is on the offensive", you probably meant "a good PM is proactive (acts to solve a problem before it shows up)". Describing someone as 'offensive' is saying there is something about them that offends you.

ha, you're right, thanks. I'll leave as-is so your comment doesn't look garfield-minus-garfield.

"To be on the offensive" means "attacking something" or "being aggressive towards something", not that the person who is "on the offensive" offends somebody in the sense that that somebody's feelings are hurt - http://www.thefreedictionary.com/go+on+the+offensive .

It's arguable whether or not a PM should be that aggressive, but I'd say his expression made sense.

"A good PM is on the offensive" and "A good PM is offensive" are two different comments, the latter much more ambiguous and easy to misconstrue.

Yes that's right, because the person I was replying to used "to be on the offensive" I didn't go back and check, but yes the OP used "offensive" which is quite different. My bad.

The easy answer is: because that is what the market dictates. Programming may be difficult, but I'd be willing to bet there are a lot more programmers out there than people willing to be a PM (and stick with it).

Yep. And notice you got down voted for saying so. It happens to me every time. Programmers don't want to hear that in many industries (those that aren't pushing cutting edge tech) their skills are a commodity. It's just a fact, and globalization is making it worse.

This. Programming is skilled labor which is why they make more than the guys that work at McDonalds but there's still a ton of programmers out there. There's a lot fewer people out there that know what to create, when to create it and how to get the right team together to accomplish it than there are people who know how to program. For every Elon Musk how many aerospace engineers are there out there?

precisely so. and i don't care - no, actually i'm glad that PMing pays more than programming, so that it will attract people willing to do it and let me concentrate on the things i find fun.

Why do you think BAs and PMs get paid more? Is there any evidence? Anywhere I've worked they are very comparable for experience levels or the programmers get paid more. I think this is an inferiority complex based on not feeling 'cool' like the business guys. Other business roles likes sales and management (both tech and biz) get more because they have more responsibilities.

This has been pointed out already in several comments, but it can never be stressed too much -- because programmers can't negotiate!

Want to get a higher salary? Do yourself and a broader programming community a service.

Learn to negotiate! Learn to negotiate! Learn to negotiate!

They get paid the same as junior programmers where I work. They are deemed as equal value to the company.

To be 100% honest a good developer should be able to take on all three roles. PM and BA are skills which should be built in as well along side other basics.

"a good developer should be able to take on all three roles" I generally would agree with you but it is not that simple. A good BA or PM can do lot of dirty work that the programmers can be shielded from in order to focus on their core value: code/build the product. Some of those dirty tasks are: 1. dealing with difficult business users who keep changing their scope and requirements. Can you imagine if you had to develop the product while the scope keeps changing ? A good BA/PM would negotiate that for you and help stop scope creep. 2. Looking at the bigger picture. This includes ensuring all the connected project members are delivering, communication is in place, people are talking to each other and everyone is on the same page. No one enjoys doing this dirty work but it brings tremendous value to a project.

There are more like these but you get the idea. Yes there are BA/PMs that do not do their task well but incompetence is not retricted to a particular line of work, is it ?

Where is this "good developer" exist?

Most good developers that I know of don't communicate as well as BA or PM when it comes to interfacing with non-technical people.

NB: Not to say that these developers are bad communicators. They're less patient, they tend to have an "ideal" picture, and they work better with computers than a normal human being.

they're usually contractors these days to be honest.

I always sit in the middle between humans and machines and am quite happy getting my hands dirty with both sides. Communication and management is part of the job.

Your reply made my day. Typically HN-ers would reply with something out of the ballpark of Reality. This one is an honest, down to earth, reality reply.

Contractors, on the other hand, have to deal with Accounting department, BAs, PMs, etc and then ship something... :D

I believe its similar to what happens in other sectors: PMs have to deal with people, do lots and lots of schleps without the constant rewards of creating something, designing something beautiful or the serendipitous discovery of something remarkable. As a developer I m not jealous of their position, I know they get paid better for doing what i Don't want to do

"I know they get paid better for doing what i Don't want to do" You summed it up well. BA/PMs do the dirty work that developers can be shielded from. Dealing with people is always a dirty work but extremely difficult to master. A good BA/PM is one who does this well. If you can tell me that you can get anyone to do anything in a project by your people's skills, power of communication, aggression, I would pay you well and would not want to lose you.

The reason is just culture there is nothing else. When the major professions Lawyers, MBA's, Doctors, Engineers became part of the majority work force a culture emerged. Somehow the people who in aggregate create the most value in the working world as far as dollar is concerned started to under bid each other for competition, you look at any software/engineering contract there is always and under bidding war going on, always.

But with Doctors, MBA, Lawyers they are always looking to get the most personal financial benefit, and even put in laws and other policy to assure they will, hence the prestige. It has gotten to the point where engineers are seen as cogs as I can hire someone else to do the same thing, plus they are paid the least anyway so they are easy to replace.

I think it is just starting to change if you go in the tech/startup world you can make more money ,developers are paid even over $500k, the difference is the culture they value your work.

Programmer for Citigroup here, Computer Science and Financial Engineering major-

At citigroup, entry level programmers are paid just as much as entry level business analysts. In a large company, no one needs "great" programmers. They really jsut need capable programmers to get everything executed correctly in such thick beurocracy. The reality is that good MANAGERS are much harder to come by, so whenever anyone, business side or technical side, proves to be a good manager, they move up and get paid more. So it's not that the programmers are paid less, it's that they don't really look like programmers once the company wants then to manage programmers, which is much much more valuable.

Bottom line, being a "good programmer" won't get you paid more. Anywhere. Not even at google. Showing that you can make a company productive and be a good manager will always get you paid more, because those are fewer and far between.

As an employee working at a consulting firm, I understand the difference in a contract environment. Me, as a programmer, charge a client for my time. The most money I can possibly make is my charge rate times however many hours. But, I have a manager, they are in charge of several, perhaps 20 programmers, working on various tasks for various clients. In reality, my salary is only about 50% of what my company charges for my time. In this scheme, money goes towards overhead, and the rest to management, whom I do agree, do a good job keeping us programmers employed, and winning contracts to work on. could I do this all myself and charge more money, sure. But in a bigger consultancy, there is a great network effect, and more jobs to be done, thus I will less likely be out of work. Is it a pyramid scheme? yes. Do I hope to be on top at some point? yes.

They're not?

I've seen very few places where PMs and analysts even get on par with normal engineers (aka, non junior).

In my engineering group, we don't have project managers or analysts. We have product managers (who are responsible for much more than a project manager, and make more than the average PM, methinks). The lead engineer on each project does some PM-y tasks, but it's generally up to the product manager to produce the documentation/charts/spreadsheets.

In our operations group, there are PMs, but they are responsible for more than managing programmers on projects--they oversee the whole project, and must manage the resources from several sub-groups. Additionally, they are the first point of contact for the client. They are well-compensated, but they are also responsible for the whole of a client project.

Depending on the aggressiveness of the corporate culture, the first point of contact also gives the client one non-sales throat to choke.

I just transitioned from an engineering role to a product management role. Product management means different things in different companies, but generally a product manager will interact directly with every other part of the company and "own" the product plan ---- what needs to get built and when. Engineering owns the how.

That said, I think project managers can really help things flow. If you've got a process you are sticking to, a project manager can help make sure things get done when they need to. This is especially important when lots of things are happening simultaneously (lots of clients and client requests, lots of business development effort, lots of growth, technical challenges).

Good business analysts and PM are more likely (maybe because of the situations they are involved in, or because of their training) to realize and explain what value they bring to the company.

For most "regular" programmers, it's not that clear :)

I think I may be due to supply and demand.

PM's tend to be local, which isolates them from outsourcing salary pressure (decreases supply). Programmers can be outsourced which exposes them to more salary pressure (increases supply).

In my opinion, it's because, outside a few rare companies, programmers are generally viewed as mental laborers: the digital, modern equivalent of blue collar workers.

Some comments above seem to rationalize this by saying that software development is viewed as a cost center. Perhaps that's part of it. But, there are many types of cost centers but which aren't viewed like programming.

It's simple, really. The core of society is composed of... You guessed it! Social shit!

So why do lawyers, politicians, lawmakers and managers get the most money even though they do nothing useful? Because we do not reward what we do not understand. Engineering, the sciences and the arts are esoteric enough that only a small collection of people 'get' them. Arguing a criminal case, promising to fix society for the billionth time, drawing up a law or telling people that they should do what you say because everyone says that you're the person to listen to is something that everybody can understand. Every person on this planet understands that a new law will affect them just as they appreciate that the country going in a different direction will do the same. In comparison, few people know what goes into making the world tick and how much of their lives are supported by IT infrastructure.

Ofcourse, everybody can understand cleaning, cooking and chopping wood too, so why do those professions pay so badly? This is where supply and demand come in - one needs higher education to perform bureaucratic functions; this is not so for cleaning and cooking. Since getting that education costs money, motivation and time, most people cannot afford it, hence it is in comparatively low supply and therefore more expensive.

In other words, it's a combination of how easy it is to understand and relate to the profession coupled with the barrier to entry.

In my not-so-humble opinion, the fact that we live in a society which values talking over walking is completely and utterly idiotic. We've all been had and we're having ourselves for doing so little about it. However, I feel no resentment towards people in these professions - the game is broken, the players are only doing what they can. The best we can do to fix this situation is to educate ourselves and each other. When the older generation dies out, the ideas in our heads will become the status quo.

Well, who should get paid more, the getaway driver, or the guy who orchestrated the bank robbery?

Any discussion on this topic always leaves me more confused than I was before reading it.

I'm a programmer and I think they are worth more too. It's a disaster when you have a bad business person and lose investors because there is no one to meet them, or it takes several months longer than expected to hire a desperately needed graphics designer, etc.. I've heard managers of mine mention getting 1400 emails a day, and I bet a lot of it is bitching they have to put up with about budgets and timelines, and business considerations - not fun coding stuff like I work with all day. You couldn't pay me to take a business job, but I acknowledge it is more essential to the actual business.

If importance were gauged by doing dirty work without which things would fail, then the janitor is also more valuable. But janitors are cheap because they are easy to get.

If good* PMs are paid more, it is because they are harder to get. That doesn't mean they are more important, just that the company believes them to be worth it and does not believe it can get a better deal without paying unreasonably for it.

* good means whatever the person hiring thinks it means. If the hiring manager believes in auras or psychoanalysis or nepotism, then those things will determine the hire.

When I'm in the mood to wear my extra cynical hat I quite like the developers who think good business analysts and project managers don't add significant value.

Gives me a heck of a competitive advantage :-)

I think that people higher up the chain get more money because that's how ultimately they are given authority. If someone who earned 25% of what you did, continually told you to do something that you disagreed with, you would probably think 'why am I listening to this guy telling me what to do?' This organisation doesn't value you as much as me, therefore I think my opinion is worth more than yours. Therefore I'm not going to do what you say. Consequently you don't have that much authority.

Something like that.

We make money in technology by making computers do things for people. This means there are two, equally-important pieces: computers and people.

PMs and BAs are supposed to be able to both understand and bring these two elements together. Of course, whether it works that way in reality is another story.

I can always tell I'm in a room full of programmers when they say "coding" is the most important part of making software. Oh really? That's a bit like saying the person laying asphalt on the road is the most important part of making the road. Oh, hey, what about the Engineers who designed the roading material? The Planners who decided where the road should go. The Project Manager who actually gets people to do things, and stops management from changing their mind about where the road should go, and when it should be created.

Nope, just the guy physically laying the road.

I had a big debate with a programmer about why Business Analysts, Project Managers, and even Enterprise Architects get paid more than programmers. Programmers create something from nothing. Without them, there would be no software. And that's indeed correct. But has the problem of getting software working in large enterprise environments been down to a lack of technology?

Generally not. It's more down to those human factors like what are the requirements, who is the stakeholder, who has responsibility for this project, who's got the budget, what are we doing, when is this ready, why did we build this when we could have bought that, all of these soft skills, they're the reasons why software projects fail. Not the software (generally, don't find an edge case and be all Aha!).

That's why I'm working on becoming an Enterprise Architect. I can barely code, and I'm OK with that. Because I do know about the structure of the business, the canonical data model with an organisation, the high level enterprise applications that support that information, and the infrastructure that support the applications. Sure I'm not an expert in any one of those areas, but being knowledgeable combined with being able to talk to the CIO and the CEO with them understanding what I'm saying, that's a rare skill indeed.

This is a very general comment. Not all programmers and Analyst/PM are of same quality. Check niche area's - e.g. HFT programming, can PM/Analyst get close? No way.

A programmer who updates his skills frequently have a good chance of staying on top.

I think the fact that bad programmers can have such a negative impact has a lot to do with it.

Heh. Where I work business analysts and PMs make substantially less than the developers.

Because bullshit baffles brains

I used to be a programmer who transitioned into BA/PM role lately. I see and understand the pains of both sides. Sometimes, I want to switch into the technical/programmer mode where I want to solve/code the thing myself. The point is that these 3 roles even though not necessarily mutually exclusive, are very difficult to do at the same time especially in large corporate environments. At a startup, I am not sure if do need a separate BA/PM but when you have to deal with 100s of business users across multiple countries, get everyone to agree on scope/requirements, keep effective communication with all stakeholders etc. etc., you need people who can do all these. This is where a good BA/PM comes in. The value of a good BA/PM can never be undermined even though it can be argued that a developer usually fills these roles many times in certain circumstances. To summarize, a good BA/PM is not someone who only is good at business/domain knowledge or a set of tools, but is someone who can deal with people, glue teams together and is not afraid to wear many hats which could include cold calling team members, pestering business users to confirm things etc. etc.

I always laugh when people question why others make more than them. Standard salary for mid-level journalists is around $27k a year. Teachers are around $35k. I don't know about other careers, but there's always somebody making less than you.

From BA/PM perspective here are some possible reasons (with no disrespect to programmers):

1 BA/PM generally spend most of their time dealing with politics, governance and bureaucracy.

2 BA/PM spend a lot of time trying to elicit requirements and deal with scope creep.

3 BA/PM act as a conduit between parties and stakeholders who rarely agree. They attempt to gain compromise and keep the show on the road.

4 BA/PM take some risk and responsibility for things going wrong. And need to fix these things.

5 BA/PM act a managers, managing people, strategy, finances.

There are more but you get the context. There are lots of intangibles (or BS) needed to manage a project. You need someone to deal with it.

In certain industries BA/PM with a mixture of business, technology and BA/PM skills can demand more pay.

I was a doubter before but seeing the daily issues that come out on a challenging project, these BA/PM are probably underpaid.

Business analysts and PMs stay at corporations longer and build salary through promotions. Programmers leave every couple of years and build salary by going to more elite and richer corporations. So a new programmer may be working at a low programmer-pay corporation early at which PMs are paid more than programmers. Eventually programmers will end up at a place where they are paid more than PMs and BAs. Even the most die hard programmer-hating director or VP can't justify paying $150k for 'people skills'.

Writing software != Selling software

after almost 50 comments, I say let the developers, BAs,PM, QAs all win. After all, we all want to get the project out of the door, make some money on the way and go home.

>After all, we all want to get the project out of the door, make some money on the way and go home.

This is Hacker News, not Project Manager Forums. I am sure most of us just want to create awesome things and not "go home"!

You took it literally when i said "go home". Fine I will refine it for you. Go home as in go build the next product.

Ours do not.

The assumption that PMs, or anyone else, get higher salaries is just wrong. Depending on the company, pay scales are all over the place. At the company I am at now, 'Engineers' (valley speak for programmer) have the highest pay scale, meaning an Engineer is paid more than any other role at the same career level.

Some businesses see programmers as replaceable cogs. Some don't. If you are a really good developer, and you want to be paid well, one sure fire way to do it is to physically move to an area where great developers are in short supply. Silicon Valley is the nexus of demand in the US, for programming talent.

If you do our engineering challenge at http://www.codeeval.com/public_sc/48/ , we'll immediately get back to you. We are always looking for talented people, and working here is awesome.

Reply on news.ycombinator.com