As a programmer-turned-CEO, I firmly subscribe to the Mythical Man Month's suggestion that your top engineers should be paid the same or more than your managers.
Otherwise (as MMM notes), the only career advancement available to your engineers is to move into management, and that's a waste of a great engineer, and a good way to wind up with a poor manager.
Speaking from experience: being a CEO is something I've learned to do, being a programmer is something that I just am. The only reason I got into management is that the size of projects I wanted to tackle exceeded what I was capable of doing myself. Unless I wanted to work on other people's projects, it meant I needed to put together my own team.
While I wouldn't want to encourage programmers to move into management as their only career path, I also wouldn't ever hire someone into management who didn't work their way up in the field. Understanding how to manage technical projects is often much easier for someone who actually knows how to implement a technical project. Apple was/is similar -- Bertrand Serlet (SVP of Software Engineering) wrote malloc, Avi Tevanian (SVP of Software Engineering, Chief Software Technology Officer) was one of the primary authors of Mach.
In conclusion: programmers do not always get paid less than project managers or business analysts. If you feel that you're stuck earning less than you deserve, don't treat that as an axiom of the industry -- figure out how to move forward in your career, even if that means finding a company that sufficiently values senior engineering staff, or working to become a senior engineer.
I've had several positions in my career where I was paid more than my manager, usually revealed to me by the manager in an informal setting. If you're delivering more value than you cost, this is not necessarily unremarkable. It does require you to be an effective employee, an effective manager, and to be an effective negotiator.
Business analyst/finance here. I believe you are generalizing quite a bit. Some types of programming skills are a commodity. Such as some types of 'analytical' skills: all that is done on a spreadsheet on a regular basis is a commodity, that is why there are so many 'analysts' in the emerging countries.
Regarding programming, making 'apps' in .NET for a big corp is considered (and maybe it is) a commodity by the management. So, if you want higher salaries, you may want to move away from that.
What also doesn't help the programmers (generalizing again, but let's do it for the sake of discussion) is this complete misunderstanding they have regarding the 'suits'. It is absolutely true that a lot of 'suits' talk BS, but they do have a feeling of the business that programmers seem not to have, otherwise there wouldn't be so many todo and project management apps out there.
My strong advise would be to actually move away from the technical side for a moment and talk with the 'suits', ask them what problems they have, ask them about the business, etc. Companies have so many problems, but they are totally disregarded and this kind of discussions don't help.
Now, a programmer that cares about the business: that is a skill that is not a commodity...
Last few bigger companies I was in, as a developer, I was involved in multiple meetings, often with different project managers for different projects. The one constant was me (and a couple other devs), being involved in meetings with marketing projects, financial reporting projects, upcoming IT purchasing decisions, operational IT issues, and more. Guess what? The developers involved in these meetings had a pretty solid view of the entire business. Yet almost any time a suggestion was made by a developer based on info from other project meetings, it was shot down or dismissed. (not 100% of the time, but close). I saw this behaviour at 3 companies of varying sizes (between 150 and 2000 employees).
Developer suggestions were generally based on a broader view of the business' overall needs (because of the breadth of discussions we were involved in) than other people at table had, which apparently can be threatening, regardless of how you present things politically.
I realize not everyone as a developer gets in those situations. Sometimes you're chained to one project and set of people for months on end. If you're not, you can have a much better view of the business needs, but that doesn't mean anyone will listen to you as a developer. You need to move out from being perceived as such - either by changing jobs to another company, or occasionally within a company. I've never had the latter option work out for me, but have seen a couple people do that successfully.
Even though you felt you went to more meetings and therefore had a "broader view of the business", perhaps the project managers also attended meetings that you were not involved in, which gave them insights you could not have possibly known? For example, maybe during weekly PM meetings where all PMs gave an update of the projects they were managing, your PM also developed a strong sense of what was going on in the business? Maybe the PMs attended meetings where the corporate strategy was discussed, which you did not attend?
Not recognizing that others may have vantage points that were unknown to me was a tough lesson to learn, but an important one. It's difficult to speculate on what someone else may know or not know.
In some cases that may have been true, but in most cases it was not. This spoke to poor company communication more than any awesomeness people think that I think I possess.
I usually assume that the suits are usually normal people and good programmers are usually smart people. That doesn't mean that what a smart person says will be listened.
You have to see the world like them, think like them and, especially, talk like them. You have to understand their incentives in the company. Etc. If you don't make clear for them why your proposal is beneficial (to them, not to the company), then you lose.
"If you don't make clear for them why your proposal is beneficial (to them, not to the company), then you lose."
Fair point - basic human nature - but then people need to stop saying "you (developer) don't understand the business needs or the company's needs". I understand them quite well. If "the company" continues to employ people who need constant ego stroking every 5 minutes, then they'll continue to bounce along, and I'll go sell my skills to one of their competitors who is more open to input from all levels (to the extent any of those exist in that industry!) :)
Well, companies' needs and suits' needs intersect at some point. You have to be smart enough to see that intersection and to propose things that look good on both sides.
The suits have 'a feeling of the business'? If its as accurate as their views about 'commodity programmers', that explains a lot.
Management's output has no unit tests, no spec, few stats to hold accountable short of annual revenue. In my experience (30 years) they function through a combination of personal feelings and witchcraft. Those that luck out are considered special for no good reason - statistics shows there are usually outliers, so a dart-throwing monkey may do as well.
Ask the suits what problems they have? Its their job to drive the program. As 'commodities' why on earth should we have to pry vital information out of some overpaid manager? I don't mean to be spiteful here, but managers that don't know intimately the details of their program, tasks, direction and resources are useless drones.
You are wrong. Management does have output test: financials. Every executive is measured on the impact he has on the P&L and KPIs. You can say those metrics are flawed, and they can be, but the same most of the IT stuff I saw in my company is flawed (because it comes from commodity programmers).
Of course, the suits are mostly unpleasant people that do not respect your work. However, being the programmer generally a smarter guy, he could try to understand what the world vision of the suits really is (mostly: more profits, less cost) and work around that. Have you ever asked yourself why such horrible pieces of software like sharepoint are so common in companies? Because who sells them understands the world vision of the business people and he can put that into a crappy product and make god damn money...
Hit it on the head. more profits, less cost. And the quality spiral that ends in "those stupid commodity programmers, why do they turn out this crap and take so long?"
And the stupid commodity programmers shake their heads and turn their backs, because explaining "I said it took longer to do it right, and you chose fast and cheap every time, and now we are where I said we were going, but you made it my fault somehow" makes them sound petulant.
Yes, believe it or not we ARE trying to work around cost and earnings, but you shoot us in the foot every time. Why? Because you are rewarded using financials. And they are recomputed on too short a cycle to reflect quality.
Bottom-line is remote from most folks in a company. Executives may be accountable for P&L but not anybody below that.
What does a middle manager do? They optimize for their cost and milestones-complete. Which drives them to maximize their budget and minimize their deliverables. Which, if you think at all about it, are exactly opposite to the company goals.
Down below that, you have programmers. Who mostly care about the quality of what they do. But find their manager cares less than crap about that.
So here we are. Right where your short-sighted financial goal-seeking puts us.
I've found that sometimes, like you in this case, I think some stated premise is just plain wrong, but when I read on, I find that I agree with the subsequent argument. In some of those cases, that is possible because the argument doesn't actually require the premise (other possibilities are that I'm being inconsistent, that on second inspection the argument is wrong, etc.). So you don't necessarily need to stop reading :).
That means you either move in the suits department, or you leave the company as programmer skills are not core for the business or the support of the business.
There is a continuing misunderstanding between "suits" and dev's, where most dev's _do_ learn the business through experience, but the suits continually choose not to, and instead of working as the "teacher" and filter between both areas, just push the demands down to the dev.
And "yes": teacher is always part of the job.
> That means you either move in the suits department
There's also the option of avoiding working all-together for companies that employ said "suits". Which, and I thank the Creator of the Universe for that, I managed to do for the last 10 years of my employee history.
Salaries are a strange combination of supply and demand and superstition and belief. First, fundamentally, it is difficult to evaluate the contribution of either a manager or a programmer. So people fall back to the notion that, well there are fewer of the former and they're higher on the org chart so they should get paid more.
Second, programming skills are seen as a commodity, while business analysis skills are seen as a rarity. This is mostly self-reinforcing perception. At the hiring stage, because people see programming as a commodity they're willing to recruit widely, while because they see business analysis as a rarity they place disproportionate emphasis on pedigree (hiring ex consultants at McKinsey, etc) which limits supply. Given the Bell Labs study, pedigree is probably vastly overrated, but business types place insane value on it. I'm in the legal field and see big firms perfectly happy to hire someone from the middle of the class at a top 10 school over someone in the top decile of a top 50 school. The difference in standardized entrance exam scores between the two is often quite small, and law firm work takes more work ethic than it does brilliance, but firms hire the folks with the pedigree because it's easier to sell that to a business type.
Third, without using too broad of a brush, I think business analysis, etc, on average, attracts a more aggressive crowd. Programmers tend to be more mellow in my experience, and that affects people's perception of whether you've got "killer instinct" and whatnot. My law school's parent university has a business school, and frankly those folks are a little strange. They Facebook-friend people indiscriminately, always seem like they're trying to sell you something, and are really dedicated to physical fitness and grooming. Given that a large component of compensation is perception, it's easy to see why these folks would have a leg up.
Having been both a programmer and a project manager, there are difficulties to both jobs, but frankly, the difficulties of project management are harder to see.
Programmers have the difficulty of the unforgiving reality of having to make things _work_ - pass tests, compile, perform. This makes their job challenging, but it also makes it rewarding in that you know when you've gotten it right, when that piece of work is done.
Project managers have a task much more like herding cats: a poorly (or non) defined problem, moving goalposts, and a lot of "least worst compromise" kind of decisions. They have to deliver business results while keeping engineers and execs happy, in many cases with much of the responsibility for a projects success and little of the authority (i.e. they can't hire or fire engineers because the engineers don't actually report to them.)
I'm not saying one is actually harder than the other - that's very situation-specific. Just that the "difficult" parts of the project manager's job are less obvious to a programmer. (And, I'd note, often the _exact_ types of discomfort that most programmers would love to avoid dealing with themselves.)
(A good project manager is a shit umbrella, a bad one is a shit funnel. If you're in a shitstorm, learn to love your umbrellas.)
I think "difficult" is a tough term to pin down. I was troubled by the fact that the assumption was made as if it was a scientific fact; especially since making the assumption clearly eliminates a valid answer to the question.
Maybe I just took too many logical reasoning / philosophy classes in college...
Meta-discussion remark: whenever I point a flaw in an argument I try to add a disclaimer stating that I'm not necessarily taking the opposite side. This seems to cool down the discussion a bit, especially if the argument in question is in line with the HN (hive-)mindset.
Edit: This was meant as a response to your comment about being downvoted, sorry.
You are not completely alone in this. And there's also the statement right alongside that equates the difficulty level with working late.
One problem is that the term "programmer" covers such a wide range, from "code monkey" through "business analyst who codes." The range of productivity in code monkeys varies greatly, but they are still essentially fungible. When you start adding analysis and problem solving skills value goes up and fungibility goes down. In organizations that have formalized the separation of coding from analysis and problem solving, the coding roles will (and should) pay less. I think that's a bad decision, but it's certainly common enough.
The truth is a lot of programming is just gluing existing systems together or coding routine CRUD apps. Ironically, those jobs seem to be relatively highly paid.
Sometimes the down voting here is rather perplexing. The post starts out by denying a rational explanation for the cause of salary differences without any justification.
How is noting a flaw in the argument/question-setup worthy of downvoting?
That bothered me too. It seems inconsistent to say that "programming is generally more difficult", but "good people skills" are relatively scarce compared to programming skills.
I think that much of the problem is that the role of project manager and low-level manager are drastically different at different companies. At many companies these roles are nearly useless; they are filled with people who attend meetings and parrot things said by the people under them to the people above them and little else. There are of course companies where this is not the case, but I am not sure that they are terribly common.
The same reason a general contractor makes more than the carpenter he subs out? Or the same reason the real estate developer makes more than the architect?
It is mostly a question of making decisions that "scale".
If engineers are mostly deciding "how to build" something, then managers are mostly deciding "what to build".
Assuming managers are not just "schedule keepers", and are actually making decisions, then it makes sense for them to be paid more based on making those decisions correctly.
If the managers decisions on "what to build" are correct, and 12 months down the line a product is more successful because of that decision, their compensation can be much more than that of individual engineers.
Certainly there is much overlap between "what to build" and "how to build it", but in general it is the "business" role to decide what to build, and engineerings role to decide how to build it.
The Socratic method is one of the most annoying things ever, not the kind of thing that will be accepted by equals. It is a poor method of information/knowledge transfer, and thus wastes the time of the person looking for info while prolonging the period in which they are asking for something. It is close to a perfect example of claiming higher status than another. None of this calculation is normally said or even thought, but it is felt. People who appreciate the Socratic method, done well, are a small minority, and it is usually done badly.
You come off both condescending and lazy when using the Socratic method with peers. Either clearly state your positions or take the downvotes.
Socratic method works in a student-teacher relation. By using it here on the message board you immediately assert that you know the true answer while the rest of us only know ignorance.
You're not making any real arguments in any of your posts (except the grandparent to this one), in my opinion. When confronted with the assertion "X", responding with "does anyone else feel not-X?" or "the same reason Y?" strike me as lazy rhetorical cheats to assert your opinion while trying to avoid just laying out an argument for it.
As such, people seem to be downvoting them as noise.
I think they shouldn't (upvoted all of them for balance) the analogy is valid and ought to be obviously so. Programming is not the only industry where the best "craftsmen" often make less than the "middlemen", that's a very common pattern.
One point I haven't seen so far in this thread: even if manager types make more money than programmer types, that does not imply that management is a more lucrative career choice.
To make the point, let me turn the question around: if management is easier and pays more, why don't more programmers choose management?
The answer is that it's not necessarily easy to land a management job, whereas there's often work for programmers to do (though programmers may need to do consulting and travel around or something).
What happens is that business types get comfortable communicating with specific managers, and then they don't want to spend time building rapport with new managers. Great if you're that one manager, but not necessarily good for the 5 that are stuck trying to apply as a manager while unemployed.
(I'm sure it's more complex than this, but I believe the above describes a significant factor.)
I think you're right. Becoming a [good] product manager involves a long path that starts as an intern/co-op in college to assisting project managers, becoming one and polishing your skills in order to get those bigger projects and ultimately a product manager and/or operations chief. Granted, at a startup, anyone can become the product manager overnight, but in that enterprisey world it takes considerable more time and you have the added problem of extended down time should you lose your job, which can occur at a moment's notice if you're on the mid-level business side. Any decent engineer with experience under their belt is usually last to be fired and first to be rehired.
Witchcraft exists on the business side and its mysteries remain the domain of tall, handsome people. It really gets to me that even smart engineers will fall for it, too. Having been on both sides of the table I can tell you that engineers who take the stance that they shouldn't be making up the business rules are doing themselves a disservice. Most business types are sitting around waiting to be prompted by the engineers and have no clue of how something is supposed to work until the actual work is done. /End rant.
At bigger companies there are often arbitrary pay limits set for non-manager employees. Nobody is going to change those pay scales without making a business case to the finance department.
The problem is that most finance people have no clue about the underlying cost dynamics of software development. Most finance analysts learned from textbook examples based on manufacturing. Many big company finance systems are still set up using software designed for manufacturing.
Guess what that means? You're basically an assembly line worker. BA's and PM's are viewed as either managers or "management track" assets.
This must change. Both for the sake of profitability and fairness to top programmers.
My recommendation, if you know anyone in the finance department try to educate them a little about the cost dynamics of software development. The sort of stuff you'd read about in Code Complete or MMM.
They'll probably ignore you. If they do, fine, whatever. If not, you may have taken the first step in getting your company to understand how to manage their most valuable asset: programming talent.
It gets even funnier in government.
In the 80s I worked in a special government lab (where 'critical' event wasn't a euphemism!)
To get the young mathematicians and programmers we needed we had to pay the same rates they would get in industry - but the pay scales were all set by rank. So the only solution was to promote 21 year old maths grads to the heights of the command structure.
There were senior site meetings that had a 'general' rank head of each dept and 20 or 30 'general' rank 20 something maths specialists!
From what I understand of the Washington DC market, senior software engineers are generally paid more than technical managers.
But, given that many good technical managers were at one point good technical developers, it makes sense that they're paid more.
Having done both roles, being the 'lead' senior technical developer is the more difficult of the two. Though technical project management is more difficult than programming.
Additionally, it's that managers are also supposed to carry more responsibility, if they make a decision and tell the coder to "no, do it like this", it should be their neck on the line if it turned out to be the wrong decision.
Even though it doesn't always turn out that way, just appearing to carry the burden of responsibility is often enough to make justifications for being paid more.
In reality, the truth is of course somewhere in between the optimistic first paragraph and the cynical second.
A good programmer is as valuable to the team as a good project manager (and vice-versa) but the project manager's work will be explainable to corporate in a way that the programmer's work isn't.
Suits (and yes, I know this is an us-vs-them mentality) understand charts and numbers and projections, etc., but rarely give a damn about what actually has to happen to earn their quarterly profit. Project managers can produce enough of those to warm the cold pits of any executive's heart; programmers can point to lines of code and get a confused, annoyed look and a trip out the door.
It's not that executives are, by nature, evil or bad people (OK, not Hitlerian evil), they just don't worry about the tiny details.
Given the hierarchical nature of most companies, developers tend to be at the bottom rung. They've got project managers above them, then department managers above them. Almost by definition, anything a developer is working on is a "detail" (and can often be regarded as 'tiny' in comparison to the whole of a project or department). Doesn't matter if that one 'tiny' detail can actually close down the company or not, by the very nature of how projects and depts are structured, it's set up to be an uphill battle to get noticed and get heard from a dev point of view.
At general equilibrium (assuming open markets), a corporation's "reservation price" will be equal to the employee's "marginal product", so we don't generally use the term "reservation price" in the employer's perspective.
OTOH, an employee will have a "reservation price" that is the minimum they'd accept to force themselves to wake up at 8am everyday and go to work.
If you are the last COBOL programmer on earth, then surely many companies formerly using COBOL have switched to other languages and platforms and, most likely, there is a cross-compiler to COBOL from Python or C or something. Thus, a COBOL programmer's marginal product to any corporation would not really be that high since the company could switch to another language instead of hiring you (especially since they will have to switch eventually (assuming you, the last COBOL programmer on earth, are mortal).
Actually its not that simple in real life regarding legacy systems. To rewrite even small parts of critical real time systems (I'm thinking bank's end of day accounting reconciliation software) in a new language could be a hugely complex undertaking, and they must maintain and update legacy apps in the meantime, even while new development is ongoing.
I was under the impression that most programmers hired these days get paid more than managers and analysts with comparable experience, often by a good margin.
The business guys tend to have the checkbook. So, if they're intellectually lazy, they go with what they know rather than whatever they might need. Given that you're not going to be able to hire Bill Joy very often, there's a lot of developers out there looking for work. Anywhere there's "lots", there's downward salary pressure (chemists, engineers, ...).
Things might change a bit when they can outsource management or when non-Western competition truly arrives.
In addition to bargaining power, I think programmers are just worse negotiators. Their educations do not prepare them for this. To hack the system — remember you're putting yourself in a wage-slave situation for years, so best to learn this trash — you should extract the highest price/benefits they're capable of paying you.
(Maybe it helps to read _Getting to Yes_, or something.)
Plus, there's an obvious class component. The further removed you are from working with your hands, the higher value you're perceived to have.
(After all, who hires these project managers and business analysts? Managers. Who naturally value themselves more than underlings, and will transfer that value perception to these managers/analysts. This argument was used in Schmidt's _Disciplined Minds_ to explain some of the higher rank theoretical physicists have over experimental physicists and engineers, even if engineers earn more money.)
"The further removed you are from working with your hands, the higher value you're perceived to have."
It's that, but it's also (perceived) pedigree. A lot of "business analysts" come from big consultancies like McKinsey, or investment banks like Goldman, et al. Managers and MBA-types have a mystical perception of those firms -- almost as if they trained jedi business knights. The truth may be far from it, at least in my experience. But perception usually trumps truth.
More importantly, from a bargaining power perspective, you have to look at their BATNA - best alternative to a negotiated agreement. A programmer is going to take a bigger pay hit switching to another job type than an MBA'ed project manager. In many cases, a project manager may be making less than they would in a management role of another type (e.g. consulting or finance.) That's going to drive up the minimum wage they'll accept, and drive up the overall price as well.
The best way to improve bargaining power is to be willing to walk away at a higher offer.
Yeah, being willing to walk away for a better offer is the most encouraging thing to have in your pocket. That's worth working to get.
Another tip I heard, and tried out, is to start with a price higher than the highest you think they're willing to part with. Even if you cringe to say it. On the logic that the price can easily come down, but it's far harder for you to push it back up. (If they accept your first offer, the reasoning goes, you didn't go nearly high enough. Remember, that first price can affect you for years.) It worked for me, though of course YMMV.
(For those who cringe in salary negotiations, Graeber's _Debt: The First 500 Years_ may give you some perspective on why it makes you feel bad.)
Definitely helps to get in a position where you interview people. (Not to mention salary negotiations.) Then it'll be clear what employers want, and what other developers do. Based on that, you can present what they truly desire.
Take for example do-at-home projects. If you can solve them, then you can really hit them out of the ballpark. The first time I reviewed the solutions, I saw that only one or two had neat complete-ish solutions. (Most had significant cut corners; one was written by an insane fellow.) It was easy to see how to go beyond the best ones: make a build file, a readme that's worthy of a good opensource project, etc.
Because it doesn't actually have anything to do with "working with your hands". Craftsmen are probably a better example - a talented craftsman, like an athlete, though he's working with his body, can command soaring rates.
The classical worker, the kind I believe the GP meant to refer to, is a commodity. It's the kind of workers it might make sense to hire as day labourers and, conversely, for whom collective bargaining is beneficial.
There has been a tendency for some businesses to treat programmers as this kind of workers, often leading to failed off-shoring efforts.
It's not a class issue. A more accurate appraisal would be that one is paid highest for strategic work, next highest for tactical, and the least for operational work.
If you're great at operational work, but are no good with tactics or strategy, you won't ever get a huge salary, in the office or in sports.
After all, look at pro-sports salaries and you'll see that the highest paid players are the ones who are put in situations where they have the ability to make potentially critical decisions, and who have a history of being relatively good with those calls.
It did, for a hundred years. Professional athletes (outside of a few rare "rock stars" like Babe Ruth) often had to get second jobs in the off season up until the 1970s. If they wanted to continue playing sports professionally, they were at the whim of their team's owner, who could and did forbid them from playing for any other team.
Read up on the Reserve clause and Curt Flood for more info about how this all changed starting with Major League Baseball in the 1970s.
Otherwise (as MMM notes), the only career advancement available to your engineers is to move into management, and that's a waste of a great engineer, and a good way to wind up with a poor manager.
Speaking from experience: being a CEO is something I've learned to do, being a programmer is something that I just am. The only reason I got into management is that the size of projects I wanted to tackle exceeded what I was capable of doing myself. Unless I wanted to work on other people's projects, it meant I needed to put together my own team.
While I wouldn't want to encourage programmers to move into management as their only career path, I also wouldn't ever hire someone into management who didn't work their way up in the field. Understanding how to manage technical projects is often much easier for someone who actually knows how to implement a technical project. Apple was/is similar -- Bertrand Serlet (SVP of Software Engineering) wrote malloc, Avi Tevanian (SVP of Software Engineering, Chief Software Technology Officer) was one of the primary authors of Mach.
In conclusion: programmers do not always get paid less than project managers or business analysts. If you feel that you're stuck earning less than you deserve, don't treat that as an axiom of the industry -- figure out how to move forward in your career, even if that means finding a company that sufficiently values senior engineering staff, or working to become a senior engineer.