21 ms·

My thoughts about the Principal role

220 points by antonmry 5y ago

efnx 5y ago
Not only is it hard to define what the principal engineering role is, it will be different at almost every company. The same goes for staff eng and even to a lesser degree senior eng.
- skeeter2020 5y ago
  Interestingly it's sometimes harder for companies that already have the role defined than for growing orgs that usually do this JIT as really strong devs top out of senior and realize/decide they don't want to be become managers. I've defined this type of role twice now by using the skills and behaviours of the specific individuals (i.e. things they're already doing), then expanding the scope and sphere of influence for growth areas. It's worked pretty well because typically you should be promoting someone when they're demonstrating performance at the next level, rather than give them a promotion and then see if they're successful or not. The role needs to be vague enough to allow for individual and strategic changes, but defined enough to provide some type of identity. This is hard.
- halfmatthalfcat 5y ago
  And even more harder is that within a company, those titles are vastly different depending on what team you get hired on to. You could be hired on at a senior level for a given team yet be considered a standard software developer or even associate on a different team. Case in point, an engineer was hired on in my current company at a Senior role, being even considered for Principal and was subsequently moved to my team. They are now gauged at almost an Associate level when compared to the rest of the engineers on my team and their titles.
- deleted 5y ago
  [deleted]
- redisman 5y ago
  The special problem with Sr Engineer is that it’s most people’s title from year 5 to year 40. If you keep improving in your craft then it can be a very wide band. I for one have no interest in being a tech lead or a staff engineer as all the non technical work exhausts and frustrates me endlessly. I’m still striving to improve every year at engineering and architecture.
teachingassist 5y ago
> Am I a manager? No. [I] let the team self organize with my help Isn't that what a manager is, or should be?
- wayoutthere 5y ago
  I look at it as being situational. Sometimes you end up with a team whose natural styles all mesh and they don’t need much leadership. Self-organization is great here; a manager’s role should be to give advice and deal with corporate politics (IMO the politics/budget angles are the difference between a principal/staff engineer and a manager). Other times you get teams whose working styles are very far apart and have a hard time finding common ground. In the latter case, self-organization leads to communication breakdowns; so you have to force some organization on the team. Ideally you would just hire a team with a diverse but complementary set of skills, but you go to war with the army you have.
  - skeeter2020 5y ago
    Also, although managers appear to work for a team or specific area, they usually interface across many or all in a department. The self organizing team will usually do so as if they are completely independent which is rarely true, so they need to organize within constraints of which they are totally unaware. Example: getting a different team to priortize work upon which your team depends will involve larger development plans, product management and the "politics" you reference. I've never met a technical lead who wants to do this and few who are good at it. This is a good thing.
vvladymyrov 5y ago
If you’d like to learn more on this topic Will Larsen has great read about being Principal Engineer. Here link to page that has link to his book https://staffeng.com/about/ https://staffeng.com/about/
version_five 5y ago
It's common in the consulting industry to have a wide range of titles - [senior] manager / principal, director, managing director, executive director, vice president, associate partner, etc. Depending on the firm, literally all of those could refer to a similar job. The reason I've seen put forward for this is to make it hard to compare titles, so that a person can feel like their title matches their seniority. I've seen this happening in tech too, especially with senior and "lead" roles (especially being "a" lead vs. "the" lead). At some places, I think the staff / principal / distinguished / etc engineer role is along these lines too, basically a way for a more experienced person to feel like they don't have the same job as a 25 year old.
- radicalbyte 5y ago
  It's also a way to provide a technical career path without having your super experienced people all stepping on each others toes.
- stephc_int13 5y ago
  I've seen that in Video Games versus Advertisement, Art Director is a high seniority position in the former while it could be an internship role in the latter.
- karaterobot 5y ago
  This, to the extent that after 13-14 years in the industry, I have no clue what differentiates any of these titles in theory, let alone in practice at individual organizations.
