This is spot-on from my perspective. The comment I’ll add is that a true Principal is different in kind, not just in experience or knowledge, from a very senior developer. A Principal embraces the interdisciplinary nature of their role. They tackle the hardest and most awkward challenges to the business because they see them coming before you do. They naturally mentor and develop junior talent, but are self-aware enough to know that they would have less impact if they were saddled with managing a team. Not every senior engineer has what it takes to become a Principal.
My thoughts about the Principal role
41–50 of 124 posts
Re: My thoughts about the Principal role
#42Principal role = expensive lean manager. They want to help others achieve something without actually getting their hands dirty. Of all the principal engineers I’ve worked with, the vast majority behave like motivational coaches/lean managers. Examples: - There’s an outage on a Sunday morning. A huge Slack thread starts. Devops and devs on call manage to fix the issue. Principal engineer gets involved ACKing other’s p…
I'm in a PE role, and I have to tell myself every day not to go do the POC because that's not how I can maximize my impact. If someone else can do that work, I'm going to try and lean on them. Strategy is hard. Much harder than I thought it would be. I am unable to make progress on strategy when I'm deep in tactical work. I do jump in when needed, but every time I get my hands dirty I fall behind on strategy. Your PE…
I’ve been at this place before even if I don’t have the title formally.
What I have learned to do is to actually do my own flavour of the PoC concurrently with the team. That way I have more material to discuss and am able to give deeper insights like “have you considered X or what happens when Y?”.
It helps getting to know the problem better while letting the responsible get to own the product.
Re: My thoughts about the Principal role
#43I 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.
Have you been able to maintain a similar level of compensation?
I started my career in scientific computing, and was paid a pittance compared to what a PE is paid at a big tech company.
I’m wondering if moving to scientific computing is a luxury afforded by putting in time at AWS.
Re: My thoughts about the Principal role
#44I 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.
How did that decision impact you financially?
Were you able to get something in a similar range as what levels.fyi lists for an Amazon Principle Engineer ($640,000 [0])?
Or did you become financially independent from the Amazon comp which allowed you to not care about the new lower salary?
[0] https://www.levels.fyi/company/Amazon/salaries/Software-Engi...
Re: My thoughts about the Principal role
#45> An architect? A big part of my work is to improve systems and platforms. Listen to problems and propose solutions. But I don't feel like the guy who does a plan which must be blindly followed by others. I don't want to be a gatekeeper who says what can be used and what can't. The only area where I feel like you need to be super careful is around architecture. How many chefs can bake the same cake before you have a…
This is... kind of precisely the distinction between technical leadership in a medium sized team vs in a really large team. It's one of the hardest challenges I work with senior devs to overcome as they move up to larger and larger scoped roles, up to principal engineer positions. Because what they have learned that got them that far stops working as they develop into more expansive roles and responsibilities.
Basically, the problem solving approach of 'I'll go away and work out how we're going to do this, then bring back a masterplan', while it offers a good path to successful project delivery early in your career, does not scale.
What worked for you when you were building a system with one or two teams working on it for three to six months is not a viable approach for systems which will have five to ten teams working on them, over multiple years.
You have to adopt approaches that decentralize decisionmaking - else you'll become a bottleneck; you have to adopt approaches that are adaptable to information that will be uncovered later and to requirements that will shift; you have to adopt approaches that acknowledge that you are never going to be 'full stack' enough to be able to make smart decisions about every single part of the solution - the mobile apps, the backends, the financial system integrations, the frontend caching, the analytics and reporting... and you need the expertise of different teams to deliver that.
You basically have to unlearn the pattern of 'let an experienced person set out the whole plan' that has been successful for you so far as you move to higher level leadership roles.
As a principal/staff/whatever in a big engineering org, your role is much more about making sure that the right people are having the right conversations and negotiating the right boundaries and not getting caught up on artificial constructs they think are being imposed by you from above. You need to leverage all the intellectual capabilities of the senior engineers on every team, not tie their hands by thinking you know more than them.
Same as as you become more senior, you shouldn't be writing critical code - eventually you also get too senior to be making critical architectural decisions.
Re: My thoughts about the Principal role
#46Principal role = expensive lean manager. They want to help others achieve something without actually getting their hands dirty. Of all the principal engineers I’ve worked with, the vast majority behave like motivational coaches/lean managers. Examples: - There’s an outage on a Sunday morning. A huge Slack thread starts. Devops and devs on call manage to fix the issue. Principal engineer gets involved ACKing other’s p…
I'm in a PE role, and I have to tell myself every day not to go do the POC because that's not how I can maximize my impact. If someone else can do that work, I'm going to try and lean on them. Strategy is hard. Much harder than I thought it would be. I am unable to make progress on strategy when I'm deep in tactical work. I do jump in when needed, but every time I get my hands dirty I fall behind on strategy. Your PE…
> I have to tell myself every day not to go do the POC
What is a "POC"?
Side Rant : It's really helpful if an acronym is at least expanded in the first use. I don't find the acronym in the article or the parent comment. I am not sure why and how this is a norm but it's frustrating as someone who wants to understand a conversation.
Re: My thoughts about the Principal role
#47Earlier quoted context omitted.
From a practical perspective, most companies large enough to support PEs as described here, are going to have misaligned hacks that made sense once upon a time but are no longer sensible. A big part of a PEs job is to keep the train moving despite nonsensical design decisions, organizational politics/empires, and legacy code bases/use cases that no one wants to touch. A good PE will help incrementally resolve/improve…
> A good PE will help incrementally resolve/improve the above situations. 100% agree. What I posted above is an idealistic perspective in which you get to greenfield an application from zero. Most real world situations involve some degree of legacy domain implementations which must be bridged into the future. Being able to rebuild the ship from the inside while it is sailing to the new world is an incredibly valuable…
Unfortunately what you're describing never actually occurs in practice, unless you're simply rebuilding an existing piece of software, which has only technical improvements (ie. better performance, fewer bugs, etc).
The cases where you are starting from zero are also the cases where you don't understand the problem domain to a sufficient degree. You can try to get clients involved earlier, but that is very dangerous:
- It's hard to get a sufficient diversity of early users.
- Clients are incapable of prioritising what's important. Everything feature they think of (even the things they won't actually use) will be essential to them if you ask.
- The actually essential features will be so obvious to them that they won't even think of mentioning them.
- They don't understand abstractions: any concept you try to define with their help will become amorphous and therefore useless.
- Engineering is fundamentally subtractive: with zero code a product could eventually do anything. As you add code, you are restricting what it can do so that the results are the "useful" ones. For example. when you create a "user" table with an "email" property, you are restricting users to have one email address. You cannot make progress without these restrictions, but if you actually spell out those restrictions, you'll get massive pushback.
This is why so many engineers like building things for other engineers - because they can be their own client.
It's also why it's impossible in most cases to go from zero to a well-architected product in one go.
Re: My thoughts about the Principal role
#48Principal role = expensive lean manager. They want to help others achieve something without actually getting their hands dirty. Of all the principal engineers I’ve worked with, the vast majority behave like motivational coaches/lean managers. Examples: - There’s an outage on a Sunday morning. A huge Slack thread starts. Devops and devs on call manage to fix the issue. Principal engineer gets involved ACKing other’s p…
I'm in a PE role, and I have to tell myself every day not to go do the POC because that's not how I can maximize my impact. If someone else can do that work, I'm going to try and lean on them. Strategy is hard. Much harder than I thought it would be. I am unable to make progress on strategy when I'm deep in tactical work. I do jump in when needed, but every time I get my hands dirty I fall behind on strategy. Your PE…
at my work, I'm a principal and my boss is a partner. he spends a lot of his time doing organizational stuff and coming up with plans to solve problems, but he also still writes PoCs. he'll take the downtime he has between meetings, solve the really hard parts of the problem and hand it to the team for incubation. I do the same thing now - I pitched an idea which requires a fair bit of pure research, and I'm going to get a rough prototype going that vets the idea, then build out my team to make it better and turn it into a robust product.
the trick is to keep the PoCs lean enough that it's easy for your reports to flesh out and change the architecture as they need, but developed enough that it's working code, so people can run it and start working from a grounded product.
Re: My thoughts about the Principal role
#49Earlier quoted context omitted.
I'm in a PE role, and I have to tell myself every day not to go do the POC because that's not how I can maximize my impact. If someone else can do that work, I'm going to try and lean on them. Strategy is hard. Much harder than I thought it would be. I am unable to make progress on strategy when I'm deep in tactical work. I do jump in when needed, but every time I get my hands dirty I fall behind on strategy. Your PE…
> I have to tell myself every day not to go do the POC What is a "POC"? Side Rant : It's really helpful if an acronym is at least expanded in the first use. I don't find the acronym in the article or the parent comment. I am not sure why and how this is a norm but it's frustrating as someone who wants to understand a conversation.
Proof of Concept
Re: My thoughts about the Principal role
#50Earlier quoted context omitted.
I'm in a PE role, and I have to tell myself every day not to go do the POC because that's not how I can maximize my impact. If someone else can do that work, I'm going to try and lean on them. Strategy is hard. Much harder than I thought it would be. I am unable to make progress on strategy when I'm deep in tactical work. I do jump in when needed, but every time I get my hands dirty I fall behind on strategy. Your PE…
> I have to tell myself every day not to go do the POC What is a "POC"? Side Rant : It's really helpful if an acronym is at least expanded in the first use. I don't find the acronym in the article or the parent comment. I am not sure why and how this is a norm but it's frustrating as someone who wants to understand a conversation.
Sorry about that. POC was introduced in the parent comment, but as you said without expansion.