Live data from Hacker News

My thoughts about the Principal role

galiglobal.com

71–80 of 124 posts

Re: My thoughts about the Principal role

#71

Earlier quoted context omitted.

I am in a PE role right now and I 100% agree that the PE is the hub. I like that. I see my role as being a catalyst. I make things move along faster and more efficiently. I like seeing growth in others on the team. Also, it’s ok if you don’t like that. If you would rather just be in there getting your hands dirty solving that one hard problem with no interruptions, then I think you should do that. You’ll be happier.…

A question for all the PEs here. When you want to reflect critically on what you do, and actually measure your performance and/or bottom line contribution, what do you measure and how? What do your bosses measure? Surely warm fuzzy feelings and other placebo effects are not enough. Imagine a situation that some underlings resent about your uselessness or lack of responsibility. What criteria/facts could possibly make…

As a manager, I’m looking at how my principals are helping the team move past big hurdles. Their ability to write code is a given, and they still do it (though not as much as they did, or at least not the same type of code). But are they mentoring and pair-programming with junior team members? Can they take what the BA/PM ask and turn it into meaningful technical tasks (that’s part of my job too - I try to lead that exercise, but need them as a sanity check and to stay on top of new things I might miss). Can they talk to a customer in a useful way (not too technical, not condescending) and do whatever problem is being discussed? Are they a go-to resource for other teams? Are senior leaders dropping in to ask them questions?

I’m definitely not looking at the raw number of Jura tasks here close. But I’m not looking at that for junior devs either.

Edit - usually, the more junior drive are more in awe of the principals. I’ve never encountered one who outwardly seemed to think the principal wasn’t contributing. More than likely, the principal was actively helping them get their own tasks done.

Re: My thoughts about the Principal role

#72
post #39

Some of this advice is great, like getting out of the way, guiding people with how to think about trade-offs and doing daily coding. But it doesn't feel like 'Principal' level advice, at least in terms of Big Tech and the blog notes the author isn't sure what the distinction is with Staff. The author complains that it's hard to be in the critical path at a senior level. This lacks self-awareness. It's always hard to…

Do the architects actually… build things? The description of the work there is more like a program manager. Which is an important organizational job which doesn’t have any power, but also isn’t the person doing the work, and so doesn’t have the understanding to design it.

Re: My thoughts about the Principal role

#73
post #57
post #27

I have personally not found the staff/principal level very enjoyable or satisfying. You end up being a hub for the larger team, helping everyone do their jobs. I'm not just referring to the coders. It's very draining and I resent that the industry classifies this type of work as technical IC work. A small subset of these higher "IC" roles do get to focus on technical IC work, but for most people a staff/principal rol…

That's currently my worry as I grow, PE is the next level up, but I don't know if I want to get this far removed from the concrete code deliverables and software architectural decisions.

So don’t let yourself get removed completely from the deliverables. Keep in there. Take some tickets off the queue and work them so your skills stay sharp. If you are worth your salt, this contribution will be noticed by other ICs on the team and your boss. Just realize that the IC role isn’t primary for you. Provide useful feedback in reviews to keep dumb stuff from happening. Make sure your team is working on the right things.

And yes, the PE contribution is harder to measure and the risk is there that others won’t see it. If you aren’t comfortable with that risk, then don’t go for the PE role.

Which is OK! It doesn’t have to be “up or out”. For me PE is as high as I want to go. I have no desire to deal with the stress and risk of moving up past PE.

I’ve also intentionally moved from a PE at my precious job back to being 100% IC in my current company and then a few years later back to PE where I am now. I did that to build up a slightly different, more marketable skill set.

Re: My thoughts about the Principal role

#74

Earlier quoted context omitted.

A question for all the PEs here. When you want to reflect critically on what you do, and actually measure your performance and/or bottom line contribution, what do you measure and how? What do your bosses measure? Surely warm fuzzy feelings and other placebo effects are not enough. Imagine a situation that some underlings resent about your uselessness or lack of responsibility. What criteria/facts could possibly make…