tkiolp4 5y ago
Principal 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 people comments, adding thumbs up emojis, and at the end says “Big thank you to all the people involved” (plus a rocket emoji) - There’s a decision to be made regarding i18n for DB tables. Architects, senior devs and the principal engineer get together to talk about potential solutions. The principal engineer acts as a lean manager: let people talk in turns, does support good ideas (I mean, he’s not clueless ofc), does try to gather everyone in to a common solution... but never gets his hands dirty as in: “what do you think about solution X? I could work on a POC to see if it’s worth it”. If, after months, it turns out that the idea to be implemented does work, then he says “All the props to the team!” (No way, really? It’s obvious that all the props should go to the team! You, principal, did nothing!). If it turns out that the idea actually does not work, then “no one is to blame, let’s do it better the next time. Let’s get feedback and blah blah”. As I said, if something works or if something doesn’t, it’s never on the principal (but hey, he gets to make twice as much as the most senior dev in the company!) - Microservices or modular monolith? Same as above. The principal engineer knows his stuff, but just as much as any other architect or senior dev, with the difference that the architects and senior devs are the ones who are going to do 99% of the work (both im terms of choosing the final decision and implementing them. The principal is just there to “support”... but that’s actually quite useless tbh) and they make significantly less money than the principal engineer.
- version_five 5y ago
  > 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 people comments, adding thumbs up emojis, and at the end says “Big thank you to all the people involved” (plus a rocket emoji) Just want to call out how accurate this is. The last place I worked was full of this kind of person (as managers, wecdid not have a principal title), and the description, right down to the emojis is bang on!
eplanit 5y ago
It seems like "Principal Engineer" is the new "Architect".
bob1029 5y ago
> 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 total shitshow on your hands? In my experience, this depends on the complexity of the cake. The more complex, the fewer chefs can be involved at the same time. The last place you want design-by-committee is when you are trying to model a very complex problem domain. Have your elder council determine the types, facts & relations for your solution, then let the team go wild on top of it. The people developing the schema should understand what normalization is and why it's so critical to long term success. 100% of business apps can start as excel spreadsheets documenting types, facts & relations. There is zero excuse to not start here [0]. Without some common understanding of what the fuck you even call things (and how they are related), you don't need to have a bunch of distributed design meetings about logic & UI that will be built on top of those concepts. [0]: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
- lumost 5y ago
  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 the above situations.
  - bob1029 5y ago
    > 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 skill set. Many developers get frustrated and demand a total rewrite (I used to do this). It would be really hard to make forward progress if you start off with a new ship in Spain every time you encountered the slightest bit of friction.
sudeepj 5y ago
> I don't feel like the guy who does a plan which must be blindly followed by others When I became PE, my boss said that if you have to successful then you need to get teams listen to you by influencing instead of an authority. At that moment, I had no idea how to go about this. But I realized one thing: "Knowledge is power". If you know the tech-stack, product & domain then you are well equipped for this role.
charles_f 5y ago
This post is good in that it doesn't try to define what a principal engineer is, but just give the author's opinion on what their job is. One thing I realized with getting jobs with increasing degrees of ambiguity and autonomy is that you can _somewhat_ make it what you want. If it turns out that what you want aligns with what is needed, then things go super well. The other thingis that titles are just a construct. They're nice badges that help rewarding people by giving ego instead of money. being a principal in a startup is different from being one at Amazon is different from being one at Facebook.
SavantIdiot 5y ago
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 contributions in your career that impact multiple products' bottom line or viability. As a bonus there is a weird deferred-income strategy they use that helps you avoid taxes, your regular bonus multipliers skyrocket, and you are expected to work 24/7. However, I witnessed several abuses where: - You can become one if you are friends with an upper manager who scoots you ahead in the line. Several times I saw this type of PE later pushed out by new management, because it was painfully obvious they were in over their heads to everyone else. - You can become one if you are in a small group that wants to justify its existence. Every group needs a principal engineer, and without one, it is a risk the group will be dissolved. Some managers of tiny groups like their ego trip and want to continue being big fish in small ponds. - And you can become one if your work a site that hands them out to puff up its image. In the latter case, there was one non-US site that was almost 40% principal engineers, and used that as their claim to fame. "We have the most principal engineers at our site" said the VP. Duh! You are also the VP that approved all of them so you could say that! So while Intel's definition makes sense and is generally true, it is abused about ... ~35% of the time? Disclaimer: Intel is an up or out company. You move up, or you move out. It is hard to hover in certain high-pressure divisions. I was passed over twice for PE and shuffled between divisions, and eventually exhausted to the point where i was "out". So i'm a tad bit bitter.
- disgrunt 5y ago
  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.
  - BigJono 5y ago
    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.
vp8989 5y ago
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 role is basically going to be that of a co-manager with no authority. I've been considering down-leveling or getting into some software niche where technical expertise is actually valued and existentially necessary to the business.
- matthias509 5y ago
  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. Probably the increase in happiness is worth it even if you have to “pay” for it with a slightly reduced salary.
  - andrey_utkin 5y ago
    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 you agree with that?
    - alistairSH 5y ago
      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.
