Ask HN: Why are non-technical managers paid more than engineers?
There are 2 open positions: Software Engineer, and Project Manager.
The Project Manager position is filled in 2-4 weeks. This person is offered more compensation than the engineers they're managing. Often their skillset appears (to engineers at least) to consist only of the most basic skills required to function in an office environment. The emerging pattern is that the winning candidate is chosen based mostly on their physical presentation, and their ability to "win conversations."
The Software Engineer position is filled in 3 months if we're lucky, and then stays open in perpetuity, because the need for engineers outpaces the company's ability to hire them. We screen thousands of resumes trying to find somebody who's even worth interviewing. We hire a recruiting agency, throw money at Greenhouse, conduct on-site rounds with a 90% fail rate, and pay mid-5-figure finder fees to Triplebyte and Hired.
The Software Engineer has a skillset that is beyond the comprehension of most people, and is so large and varied that some part of it is even beyond the comprehension of their peers and vice-versa. There's often a lifetime of work behind the development of that skillset, since they were in their teens or even earlier, most of it above and beyond any standard educational curriculum.
Software companies would seem to be one of the most (if not the most) extreme examples of supervisors being more replaceable than their direct reports in hiring.
So why are software companies so willing to offer more pay for a managerial role that is easy to hire for, and so unwilling to offer more pay for a technical role that is one of the hardest to hire for? Why does it seem like market forces just don't apply here?
38 comments
[ 4.9 ms ] story [ 23.5 ms ] threadThe architect might pass interviews for tech strategy, systems engineering, innovation and mentoring, but be failed by the senior devs on some detailed low-level tech question, which just happens to keep that architect slot open for them in the future - even if it means more workload in the short term.
Management is knowing of to make people work together toward a common goal.
1. A managerial role is not _easy_ to hire for if you're looking for someone who has (for a start) correct skills & experience to manage a team (of engineers only, or of various backgrounds).
One of their roles is to help his team focus on what they want to/can do for everyone to succeed. That implies a lot of ingesting, structuring information and communicate it in all directions, all of the time. You need practice, and skills, to handle that without becoming completely numb.
2. Technical skills aren't everything. Far from that. When hiring, it's among the last items on my checklist. You want people to be motivated for the job, to be capable and willing to work in a team, to be willing to learn and spread what they learnt. What they know and can bring in total derives from that.
3. You get 1 manager for several members of a team. And a manager also coordinates with other managers & team members. Budget-wise, you can take and compare the manager compensation with any one team member's compensation but that does not make much sense.
4. Companies success being the result of (mostly) the technical excellence of their teams is the worst toxic professional myth I've encountered; it took me 5 years to see it and 10 more to accept it.
Purpose/strategy (know what you want) + design (know how to get there) + logistics (know who/what to ask for it) trumps most of the rest.
The bonus is if you also have the technical skills to do it but that's not a requirement.
Being an engineer is great, I love it. But it's far from being THE ultimate valuable role in a company.
I have almost three years of experience and found myself leading a team of 14 people, all of them sysadmin and/or system engineers. I reported to my manager, as did the people i lead.
I can tell you, managing people is IMMENSELY hard.
People have all kind of problems and issues, serious and trivial, and can create a problem out of a stupid technical detail. Some people can’t take a criticism and will take it to hr.
I am still amazed ad how well my manager is capable of keeping his temper, how he can tone down a heated discussion and manage to get people to work together, reach some form of consensus and generally move forward.
I just don’t have (yet?) that kind of skills.
I do however realise that it is a completely different skillset, and that for such job one would need just enough technical knowledge to understand what the problem is about and who to pull into the discussion should things get too technical.
But there are many people to make an organisation work.
There, experts provide their expertise, managers make calls (hopefully for everyone - that's also part of their job, informed calls).
If the call was wrong, you can question & identify if it is either the manager's judgement that was debatable, or the piece of expertise provided, or both. And then decide what to do: change the methods, change the role, change the teams, move the people.
If you have a single person being the expert and making the calls, all you have is a bus number of 1.
> you can question & identify if it is either the manager's judgement that was debatable
You are probably referring on some VP level person, so I think they usually have even lower expertise, and will just fire manager who doesn't deliver, which is correct, VP shouldn't dig to such low level of execution.
Of course knowing enough about the product and space is important to make correct technical decisions as a manager. That goes without saying. The point is rather that the goal of a technical manager is not to come up with all of the answers, but put the right heads together to answer tough questions.
Also, technical skills have "shelf-life": they tend to phase-out / get cannibalized / commoditized after 3-6 years.
For managerial roles you need people with skills that improve over time and are not dependent on technology.
At least in theory, whether a project goes well or badly, it is the leader that is accountable for that result. They get paid well to bring success to a project. They get fired fast for failing.
As a dev, you typically are not held to that level of accountability. If you do good work on a crappy project, you just get moved to a different project when it all blows up, instead of being unemployed. So with less personal risk, you also get less compensation.
I’ve seen teams where a director level sat down with engineers to understand the launch plan, what system metrics are/will be available, what are technical dependencies? Does team A own them or team B? What’s the escalation path in case of failures? Have we stress tested? Failure tested? If dependencies all died, how resilient are our systems? Do they fail gracefully? What’s the forecasted peak request rate? What’s our infrastructure spend? The list goes on...
I’ve been on other teams where management is high in the clouds - strategy only and even the immediate or other technical management refuses to get involved in any kind of planning, estimates, or generally having any accountability of deliverables. The couple overachievers in the engineering team are basically the ones responsible for the success if the project succeeds (and sometimes they’re also owning the definition of success and success metrics). If this scares you it should.
My point being, there is certainly a broad spectrum.
These experiences are from 3 of the FAANGs.
That said I think the "cushy" thing about being a PM though is there isn't a new framework to learn next year - you can just keep building on your existing people skills. How to win friends and influence people is more relevant and enduring than any tech skills from the 1930's (or even the 1990's), for example.
But overall IF they are good they are worth it. (If they are bad they cost just as much and are much more harmful than a bad dev)
It really depends on which part of the "software world" the company is situated in and the value they put in engineering.
A lot of companies have this exaggerated structure to value the work done by the project manager and business analyst (usually spec-ing out work and abstracting customer interaction from the rest of the team). The effects of abstracting customer interaction allows them to be valued highly, which will make them reside on the top of the chain and get compensated accordingly. The rest of the team doesn’t matter that much as long as they’ve got the right qualifications to convert requirements into working code.
This stackoverflow answer will give you an idea:
https://softwareengineering.stackexchange.com/questions/4577...
Very common:
Product managers typically come from sales/business development and can’t articulate VOC or requirements in an intelligible way, even though that may be a listed duty of theirs. They are great at taking their customer base to the baseball game and knocking back a few beers, but engineering ultimately has to collect those insights on their own.
Project managers that have only a PMP or a some kind of tangential management qualification treat every project the same way but do not have the technical understanding to be useful. In their eyes rushing schedules, gate clearing, and release trumps any other concerns and often the result is shipping a turd product with bare bones checkbox requirements (that they never actually appreciated, understood, or cared about) that flops. But they get to claim they navigated X number of product releases on their resume.
Business analysts possess half the knowledge they need to be competent. You need expertise in the business, customers, products, requirements, research, and analytics (basically a step just below the base knowledge you need to do systems engineering without having the technicals to develop a systems solution). You usually get someone with just enough knowledge in one area of computer science, analytics, or business (but almost never a complete suite of knowledge to provide useful input into the process).
Engineering is hard. It’s a mixture of multiple disciplines of knowledge and wearing many hats. What holds back engineering salaries is that management, sales, and business types compete with engineering to improve the bottom line, seeking to minimize/outsource the importance of technical solutions and maximize other methods/budgets like marketing gimmicks, cutting costs, and inserting processes in a kludge or bureaucratic manner with the illusion of accountability (I have never witnessed actual accountability) via their hierarchies being closer to executives and board members who tend to have a disproportionate influence on matters like budget for competent engineers.
I have seen enough turd products released that do insurmountable damage to a company that I run if I detect the scent that engineering is treated as just another resource that translates requirements into shipped products and is not on equal footing and input as sales, business process, and management.
This is literally true of every senior job role.
It seems like it's mostly software engineers that don't get this.
Managers want it be structured like your explanation, what they actually get is structured by supply and demand. Because they setting below the market rate they then struggle get anyone.
If a company comes along and does not follow hierarchical setting salaries, then they will get all the better programmers.
Overtime if the software is critical to their business, then they will die out.
It just takes time.
Managers report to the executives / upper management, and have all the relationships, political capital, and power.
Is it fair? That's a separate question, but not a question the company cares about. Remember a company isn't a democracy, it's a dictatorship/oligarchy, probably led by someone non-technical who's goal is to maximize business profits, not please engineers.
As an engineer I wish it was different.
Landing on a role with bigger responsability must be properly compensated or you won't be able to fill the position.
That is documented at https://en.wikipedia.org/wiki/Bullshit_Jobs and https://www.vox.com/2018/5/8/17308744/bullshit-jobs-book-dav....
It specifically mentions "taskmasters" who manage/create work for others, and project managers might be put into that category by some (but again, not by me as a general rule).
At the highest paying tech companies (FANG) there are usually 3 "manager" roles:
- Product Manager: Interfaces between marketing, engineering and design to manage the development of new features and products. Not necessarily a people manager and does not directly manager engineers.
- Project Manager: Manages scheduling, task assignment, communication between teams, assigns bugs. Does not directly manage engineers.
- Engineering Manager: Primarily a people manager, usually was a SWE previously. Does manage engineers.
Of the 3, the project manager path is probably the least lucrative at the same level. Product and engineering tend to have similar pay.
Good engineering managers have a unique blend of managerial skill AND technical skill. On the other hand, there are lots of anti-social weirdos that are great ICs in engineering. As a result, I'm inclined to say that supply and demand is working pretty well.
Soure: glassdoor.com