
Ask HN: What are engineers rewarded for at your company? - baron816
I was promoted this year, but my promotion seemed to have very little to do with my technical abilities. In fact, my manager seems to have very little interest in my technical abilities at all, or my velocity, or the quality of my output. My impression is that any rewards I receive are dependent on my communication skills. Is that normal?
======
bkovacev
I always compare management to sports - where consistency is the key. If
you're consistent across the entire season, you're the key player of that team
and will get promoted/bumped with salary and so on. People rely on you and
they know you'll get the job done. Managers are like coaches, they operate
with resources to deliver a project or achieve a goal. If you help them by
being consistent in your outputs (communication, velocity, quality) you will
be rewarded - they rely on you to be the silent enforcer of their philosophy
and a role model for others - nothing bad in that.

------
idunno246
What i've seen, from new grad to mid level its generally technical abilities -
can you get work done. In many cases by that point youre pretty close to the
bar for an individual coder - there's only so many hours in a day. At that
point the expectation starts shifting to can you increase the business, where
coding is a tool to do it. but so is leading teams and training people, if you
can increase 10 engineers by 10% in a month, youve paid for a whole new
engineer. or working with product to make sure youre building what solves the
problem theyre solving. Going really deep optimizing some code path that saves
some money might be worth it, and its one way to get promoted, but it's
usually fairly localized. Generally the communication ways are more visible
and impactful.

We have a rubric on what each level is, and the higher you go the expectation
on breadth of the org that you affect is higher. Your code, your team, your
org, multi-org

------
iradik
Mastering ambiguity and comm skills. As you move up job levels your role
changes from problem solving to problem formulation. You need to be able to
tell other engineers what problems need to be solved.

Not valuing technical contributions seems odd. There should always be a base
level of strong technical competence that you build atop.

But technical chops alone won’t get you promoted. Also producing a large
volume of work won’t get you promoted; that will get you a reputation as a
code monkey.

------
ha470
Ideally you (and everyone else) should be rewarded for business impact- which
can come from communication, code quality, velocity, and any number of other
things.

------
president
The simple answer is that to get rewarded, you only need to do the things that
will put your boss in a position where he will get rewarded.

------
gesman
Move on.

------
throwaway2019G
Being irreplaceable. I worked on a team where our full-stack engineer put in
nights and weekends consistently and received a $100 gift card for Christmas.
Our data architect worked reasonable hours and received a 5 figure Christmas
bonus because he was the only person in the company that truly understood how
our vital algorithms worked (he wrote them).

Our full-stack engineer left soon after that.

~~~
codingdave
Irreplaceable means not promotable. It might get you bonuses, but they cannot
promote an irreplaceable architect unless they replace them. Hence the
problem.

I work the opposite way - I actively try to cross-train everyone on my work so
I can easily do something else. Whether that is new development, or a new
role, it is not just maintaining the same old stuff that I built to make me
'irreplaceable'

~~~
throwaway2019G
Generally very true. Ultimately it's just a game of leverage. If you're
hyperspecialized and irreplaceable, you have essentially unlimited bargaining
power against your current company. At the same time, if you're
hyperspecialized and irreplaceable, you likely have less bargaining power on
the general market because you've overspecialized.