heinrichhartman 5y ago
One thing we have made good experiences with recently is, having two separate meetings for managing engineering initiatives: 1. Engineering Meeting - led by Principal Engineer. With pure focus on technical questions. We go through open issues, PRs and discuss technical questions, engineering decisions like API design. Stakeholders from other teams are invited to participate. 2. Planning Meeting - led by a Engineering Manager. Report on progress, discuss priorization and decide work assignment a.k.a. "sprint planning". The principal engineer can take part in this as a team member. This helps me (as a principal) to stay away from people- and project management and purely focus on engineering topics (inc. writing code), which is where I see as my core competence.
solidist 5y ago
Nice. Here is my attempt following a few years partnering as an eng manager: https://dev.to/solidi/what-is-a-principal-engineer-anyway-55n0 https://dev.to/solidi/what-is-a-principal-engineer-anyway-55...
vii 5y ago
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 be in the critical path. Shipping on time is one of the toughest deliverables of the software engineer role, and one that many people struggle with. Accurately estimating development costs including wall time vs. actual time someone has to work on a project is a very important skill. It's not acceptable for senior engineers to abrogate responsibility for this, especially if they claim to be mentoring other engineers. Senior engineers own the business outcome and must weigh costs of all kinds, from security risks to technical debt. As scope increases, the feedback loops get longer and longer. A new engineer can tell if they did well with a comprehensive unit test. A junior engineer can tell if they did well with a performance or integration test. A senior engineer can tell if they did well with an A-B test in the market. A staff engineer can tell if they did well by seeing market share grow. In Big Tech, senior staff and principal roles carry the idea of doing something to 'shock the world' - that is, successfully shipping innovation that people were afraid to, for example, because it seemed risky. Greasing the wheels of communication between teams and helping people avoid common mistakes is fine and a good thing. But there is limited business value in building consensus around the latest "architecture" or framework or language or whatever, however nice it feels to enjoy the social status as the person turned to for this kind of question. Step change innovation is the real value add and this article hardly touches on it.
- astrange 5y ago
  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.
- antonmry 5y ago
  Interesting feedback, thanks! What I describe in the article are the challenges of the role based in my experience. What you describe it's the business as usual work. Innovation, deliver and push key initiatives, etc. are the reason to be promoted to Principal in first place. They are important but they aren't what I find more challenging in the role.
URSpider94 5y ago
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.
softwaredoug 5y ago
My quality of life as a senior staff eng depends on a couple things. Be curious what others would add: - *good manager*: at my company, I’m paired with a manager over a focus area. If they are good we'll form an effective partnership. They’ll help protect focus time, take on lots of planning and people management work, while I focus on the teams technical leadership and roadmap. -*Important company priority*: if what I’m working on actually matters to the company, we'll get the resources we need to execute. Without this, our team will be frequently poached and we won’t achieve much. - *strong stakeholder relationships*: I regularly meet with and take feedback from stakeholders. They can see where we’re going on a tech level and incorporate us into their plans. We can be an asset to the company’s different, customer facing product lines, not a hermitted group of devs. - *strong inter-disciplinary collaboration*: we have all the disciplines we need on the team. Whether it’s data, UX, eng, or something else, we’re not playing politics to negotiate with another management structure on every little task our team needs. It just gets done a a virtue of this discipline being a teammate... - *A road to prod*: we ship early and ship often. We don’t have anything in our way external to the team for shipping. Also we’re not working on a theoretical thing, it’s actual prod code we help with! -*hiring great people*: we hire amazing people, and usually we don’t have to worry about their quals. Or worry about them being a jerk. Also we meet to ensure they’ll be a good fit for the team. -*a clear area I own*: I want to make sure that if I’m given technical authority over an area, there’s not another overlapping staff/principal eng who’s also expecting to own some of that space. It’s clear what the groupings are and who does what to avoid politics and ego clashes between alpha geeks. -*active burnout prevention*: the culture and management work against my hard-charging style and strongly encourage me to walk away from work during vacations, weekends, and evenings...
- analog31 5y ago
  I'm senior staff, and I think you really nailed it. In my case I'm in a more exploratory research team, so a lot of my stuff doesn't make it to production, but I develop the techniques that will hopefully lead to the next generation of products. Maybe I'd add a couple things: * Always learning. * Visibility and interaction with a broader range of people. For instance I work for a big multi-national, and I greatly enjoy cross site collaborations.
