Comment by arcticbull | Hacker News Reader

Comment by arcticbull | Hacker News Reader

Parent Full thread

> Are you saying that people should only focus on building infrastructure for other engineers and never actually make a product?

Sorry, maybe I was unclear. I wasn't intending to opine on that aspect. I think product and infrastructure are both super valuable. You're goaled on impact not necessarily on whether you build infra or product per se. Infra you're rewarded based on the impact of the product teams leveraging your infra - and product teams you're goaled on moving specific metrics.

I've worked at 2 FAANGs - on product teams - and my experience has been that if your product moves metrics that your org has decided are important then you will be rewarded.

What I meant when I said "leaf services like that" was "leaf services whose measurable impact doesn't align with org goals."

> That being said, bad projects definitely exist within big companies, and it's not always easy for (junior in particular) people to know if they are working on something useful or not.

Yeah, that's basically what I was trying to say.

> Infra you're rewarded based on the impact of the product teams leveraging your infra - and product teams you're goaled on moving specific metrics.

This was not the case for me. I was told that my project had significant positive impact, and had many product teams vouch for me, but it didn't matter because "the principal engineers don't know who you are".

No you were perfectly clear.

You just did not approach this constructively. It would have been better if you asked first about how the impact was and could have be measured. Or at least responded more directly when they tried to explain the impact better. Instead of making and sticking to an assumption that the service wasn't useful.

It may well be that the person misunderstood their impact, but your arguments did not address that after the person came back with theirs. They could have been an edge case, that they are in an unfortunate situation in the human process of deciding rewards, where choosing and calculating metrics is itself subject to errors in judgment, and you tried to generalize your experiences to their corner of the world, which normally requires a stronger questioning.

Now, it's also perfectly fine advice that if a person wants to be rewarded, they should pursue projects that move the metrics of what's normally perceived as important. But that is also trivial advice.

A common chokepoint in an engineer's career development is challenging others' preconceived notion of what is important. Often this is with non-technical management, but unfortunately this is sometimes needed with technical peers too. It's politically convenient to just go with the flow and align oneself to the most visible metrics, but that way only a limited amount of bottom-up innovation can happen, and those can be critical to the business.

The best one can do is to establish the importance of the project before you do it, but I've seen important projects that were initially not supported by management, and only got traction when an IC did it anyway and demonstrated the value. Sometimes ICs were lucky that the impact was measurable and recognized, sometimes not so much and were deemed to have wasted precious company resources.

The world is not perfect and we often have to choose between taking a calculated risk or to conform. It's hard to get business processes 100% right, and not easy for a person to do things with guaranteed outcome, so we just have to live with it and try our best to navigate strategically.

That's fair criticism, and I appreciate your sharing it. I'm not always mindful that tone doesn't carry well by text, and I could have done a better job approaching this.

Reply on news.ycombinator.com