Ask HN: What are engineers rewarded for at your company? | Hacker News Reader

Ask HN: What are engineers rewarded for at your company?

18 pointsbaron81613 comments

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?

View on HN

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.

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

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.

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.

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.

Move on.

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.

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'

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.

Consistently working nights and weekends is imho a warning sign from both an employee viewpoint as well as for enlightened employers.

We had a guy who knew everything, and was a gate keeper to that knowledge. New VP came in, and said he had to no longer be a silo of knowledge. He kept being a silo. VP fired him and expected the team to play catch up, knowing the company would take a hit short term but be better long term. Buyer beware.

How did that work out in the short term and then in the long run?

Short term was scary, some folks put in more hours, systems too longer to recover if something went sideways (which they did, a lot). Long term, it was great. A whole team of people who were able to keep systems green and diversity of opinions on how to improve systems. It worked out better than I could have expected.

Reply on news.ycombinator.com