tibiahurried 5y ago
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.
- sys_64738 5y ago
  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.
  - tibiahurried 5y ago
    hehe I guarantee you I have worked indeed in many large FAANG and not, tech companies. And it is pretty much the same everywhere. I think when you get at a certain level, people tend to rest and vest, thus producing little to no tangible value for the company. But, since their networking is strong, they keep sticking around. Large corp => too many "architects" => meetings => ... and nothing gets done. Ever asked yourself why big corp innovate through acquisition?
sys_64738 5y ago
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.
- redisman 5y ago
  I’m confused - you’re describing a Sr Engineer
mateCheck 5y ago
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.
cactus2093 5y ago
This is a pet peeve of mine due to how common it is in all sorts of tech career advice, but I can never take a tech blogger/influencer seriously when they are so flippant about amounts of money that most people will never see in their entire lives. If you look at salary info on a site like levels.fyi for top tech companies the difference between a senior vs staff vs principal engineer salary is pretty mind boggling. E.g. looking at Google right now, the annual total comp goes from $353k at senior level to $486k at staff level to $992k at the principal level. Just a cool million dollars a year on the table, and the author is saying things like "Nobody complains about a salary raise but optimize to career based on the salary is a quite bad idea if you are already covered." The whole piece is about how they just really like selflessly helping other engineers, and it's got nothing to do with pay or status. It's not like we're just talking here about the difference between upgrading your car from a Toyota to a Lexus, or staying at a slightly nicer hotel when you go on a vacation. This is the ability to never worry amount money again for the rest of your life after just a couple of years in the role. It's the ability to retire 20 years younger or pay off your kid's 4 year ivy league education in just a year of savings or fund your own charity that helps thousands of people, or whatever else you might want to do in some of your wildest dreams. I can't help but see it as anything other than a very obnoxious flex/virtue signal whenever people in elite tech roles make claims like this about how salary is so much less important than how much you're learning, and other things of that nature.
rufus_foreman 5y ago
I had that job title once. It was a way for my boss to justify paying me more, I just wrote code. Job titles don't mean anything to me but they do to HR.
deleted 5y ago
[deleted]
- deleted 5y ago
  [deleted]
plank_time 5y ago
25 years of experience, and I never wanted to get above Staff Engineer. The work is just not something that I enjoy. I love coding, and I like working directly with my team. When I applied to new companies, I purposefully applied at the Senior engineer level, not Staff or higher. Sometimes I wonder if I should have just put on my big boy pants on and put in the extra work to get promoted, something my bosses actually asked me to do. And more especially when I see my peers become at a higher level, director, VP etc. But life is short and I never would have stayed in the business if I had to care about things that I fundamentally don’t care about. Almost dying a couple of years ago really helped gel my thoughts on that.
cudgy 5y ago
“If after one year, you can't leave a team without impact, you've failed in your work.” A top managerial professor I knew defined a manager’s role to be exactly this. Principal or manager or whatever you are called doesn’t matter in the end, since once you go beyond “senior” level positions your role largely should be facilitating, empowering, and advocating for the members of your team. In reality, these roles unfortunately deteriorate into countless meetings with other managers and political struggles within a strong current of corporate compromises. Ignoring the latter part usually results in bad outcomes for one’s career at this level. In my opinion, a true, technical principal role only works when there is another very capable person that fulfills the role of shielding the principal from the inevitable political, hierarchical forces that will head their way particularly from the sales and marketing departments.
- mavelikara 5y ago
  > In reality, these roles unfortunately deteriorate into countless meetings with other managers and political struggles within a strong current of corporate compromises. It is unfortunate that talented programmers turn their backs on leadership roles requiring inter-personal skills, propagating the stereotypes that prevent programers from progressing in their careers. > In my opinion, a true, technical principal role only works when there is another very capable person that fulfills the role of shielding the principal from the inevitable political, hierarchical forces that will head their way particularly from the sales and marketing departments. Needing such "adult supervision" is harmful for programming profession in the long run.
  - cudgy 5y ago
    This is not about who is the “adult” … it’s about creating an environment for success given the expectations of the job. Technical roles like a true principal at a high level require deep concentration and focus … being interrupted every 15-30 minutes to attend a meeting, answer a phone call, strategize a political response, respond to a slack message, handle complaints from critical clients, attend budget meetings, create reports, etc. is not the right environment.