As a manager, I’m looking at how my principals are helping the team move past big hurdles. Their ability to write code is a given, and they still do it (though not as much as they did, or at least not the same type of code). But are they mentoring and pair-programming with junior team members? Can they take what the BA/PM ask and turn it into meaningful technical tasks (that’s part of my job too - I try to lead that…

This. If I’m not helping junior devs get their work done, I am failing as a PE.

Re: My thoughts about the Principal role

#75

Job titles are overrated. Often they are not an indication of skills and/or achievements, but rather political ability to networking and managing up in the company. I have worked with Principals, Architects etc ... they were more an obstacle than facilitators. Most of them, if they were to interview, they wouldn't even be able to get a job as a senior engineer.

At that level it's not what you know but who you know. Your ability to interface with the rest of the org and get things done is where you deliver value. If you see senior people as such obstacles then it suggests you've not worked for a larger org or perhaps the obstacle isn't those other people.

Re: My thoughts about the Principal role

#76

It is supposed to be a super-smart engineer who is extremely vertical in multiple disciplines, can solve complex problems, and can navigate politics. I worked at Intel. A principal engineer in the process or architecture was vastly different than a principal engineer elsewhere. For the most part, you become a principal engineer by sticking around, doing lots of extra work, and making at least several major contributi…

I consider principal engineers / architects "astronauts". They've spent so much time floating around they've forgotten what solid ground feels like. They're both disoriented and atrophied when it comes to engineering. It's a trap. You'll eventually have to come back down to earth, and the longer you spend in this role the harder it will be.

I don't know that I even really buy into the idea of a "principal engineer". Even in a really large company where you have a shit ton of people working on one bit of software, principal engineer doesn't seem like a well defined role that you need, because once you scale past the point where one person (a "lead engineer" or whatever) can manage the technical side for everything, the next "level" up in whatever structure you're working with by definition has to defer to their subordinates for technical expertise. That makes it a management role, not an engineering role.

I think once you're in "principal engineer" territory, it's your job to divvy up the work and hire people to make their own decisions and take responsibility.

If I was hiring specifically for that role I'd probably go with engineering manager or technical product manager or something.

Having said that I think you could make the case that principal engineer works if you're doing that stuff as well as taking responsibility for a subset of the app and continuing to do engineering work. Because I think there's a fairly large range of team sizes where you probably don't have 40 hours of managing to do per week (probably a range like 10-30? Maybe higher? Probably depends a lot on the app too). It's a nice hack to deal with the fact that you can't give someone two job titles.

Btw I think that strategy is underutilised. I've worked with far too many people that are doing 15 hours of really useful stuff and 25 hours of making everyone else's life more difficult because they're a bit constrained by their narrow job description. I really think more devs and designers should have side gigs as little mini PMs, POs and BAs instead of the usual strat of scaling up as quick as possible and running face first into the consequences of Parkinson's law.

Re: My thoughts about the Principal role

#77
An IC4 role is generally one where you can give a problem to the IC4 and have them figure out how to break it into work and get things done. They don't need hand holding like junior engineers but they also know how to get input from experienced peers and make informed decisions. You're not payed to solve run of the mill problems at this level but to leverage your experience and intuition. Collaboration is critical.

Re: My thoughts about the Principal role

#78

It is supposed to be a super-smart engineer who is extremely vertical in multiple disciplines, can solve complex problems, and can navigate politics. I worked at Intel. A principal engineer in the process or architecture was vastly different than a principal engineer elsewhere. For the most part, you become a principal engineer by sticking around, doing lots of extra work, and making at least several major contributi…

I consider principal engineers / architects "astronauts". They've spent so much time floating around they've forgotten what solid ground feels like. They're both disoriented and atrophied when it comes to engineering. It's a trap. You'll eventually have to come back down to earth, and the longer you spend in this role the harder it will be.

Maybe that's your experience but the decisions and discussions you're not privy to is where their value is added. An IC4 isn't there to write implementation code as junior engineers can do that.

Re: My thoughts about the Principal role

#79
post #27

I have personally not found the staff/principal level very enjoyable or satisfying. You end up being a hub for the larger team, helping everyone do their jobs. I'm not just referring to the coders. It's very draining and I resent that the industry classifies this type of work as technical IC work. A small subset of these higher "IC" roles do get to focus on technical IC work, but for most people a staff/principal rol…

I quit my job as a PE in AWS, and now work on writing performance-critical code in a scientific context. I couldn’t be happier with the decision. If you’re considering getting out, I would encourage it. Getting back to working on primarily technical problems, rather than social/communication scaling ones, has been great for my overall happiness.

[deleted]

Re: My thoughts about the Principal role

#80
Question for Principal Engineers and Senior Managers, Directors here -

can you shed some light on how to influence senior engineers and PEs, and directors? I am rising in my career track as a people manager, but I see that PEs, directors don’t appear convinced or influenced by me. Please suggest some learning resources, books, blogs, YouTube videos etc.

Post reply on HN