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:
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."
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.
> 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.
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.
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.
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.
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
VS
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.
> 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.
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!"
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".
"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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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?
> 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 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.
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.
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.
> 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)
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.'
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).
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/