fukmbas 5y ago
Principal roles are more BS made up by business types with MBAs. Eliminate Product!

220 points by antonmry 5y ago

efnx 5y ago

Not only is it hard to define what the principal engineering role is, it will be different at almost every company. The same goes for staff eng and even to a lesser degree senior eng.

skeeter2020 5y ago
Interestingly it's sometimes harder for companies that already have the role defined than for growing orgs that usually do this JIT as really strong devs top out of senior and realize/decide they don't want to be become managers. I've defined this type of role twice now by using the skills and behaviours of the specific individuals (i.e. things they're already doing), then expanding the scope and sphere of influence for growth areas. It's worked pretty well because typically you should be promoting someone when they're demonstrating performance at the next level, rather than give them a promotion and then see if they're successful or not. The role needs to be vague enough to allow for individual and strategic changes, but defined enough to provide some type of identity. This is hard.
halfmatthalfcat 5y ago
And even more harder is that within a company, those titles are vastly different depending on what team you get hired on to. You could be hired on at a senior level for a given team yet be considered a standard software developer or even associate on a different team. Case in point, an engineer was hired on in my current company at a Senior role, being even considered for Principal and was subsequently moved to my team. They are now gauged at almost an Associate level when compared to the rest of the engineers on my team and their titles.
deleted 5y ago
[deleted]
redisman 5y ago
The special problem with Sr Engineer is that it’s most people’s title from year 5 to year 40. If you keep improving in your craft then it can be a very wide band. I for one have no interest in being a tech lead or a staff engineer as all the non technical work exhausts and frustrates me endlessly. I’m still striving to improve every year at engineering and architecture.

teachingassist 5y ago

> Am I a manager? No. [I] let the team self organize with my help Isn't that what a manager is, or should be?

wayoutthere 5y ago
I look at it as being situational. Sometimes you end up with a team whose natural styles all mesh and they don’t need much leadership. Self-organization is great here; a manager’s role should be to give advice and deal with corporate politics (IMO the politics/budget angles are the difference between a principal/staff engineer and a manager). Other times you get teams whose working styles are very far apart and have a hard time finding common ground. In the latter case, self-organization leads to communication breakdowns; so you have to force some organization on the team. Ideally you would just hire a team with a diverse but complementary set of skills, but you go to war with the army you have.
- skeeter2020 5y ago
  Also, although managers appear to work for a team or specific area, they usually interface across many or all in a department. The self organizing team will usually do so as if they are completely independent which is rarely true, so they need to organize within constraints of which they are totally unaware. Example: getting a different team to priortize work upon which your team depends will involve larger development plans, product management and the "politics" you reference. I've never met a technical lead who wants to do this and few who are good at it. This is a good thing.

vvladymyrov 5y ago

If you’d like to learn more on this topic Will Larsen has great read about being Principal Engineer. Here link to page that has link to his book https://staffeng.com/about/ https://staffeng.com/about/

version_five 5y ago

It's common in the consulting industry to have a wide range of titles - [senior] manager / principal, director, managing director, executive director, vice president, associate partner, etc. Depending on the firm, literally all of those could refer to a similar job. The reason I've seen put forward for this is to make it hard to compare titles, so that a person can feel like their title matches their seniority. I've seen this happening in tech too, especially with senior and "lead" roles (especially being "a" lead vs. "the" lead). At some places, I think the staff / principal / distinguished / etc engineer role is along these lines too, basically a way for a more experienced person to feel like they don't have the same job as a 25 year old.

radicalbyte 5y ago
It's also a way to provide a technical career path without having your super experienced people all stepping on each others toes.
stephc_int13 5y ago
I've seen that in Video Games versus Advertisement, Art Director is a high seniority position in the former while it could be an internship role in the latter.
karaterobot 5y ago
This, to the extent that after 13-14 years in the industry, I have no clue what differentiates any of these titles in theory, let alone in practice at individual organizations.

tkiolp4 5y ago

