Having been at several companies, I think I was happiest about my career when I didn’t have a fancy title and did not really know anyone else’s either (aside from obvious managers). It was nicer just knowing who’s in charge of what thing, and seeing your influence grow as you are trusted with more things.
When I see titles, it just makes unhelpful thoughts enter my head, like: are all these people “at my level” really contributing as much as me? Sometimes I even thought the reverse, like: how can this seemingly-junior person still be stuck at that level, when he is clearly doing all this great stuff we depend on every day? Of course the especially soul-crushing case is when you encounter people that clearly suck at what they do, and they’re 1-2 levels above you; and worse, I have occasionally seen those people promoted further!
It is also hard not to look at titles on places like LinkedIn. I know I shouldn’t care, since titles mean different things at every company, and some especially-impressive-sounding titles can range from “meh” to “god-level” depending on where it is. And yet, it gets in my head sometimes, making me wonder every few years if I am at the level I should be.
When the title “matters” at a company, it also makes me consider it a factor in annual reviews. If I get a raise, bonus, etc. but see my damned title stagnate year over year, suddenly I care about this and take it as a complete lack of recognition by the company (that literally would not happen if they simply did not tell me what my title is!).
I hadn't thought about it in this context before, but I used to train Kendo (https://en.wikipedia.org/wiki/Kendo), a Japanese martial art, a long time ago. One interesting thing is that Kendo doesn't have belts like most other martial arts, the principle being that seeing the color of someone's belt causes you to prejudge their ability. Ideally, you should only know how good they are by actually training/fighting with them.
I've been very disappointed by comparing people's titles with their actual technical ability -- somehow it never seems to be the case that the ability outstrips the title.
>> somehow it never seems to be the case that the ability outstrips the title.
Really? You've never worked with a junior who's punching far above their weight? I've had several on my team and work as hard as I can to get them promoted asap.
> Kendo doesn't have belts like most other martial arts, the principle being that seeing the color of someone's belt causes you to prejudge their ability.
TIL: This is a really interesting perspective; Thank You for this! I will use it from now to calm myself down. I, always either got mortified by the extreme skill of my juniors or by the incompetence of seniors — not sure if it’s the case with me or is it a general feeling.
The Kendo way at-least makes me ignore the titles :)
Reminds me of rocket league. It's 1v1s do not tell you the rank of your opponent until the end of the game. But you can clearly tell when you come across a player that is one rank above you. They play very differently.
Beating that higher ranked player promotes you to their rank (and demoted them). It's like a mini boss that the game doesn't tell you about.
A long time ago, Judo didn't have color belt either, they added it for the Europeans so that they could see their progression..
That's one benefit but I think that the main benefit is that when you've a high level, you'll know that this guy in front of you is a beginner and you'll go soft on him, which is quite important: if he doesn't know how to fall properly the beginner could be injured if the "high level" guy doesn't notice in time..
> and seeing your influence grow as you are trusted with more things.
That's the ideal scenario, that you earn the esteem and trust of your peers because the work you do speaks for itself.
The flipside with this is, this process takes time. It really takes years. Sometimes there will not be that time. You are a new hire brought in to do a high-impact thing; or a high-impact project crosses across the entire organization where suddenly all participants are relative stranger; or the team you worked in was of very low external visibility but a mentor recognized your potential and pulled you out to help recalibrate a different but malfunctioning team, etc...
Then titles are important. It is very unfortunate that we are very cynical of titles, because, in well-run organizations, they are meaningful, and in fact, should be meaningful. Imagine in the military if every officer had to prove themselves over and over again. It's unworkable.
At some point, larger organizations will need to grant leverage to a technical individual. A title helps with providing that.
I agree and go further to say I've seen people with demonstrated contributions suddenly clearly being more valued when they get a title, to the point that nothing changes about what they do but others rate the impact as being larger after a promotion, to the point that they eventually are actually having larger impact just because others now believe they can / should.
I've also seen the opposite, perfectly fine engineers get worse after a promotion due to the weight of the title, without any other change to their work / schedule.
You hit the nail on the head. It was very different coming from Microsoft, where people's title and level (about one-two levels corresponded to a particular title) were visible in every chat dialog, to Google where you can edit your title to anything you want and levels can be seen only by going to a tool and looking it up specifically.
When I started at Twilio, I set my title on whatever chat we were using to something silly like "Director of Naptime Initiatives". (Well, ok, when I started we just had a poorly-used internal IRC server, so I guess this was a bit later when we got HipChat or whatever.) Sadly, these days the title field on Slack is synced with Active Directory, which has the human-readable title name, plus the level number.
It's really dehumanizing. I think I'd rather not know people's titles, just what team they're on, and their role.
At my current company, where I've been for over ten years, I've always just made up a title to match my current focus/what seemed "fresh." My original external title that was made up to hire me didn't actually make a lot of sense and differed from the internal HR title anyway.
Ended up doing something similar in my original tech job as well. I'm not sure I've ever really used my official HR title and would probably have to look it up to be sure I'm remembering it correctly.
I'm waiting to find a place that won't push me to keep advancing up the career ladder, without leaving my salary lagging behind the rising cost of living.
Does having limited ambition make you a bad dev/engineer, if you keep learning new things and contributing quality code at your current level of responsibility?
It doesn't make you a bad engineer, but it does, generally, put a ceiling on the value you are able to provide to the company. Individual contributors can only get so much done in a given amount of time, and over a long enough time scale, are generally interchangeable with one another.
Sure, you might have some specialized knowledge or understand system X better than anybody else, but there's diminishing returns on that, hence why you won't get big raises forever.
As you move up the chain, it eventually stops being about your direct technical contributions and about your ability to multiply the value of everybody under you in your org.
It certainly doesn't make you a bad anything. Your level of ambition is a personal thing. It's yours alone, and no one gets to look down on it[0]. This idea that a person's worth is tied to how far they want to and are able to go in their career is something that needs to die.
If you're happy with where you are, and happy with your salary and status, then it's fine to stay there! Certainly, as you say, continue to learn new things, make quality contributions, and get your work done.
Many companies will have what they call "terminal levels" for individual contributors (most probably don't really advertise this unless you specifically talk about it with your manager). The idea is that you can work at a level where you can get your day-to-day work done with minimal guidance, even if you need guidance on the bigger picture stuff (like what you should be working on, and why). You should certainly talk to your manager about this, if you feel comfortable. And if you don't, and/or they keep pushing you to climb the ladder further, then yeah, you should probably find a new gig.
One caveat: ageism is still an unfortunate thing in our industry, and as you get into your 40s and beyond, if you're still "only" a "senior software engineer", you may have trouble getting new jobs.
Companies don't want to get stuck with people who are perpetually "junior" and need a lot of hand-holding to get their jobs done. That's of course ok for a while someone is learning and growing, but if they aren't growing out of that, they're a liability and time sink. But once you're past that point, you should be ok. The only problem is if you end up at a weird place where no one wants to progress up through staff/principal/architect/fellow, in which case I wouldn't be surprised if everyone starts getting pressured to up their ambition. But that sort of scenario seems somewhat unlikely?
[0] Well, unless they are in your immediate family and your lack of ambition is putting their livelihood at risk in ways they can't mitigate. But I'm assuming that's not the case here ;)
What will you do when you're in your 50s? I've seen what happens to older developers, they're one layoff from being totally screwed. Ageism is a real problem in the industry and it motivates me to keep advancing.
On the flip side, having a title is a good way to know if you're being compensated appropriately. If you see someone 2 levels above you working on much less impactful projects then perhaps it's time to have a conversation with your manager about pay or time to start looking for new jobs.
On a side note, I use to see people with higher titles than mine not visibly doing as much as me, and found it grating. Now I have one of those titles, and I'm working harder than before, but a lot of it is with vendors, contractors, and overseeing projects. To ICs inside a particular project, it probably likes like I'm not doing much of anything. It changed my outlook on such things a lot.
Why do you feel you should be paid more because you feel you are doing more work? You are paid the least amount possible to fill your position during the hiring cycle. Your worth is what the market will pay you.
The fact that someone else is doing more or less with a higher title shouldn't influence your life at all. Jealousy shouldn't tell you when you should look for a job. If you are unhappy leave if you are happy stay. If your happiness is determined by what a random person is paid you will never be happy.
Don't get carried away by marketing of thoughts, few folks prefer to be the mouthpiece of some grandiose concept .. if crazy ideas have followers, it becomes a cult...a cult over to.e becomes religion.
There might be some honesty / truth behind what is described but in my 2 decades of IT work, mostly ass kissers have taken home the big bucks .
> when you encounter people that clearly suck at what they do, and they’re 1-2 levels above you
I think this is a logical contradiction. If there exists people that you are in a position to judge their competence you deserve to be in their position or higher, therefore it cannot be that they are 1-2 levels higher than you.
Always keep in mind that sometimes the "principal engineer" title is just a company's only way of hiring a senior engineer because their pay bands are so far below market rate. Don't let a description of a Google principal engineer scare you away from inquiring and applying for principal engineer positions at other companies.
Or more generally: Job titles aren’t portable between companies in the tech industry. Don’t assume that they mean the same thing at every company. Don’t assume a company is underpaying people just because they’re giving out Principal Software Engineer titles. Principal Software Engineer at one company could just be the equivalent of Senior Software Engineer II at another company.
On the hiring side, everyone knows that titles only indicate relative seniority within a company. Interviewers must actually interview candidates to determine what their role was, how experienced they are, and other factors.
It can be a warning flag, however, if a company is giving titles like “Principal Staff Software Architect” to someone who is clearly junior enough that they would require a lot of mentoring and guidance if they were hired. It’s common that candidates are resistant to downleveling their titles when changing jobs, so handing out enormously inflated titles is one way companies try to trap junior employees in their companies. At least until they realize that nobody cares about their inflated titles and they still have to pass the same tech interviews as everyone else.
As someone whose first job title was "Assistant Director of IT," and who did nothing but write really bad PHP for a couple hours every day, this tracks with my experience. It also made interviewing harder because if you get a resume from someone with one job they've had for two years, and that job is Assistant Director, you're probably - rightfully - trashing that resume. I eventually learned to just change the title but then explain on first contact that my actual title was different, it just didn't bear any relation to what I was actually doing.
The vast majority of titles in tech confer more prestige than deserved, because there's no downside to a company handing them out like candy. I don't look at it as a portability issue, the incentive isn't to be accurate to begin with. Inflated seniority is just a perk they can offer that doesn't cost them any money, so everyone offers it. Titles across the industry are meaningless unless you're calibrated to that company's levels.
This reminds of a story I encountered in finance where everyone in the department got a bump in title as their bonus. I asked one what was difference in their role: nothing. Since everyone got bumped, everyone's role stayed the same. This was during the financial crisis and was the bank's (well known) cheap ass way to get away without paying a monetary bonus.
I'm stuck inside a 5000 person IT company hiding inside a much larger consumer product company, and 3/5 of us are all 'principal' engineers by title. This includes a bevy of old timers who exist just to run a few ancient shell scripts and otherwise keep a chair warm. Although they are shrinking quickly, they still vastly outnumber us coming in from the software industry. There is no title above principal here; we are hired into principal and that's it until we invariably get bored or stressed out and leave.
We have other titles above principal, which I wont name here because you could figure out where I work, but suffice, those titles are gated and only promotable by multiple director consensus. It keeps their numbers very, very low. My department wont mint a new one, but only hire outsiders already at the title.
Vice Presidents at large financial institutions are a joke. Coming from any other industry you'd think it's some sort of executive position. Nope, just a random senior software engineer 8 levels down on the corporate ladder. To be fair the first 6 levels (all the way to the CEO) are all "Managing Directors".
i had a job where i was the first staff, but when they started promoting everyone to staff cause every senior wanted a promotion, they had to create new levels of staff to differentiate
I was under the impression that Staff just meant you have some sort of leadership role, as opposed to just being an individual contributor. Is that not the case?
Yes, this. Principal means something vastly different between Microsoft and Google (where at Microsoft it means “Staff”). I even got recruiting emails from some not-popular SV firms for “Principal software engineer” when I had 3 years of experience.
One company out there 'staff' is entry level. Whereas in all the companies I worked at 'staff' was a very prized title to have. Another company I worked at my title was basically just some random bits of roman numerals and something that sounded vaguely like a engineer. I usually just put sr software engineer/developer depending on the company and role.
Are there many folks who care more for a title than compensation? Granted, a higher title might help one win more compensation when negotiating one's next job, but fundamentally one must back that up. I mean, you could hire me as a principal engineer for $100,000 today and I could hope I can get hired as a distinguished engineer for $800,000 next year, but somehow I don't think anyone with that much money to spend is going to make that terrible of a mistake.
Right? Because if not, I need to have a discussion about titles!
I'm not aware of companies caring what your current or last job title is when they hire you, and for that reason I don't think most developers care what title they get when taking a new job. The titles are really only important internally, if companies have a culture of respecting certain titles, or when they have strict salary bands for each job title that are matched to some supposed industry standard. Salary bands are a blanket corporate policy that many companies use to enforce a very crude form of hiring discipline, and over time they can get really out of touch with reality (always on the low side, of course.) In the last couple of years I've spoken with several companies that limit the salary of "senior" developers to $160k or even less. Some of these are stodgy old companies like you would expect, but some are also midwestern companies that are switching to a "remote first" model but still have salary bands calibrated to their low-COL city of origin.
Managers deal with unrealistic salary bands via title inflation when they can, but sometimes their hands are tied. I joined a team that did have the freedom to use title inflation and ended up with a principal title in a team with more principal engineers than non-principal engineers.
I've seen this exactly. Someone at my former company was a Principal engineer but when they left to go to Netflix they were then just a Sr. Engineer. They definitely were not Principal engineer material so think it was all to appease the pay-band gods.
Exactly it's just a job description and name. In my last job our org rarely promoted anyone technical (only managers and above) so almost everyone was either Lead Software Engineer, or Senior Software Engineer. Other orgs promoted everyone to the max no matter what they did - I knew a group where the lead was a Director but coded, and all of his reports where Principals; yet they did simpler work than anyone in our org did.
I'm a principal engineer for the next 3.5 days, and then I retire.
The key element is that you are half technical and other half people. You could say the other half is political, but that's just what happens when you get a bunch of people together. The key is that larger companies are hard to steer. You can't have N engineers in N directions, and you need to point them in direction.
The way I look at it from a technical perspective is ensuring that the game being played is winnable. Is the project going to work? Or, is this a death march waiting to happen? Do people know what they need to do? Do they have the tools and knowledge? Are stake-holders bought into the picture? Is funding going to endure the march?
The title is entirely useless if you are not in a large organization. Turning the ship even 1 degree is a lot of talking and organizing... Meh...
I like to build, but I'm happy to never build a pyramid again.
Not in my experience: there are typically specific project and program managers. The job of the Staff/Principal Engineer is usually to perform some kind of technical leadership: guiding code reviews, mentoring, architectural or technology guidance (what framework should use use?), remember the lessons learned from previous projects, and also serve as a liaison between the technical and non-technical departments in a company.
And in most cases, that's in addition to writing code. One of my last job descriptions as a Staff Engineer had me writing code about 10% of the time :-(
Not in my experience. I think a key thing is that a principal engineer is technical glue. You run around talking people getting insight on what is happening on the front-line, and then you nudge things in directions such that the game wins.
Does this meaning providing tactical insight for the project? yes.
Does this mean questioning priorities and aligning priorities? yes.
Does this mean that making sure the department is sustainable on hiring objectives? yes.
You could say that the role is being a smart technical person that is responsible at the level of "almost stake holder". A key thing here is that a principal engineer should also have significant stock. At a big company, this should be in the seven figures.
When my partner and I first meet we were both senior engineers at larger SF tech companies. Three years later she is a principle engineer and I stayed a senior engineer. She and I agree that everything past a senior engineer is political. She is much better and handling the complex social dynamics of the management class. It's kinda a game of finding the least common denominator that works best by not pissing off people and making everyone maximally happy. That often means the decisions you make you know are not the most optimal, but the most politically optimal. Just our observations.
> That often means the decisions you make you know are not the most optimal, but the most politically optimal.
Not intended to quibble, but to me that smacks of the dreaded "mid-level management" tier.
As a lead or principle, I describe what I do as being a "fire-and-forget resource". I build everything myself and don't require supervision. I will deliver regardless and am also able to justify my decisions. People seem to be happy so far.
That process is almost completely independent from meat-space concerns, aside from the requisite UX design.
> As a lead or principle, I describe what I do as being a "fire-and-forget resource". I build everything myself and don't require supervision. I will deliver regardless and am also able to justify my decisions. People seem to be happy so far.
Terminology is subjective of course, but:
I would also expect the above from a "senior" developer.
I would expect a "lead" developer to additionally be involved in leading a team and coordinating work within that team. (either from a project, people or tech perspective, or all/both).
I would expect a "principle" developer to be working at a higher level coordinating work between multiple teams and making architectural decisions that cut across the whole org or a large subsection of it at a larger company.
The political part is so important, and such a departure from solving technical problems. I feel like nothing in my life has prepared me for it, or maybe I just ignored everything that would have.
I think there's a continuum of political savvy, though, where most developers have some level of it. For example, if one of your developers creates a new service using a technology that is new to the codebase, and half of the senior developers say, "Ugh! I'm not touching that. It's just <developer's name> showing off his big brain. I'm not wasting my time figuring out that unnecessary academic crap," you can understand how that was a failure even if a purely technical evaluation concluded that the learning curve was reasonable and the benefits outweighed the effort required. Before committing to the technology, it was necessary to introduce the idea in a way that got the senior devs to buy in, and if you can't accomplish that, you can't use the technology at all, because it's going to create morale and social problems as well a creating an isolated service that few people will work on.
That's a basic level of political savvy I think most people can relate to, so, if you can understand that much, you have a base to build on.
In my experience the issue experimented technical contributors have with politics is not savviness, it's managing frustration. Unless you enjoy playing politics for politics sake and value the grind of improving your position in the system, the mix of ineffective compromises and letting things rot because the blame will go the right way tends to wear you down in the long run.
Another way to look at it is you are expected to include business factors into your decision making. Sometimes the most optimal engineering solution is not the most optimal business solution. Politics can definitely be a factor, but being able explain clearly why doing something helps the business can be a big part of making the jump to more senior roles.
> She and I agree that everything past a senior engineer is political. She is much better and handling the complex social dynamics of the management class. It's kinda a game of finding the least common denominator that works best by not pissing off people and making everyone maximally happy. That often means the decisions you make you know are not the most optimal, but the most politically optimal.
A colleague of mine at previous company once described all this in two words "managing expectations" :)
It goes beyond managing expectations. What goals do you take? What goals do you ouah back against? How do you do this? How do you route around cranky groups that get nothing done?
> She and I agree that everything past a senior engineer is political
At the big tech company I work at, we're often told that even even senior is primarily a non-technical designation. Technical expertise and independence is expected of the level below senior, and in order to make the jump to senior you need to demonstrate leadership and other for skills - influencing others, project management, coordinating between teams, etc. Principal is a level above that that is kind of the same but more.
Life is a human communication game first, as the “best system” we’ve socially engineered is externalized support towards common goals. It’s not science or engineering; it’s sympatico.
The problems we’re solving at these jobs (I reserve work for its meaning in physical systems, jobs/career for you know), are ostensibly people problems. So the decisions I make are optimized for that. I don’t call it politically optimal, but optimal, because that’s it; that’s THE game of life.
It’s subtle language emphasis maybe, but I used to visualize my thoughts as a text stream and “rewrite” constructs I did not appreciate in the moment. Redefining ideas like “optimal” to be human first behavior. Ideas like “optimal technical solution” are boxed away for when I’m working.
It helped me understand managements drive, to have folks doing useful things, but also made me question how useful much of this is except as busy work.
For anyone who is a Principal Engineer at a FAANG, what do you do day to day?
I'm a Principal Engineer, not at a FAANG, and that mostly means i'm an expert at what I do and know the product inside and out, and I spend a good amount of time coding. I do also help others, answer questions, and deal with complex problems. I'd say I do 80% coding and 20% meetings / other things.
I interviewed somewhere else and they wanted me to do 50% coding and 50% meetings / other things. Was a bit surprised, since i'd personally rather code and keep my skills up.
My take is companies should have their top engineers spending a sigificant amount of time coding, or at least architecting, but I could imagine, and have read, that at FAANG sized companies it becomes more political? Also with so many employees I guess in theory the idea is to have Principals spend more time leveling up the rest of their workforce? In practice does that happen?
Staff/principal level here. I accelerate my team. Sometimes that involves writing code, sometimes that involves teaching/mentoring others, sometimes it means improving our tools and processes, sometimes it involves hammer out our architecture and security approach, and sometimes it involves figuring out what baroque process I need to go through in order to get legal’s approval to launch our new product. I make sure almost all of what I do is well documented and communicated to the rest of my team.
The three rough metrics I’ve heard for how staff/principals are evaluated are “creating clarity”, “impact”, and “leadership.” Those metrics are all very difficult to perform on if I were focused on my code related output as an individual, although there are people who make and achieve within that level in my company who do more straight up coding then I do. The important thing is good judgement on where to spend your time to have the most impact.
If you wanted me to put numbers on it, I’d say my time is probably 25% coding, 20% meetings, 20% working on infrastructure and tools, 20% documenting/communicating, and 15% mentoring/recruiting.
this is a great summary, and pretty much exactly reflects my role. My job is to help other engineers in our org be as productive as possible. That always means trying to include other people in what I'm doing from a mentor/career-development perspective, but otherwise follows your % splits pretty well.
The bits that people don't talk about frequently are things like "what do you actually do in the 20% of the time you are coding?" It's usually things like performance analyses and optimizations, solving misc tech debt that I have the flexibility to work on since my time isn't allocated to project teams/squads, architecture and PoC work for new capabilities we think we will need, and honestly sometimes its just picking up a couple super low level tasks anyone could do because keeping team members focused on other things is what's most important.
At least in my org the common theme is almost always "there's a hard problem over there, go help them fix it'.
Source: principal engineer for a couple years, senior for 6 or 7 years before that. Not at a FAANG, but in a ~350 person technology org at a company with nationwide offices and consumer product presence in the USA.
On the whole my responsibilities are a mix of things:
1. Technical strategy - primarily writing strategy docs and discussing with other tech PEs. Usually precursor to architecture.
2. Business Strategy - reviews with non tech staff and leadership (across the org) about what the business needs are, where we see the future going. Often takes the form of reviewing other peoples documents or contributing sections to those
4. Architecture - Creating architecture documents - lots of text and boxes and lines. Several rounds of reviews. Usually precursor to coding or reading other people's code.
5. Coding - takes the form of staring at various IDEs and scratching my head.
6. Reading other people's code - same as above. Also include code reviews.
7. Operations - On call stuff. Usually where all the architecture stuff falls apart :-)
8. Mentorship - structured 1:1s, feedback, etc
9. Prototyping and demos
I spend probably 90% of my time doing the items above. The mix among these items varies but I consider all of it my work. For the rest I sometimes get pulled into the items below that are not officially my responsibilities
- Conferences and public speaking - I could, but choose not to
- Project tracking and reporting
- Managing people's careers directly
- Funding decisions
My work is rarely political depending on how you define politics. To me politics is about "who gets the cool stuff" so mostly funding decisions. I do get pulled in occasionally to sort out "who should build this" discussions but they are usually good faith discussions trying to align expertise and charters before funding decisions are made. Biz and tech strategy does involve consensus building but I suspect the Real Politics™ happen behind the scenes at higher levels.
I am happy to be open here if it helps others. I am not with a FAANG, I am employed by Red Hat. My title is Senior Principal Software Engineer. At Red Hat it goes Software Engineer -> Senior Software Engineer -> Principal Software Engineer -> Senior Principal Software Engineer -> Distinguished Engineer.
My main duties are that I lead a team of 7 engineers and we all work on open source security projects.
My day is a mix of half coding / half meetings. I am UK based, so my mornings are nice and free (while the US sleeps) and then around 2pm I have a large chunk of meetings. The meetings are mostly with my team, senior management, and open source community meetings.
For me being a Principal is a much more than just coding prowess. You also need good 'soft skills'. You need to mentor engineers and think about their growth. Make sure they are challenged enough to grow, but not so much that they end up stressed and out of kilt. You need to be able to communicate with not just other software engineers, but also product managers, directly with customers and many other verticals within a business.
I'm a staff/principal at a FAANG. My experience agrees with the other answers here that "it depends"—specifically, on what the larger org or team needs from me at the moment. There is a chunk of consistent work, though, which is somewhat of a mix between an engineering manager and an IC.
Like engineering managers, I am responsible for planning out a team's long term goals and reporting on them to senior management. Also like engineering managers I'm responsible for hiring and evaluating technical talent, particularly the senior software engineers in our org plus people who are under consideration for promotion or hiring into my level.
Unlike engineering managers, it's important that I do "hands on" work. This includes my own tech designs and coding, but much more reviewing the designs and code of others. I see my job as delivering technical artifacts through others. What's different between the principal/staff role and the senior eng/tech lead role is the levels of indirection. For a senior eng, you are generally owning the output of a team of people (roughly 3-7 people, though it varies).
At the staff/principal level you work at the level of a team of teams, so your job is really to develop and mentor the tech leads of those teams. Occasionally you might be called in as a tie-breaker or to assist on some cross-team issue, but ideally that doesn't happen too often because the tech leads know their stuff (and they'd better because there is no way you can know the details of multiple team's worth of systems).
I've been a "Principal Engineer" at a large software company and I feel like I embodied each of those archetypes at various points. At various points I was neck deep in critical code, doing the dog and pony show at the executive level, coordinating with other engineering teams and several product managers, and generally doing all of things required to keep pushing something forward.
My relationship with my manager was much more of a peer partnership than manager/IC. I let my manager know what I was up to, progress on things, and any challenges that needed help. The latter bucket was usually empty, but occasionally some cross-org priorities need to be clarified and sorted out.
As others have noted, it really varies between companies, but the main difference between Senior/Staff and Principal is that the latter can be a much more "people" oriented role. You still own and carry the technical vision, but you increasingly interact with non-technical people to enable it and to make it happen.
> My relationship with my manager was much more of a peer partnership than manager/IC.
To all the managers out there please make note of the above. Do yourself a favour and please give senior engineers enough autonomy and freedom.
At my previous place I managed a senior engineer and made it amply clear to him that we are peers. Between us my job was to handle all the bureaucracy (including scheduling meetings, finding meeting rooms etc.,) and his was to be the team's tech lead.
I am currently a principal engineer and have exactly the work life you described. Maybe in a bigger company the Principal is split from those archetypes but in my smallish team (within a large global org) I am the Principal because I do all of those things.
Principal Software Engineers are essentially the Engineer Owner of a solution or closely related set of solutions.
They're expected to know the ins and outs of the solution both at a business level ('Hey, Principal, how much would it cost and how long would it take to do 'x'?' -- Some Sales Person), and have responsibility for the solution's engineering ('Two months? Great! See you at the February demo for the users group!' -- Some Sales Person), and be able to solve the more difficult engineering issues that crop up ('The app you promised to integrate with by February only uses SOAP and consists of around 14,000 on-prem installs...I graduated after the year 2000 so I'm not sure how SOAP works, can you walk me through this 'wizdal' thing?' -- Some Senior Engineer that you asked to look into the new project).
I feel like the summary of the whole article could be "important and/or impactful stuff". Saved you a click and a "you have 1 Medium article left" banner.
The definition bullets will probably be highly dependent on the company and while companies will likely copy those, they are likely not even transferable within a company, let alone across different companies.
For example, within company A, Mike is a manager that is a perfectionist leading a Java EE mid-sized application. Mike is hard on himself and is hard on his people. His people are probably underpaid, and that's how he likes it. Getting to a senior level is difficult. Getting above is political.
Within company A, Janet is a manager leading a relatively recent PaaS offering. She likes nimble, agile teams. She rewards quick thinking, wants her team to be satisfied, and gives her team yearly stock options because she doesn't want anyone to leave. Getting to a senior level is fairly manage-able after 1 to 2 years, provided one is viewed as a senior. Getting above is doable, provided one has peer support.
Now, company B is a consulting company that wants to offer "senior" engineers for $1000+/hour. They never hire anyone with the title "junior" (not even fresh grads) and promote practically everyone after 8-16 months to a senior title. Principal level is then another 6-8 months away, but they have very few of those due to insane attrition rates by that point.
Readit News
When I see titles, it just makes unhelpful thoughts enter my head, like: are all these people “at my level” really contributing as much as me? Sometimes I even thought the reverse, like: how can this seemingly-junior person still be stuck at that level, when he is clearly doing all this great stuff we depend on every day? Of course the especially soul-crushing case is when you encounter people that clearly suck at what they do, and they’re 1-2 levels above you; and worse, I have occasionally seen those people promoted further!
It is also hard not to look at titles on places like LinkedIn. I know I shouldn’t care, since titles mean different things at every company, and some especially-impressive-sounding titles can range from “meh” to “god-level” depending on where it is. And yet, it gets in my head sometimes, making me wonder every few years if I am at the level I should be.
When the title “matters” at a company, it also makes me consider it a factor in annual reviews. If I get a raise, bonus, etc. but see my damned title stagnate year over year, suddenly I care about this and take it as a complete lack of recognition by the company (that literally would not happen if they simply did not tell me what my title is!).
I've been very disappointed by comparing people's titles with their actual technical ability -- somehow it never seems to be the case that the ability outstrips the title.
Really? You've never worked with a junior who's punching far above their weight? I've had several on my team and work as hard as I can to get them promoted asap.
TIL: This is a really interesting perspective; Thank You for this! I will use it from now to calm myself down. I, always either got mortified by the extreme skill of my juniors or by the incompetence of seniors — not sure if it’s the case with me or is it a general feeling.
The Kendo way at-least makes me ignore the titles :)
Beating that higher ranked player promotes you to their rank (and demoted them). It's like a mini boss that the game doesn't tell you about.
That's one benefit but I think that the main benefit is that when you've a high level, you'll know that this guy in front of you is a beginner and you'll go soft on him, which is quite important: if he doesn't know how to fall properly the beginner could be injured if the "high level" guy doesn't notice in time..
People get promoted until they reach their level of incompetence :-)
> and seeing your influence grow as you are trusted with more things.
That's the ideal scenario, that you earn the esteem and trust of your peers because the work you do speaks for itself.
The flipside with this is, this process takes time. It really takes years. Sometimes there will not be that time. You are a new hire brought in to do a high-impact thing; or a high-impact project crosses across the entire organization where suddenly all participants are relative stranger; or the team you worked in was of very low external visibility but a mentor recognized your potential and pulled you out to help recalibrate a different but malfunctioning team, etc...
Then titles are important. It is very unfortunate that we are very cynical of titles, because, in well-run organizations, they are meaningful, and in fact, should be meaningful. Imagine in the military if every officer had to prove themselves over and over again. It's unworkable.
At some point, larger organizations will need to grant leverage to a technical individual. A title helps with providing that.
I've also seen the opposite, perfectly fine engineers get worse after a promotion due to the weight of the title, without any other change to their work / schedule.
It's really dehumanizing. I think I'd rather not know people's titles, just what team they're on, and their role.
Ended up doing something similar in my original tech job as well. I'm not sure I've ever really used my official HR title and would probably have to look it up to be sure I'm remembering it correctly.
Also, lots of folk deliberately opt out of level visibility, too.
Does having limited ambition make you a bad dev/engineer, if you keep learning new things and contributing quality code at your current level of responsibility?
Sure, you might have some specialized knowledge or understand system X better than anybody else, but there's diminishing returns on that, hence why you won't get big raises forever.
As you move up the chain, it eventually stops being about your direct technical contributions and about your ability to multiply the value of everybody under you in your org.
If you're happy with where you are, and happy with your salary and status, then it's fine to stay there! Certainly, as you say, continue to learn new things, make quality contributions, and get your work done.
Many companies will have what they call "terminal levels" for individual contributors (most probably don't really advertise this unless you specifically talk about it with your manager). The idea is that you can work at a level where you can get your day-to-day work done with minimal guidance, even if you need guidance on the bigger picture stuff (like what you should be working on, and why). You should certainly talk to your manager about this, if you feel comfortable. And if you don't, and/or they keep pushing you to climb the ladder further, then yeah, you should probably find a new gig.
One caveat: ageism is still an unfortunate thing in our industry, and as you get into your 40s and beyond, if you're still "only" a "senior software engineer", you may have trouble getting new jobs.
Companies don't want to get stuck with people who are perpetually "junior" and need a lot of hand-holding to get their jobs done. That's of course ok for a while someone is learning and growing, but if they aren't growing out of that, they're a liability and time sink. But once you're past that point, you should be ok. The only problem is if you end up at a weird place where no one wants to progress up through staff/principal/architect/fellow, in which case I wouldn't be surprised if everyone starts getting pressured to up their ambition. But that sort of scenario seems somewhat unlikely?
[0] Well, unless they are in your immediate family and your lack of ambition is putting their livelihood at risk in ways they can't mitigate. But I'm assuming that's not the case here ;)
Deleted Comment
The fact that someone else is doing more or less with a higher title shouldn't influence your life at all. Jealousy shouldn't tell you when you should look for a job. If you are unhappy leave if you are happy stay. If your happiness is determined by what a random person is paid you will never be happy.
There might be some honesty / truth behind what is described but in my 2 decades of IT work, mostly ass kissers have taken home the big bucks .
I think this is a logical contradiction. If there exists people that you are in a position to judge their competence you deserve to be in their position or higher, therefore it cannot be that they are 1-2 levels higher than you.
Logic is a great tool by the way, but unless you are applying it formally you might be better off not trying to invoke it casually.
Source: have been that person.
On the hiring side, everyone knows that titles only indicate relative seniority within a company. Interviewers must actually interview candidates to determine what their role was, how experienced they are, and other factors.
It can be a warning flag, however, if a company is giving titles like “Principal Staff Software Architect” to someone who is clearly junior enough that they would require a lot of mentoring and guidance if they were hired. It’s common that candidates are resistant to downleveling their titles when changing jobs, so handing out enormously inflated titles is one way companies try to trap junior employees in their companies. At least until they realize that nobody cares about their inflated titles and they still have to pass the same tech interviews as everyone else.
We have other titles above principal, which I wont name here because you could figure out where I work, but suffice, those titles are gated and only promotable by multiple director consensus. It keeps their numbers very, very low. My department wont mint a new one, but only hire outsiders already at the title.
Yikes, that sucks.
Deleted Comment
2 years ago I was hired as Staff with pretty high bar to clear.
This year I know a team where all the seniors complain they’re not Staff, and now half the team are Staff engs.
Right? Because if not, I need to have a discussion about titles!
Managers deal with unrealistic salary bands via title inflation when they can, but sometimes their hands are tied. I joined a team that did have the freedom to use title inflation and ended up with a principal title in a team with more principal engineers than non-principal engineers.
Dead Comment
The key element is that you are half technical and other half people. You could say the other half is political, but that's just what happens when you get a bunch of people together. The key is that larger companies are hard to steer. You can't have N engineers in N directions, and you need to point them in direction.
The way I look at it from a technical perspective is ensuring that the game being played is winnable. Is the project going to work? Or, is this a death march waiting to happen? Do people know what they need to do? Do they have the tools and knowledge? Are stake-holders bought into the picture? Is funding going to endure the march?
The title is entirely useless if you are not in a large organization. Turning the ship even 1 degree is a lot of talking and organizing... Meh...
I like to build, but I'm happy to never build a pyramid again.
Deleted Comment
And in most cases, that's in addition to writing code. One of my last job descriptions as a Staff Engineer had me writing code about 10% of the time :-(
Does this meaning providing tactical insight for the project? yes.
Does this mean questioning priorities and aligning priorities? yes.
Does this mean that making sure the department is sustainable on hiring objectives? yes.
You could say that the role is being a smart technical person that is responsible at the level of "almost stake holder". A key thing here is that a principal engineer should also have significant stock. At a big company, this should be in the seven figures.
Deleted Comment
Not intended to quibble, but to me that smacks of the dreaded "mid-level management" tier.
As a lead or principle, I describe what I do as being a "fire-and-forget resource". I build everything myself and don't require supervision. I will deliver regardless and am also able to justify my decisions. People seem to be happy so far.
That process is almost completely independent from meat-space concerns, aside from the requisite UX design.
Terminology is subjective of course, but:
I would also expect the above from a "senior" developer.
I would expect a "lead" developer to additionally be involved in leading a team and coordinating work within that team. (either from a project, people or tech perspective, or all/both).
I would expect a "principle" developer to be working at a higher level coordinating work between multiple teams and making architectural decisions that cut across the whole org or a large subsection of it at a larger company.
Reminds me of the classic: https://www.ribbonfarm.com/the-gervais-principle/
I think there's a continuum of political savvy, though, where most developers have some level of it. For example, if one of your developers creates a new service using a technology that is new to the codebase, and half of the senior developers say, "Ugh! I'm not touching that. It's just <developer's name> showing off his big brain. I'm not wasting my time figuring out that unnecessary academic crap," you can understand how that was a failure even if a purely technical evaluation concluded that the learning curve was reasonable and the benefits outweighed the effort required. Before committing to the technology, it was necessary to introduce the idea in a way that got the senior devs to buy in, and if you can't accomplish that, you can't use the technology at all, because it's going to create morale and social problems as well a creating an isolated service that few people will work on.
That's a basic level of political savvy I think most people can relate to, so, if you can understand that much, you have a base to build on.
A colleague of mine at previous company once described all this in two words "managing expectations" :)
At the big tech company I work at, we're often told that even even senior is primarily a non-technical designation. Technical expertise and independence is expected of the level below senior, and in order to make the jump to senior you need to demonstrate leadership and other for skills - influencing others, project management, coordinating between teams, etc. Principal is a level above that that is kind of the same but more.
All this to say: every company is different.
The problems we’re solving at these jobs (I reserve work for its meaning in physical systems, jobs/career for you know), are ostensibly people problems. So the decisions I make are optimized for that. I don’t call it politically optimal, but optimal, because that’s it; that’s THE game of life.
It’s subtle language emphasis maybe, but I used to visualize my thoughts as a text stream and “rewrite” constructs I did not appreciate in the moment. Redefining ideas like “optimal” to be human first behavior. Ideas like “optimal technical solution” are boxed away for when I’m working.
It helped me understand managements drive, to have folks doing useful things, but also made me question how useful much of this is except as busy work.
I'm a Principal Engineer, not at a FAANG, and that mostly means i'm an expert at what I do and know the product inside and out, and I spend a good amount of time coding. I do also help others, answer questions, and deal with complex problems. I'd say I do 80% coding and 20% meetings / other things.
I interviewed somewhere else and they wanted me to do 50% coding and 50% meetings / other things. Was a bit surprised, since i'd personally rather code and keep my skills up.
My take is companies should have their top engineers spending a sigificant amount of time coding, or at least architecting, but I could imagine, and have read, that at FAANG sized companies it becomes more political? Also with so many employees I guess in theory the idea is to have Principals spend more time leveling up the rest of their workforce? In practice does that happen?
The three rough metrics I’ve heard for how staff/principals are evaluated are “creating clarity”, “impact”, and “leadership.” Those metrics are all very difficult to perform on if I were focused on my code related output as an individual, although there are people who make and achieve within that level in my company who do more straight up coding then I do. The important thing is good judgement on where to spend your time to have the most impact.
If you wanted me to put numbers on it, I’d say my time is probably 25% coding, 20% meetings, 20% working on infrastructure and tools, 20% documenting/communicating, and 15% mentoring/recruiting.
The bits that people don't talk about frequently are things like "what do you actually do in the 20% of the time you are coding?" It's usually things like performance analyses and optimizations, solving misc tech debt that I have the flexibility to work on since my time isn't allocated to project teams/squads, architecture and PoC work for new capabilities we think we will need, and honestly sometimes its just picking up a couple super low level tasks anyone could do because keeping team members focused on other things is what's most important.
At least in my org the common theme is almost always "there's a hard problem over there, go help them fix it'.
Source: principal engineer for a couple years, senior for 6 or 7 years before that. Not at a FAANG, but in a ~350 person technology org at a company with nationwide offices and consumer product presence in the USA.
On the whole my responsibilities are a mix of things:
1. Technical strategy - primarily writing strategy docs and discussing with other tech PEs. Usually precursor to architecture.
2. Business Strategy - reviews with non tech staff and leadership (across the org) about what the business needs are, where we see the future going. Often takes the form of reviewing other peoples documents or contributing sections to those
3. Product design reviews - reviewing CX/UX documentation
4. Architecture - Creating architecture documents - lots of text and boxes and lines. Several rounds of reviews. Usually precursor to coding or reading other people's code.
5. Coding - takes the form of staring at various IDEs and scratching my head.
6. Reading other people's code - same as above. Also include code reviews.
7. Operations - On call stuff. Usually where all the architecture stuff falls apart :-)
8. Mentorship - structured 1:1s, feedback, etc
9. Prototyping and demos
I spend probably 90% of my time doing the items above. The mix among these items varies but I consider all of it my work. For the rest I sometimes get pulled into the items below that are not officially my responsibilities
- Conferences and public speaking - I could, but choose not to
- Project tracking and reporting
- Managing people's careers directly
- Funding decisions
My work is rarely political depending on how you define politics. To me politics is about "who gets the cool stuff" so mostly funding decisions. I do get pulled in occasionally to sort out "who should build this" discussions but they are usually good faith discussions trying to align expertise and charters before funding decisions are made. Biz and tech strategy does involve consensus building but I suspect the Real Politics™ happen behind the scenes at higher levels.
My main duties are that I lead a team of 7 engineers and we all work on open source security projects.
My day is a mix of half coding / half meetings. I am UK based, so my mornings are nice and free (while the US sleeps) and then around 2pm I have a large chunk of meetings. The meetings are mostly with my team, senior management, and open source community meetings.
For me being a Principal is a much more than just coding prowess. You also need good 'soft skills'. You need to mentor engineers and think about their growth. Make sure they are challenged enough to grow, but not so much that they end up stressed and out of kilt. You need to be able to communicate with not just other software engineers, but also product managers, directly with customers and many other verticals within a business.
Like engineering managers, I am responsible for planning out a team's long term goals and reporting on them to senior management. Also like engineering managers I'm responsible for hiring and evaluating technical talent, particularly the senior software engineers in our org plus people who are under consideration for promotion or hiring into my level.
Unlike engineering managers, it's important that I do "hands on" work. This includes my own tech designs and coding, but much more reviewing the designs and code of others. I see my job as delivering technical artifacts through others. What's different between the principal/staff role and the senior eng/tech lead role is the levels of indirection. For a senior eng, you are generally owning the output of a team of people (roughly 3-7 people, though it varies).
At the staff/principal level you work at the level of a team of teams, so your job is really to develop and mentor the tech leads of those teams. Occasionally you might be called in as a tie-breaker or to assist on some cross-team issue, but ideally that doesn't happen too often because the tech leads know their stuff (and they'd better because there is no way you can know the details of multiple team's worth of systems).
Deleted Comment
My relationship with my manager was much more of a peer partnership than manager/IC. I let my manager know what I was up to, progress on things, and any challenges that needed help. The latter bucket was usually empty, but occasionally some cross-org priorities need to be clarified and sorted out.
As others have noted, it really varies between companies, but the main difference between Senior/Staff and Principal is that the latter can be a much more "people" oriented role. You still own and carry the technical vision, but you increasingly interact with non-technical people to enable it and to make it happen.
To all the managers out there please make note of the above. Do yourself a favour and please give senior engineers enough autonomy and freedom.
At my previous place I managed a senior engineer and made it amply clear to him that we are peers. Between us my job was to handle all the bureaucracy (including scheduling meetings, finding meeting rooms etc.,) and his was to be the team's tech lead.
Principal Software Engineers are essentially the Engineer Owner of a solution or closely related set of solutions.
They're expected to know the ins and outs of the solution both at a business level ('Hey, Principal, how much would it cost and how long would it take to do 'x'?' -- Some Sales Person), and have responsibility for the solution's engineering ('Two months? Great! See you at the February demo for the users group!' -- Some Sales Person), and be able to solve the more difficult engineering issues that crop up ('The app you promised to integrate with by February only uses SOAP and consists of around 14,000 on-prem installs...I graduated after the year 2000 so I'm not sure how SOAP works, can you walk me through this 'wizdal' thing?' -- Some Senior Engineer that you asked to look into the new project).
The definition bullets will probably be highly dependent on the company and while companies will likely copy those, they are likely not even transferable within a company, let alone across different companies.
For example, within company A, Mike is a manager that is a perfectionist leading a Java EE mid-sized application. Mike is hard on himself and is hard on his people. His people are probably underpaid, and that's how he likes it. Getting to a senior level is difficult. Getting above is political.
Within company A, Janet is a manager leading a relatively recent PaaS offering. She likes nimble, agile teams. She rewards quick thinking, wants her team to be satisfied, and gives her team yearly stock options because she doesn't want anyone to leave. Getting to a senior level is fairly manage-able after 1 to 2 years, provided one is viewed as a senior. Getting above is doable, provided one has peer support.
Now, company B is a consulting company that wants to offer "senior" engineers for $1000+/hour. They never hire anyone with the title "junior" (not even fresh grads) and promote practically everyone after 8-16 months to a senior title. Principal level is then another 6-8 months away, but they have very few of those due to insane attrition rates by that point.