Ask HN: Dealing with Preferential Treatment | Hacker News Reader

Ask HN: Dealing with Preferential Treatment

7 pointsxenocratus8 comments

Hi all,

I've been tormented for a while about some things I notice in the way our engineering teams work (I'm a software engineer in a tech company). It seems like engineers are quite noticeably split into a handful who get access to more interesting/high-profile pieces of work and opportunities to grow, and the grunts who get assigned more menial pieces of work, with no serious growth prospect.

Since I'm quite new in the industry, I'm wondering if this is normal or usual in the field, or if it's a red flag that should make me wonder.

Does anyone have similar or contrasting experiences?

View on HN

> the grunts who get assigned more menial pieces of work

Funnily enough if you automate and re-architect those menial pieces of work, you will turn that pile of boredom into a "serious growth prospect".

> Does anyone have similar or contrasting experiences?

The grass is sometimes, not always, greener where you water it. I've been in that position, most of the boring stuff for me are related to internal operations. "High profile pieces of work" usually equate to "greenfield" customer facing UI or features, while it's always great to work on new stuff, there's also serious growth into improving something that currently works.

Personal experience on preferential treatment? it worked for me where if you try your best that every boring thing you touch turns into gold, you can make a new 'market'.

Example: slowly refactor some boring internal backend services, take 30 mins to sketch a few wireframes and show it around of what it could be to fellow users/officemates. It gets enough eyeballs that it turns into something exciting that other engineers would want to work on too. Management decides if it's worth the time or not, the key to win their approval is if the refactor/re-architecture/development is small enough to solve a very painful process point (ex: accounting needs data from different databases, solving a very buggy scenario from a current product currently solved by shoehorning manual data entries in some backend, etc.).

If you don't get approval, it's okay, you've refactored something crucial and your other officemates have definitely seen your worth. Just keep repeating it.

I did something similar once, the company had and legacy IE app that was in heavy use but written off as a liability. I refactored the activex controls and pitched a project to modernize. That project turned out to be a huge win for sales who no longer had to tell prospects “requires ie 11”. I got a hell of a bonus that year.

Thank you for the tip! I'll try and do something along those lines.

The problem is time, unfortunately - especially when developing products, the timelines are quite restricting: tickets are estimated by the team, large deviations usually need to be explained. So if there's something I can do in a sensible amount of time, I'd go for it. Plus all the overhead of helping others, reviewing/merging PRs etc.etc.

One of my main approaches to try and prove myself was to help out with identifying/fixing company-wide issues in some of our platforms. Got me some good contacts (and a very senior engineer offering to mentor me for a bit) and I certainly learned a lot doing it.

Where is ther a place on this planet that doesn't have a pecking order? Yes, engineers that are deemed to be more capable (whether they are or not) or experienced and/or are in the good graces of the organization's leaders get offered better choices than those who are not. If you're lucky, said leaders are themselves competent in identifying capable people and the organization prospers.

If you want better choices by an honest route, demonstrate that you're more capable than your colleagues who also want those opportunities, express your interest to your management chain and ask for their guidance in helping get them[1], and make sure you're well enough respected and liked by your colleagues that you won't be shot down when you're under consideration.

[1] And if your manager(s) aren't helping in this regard, transfer to another manager or find a new job.

Been trying that for a while (to demonstrate things), and while I've spent tonnes of time helping colleagues (even more senior ones) both in my team and in others, it's almost irrelevant when it comes to management. (Been doing this for more than 2 years now.)

I'm starting to realise that there's a supply-demand chain - limited number of growth opportunities which need to be distributed among the engineers. So if I didn't catch the initial train, then there's little to no prospect of getting on it while it's going.

Do the "grunts" have different job titles? Are they more junior?

Is your problem that managers give the most important problems to the best programmers? Would you do it any differently?

Nope, same job titles.

And no, not necessarily the best programmers. Sure, some of them are/were somewhat better to begin with, but by providing them with more growth prospects you're widening the gap.

Edit: I mean, sure, I'd give the difficult problems to the best engineers WHEN there's a tight time constraint or when it's something that only they can do. But difficult problems are not the only growth prospects in tech.

That does sound frustrating. I think it is good advice to view your work as an opportunity to take initiative and build something impressive, like a test suite or any kind of tool to automate some the work so there won't be any "unimportant" tasks for anybody to work on.

Reply on news.ycombinator.com