Principal 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 people comments, adding thumbs up emojis, and at the end says “Big thank you to all the people involved” (plus a rocket emoji) - There’s a decision to be made regarding i18n for DB tables. Architects, senior devs and the principal engineer get together to talk about potential solutions. The principal engineer acts as a lean manager: let people talk in turns, does support good ideas (I mean, he’s not clueless ofc), does try to gather everyone in to a common solution... but never gets his hands dirty as in: “what do you think about solution X? I could work on a POC to see if it’s worth it”. If, after months, it turns out that the idea to be implemented does work, then he says “All the props to the team!” (No way, really? It’s obvious that all the props should go to the team! You, principal, did nothing!). If it turns out that the idea actually does not work, then “no one is to blame, let’s do it better the next time. Let’s get feedback and blah blah”. As I said, if something works or if something doesn’t, it’s never on the principal (but hey, he gets to make twice as much as the most senior dev in the company!) - Microservices or modular monolith? Same as above. The principal engineer knows his stuff, but just as much as any other architect or senior dev, with the difference that the architects and senior devs are the ones who are going to do 99% of the work (both im terms of choosing the final decision and implementing them. The principal is just there to “support”... but that’s actually quite useless tbh) and they make significantly less money than the principal engineer.

version_five 5y ago
> 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 people comments, adding thumbs up emojis, and at the end says “Big thank you to all the people involved” (plus a rocket emoji) Just want to call out how accurate this is. The last place I worked was full of this kind of person (as managers, wecdid not have a principal title), and the description, right down to the emojis is bang on!

eplanit 5y ago

It seems like "Principal Engineer" is the new "Architect".

bob1029 5y ago

> 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 total shitshow on your hands? In my experience, this depends on the complexity of the cake. The more complex, the fewer chefs can be involved at the same time. The last place you want design-by-committee is when you are trying to model a very complex problem domain. Have your elder council determine the types, facts & relations for your solution, then let the team go wild on top of it. The people developing the schema should understand what normalization is and why it's so critical to long term success. 100% of business apps can start as excel spreadsheets documenting types, facts & relations. There is zero excuse to not start here [0]. Without some common understanding of what the fuck you even call things (and how they are related), you don't need to have a bunch of distributed design meetings about logic & UI that will be built on top of those concepts. [0]: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

lumost 5y ago
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 the above situations.
- bob1029 5y ago
  > 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 skill set. Many developers get frustrated and demand a total rewrite (I used to do this). It would be really hard to make forward progress if you start off with a new ship in Spain every time you encountered the slightest bit of friction.

sudeepj 5y ago

> I don't feel like the guy who does a plan which must be blindly followed by others When I became PE, my boss said that if you have to successful then you need to get teams listen to you by influencing instead of an authority. At that moment, I had no idea how to go about this. But I realized one thing: "Knowledge is power". If you know the tech-stack, product & domain then you are well equipped for this role.

charles_f 5y ago

This post is good in that it doesn't try to define what a principal engineer is, but just give the author's opinion on what their job is. One thing I realized with getting jobs with increasing degrees of ambiguity and autonomy is that you can _somewhat_ make it what you want. If it turns out that what you want aligns with what is needed, then things go super well. The other thingis that titles are just a construct. They're nice badges that help rewarding people by giving ego instead of money. being a principal in a startup is different from being one at Amazon is different from being one at Facebook.

SavantIdiot 5y ago

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 contributions in your career that impact multiple products' bottom line or viability. As a bonus there is a weird deferred-income strategy they use that helps you avoid taxes, your regular bonus multipliers skyrocket, and you are expected to work 24/7. However, I witnessed several abuses where: - You can become one if you are friends with an upper manager who scoots you ahead in the line. Several times I saw this type of PE later pushed out by new management, because it was painfully obvious they were in over their heads to everyone else. - You can become one if you are in a small group that wants to justify its existence. Every group needs a principal engineer, and without one, it is a risk the group will be dissolved. Some managers of tiny groups like their ego trip and want to continue being big fish in small ponds. - And you can become one if your work a site that hands them out to puff up its image. In the latter case, there was one non-US site that was almost 40% principal engineers, and used that as their claim to fame. "We have the most principal engineers at our site" said the VP. Duh! You are also the VP that approved all of them so you could say that! So while Intel's definition makes sense and is generally true, it is abused about ... ~35% of the time? Disclaimer: Intel is an up or out company. You move up, or you move out. It is hard to hover in certain high-pressure divisions. I was passed over twice for PE and shuffled between divisions, and eventually exhausted to the point where i was "out". So i'm a tad bit bitter.

disgrunt 5y ago
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.
- BigJono 5y ago
  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.

vp8989 5y ago

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 role is basically going to be that of a co-manager with no authority. I've been considering down-leveling or getting into some software niche where technical expertise is actually valued and existentially necessary to the business.

matthias509 5y ago
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. Probably the increase in happiness is worth it even if you have to “pay” for it with a slightly reduced salary.
- andrey_utkin 5y ago
  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 you agree with that?
  - alistairSH 5y ago
    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.

