
Ask HN: Dealing with Preferential Treatment - xenocratus
Hi all,<p>I&#x27;ve been tormented for a while about some things I notice in the way our engineering teams work (I&#x27;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&#x2F;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.<p>Since I&#x27;m quite new in the industry, I&#x27;m wondering if this is normal or usual in the field, or if it&#x27;s a red flag that should make me wonder.<p>Does anyone have similar or contrasting experiences?
======
acesubido
> 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.

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

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

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

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

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

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

