Live data from Hacker News

Advice for new principal tech ICs (i.e., notes to myself)

eugeneyan.com

41–50 of 163 posts

Re: Advice for new principal tech ICs (i.e., notes to myself)

#41

In short, you manage people. You tell others what to do and you think about what to do. It's technical management. You create impact off the work of others. You tell 10x people to do 10x work and you get 10x the credit when management only is like 1x of talent and effort. I met a principle engineer who didn't know what a database transaction was and it still fits every description on this site. We shouldn't call thes…

> In short, you manage people. You tell others what to do and you think about what to do. As a principal scientist I definitely don't manage people. Mainly, people managers have power to tell people what to do and when. I have zero power over anyone. No one needs to listen to me. Ever. If people ignore me there's literally no one I can complain to. And no one tells me what to do. If I wasn't competent at my job I'd b…

>But the team got the credit for being on top of things as a whole, not me. As it should be. >If only! 70% of the work I do is invisible small course corrections here and there across multiple orgs that fix things no one ever hears about but would be disasters down the road. >For the vast majority of what I do other people get 100% of the credit and my name is a small footnote at best.

Then your case is the exception, not the rule. To reach the level of principal, you generally have to be recognized for delivering high impact. Visibility is not just ego, it is how organizations perceive value. If your work earns you no visible credit, then no one really knows what you contribute. And if no one knows, how could anyone justify promoting you in the first place.

That is the ideal. In the ideal world, principals are elevated because they have a visible history of making the system better. They build frameworks that others rely on. They turn chaos into structure. They guide teams through impossible projects. Their reputation is not something they chase, it forms naturally from the wake of their work. In the ideal, visibility is the residue of real impact. People talk about them because their fingerprints are on every success.

But the corporate world rarely functions on ideals. In the real world, power accrues to whoever is closest to power. Titles often flow through social gravity more than technical merit. Some people climb because they deliver, others because they simply survive long enough to become unmovable. The higher you go, the more politics matters and the less evidence is required. Impact becomes subjective. Influence becomes reputation. And reputation, once earned, decays slowly.

In that reality, being invisible is not a liability. It can be a strategy. A principal who keeps their head down, avoids controversy, and stays on friendly terms with the right directors can outlast a dozen brilliant but abrasive engineers. The irrelevant survive because they are not a threat to anyone’s ego. The company quietly carries them, paying tribute to their title while forgetting their function.

Even the ideal, though, cannot escape the need for visibility. A principal who does great work in secret still fails the fundamental requirement of leadership: to be seen. Influence requires perception. You cannot guide a culture if nobody knows you are there. Quiet impact might keep systems healthy, but it does not create belief, and belief is what organizations promote. The best engineers learn to make their results legible. They translate their impact into stories others can tell. Without that, the work disappears into the background noise of everyone else’s effort.

So there are really two systems running in parallel. The first is the ideal, where promotion is earned through visible excellence and quiet authority. It demands both impact and awareness. The second is the reality, where promotion is often granted through time served, connections maintained, and an ability to avoid friction. The ideal rewards contribution; the reality rewards endurance.

You can succeed in either system, but they ask for different currencies. The ideal asks for mastery, courage, and the discipline to lead by example. The reality asks for patience, diplomacy, and the instinct to stay useful enough but never threatening. One builds respect. The other builds stability.

And most companies, if we are honest, prefer stability. Stability requires engineers to act the way you describe but talk the way I do. You talk about the ideal, you even believe you walk it, but because no one can see your impact, no one can tell the difference.

I've held the ranking of staff in many companies. I've interacted with principals, staff, and distinguished engineers and I can tell you visibility is required to fulfill the ideal. If visibility wasn't there, than the person earned the rank through other un-ideal means.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#42
Are you an individual contributor if the vast majority of your work isn’t individual contribution? And you’re not a “working-level” IC? God I hate all this big corporate hierarchy terminology. Along with all the pontification about what a “staff” or “principal” or “senior” really is, as if the terms have (or can have!) a stable meaning that we definitely agree upon enough for this all to make sense.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#43
post #29

Earlier quoted context omitted.

> In short, you manage people. You tell others what to do and you think about what to do. As a principal scientist I definitely don't manage people. Mainly, people managers have power to tell people what to do and when. I have zero power over anyone. No one needs to listen to me. Ever. If people ignore me there's literally no one I can complain to. And no one tells me what to do. If I wasn't competent at my job I'd b…

This is much like real Principal Engineer roles I've seen. The skeptics of the role might not have seen how easily and badly a large multiple-team effort can go astray, and the value of someone spotting the problems, and making sure they get addressed, before the product line or company is ruined.

I agree with your second sentence. But Anyone can do that, it's not a skill exclusive to principals. The idea that only certain types of people have the intelligence to spot things like this are principals is wrong.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#44

In short, you manage people. You tell others what to do and you think about what to do. It's technical management. You create impact off the work of others. You tell 10x people to do 10x work and you get 10x the credit when management only is like 1x of talent and effort. I met a principle engineer who didn't know what a database transaction was and it still fits every description on this site. We shouldn't call thes…

Some companies suck at promoting the right people, but a good principal engineer is the 10x person, or someone who makes several teams more effective by helping them figure out the bigger technical issues. If you think management is like 1x talent and effort, you should try management for a bit.

I have. It's more stressful. But it's still 1x talent and 1x effort. Anyone can do it, it's just harder in the same way being a garbage man is hard.

10x engineers don't need to be principals. The idea behind principals is that they don't do any engineering. They leverage the work of others to become 10x. It's very much considered a "leadership" or management role overall.

A 10x engineer is usually literally a person who can output 10x through his own work alone. As a sidenote, with AI everyone is now 10x. So it's really a 20x thing now.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#45
post #27

I find it amusing how people take this 'leveling game' at big companies so seriously. The title they get at these companies become their identity. They live by the rules the company imposes on them. Amusingly almost the opposite of independent thinking, which they are so proud of. What I found during my career is that some people blossom at these big companies, and some, with equal talent cannot really realize themse…

Sounds like you have some beef to pick, not sure why you feel the need to discredit this person you don’t even know.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#47
post #42

Are you an individual contributor if the vast majority of your work isn’t individual contribution? And you’re not a “working-level” IC? God I hate all this big corporate hierarchy terminology. Along with all the pontification about what a “staff” or “principal” or “senior” really is , as if the terms have (or can have!) a stable meaning that we definitely agree upon enough for this all to make sense.

My favorite bit is all the contradictions

> 25. To get to principal, you need to put yourself on the critical path. To be effective as a principal and go beyond it, you need to actively remove yourself from it.

And

> 26. If you were promoted to principal, it’s because you’ve been acting as a principal for a while

Say you need to keep doing what you’re doing, but also change everything.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#50
post #39

Earlier quoted context omitted.

It’s definitely not for everyone. But if the person, the org and role are a good fit, it’s not going to be that kind of worst case scenario. IMO, “nothing is not your job” is odd phrasing that doesn’t really mean “everything is your job,” it’s more like “see something, say something—-in a way that is received constructively and results in positive change, whether through your own actions or others’.” The unstated cor…

The way the author describes it (in contradicting terms; see the point where he claims if you're a Principal IC, you were promoted because you already acted like one, making the ~30 items of advice redundant) it's the most stressful position ever. Be critical, don't be in the critical path, be laid back in an advisory role but be hands-on or you're setting yourself up for failure, work on stuff you enjoy but be ready…

All that and also without a team of engineers working with you on the same problems, and you have limited formal power to actually set priorities and assign work. That sounds miserable.
Post reply on HN