heinrichhartman 5y ago

One thing we have made good experiences with recently is, having two separate meetings for managing engineering initiatives: 1. Engineering Meeting - led by Principal Engineer. With pure focus on technical questions. We go through open issues, PRs and discuss technical questions, engineering decisions like API design. Stakeholders from other teams are invited to participate. 2. Planning Meeting - led by a Engineering Manager. Report on progress, discuss priorization and decide work assignment a.k.a. "sprint planning". The principal engineer can take part in this as a team member. This helps me (as a principal) to stay away from people- and project management and purely focus on engineering topics (inc. writing code), which is where I see as my core competence.

solidist 5y ago

Nice. Here is my attempt following a few years partnering as an eng manager: https://dev.to/solidi/what-is-a-principal-engineer-anyway-55n0 https://dev.to/solidi/what-is-a-principal-engineer-anyway-55...

vii 5y ago

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 be in the critical path. Shipping on time is one of the toughest deliverables of the software engineer role, and one that many people struggle with. Accurately estimating development costs including wall time vs. actual time someone has to work on a project is a very important skill. It's not acceptable for senior engineers to abrogate responsibility for this, especially if they claim to be mentoring other engineers. Senior engineers own the business outcome and must weigh costs of all kinds, from security risks to technical debt. As scope increases, the feedback loops get longer and longer. A new engineer can tell if they did well with a comprehensive unit test. A junior engineer can tell if they did well with a performance or integration test. A senior engineer can tell if they did well with an A-B test in the market. A staff engineer can tell if they did well by seeing market share grow. In Big Tech, senior staff and principal roles carry the idea of doing something to 'shock the world' - that is, successfully shipping innovation that people were afraid to, for example, because it seemed risky. Greasing the wheels of communication between teams and helping people avoid common mistakes is fine and a good thing. But there is limited business value in building consensus around the latest "architecture" or framework or language or whatever, however nice it feels to enjoy the social status as the person turned to for this kind of question. Step change innovation is the real value add and this article hardly touches on it.

astrange 5y ago
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.
antonmry 5y ago
Interesting feedback, thanks! What I describe in the article are the challenges of the role based in my experience. What you describe it's the business as usual work. Innovation, deliver and push key initiatives, etc. are the reason to be promoted to Principal in first place. They are important but they aren't what I find more challenging in the role.

URSpider94 5y ago

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.

softwaredoug 5y ago

My quality of life as a senior staff eng depends on a couple things. Be curious what others would add: - *good manager*: at my company, I’m paired with a manager over a focus area. If they are good we'll form an effective partnership. They’ll help protect focus time, take on lots of planning and people management work, while I focus on the teams technical leadership and roadmap. -*Important company priority*: if what I’m working on actually matters to the company, we'll get the resources we need to execute. Without this, our team will be frequently poached and we won’t achieve much. - *strong stakeholder relationships*: I regularly meet with and take feedback from stakeholders. They can see where we’re going on a tech level and incorporate us into their plans. We can be an asset to the company’s different, customer facing product lines, not a hermitted group of devs. - *strong inter-disciplinary collaboration*: we have all the disciplines we need on the team. Whether it’s data, UX, eng, or something else, we’re not playing politics to negotiate with another management structure on every little task our team needs. It just gets done a a virtue of this discipline being a teammate... - *A road to prod*: we ship early and ship often. We don’t have anything in our way external to the team for shipping. Also we’re not working on a theoretical thing, it’s actual prod code we help with! -*hiring great people*: we hire amazing people, and usually we don’t have to worry about their quals. Or worry about them being a jerk. Also we meet to ensure they’ll be a good fit for the team. -*a clear area I own*: I want to make sure that if I’m given technical authority over an area, there’s not another overlapping staff/principal eng who’s also expecting to own some of that space. It’s clear what the groupings are and who does what to avoid politics and ego clashes between alpha geeks. -*active burnout prevention*: the culture and management work against my hard-charging style and strongly encourage me to walk away from work during vacations, weekends, and evenings...

analog31 5y ago
I'm senior staff, and I think you really nailed it. In my case I'm in a more exploratory research team, so a lot of my stuff doesn't make it to production, but I develop the techniques that will hopefully lead to the next generation of products. Maybe I'd add a couple things: * Always learning. * Visibility and interaction with a broader range of people. For instance I work for a big multi-national, and I greatly enjoy cross site collaborations.

