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/
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.
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.
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".
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.
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.
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.
ALL of those products/projects you list did required managment and business skills to be successful.
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.
This right here should have been the top rated comment on StackExchange. And, everything else the parent said is dead on.
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!"
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.
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.
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.
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.
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.
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.
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.
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)
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.
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?
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.
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.
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)
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.
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)
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.
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.
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.
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.
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.
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 $$$ :)
Hand = Developers Eye = Customers, Marketing, C-staff (read: stakeholders) Coordination = Project managers
It's arguable whether or not a PM should be that aggressive, but I'd say his expression made sense.
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.
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.
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 :) ).
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.
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.
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.
Contractors, on the other hand, have to deal with Accounting department, BAs, PMs, etc and then ship something... :D
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 ?
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.
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?
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.
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).
This is Hacker News, not Project Manager Forums. I am sure most of us just want to create awesome things and not "go home"!
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.
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.
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.
Finally, I'm not sure pms do get paid more.
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.
Want to get a higher salary? Do yourself and a broader programming community a service.
Learn to negotiate! Learn to negotiate! Learn to negotiate!
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.
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.
I've seen very few places where PMs and analysts even get on par with normal engineers (aka, non junior).
For most "regular" programmers, it's not that clear :)
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).
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.
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.
Gives me a heck of a competitive advantage :-)
Something like that.
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.
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.
A programmer who updates his skills frequently have a good chance of staying on top.
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.
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.
