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.
OK, perhaps I should have said "rarely." I've had direct reports who were like that and happily gave them the max rating on Performance Reviews and recommended promotions.
That said, it definitely gets rarer the higher up you go.
> 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 eventually stops being about your direct technical contributions and about your ability to multiply the value of everybody under you in your org.
I thought that was the whole point of the IC track: putting a technical person into a role where they can be a multiplier without burdening them with management responsibilities.
Every staff/principle/architect IC I've ever worked with has had that kind of positive effect on the teams around them. Their schedules were indistinguishable from most managers, except they met mostly one on one and they could get a senior engineer's worth of work (impact wise) done in between the meetings instead of paying the management overhead.
Parent was explicitly stating they didn't want to climb the career ladder. i.e. They wanted to remain at a Sr Engineer level perpetually, but also not have their salary stagnate.
I don't disagree that principle engineers can and should have a big multiplying effect, but I also wouldn't consider them strictly IC's either, even if they don't have people managing duties.
> They wanted to remain at a Sr Engineer level perpetually, but also not have their salary stagnate.
Pretty much that, except that I wouldn't use the word "stagnate". What I said was "lag behind the cost of living", which might not have been the most concise way of putting it, but I hoped it would get my point across.
Essentially, the conundrum I've faced too often is that if you're not climbing the ladder, the purchasing power of your salary will start falling, even if your salary rises, because the raises you get reflect the lack of regard the company has for people who aren't climbing the ladder.
Stagnation, for me, would be to stay at the more-or-less same purchasing power. And I would be fine with that.
Agree with this pretty strongly. However there is something I've observed: org multipliers can exist without managing people. HR generally doesnt know what to do with them. It's almost unreasonable to call them ICs, but there you have it.
> 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.
This will forever strike me as a post hoc rationalization for justifying salary increases when the truth is that the salary increase is just a natural outcome of being granted institutional authority. This is the most visible with the CEOs that fail being given absurd bonuses and then justifying that as necessary to attract top talent. The people that are value divisors are still given huge remunerations precisely because of the position, not because of their impact.
To the exclusionary aspect of the idea, unless your employees are being micromanaged then a large part of their work is discretionary. If they are not being kept in the dark and are not working alone then a large part of their work is also collaborative. Putting these things together, your good employees will field requests from other teams, prioritize them on an ad hoc basis, connect dots and report opportunities amongst themselves: solving problems that influence many more customers than the direct ones they work with. Promoting them will move them out of the circle where they learn about these situations on the ground. Instead of multiplying your capabilities, you may end up dividing your people by removing a key communicator from the employee social network when you promote them. Potentially, everyone recognizes there is a problem, but the problem solver role is a vacuum. Worse if nobody is able to recognize there is a problem now that the person who was able to recognize it is faced with different challenges.
Institutional authority is not isomorphic to collaborative potential (or any general notion of work multiplication). Personal authority, respect, cooperation, skill, insight, all kinds of things can make a person's individual contributions many times greater. All these things are independent of institutional authority and the actual use of institutional authority will almost always come off as a cheap form of insecurity: "Do it because I'm the boss."
The truth is that it is easy to create a hierarchy and challenging to measure impact.
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.
I don't know. I really don't, and that's scary. I've been programming since I was 7 years old, on a ZX Spectrum 48k, and now that I'm 40+, it's been a long, long time. And in all that time, I've never really wanted to be the guy who has to be responsible for a bunch of other people. All I've ever enjoyed about software development was being elbow-deep in code, and learning new things. And now that I'm older, I'm starting to get scared that the world doesn't appreciate people like that.
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.
I have found the same thing over the years. A lot of times the folks who 'just don't do anything' and 'just don't understand' were doing plenty and understood plenty, I just was too immature to get that at the time.
Not 100% always, mind you, but way more often than not.
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.
At one of my jobs, all the developers were given the title "Member of Technical Staff" because our boss had worked at a particle accelerator (he had a PhD in physics) and that's what the scientists running experiments had on their badges. He did it for morale, and it probably did make us feel a bit fancier while we were writing Grails and GWT code.
I've always thought of "Member of Technical Staff" as a Bell Labs thing.
I almost did it at my last startup, to signal the egalitarian, cooperative engineering culture that I intended. One of the concerns was that it could hurt people's career mobility out (and willingness to join, since the startup was unlikely to be the engineer's home for the next few decades until retirement).
I think it works easily when your organization is known as one of the places to go, everyone knows that they do titles that way, and that anyone there is worth considering as a hire. (But not when recruiters filter their resume keyword searches for senior, staff, or principal.)
I don't know why Google didn't do it, way back when, since they did a few other culture things. I suppose that might've set a different tone for our industry today. (Though what seemed at the time to be low-loyalty culture coming out of California was already in force when Google started, most conspicuously in what I called "IPO-hopping", and maybe Google just had to work within that, at the time.)
Well, every dev is listed as "Software Engineer" unless they change it specifically. Maybe you're forced to change it if you're a manager, but I'm unsure of that. So you never exactly know the level of the person you're talking to unless you work with them a lot or go out of your way to look it up.
I think it's sort of a labs (whether national labs or more broadly) thing. I have a good friend who works for one of the national labs subcontractors and they use the technical staff terminology.
I think this is pretty common at early stage YC companies. At least the one I started at did this until they needed to give us fancy titles to impress investors.
I had the inverse experience: I worked for a startup that gave literally everyone in the engineering department the same title of “Senior Software Engineer” in the HR system because they had one boilerplate offer letter used for everyone.
I was a manager-of-managers, but officially I was a “senior software engineer”. Burned me badly on a couple reference checks, until I specifically started explaining the situation during interviews.
Yup. And I always am weary of any manager at a startup. They think just because they were a manager at a startup, it means they can be a manager at a much larger company. How many people did you manage? (some of them managed 1 person) What did you actually manage? (can't explain other than order people around) Don't assume the title means they know how to actually do the job at your company. Titles tend to be severely inflated at small startups.
I had a job as a VP a few years back… at a six-person startup. I cringe when I list that job on my resume - do I lie and list the title accurately (I was a programmer with a massively inflated title) or report what my actual given title was and risk being seen as misleading?
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.
There are only a few titles that mean anything, and normally it isn't what you think.
Legal at a bank only a vice president or higher can make some loan decisions. Thus if you go to a large chain bank to get a mortgage you will talk to a vice president. Their title must be vice president, but they doesn't make a lot of money, and don't have much power other than the ability to give you a mortgage.
Last time I posted the above someone chimed in "yeah, even though all I do is write code all day I'm a vice president because what my code does can only be done by a vice president"
You also see a lot of salesmen who are vice presidents - again they don't have a lot of power in the company, but the places they sell to want to talk to a vice president so sales hands out those titles.
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?
The only job in the tech industry that's not some sort of leadership role is Intern. Everyone leads and mentors. Senior Engineers at the level of a single team, with perhaps some cross-team impact. Staff Engineers at the level of an org with several teams.
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.
I "normalize" my previous titles to whatever pattern/scheme my current company uses. It more clearly demonstrates the career progression on your resume and you typically only get a reference check at your previous employer so putting an "inaccurate" title for jobs older than that is unlikely to matter. Obviously don't inflate the titles.
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.
I think it depends on the complexity of what you're building. If it's something very novel or something that requires a lot of domain or technical expertise, then you might need a principal engineer to be the point person to figure out how to even build it, or build it right. Some problems are best solved by a single person with the right skills.
Some career ladders allow for this, others are more rigid about the size of team you need to be directly leading .
I think this is the appropriate answer. In my experience as Staff engineer, the tasks I was best suited to were the nebulously defined "the customer needs X" where X cross cut a lot of domains and required input from a variety of people that would be affected by that feature X. This usually meant that I'd have to get them all together at some point and find a way to satisfy all their contradictory needs before even coming up with what the real task definition of X was.
That's generally more than you'd expect from a typical Senior Engineer.
This gets tough. My company also loosely views Senior as the pinnacle of technical achievement with Lead and Principal engineers essentially being much higher level with no direct reports, but still doing policy, stakeholder, and political activities. Recently, some have pointed out the flaws in such a system as it leaves out the potential for promoting and giving a pay raise to senior staff that have continued making themselves far more valuable, but don't want to be capped or go into politics. There needs to be a path for someone who is just beast on the technical side and can be brought out to solve any problem. If that person is an order of magnitude more knowledgeable than your seniors, then they deserve to be distinguished as such. Our competitors that have figured this out have titles to better reflect this reality.
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 admit #9 is fun but I try not to do too much #9, because there's a huge risk to doing too much of that: losing touch with what's important to the bottom line, and indirectly influencing all the other ICs that prototypes get you promoted. That's just not true in my company. My prototypes are usually for exploring something important to the company or validating a tech hypothesis of some sort. I try to spend more time writing production code where possible.
It does feel like some folks ignore the business side of things but I think I enjoy being a part of the larger picture. It's definitely not for everyone. I know several people who are personally happy and have had WILDLY successful careers being hands-on tech specialists and ignoring the business side. It's great that it works for them.
Not everyone can do the same thing over and over again their whole life. Soon, I'm going to scream if I have to build another website or app... thankfully I'm making a massive career shift into Aerospace.
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.
My definition is "Finds and creates the most valuable work for other engineers to do."
I really started to see the value once I moved from Principal to Manager. All of a sudden I was busy with boring manager stuff and needed an IC who could get deep into the details of our initiatives and make sure everyone's efforts were lining up. You don't need the title of Principal to do this role, of course, but ICs who see the big picture and understand what's important for the business are invaluable.
The other points in the article are on the money as well, especially around modeling and amplifying a good dev culture for the organization.
I like this definition, even if it overlaps with the PM role. In effective teams I’ve been part of, the PM and engineering leads help each other winnow down the work, with the PM making the final call for priority (except in circumstances where that doesn’t make sense).
I'd definitely recommend https://staffeng.com/ for anyone who's making the transition from senior to staff+. I found it invaluable when I made that transition.
Also, I want to add a more positive anecdote to accompany some of the more negative ideas of principal engineers. I’m a senior software engineer (L5 in FAANG terms) and I’ve worked with a handful of principal engineers who have all been incredible colleagues.
All the principal engineers I have worked with have been humble and ego-less engineers. There’s this notion that they just write docs but they’re invaluable code/spec/design reviewers, they have taken on major refactors to tackle tech debt that just
lingered for years, and have generally unblocked me on so many occasions. The strongest principal engineers have never taken credit for massive projects they have orchestrated but “everyone knows” they’re valuable.
It takes a lot of skill, and I’ve found they switch between the “archetypes” effortlessly. Beyond that, they’ve helped me grow in my career and find impactful projects that look good on perf reviews. In my mind, the good ones are definitely worth their cost.
Same things as senior but more. Source: I've been one.
Senior and principal prefixes are there to provide respect in orgs that rely on titles for respect (possibly a sign of toxicity), or a way to explain to HR why someone's salary is higher.
A bit of a problem tho for most orgs. If you can only pay more money by promoting people, the job market is suddenly so hot people will leave if you don’t get them more money, but it is a bit silly to just promote every one, and there is a useful distinction to be had between people whose work is mostly heads down coding vs people whose work is also mentoring and communicating technical views to larger numbers of people. The words around promotions usually seem to be about expanding influence and affecting larger numbers of coworkers. That is useful, and fun if you like it, but the purely awesome coders might also need big raises when job market spikes.
If you're a senior engineer and you're sort of wondering "what's beyond senior?", you might be interested in the book "Staff Engineer: Leadership beyond the management track". I found it enlightening, and it's nice seeing companies embracing the whole "Staff plus"-track.
This is an awesome book. It's not just based on one person's opinion or experience: it talks about different archetypes of staff+ roles (https://staffeng.com/guides/staff-archetypes).
> To achieve the “org-level” impact, principal engineers need to be very selective on what to work on and use as much leverage as they can. For example, to set them up for success and maximize their influence, a principal engineer usually directly reports to a “director-level” engineering leader.
Whoa, that is a cynical take and smells a little of sour grapes.
I 100% agree that the PE title is abused both out of nepotism, and out of site-wide populism, but the intent is relatively pure, at least at large companies where the title actually matters:
There are some engineers that are so good at solving problems that they can be dropped into any crisis situation and help fix it, like a special forces soldier. After 30+ years in engineering I've seen them in action, and most of the time they deserve the title. They are just that good. Those are your PEs.
However, you need a large enough sample population to produce PEs because it is based on relative performance. It is harder to identify one in a group of 10, but in a division of 1000 it becomes abundantly clear.
Typically how you become a PE is by waiting in line and keeping at what you do, because usually there are only so many PE's promoted per year to help mitigate abuse of the system (there will be some in bigger organizations). This idea of being selective is ... misguided. You don't really have a choice.
Now combine those last two paragraphs and I can see how it appears there is room for gaming the system by only picking cherry products. However, it is unlikely you would be able to say to a VP or GM, "Hey, I want to work on THAT project, not this crap one you stuck me on, because I want more visibility for promotion!" Maybe that'll work, but good luck?
>However, it is unlikely you would be able to say to a VP or GM, "Hey, I want to work on THAT project, not this crap one you stuck me on, because I want more visibility for promotion!"
I think this is very dependent on the incentives that are set up for the GM. If they're being judged on how they're developing their org, and number of promotions is looked at, now they may agree with you that the non-crap thing is the best thing to work on.
There's also the more implicit side of it, where if you're just generally good at what you do (or more cynically, if you're on the manager's good side for whatever reason), they'll be more inclined to let you work on what you want regardless of the motivations.
This is what I was referring to with site-level bias. I've seen certain sites brag about their # of principal engineers. Ultimately sites are handed jobs based on their past performance, but this abuse of the system remains. I'm being a little naive, but that's just me, and these abuses aren't that frequent.
> There are some engineers that are so good at solving problems that they can be dropped into any crisis situation and help fix it... Those are your PEs.
I agree that "the solver" is one flavor of the role, but I think there are a few other valid ones too. Many of the staff+ engineers I've interacted with fall in the "tech lead" or "architect" category.
In my experience the more senior you get the more like an organizational therapist you are expected to become. Instead of writing code you're helping engineering teams and executives communicate, fixing communication silos, writing specifications and requirements, reviewing progress on large multi-team features, and generally trying to move the ball on big-picture projects that span multiple feature teams/code-bases/etc.
This kind of work needs high-functioning social skills, excellent written communication skills, an ability to understand a large problem domain and all of the organizational levers you need to move to get it done. You'll also need to be able to tolerate long feedback cycles as the projects you take on will probably take months to see the light of day and you won't be writing the software yourself most of the time. At most I've seen engineers at this level write prototypes or reference implementations. Some enjoy it while others quickly learn that staying at a senior level was probably better for them.
While I haven't read it, I listened to Will Larson's interview on SEDaily (before the show em... changed). It was quite interesting and it was in my reading list since then.
Speaking as a principal software architect for a large (30bn) company:
- convincing others to one's ideas of good architecture - and contributing to enterprise architecture,
- lots of time spent to evaluate designs, ideas, products, acquisition targets,
- every fourth blue moon - some actual low level design work and programming pet projects/pocs/prototyping. Rarely :-(
I like this type of work, gives good exposure to new tech and the ability to choose what tech is being used. For my next job I want something more focused on actual programming though.
When I started out as a developer the engineering part of the title wasn't as widely used. I was working at large enterprise and my manager started to use the term engineer to describe us to other teams, and my coworkers found it funny. It was chalked up as typical overblown language from my manager. Fast forward to now and everybody is an engineer. Also I have noticed a general inflation of the titles associated with it. Senior is the new Junior, etc. I'm sure its company dependent but my 2c
The descriptions in the article are roughly correct for companies that have modeled themselves on Google, which is most companies headquartered in the Bay Area.
Microsoft's Principal Engineer is much more junior than at these companies. It's more like Senior/Staff Engineer. Amazon (headquartered in Seattle like Microsoft), also has a Principal Staff Engineer role which is less senior than Principal at Google and most other Bay Area companies, roughly equivalent to Senior Staff at those companies.
Depends on your perspective I suppose. There's definitely an advantage to being able to play that game, but if you overdo it it tends to be to the detriment of the team or the company culture.
At faang-level tech companies. Total comp. Base is likely 30% of that. By the time someone reaches principal they've likely been at the company for 5+ years which for many is long enough for equity to snowball such that previous years' grants are vesting at 5x their grant valuation. (Or if they're hired on as principal they're likely leaving similar comp on the table so hiring managers have to make up for it, usually with future-vesting equity of similar current valuations.)
In total compensation yes. That means it usually includes stock and at that level about 50-60% of your compensation will be stock.
Look at https://www.levels.fyi to compare companies, but yes overall 800k to over 1 million is quite common for a Principal and typically it requires about 10-15 years of experience.
Principal software engineer: the old grumpy guy who berates and borderline verbally abuses new/junior engineers and jeopardizes mental health across the org.
As a Software Engineer, I consider it my obligation to ensure that people across an organization understand that it is not normal and not acceptable for a Software Engineer to be rude, angry, grumpy or dismissive. The genius mystique must be defeated. I behave as an activist employee: if there's a nerd bringing shame upon nerd kind, I make sure to tackle it head-on. I implore everyone to be activist employees. A nerd who berates someone? Your new mission is to get them out of the organization, and teach everyone who has been in the blast-radius of their bullshit that they were not a god, that their behavior _was not worth it_ no matter how good their code was. You'll change lives for the better, more so than your code ever will.
Thank you for your service!! We need more of you. The problem is where I work these toxic characters are supported and enabled by equally toxic leadership and executives.
I've found that the shield toxic people have around them is often a self-fulfilling prophecy. Leadership can be in a difficult position, because their interface to the people suffering the toxic element is often through the toxic element -- and the same is true in reverse -- which masks the problem. Leadership might think "this person is unpleasant to work with" but also think "their team is delivering so they must be doing something right!" which a team can perceive as protection or an endorsement from leadership, but can be challenged quite easily by demonstrating that their behaviour is harming the team.
Even if you're confident they do have immunity, and that there's no way to pierce through their immunity, there's still opportunities to have a positive impact. A great place to start is with junior employees: every time there's an incident, reach out to them and let them know that this behaviour isn't normal or acceptable. Junior employees are in the worst position: they don't know what is normal and what is not. As a senior employee, you can say with confidence whether behaviour is normal or not, and so just saying "this is not normal" can make the world of difference to someone junior. Also, depending on the organization, reporting incidents can be useful even if it feels like you're just shouting into the void: you never know when these reports will come in useful.
You can form a pithy but unnuanced and unhelpful caricature about every level.
Junior software engineer: arrogant, self-entitled child who thinks they know everything but doesn't even know what they don't know but insists that their ideas are better, creating a people-hostile minefield across the org.
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!).