tibiahurried 5y ago

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.

sys_64738 5y ago
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.
- tibiahurried 5y ago
  hehe I guarantee you I have worked indeed in many large FAANG and not, tech companies. And it is pretty much the same everywhere. I think when you get at a certain level, people tend to rest and vest, thus producing little to no tangible value for the company. But, since their networking is strong, they keep sticking around. Large corp => too many "architects" => meetings => ... and nothing gets done. Ever asked yourself why big corp innovate through acquisition?

sys_64738 5y ago

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.

redisman 5y ago
I’m confused - you’re describing a Sr Engineer

mateCheck 5y ago

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.

cactus2093 5y ago

This is a pet peeve of mine due to how common it is in all sorts of tech career advice, but I can never take a tech blogger/influencer seriously when they are so flippant about amounts of money that most people will never see in their entire lives. If you look at salary info on a site like levels.fyi for top tech companies the difference between a senior vs staff vs principal engineer salary is pretty mind boggling. E.g. looking at Google right now, the annual total comp goes from $353k at senior level to $486k at staff level to $992k at the principal level. Just a cool million dollars a year on the table, and the author is saying things like "Nobody complains about a salary raise but optimize to career based on the salary is a quite bad idea if you are already covered." The whole piece is about how they just really like selflessly helping other engineers, and it's got nothing to do with pay or status. It's not like we're just talking here about the difference between upgrading your car from a Toyota to a Lexus, or staying at a slightly nicer hotel when you go on a vacation. This is the ability to never worry amount money again for the rest of your life after just a couple of years in the role. It's the ability to retire 20 years younger or pay off your kid's 4 year ivy league education in just a year of savings or fund your own charity that helps thousands of people, or whatever else you might want to do in some of your wildest dreams. I can't help but see it as anything other than a very obnoxious flex/virtue signal whenever people in elite tech roles make claims like this about how salary is so much less important than how much you're learning, and other things of that nature.

rufus_foreman 5y ago

I had that job title once. It was a way for my boss to justify paying me more, I just wrote code. Job titles don't mean anything to me but they do to HR.

deleted 5y ago

[deleted]

deleted 5y ago
[deleted]

plank_time 5y ago

25 years of experience, and I never wanted to get above Staff Engineer. The work is just not something that I enjoy. I love coding, and I like working directly with my team. When I applied to new companies, I purposefully applied at the Senior engineer level, not Staff or higher. Sometimes I wonder if I should have just put on my big boy pants on and put in the extra work to get promoted, something my bosses actually asked me to do. And more especially when I see my peers become at a higher level, director, VP etc. But life is short and I never would have stayed in the business if I had to care about things that I fundamentally don’t care about. Almost dying a couple of years ago really helped gel my thoughts on that.

cudgy 5y ago

“If after one year, you can't leave a team without impact, you've failed in your work.” A top managerial professor I knew defined a manager’s role to be exactly this. Principal or manager or whatever you are called doesn’t matter in the end, since once you go beyond “senior” level positions your role largely should be facilitating, empowering, and advocating for the members of your team. In reality, these roles unfortunately deteriorate into countless meetings with other managers and political struggles within a strong current of corporate compromises. Ignoring the latter part usually results in bad outcomes for one’s career at this level. In my opinion, a true, technical principal role only works when there is another very capable person that fulfills the role of shielding the principal from the inevitable political, hierarchical forces that will head their way particularly from the sales and marketing departments.

mavelikara 5y ago
> In reality, these roles unfortunately deteriorate into countless meetings with other managers and political struggles within a strong current of corporate compromises. It is unfortunate that talented programmers turn their backs on leadership roles requiring inter-personal skills, propagating the stereotypes that prevent programers from progressing in their careers. > In my opinion, a true, technical principal role only works when there is another very capable person that fulfills the role of shielding the principal from the inevitable political, hierarchical forces that will head their way particularly from the sales and marketing departments. Needing such "adult supervision" is harmful for programming profession in the long run.
- cudgy 5y ago
  This is not about who is the “adult” … it’s about creating an environment for success given the expectations of the job. Technical roles like a true principal at a high level require deep concentration and focus … being interrupted every 15-30 minutes to attend a meeting, answer a phone call, strategize a political response, respond to a slack message, handle complaints from critical clients, attend budget meetings, create reports, etc. is not the right environment.

fukmbas 5y ago

Principal roles are more BS made up by business types with MBAs. Eliminate Product!