Stop trying to promote my best engineers | Hacker News Reader

Stop trying to promote my best engineers

idiallo.com

15 pointsfoxfired7 comments

I'm finding myself in this position right now. For almost two decades I have worked as a software engineer, slowly learning more and becoming more capable at designing and developing software. Yet, we have a significant lack of leaders and managers. I have been asked several times to take on such a lead role, but what makes me great at developing software does not make me great at organizing and managing a group of people. I have tried it - it didn't go well. Those aren't my interests or my aptitudes. Still, management keeps trying to get me to take on these vacant roles just because they know I have done well for them in everything else, but they overlook that they are asking me to do something very different from the thing I have been shown to do well.

I largely disagree with this premise.

We should be encouraging people to grow, and we should be rewarding them based on something as close to product/customer impact as possible.

If someone is an incredible Senior dev who doesn't want the cross-team responsibilities of a Staff dev or people management responsibilities, then yes, they should be OK to stay as a Senior dev without pressure that they HAVE to do something else. This doesn't mean that you should pay them as much as a Staff, because a Staff has more impact and that's why you're paying them more.

In particular, you want well-defined pay bands for job titles, because otherwise things get unfair quickly. Best case people find out that people are getting paid rapidly different amounts for the same job, get angry, and leave. Worst case there's a pattern where you're paying all of demographic X less than everyone else and you get sued.

I think the true problem here lies in reconciling titles with responsibilities. In software engineering most of our titles are very generic and can span different disciplines entirely. A senior dev working on database and a senior dev working on front-end probably shouldn't be compensated the exact same because their disciplines are completely different so conversely the value they bring to the company can vary wildly, but they're still senior devs by title. But if the best mechanism by which we can 'reward' these people is by adjusting their title this comes with an implied difference of responsibilities. Instead I think we need to do away with the HR non-sense of correlating titles with value. If an engineer does something of value that should be rewarded, give them a raise or bonus, not a title change.

>A senior dev working on database and a senior dev working on front-end probably shouldn't be compensated the exact same

Strong disagree. There is an antipattern I've seen across the entire industry, including big companies that should know better, where UI work is undervalued and considered "not as complex" or "simpler". I have fought with promo committees who didn't want to promote people because they assumed the UI work was "easy". All of the people making these claims had worked exclusively in backend for a long time and all of the should have to go take an IC role putting up with the hell that is modern frontend development. Only then will I give any credence to how difficult they think UI work is.

If your argument was "because there are 10x more frontend devs fighting for the same job", that's one thing, but saying it should be done because the disciplines are different is nonsense.

I think you're misunderstanding my argument, or maybe you have a rather radical point of view on compensation in the industry. My point was that compensation should be directly tied to your value to the company and not loosely correlated with your job title as it is currently. Determining how valuable you are to a company can be hard in itself though. I actually fully agree with you about companies under valuing front end positions, but I think that's more due to market forces (there's a larger supply of front-end web developers than any other type of developer) which is slightly outside the scope of my argument.

It's strange to me that you believe different disciplines should be compensated the same as no other industry would even consider that. Imagine I'm making a child's toy, should the CAD designer be compensated the same as my machinist just because they're working on the same project? In the same token why should the developer who is doing a completely different job from another developer be compensated exactly the same just because they're working on the same webapp and coding? It just doesn't make sense.

> A senior dev working on database and a senior dev working on front-end probably shouldn't be compensated the exact same because their disciplines are completely different so conversely the value they bring to the company can vary wildly, but they're still senior devs by title.

Exactly. The UI is the front face of the company, facing the customer. Nobody cares what's behind. UI is also much harder. That's why I almost never do UI or UX work. It's way too hard. Doing the backend is so much easier. And nobody cares if it needs 2x more memory or 2x more time. But if you are wasting screen estate and create annoying click-throughs everybody gets excited

> Best case people find out that people are getting paid rapidly different amounts for the same job, get angry, and leave.

This is only a problem if the disparity does not match the difference in contribution. I'm sure most of us have been in situations where ourselves and two other people have the same job and are earning roughly the same, and we perceive the situation as massively unfair because one of them should be earning half as much, and the other twice as much. I've been in teams where I would have been perfectly ok with specific people earning twice as much as myself. It's ok to admire someone's skill, be motivated to reach it, and accept that they should earn more in the meantime.

In practice ego makes truly merit-based compensation impossible to implement. We just often think too highly of ourselves. The other obstacle is that the difference in contribution from a low-performer to a high-performer varies widely with profession, with software development being (in my opinion) one of the widest.

Reply on news.ycombinator.com