Ask HN: Why are non-technical managers paid more than engineers?

Senior engineer speaking. 20 years of experience in the software industry.

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.

> Management is knowing of to make people work together toward a common goal.

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.

Number 2 is so hard for a lot of engineers to grasp. Technical knowledge does not translate to strong management skills. In fact, I would say at a certain point deep technical expertise becomes a hinderance on your ability to manage people.

technical skills are necessary to make educated decisions and judgments. Managers on high tech projects without such skills blindly shuffle people between roles usually base on which person is nicer to talk.

Right. For every single person, yes.

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.

All those iterations take resources from somewhere else. Manager with strong tech skills can reduce number of mistakes and frictions significantly and improve projects chances.

> 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.

I am not implying no technical skills are necessary to manage. The point is that hyper-technical skills in very specific niches seem to negatively correlate with people skills required to manage well.

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.

> 2. Technical skills aren't everything

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.

Have you heard about the law of supply and demand? Because it is bullshit. Salaries are not set based upon some fictional law of economics. Instead, look to sociology and biology to explain managerial salaries. Developers may be harder to recruit than managers but occupy a lower rung on the totem pole than them. Hence cannot be paid more than managers. Because pay is status and leaders have more status than followers. The more people you lead the more status and money.

This makes sense but will be downvoted.

I upvoted it. It's a good insight.

Supply and demand and your explanation are both true. They are competing.

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.

This is the best explanation. As much as managers pretend like lead/senior engineers are on the same rung of the hierarchy, they're not. Engineers are seen as "resources", a cost center, an input that produces an output, a more differentiated assembly line worker (engineers have higher status at tech companies obviously, but it's still the same dynamic).

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.

I agree that Pay is status; but I believe with a bigger pay comes bigger responsability.

Landing on a role with bigger responsability must be properly compensated or you won't be able to fill the position.

Correct, but I'd like to point out that responsibility does not imply consequences. If the higher-ups mess up they can blame it on those below them. Usually it is done in an indirect way by setting expectations. For a lot of people, if they are the ones setting expectations they mentally take themselves out of the equation, assuming they are good. They might be wrong.

Programmer jobs are harder to fill because programmers have a long list of personal preferences, trick questions, random algorithms to quiz your depth of understanding on, arbitrary answers and stack-specific questions in their arsenal for rejecting candidates. Everyone else focuses on what the job actually entails and how much they will be making.

Yes, existing devs often have a vested interest in rejecting candidates, especially those hires who are more senior than them, and whose job they might have aspired to fill as an internal promotion.

The 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.

I also feel like many programmers enjoy making interview questions as tricky as they can and finding every possible reason to reject other programmers they’re interviewing in order to appear superior in abilities. How can it be that every company complains they cannot hire engineers fast enough, pay 10s of thousands to outsourced recruiters and recruitment services, and yet there are many engineers, not short of decent ones, having to go through at least 5-7 interviews in order to land one offer.

Project manager can mean different things in different companies. I've seen PM's negotiate complex contracts with customers and as a result bring in a lot more revenue for the company without any additional development work. For the regular PM who's just managing internally, if they are good the should help reduce the amount of unnecessary work from the business and have developers working on the most crucial work. Being able to negotiate with different 'kinds' of people is a real skill, and it's not just basic office skills.

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)

Accountability.

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.

This depends on where you work, including it’s org and/or team culture. I’ve been on teams where management wanted details - what is our delivery plan (PMs and technical leaders communicate this to more senior management and involve engineers to ask questions, understand what’s achievable, set dates and expectations with stakeholders, clearly define CX, write or review customer stories, etc).

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.

Is 1st, F or G? 2nd the commerce A? 3rd N?

Just wanted to point out that typically in the US, the role you seem to be describing is that of an engineering manager, not a project manager. If your company is finding engineering managers in 2-4 weeks, it probably is not a top-tier tech company.

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.

This is the most correct answer. In my company software engineers easily make more than project managers. People manager make a bit more than engineers but not that much. 10-20k more.

Soure: glassdoor.com

In my experience, a good project manager makes a good team fantastic. A bad project manager makes a good team dysfunctional. While I can't speak for all the project managers you work with, one who can turn a good team of more than three or so engineers fantastic is worth significantly more than one single good engineer.

> There's often a lifetime of work behind the development of that skill.

This is literally true of every senior job role.

It seems like it's mostly software engineers that don't get this.

> 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?

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...

Unfortunately I’ve seen most project managers, BAs, and product managers that have no understanding of the VOC, requirements, or the engineering.

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.

In general, in the business venue, the big share of income goes to those that can offer some form of command and control to a business venture.

Maybe the non-technical managers are better at salary negotiation than the software engineers?

Be thankful you're not a musician.

The best comment so far!

Assumption of facts not in evidence. At many companies including the biggest, engineers are paid more than peer product/project/program managers, and most managers are engineers also.

Project managers do not always make more than software engineers. In fact, entry level PMs often make significantly less. It depends on the org and seniority of the position really.

Because they set the pay scales, and engineers aren’t organized enough to force them to set them differently.

The managers are more valuable to the company than the engineers...

I actually think a lot of Project Managers do a good job, and are valuable, but surprised nobody has mentioned David Graeber's Bullshit Jobs theory.

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).

Scale