Stories of reaching Staff-plus engineering roles(staffeng.com)
staffeng.com
Stories of reaching Staff-plus engineering roles
https://staffeng.com/
86 comments
I think the recent "Staff-plus" fascination comes from the extreme dilution these past years of the "Senior" engineering role. Meaningless title inflation is real.
I was given the staff title at 8YOE at a startup because one of the less experienced engineers was given senior through title inflation before I was hired, so they felt I should be a tier above.
Yup. When people are "senior" engineers with less than 5 years experience they need to have something to look toward.
I also need to be able to quickly communicate with recruiters and managers which roles I would be a good fit for.
My favorite is the kid on their first job out of college who after 3 years is now "Senior". Seen too many of these to be funny. I worry about hiring.
That was like the majority of my last company, ha.
To be fair, a kid after three years of high school is "senior". As is a kid after 3 years of college. Perhaps your word2vec("senior") is what needs recalibrating.
Not really, senior is meant to imply you are in the late stages of your career (or school or college or whatever) and have some wisdom to share. It’s reasonable to question if you can get that in a career - which could last 40 years! - when you are 3 years in.
This sounds a bit like King Canute saying the tide won't come in. Everywhere my peers are, senior just means a step up from plain engineer/developer & sits at roughly 5-10 years. The name doesn't have to mean anything, it could be interchangeable with the level numbers at larger companies - ask finance people what Vice President means.
Sure, some industries have really stupid conventions. But historically the IT industry doesn't hand out Senior or Lead titles until you attain actual Senior-level characteristics. I know people who've worked for 15 years and aren't Senior.
Time does not determine titles, skills do.
Exactly, and education. Someone who has a PhD and post doc work who is 5 years out of school is different than a BS with 5 years.
Some skills come with experience.
https://twitter.com/zainrzv/status/1502550200396750851
Junior engineer:
Take this tightly defined feature & build it
Mid-level engineer:
Take this vaguely defined feature & build it
Senior engineer:
Take this known problem & figure out how to solve it
Staff engineer:
Take this goal & find the problems we should be solvinghttps://twitter.com/ryaneccles/status/1502707481327255553
Senior staff engineer:
Define what good goals entail
Distinguished engineer:
Please don’t work for our competitorsThere is a parallel progression for product people also. Part of of it involves embracing this engineering one in others. And vice versa, in partnership.
Having been on a pathway to this level of engineering for a few years at my previous company, I was very disappointed when new management came in and effectively said ‘we’ve heard great things about what you’re doing but we need you to start from scratch and impress us’, to the point that last week I left the company I’d been a part of for over 7 years over the effective reset of all progress towards that next level. No real point to my comment, just a message that if you are just using these roles as a retention strategy for your best engineers, make sure to follow through with it or you may find that your best talent actually leaves over how its managed…
As an aside, I’m really liking the team at my new role as well as the increased breadth of the role to start with.
As an aside, I’m really liking the team at my new role as well as the increased breadth of the role to start with.
Yeah, sometimes it happens. Tech leadership roles are hard to grok to some managers. Sadly in many cases they notice the vacuum left behind instead of the work put in.
On management change, you need to re-assert your value, it shouldn't be super difficult, but sometimes it's easier to just leave.
On management change, you need to re-assert your value, it shouldn't be super difficult, but sometimes it's easier to just leave.
As a "staff-plus" engineer at one of the big tech companies, I find that much of this material is simply not true in practice.
Staff promotions are of course given to some people with a good mastery of soft leadership skills, technical thought leadership and related qualities.
They are also given out for a number of other reasons. For example, when someone is perceived as a flight risk, because it makes their manager look good to promote their team, because someone has been given a lot of responsibility, whether or not they're good at handling it, because it's good for team morale to show that promotion is achievable, or because it can make a headache go away for the manager.
These reasons are all perfectly valid. But let's not overdo the Jedi-like "staff-plus" engineer trope.
Staff promotions are of course given to some people with a good mastery of soft leadership skills, technical thought leadership and related qualities.
They are also given out for a number of other reasons. For example, when someone is perceived as a flight risk, because it makes their manager look good to promote their team, because someone has been given a lot of responsibility, whether or not they're good at handling it, because it's good for team morale to show that promotion is achievable, or because it can make a headache go away for the manager.
These reasons are all perfectly valid. But let's not overdo the Jedi-like "staff-plus" engineer trope.
Yeah I don’t really get why some people in the community have decided that their staff titles mean they’re some kind of warrior monk caste, with these new conferences, books, websites, threads. It’s just another regular step on the ladder you make by doing a reasonably good job and growing regular skills as normal. I don’t think it requires this level of mythology or introspection.
Absolutely — the sudden lionization of the term "staff" seems to be a combination of a personal marketing push (from those selling the shovels) combined with being a useful recruiting strategy.
At one big tech company I worked at, it was never mentioned even once for years and years, and then introduced very suddenly. All existing engineers were grouped into staff versus non-staff based on their existing level, and from then on it was used for recruiting purposes — a superior title to sweeten the offer pot for experienced engineers in a competitive talent market.
I'm personally familiar with some of the people being interviewed on this list and they're fine engineers, but certainly no better than many non-staff engineers at their same companies. And to imply that they're some kind of rare, exotic special species that's totally apart from their non-staff counterparts is in total honesty, just weird.
Nearest I can tell, the term "staff engineer" was an unusual one in use at certain shops, and was popularized big time around 2020. I've kept every recruiter email I've ever gotten since 2018. Prior to 2020, the term "staff" was mentioned in exactly two of them. Starting around Feb 2020, it's now mentioned in 20+ emails a year. Before it, we just used other terms like "principal" instead.
At one big tech company I worked at, it was never mentioned even once for years and years, and then introduced very suddenly. All existing engineers were grouped into staff versus non-staff based on their existing level, and from then on it was used for recruiting purposes — a superior title to sweeten the offer pot for experienced engineers in a competitive talent market.
I'm personally familiar with some of the people being interviewed on this list and they're fine engineers, but certainly no better than many non-staff engineers at their same companies. And to imply that they're some kind of rare, exotic special species that's totally apart from their non-staff counterparts is in total honesty, just weird.
Nearest I can tell, the term "staff engineer" was an unusual one in use at certain shops, and was popularized big time around 2020. I've kept every recruiter email I've ever gotten since 2018. Prior to 2020, the term "staff" was mentioned in exactly two of them. Starting around Feb 2020, it's now mentioned in 20+ emails a year. Before it, we just used other terms like "principal" instead.
I appreciate the viewpoint. One thing to consider is that I think many people in the industry still don’t fully grok the “IC track”, and there is a perception that you need to transition to management to really progress past senior. At FAANG this is obviously ridiculous, the staff/principal levels are visible and progression is clear.
Another related concept is that there really isn’t much written on the subject of “what should I focus on improving” for senior engineers. In a big org you can look to the engineers at the next rung for role models, but at smaller companies there might not be many staff plus, and so the diversity of types of roles may not be clear.
All this is to say that I think this advice is more useful to senior engineers at smaller companies, than it is for those at a similar stage in their career at extremely large companies.
Another related concept is that there really isn’t much written on the subject of “what should I focus on improving” for senior engineers. In a big org you can look to the engineers at the next rung for role models, but at smaller companies there might not be many staff plus, and so the diversity of types of roles may not be clear.
All this is to say that I think this advice is more useful to senior engineers at smaller companies, than it is for those at a similar stage in their career at extremely large companies.
The place I work at (size: couple of thousand employees) has had a 'staff' title for at least a decade, but my impression has always been that it was mostly just the result of "we have enough levels that we want a title above 'senior' and below 'principal'". There's no strong boundary at the 'staff' level -- if you look at the grade criteria there's a fairly clear through line all the way up, with higher grades having more responsibility, wider view of the business, etc, and of course it gets steadily harder to get the promotion.
Nearest I can tell, the term "staff engineer" was an unusual one in use at certain shops, and was popularized big time around 2020.
That looks about right. It came along with the increases in hiring and compensation in parts of the industry, the resulting employee's market, the resulting desire to show a long technical career ladder with many more steps than we used to have, and the resulting devaluation of the "senior" title that was once a big deal. For employers to show how much they value the more capable people who used to be "senior" and can take on roles like technical leadership or cross-team architecture, the employers have now adopted titles like staff, senior staff, principal, fellow, etc.
Naturally those positions attract interest for the same reason that "senior" used to. It's the level where a person typically becomes self-sufficient and able to work on more demanding initiatives under only broad direction. It's also the level where those with an interest in technical leadership become capable enough to run larger teams or groups effectively and probably limit their personal technical contributions to more strategic activities or surgical interventions.
I'm not sure how much has really changed apart from the titles, though. There has always been a qualitative shift in emphasis around that level of experience and ability for developers, whatever we choose to call it. And the responsibility and authority you have in your role, often reflected in compensation and how colleagues relate to you, has always said more about your real seniority than any formal job title.
That looks about right. It came along with the increases in hiring and compensation in parts of the industry, the resulting employee's market, the resulting desire to show a long technical career ladder with many more steps than we used to have, and the resulting devaluation of the "senior" title that was once a big deal. For employers to show how much they value the more capable people who used to be "senior" and can take on roles like technical leadership or cross-team architecture, the employers have now adopted titles like staff, senior staff, principal, fellow, etc.
Naturally those positions attract interest for the same reason that "senior" used to. It's the level where a person typically becomes self-sufficient and able to work on more demanding initiatives under only broad direction. It's also the level where those with an interest in technical leadership become capable enough to run larger teams or groups effectively and probably limit their personal technical contributions to more strategic activities or surgical interventions.
I'm not sure how much has really changed apart from the titles, though. There has always been a qualitative shift in emphasis around that level of experience and ability for developers, whatever we choose to call it. And the responsibility and authority you have in your role, often reflected in compensation and how colleagues relate to you, has always said more about your real seniority than any formal job title.
One of the reasons may that beyond big tech, the role is largely unknown, leading to huge differences how the staff role is defined. There are companies where staff means a senior+ role with equal scope and staying on the same team. In others, staff carries a significant scope change, meaning that the bar to reach staff is higher.
There is this whole subculture of fetishization of titles and honorifics in general that some people feel very strongly about. But there are a ton of other places where basically no one cares and they'll look at you sideways if you insist on them caring.
I used to be in group A but now I'm probably in group B. If I compare title/rank between engineering and managerial tracks where I work, there are many, many more people sitting at that rank in management than there are in engineering. The rank confers all sorts of things in terms of pay, chiefly it's used for determining our performance bonuses. I suspect that engineers are just being played by our corporate overlords but I'm not inside of the management beast to know for sure.
Having a good IC advancement track is somewhat orthogonal to a focus on specific titles across companies though. I've always been an IC and I mostly haven't even used whatever my official title was--and might even have had to look it up.
If there is an IC advancement track then the titles don't matter. All the discussion around titles is specifically to have an IC advancement track, which very few companies have.
Depends on the company, at some, including the one I'm at, most Senior Engineers will not become Staff Engineers. And from what I hear, this is a growing approach throughout the tech industry, although I think the majority of companies will still continue to treat Staff as "Senior with a few more years experience". It'll be interesting to see how the industry grows. I think we'll see more levels added above Senior beyond the two or three "Staff" type roles.
[deleted]
>Yeah I don’t really get why some people in the community have decided that their staff titles mean they’re some kind of warrior monk caste,
I've never been promoted, nor have I ever promoted anyone to "staff plus" because of warrior-monk like engineering skills. Most often it is a combination of good soft skills and proven decision making around people and organization objectives. Usually it is because the person being promoted had the ability to make the business unit better in some way that is needed. And yes, that does mean that every promotion is really done to make the person a step above the newly promoted person even more effective.
> It’s just another regular step on the ladder you make by doing a reasonably good job
This is the secret. A reasonably good job means you are learning not just how to make software, but also how to lead others that are making software. There's nothing mythic about it. But for many it requires going outside of the comfort of the purely technical.
I've never been promoted, nor have I ever promoted anyone to "staff plus" because of warrior-monk like engineering skills. Most often it is a combination of good soft skills and proven decision making around people and organization objectives. Usually it is because the person being promoted had the ability to make the business unit better in some way that is needed. And yes, that does mean that every promotion is really done to make the person a step above the newly promoted person even more effective.
> It’s just another regular step on the ladder you make by doing a reasonably good job
This is the secret. A reasonably good job means you are learning not just how to make software, but also how to lead others that are making software. There's nothing mythic about it. But for many it requires going outside of the comfort of the purely technical.
> They are also given out for a number of other reasons. For example, when someone is perceived as a flight risk, because it makes their manager look good to promote their team, because someone has been given a lot of responsibility, whether or not they're good at handling it, because it's good for team morale to show that promotion is achievable, or because it can make a headache go away for the manager.
Big tech company is a huge group that has widely different cultures. Based on these reasons you listed, you likely didn't work at a FAANG or similar company (Uber, Doordash, Lyft, Airbnb...etc). The reasons you listed are responsible for 0% of Staff promotions at these companies (except the "given a lot of responsibility they're not good at handing" reason you gave, assuming the person is taking credit for other people).
I agree that all of your reasons are valid for Senior and lower promotions, but these companies take Staff+ to another level by using a completely different promotion process beyond Senior level (even L5B or Senior II at Uber uses the more strict process).
The reason you see the "Jedi-like" trope is because the strict bar set for Staff plus promotions at these companies. To be fair this Jedi trope is created by the perception of other engineers because of the difficulty of achieving these levels and not knowing what it takes to do it. Career advice including this StaffEng book actually lessen the trope because it makes it clear how you can get these roles and removes all the mystique around the unknown.
The root cause for promotions occurring for the reasons you listed are due to promotion decisions being owned by just the manager or only a single chain of command (manger's manager, director..etc). This is how Senior and lower promotions also work at these FAANG+ companies. To get rid of that bias and gaming, all Staff plus promotions go through a promotion committee, and your manager has no power aside from submitting your promo packet to the committee.
No matter how bad the manager or his director of even Senior director wants to keep the employee or look good, they have no say in the promotion decision. There is a calibration process that ranks all engineers submitted to the committee against each other and only approves a small % at the top rank. Someone who got Staff promo this year might not have next year depending on the competition.
None of this is to say that the process is perfect or removes all bias. But the process is very strict and the promo comitte vigorously applies the rubric which is why you see all of this advice to exhibit skills typical on these rubrics.
Big tech company is a huge group that has widely different cultures. Based on these reasons you listed, you likely didn't work at a FAANG or similar company (Uber, Doordash, Lyft, Airbnb...etc). The reasons you listed are responsible for 0% of Staff promotions at these companies (except the "given a lot of responsibility they're not good at handing" reason you gave, assuming the person is taking credit for other people).
I agree that all of your reasons are valid for Senior and lower promotions, but these companies take Staff+ to another level by using a completely different promotion process beyond Senior level (even L5B or Senior II at Uber uses the more strict process).
The reason you see the "Jedi-like" trope is because the strict bar set for Staff plus promotions at these companies. To be fair this Jedi trope is created by the perception of other engineers because of the difficulty of achieving these levels and not knowing what it takes to do it. Career advice including this StaffEng book actually lessen the trope because it makes it clear how you can get these roles and removes all the mystique around the unknown.
The root cause for promotions occurring for the reasons you listed are due to promotion decisions being owned by just the manager or only a single chain of command (manger's manager, director..etc). This is how Senior and lower promotions also work at these FAANG+ companies. To get rid of that bias and gaming, all Staff plus promotions go through a promotion committee, and your manager has no power aside from submitting your promo packet to the committee.
No matter how bad the manager or his director of even Senior director wants to keep the employee or look good, they have no say in the promotion decision. There is a calibration process that ranks all engineers submitted to the committee against each other and only approves a small % at the top rank. Someone who got Staff promo this year might not have next year depending on the competition.
None of this is to say that the process is perfect or removes all bias. But the process is very strict and the promo comitte vigorously applies the rubric which is why you see all of this advice to exhibit skills typical on these rubrics.
> you likely didn't work at a FAANG or similar company
I do work at a FAANG company. I'm very much familiar with the promo process, as an individual, as a manager and as a peer reviewer.
Managers cannot unilaterally promote a report, but they have an influential role in helping shape the packet, in getting the right reviews from sufficiently senior employees and in trailing performance reviews. The managers also read the ladder description, not just the committees, and make sure the packets contain "evidence" of all the key points. Nothing broken here, just rigmarole that people on all sides need to follow.
You can choose to believe that the committees can do a good job of ranking applicants, but a large part of this is down to how good the packet itself is.
I should state that nothing is wrong here in my opinion. There's no managerial conspiracy or role inflation. My point is that being a Jedi-like "Staff-plus" engineer is not at all necessary to reach the level.
I do work at a FAANG company. I'm very much familiar with the promo process, as an individual, as a manager and as a peer reviewer.
Managers cannot unilaterally promote a report, but they have an influential role in helping shape the packet, in getting the right reviews from sufficiently senior employees and in trailing performance reviews. The managers also read the ladder description, not just the committees, and make sure the packets contain "evidence" of all the key points. Nothing broken here, just rigmarole that people on all sides need to follow.
You can choose to believe that the committees can do a good job of ranking applicants, but a large part of this is down to how good the packet itself is.
I should state that nothing is wrong here in my opinion. There's no managerial conspiracy or role inflation. My point is that being a Jedi-like "Staff-plus" engineer is not at all necessary to reach the level.
True the manager does have influence in that way. They can definitely increase the chances. I read the parent comment as saying it was as flexible as Senior and below promos which is why I incorrectly assumed you hadn't worked in FAANG culture.
I think the promo comittees do a significantly better job than relying on managers alone, but they definitely have bias. Not perfect, or even good but still way better because there's less incentive to game the system.
I agree that Staff-plus isn't Jedi-like and there is a trope about that. I assumed your criticism there was about the StaffEng book which doesn't promote that trope, instead it gives a practical guide on what it usually takes to get that promo.
I think the promo comittees do a significantly better job than relying on managers alone, but they definitely have bias. Not perfect, or even good but still way better because there's less incentive to game the system.
I agree that Staff-plus isn't Jedi-like and there is a trope about that. I assumed your criticism there was about the StaffEng book which doesn't promote that trope, instead it gives a practical guide on what it usually takes to get that promo.
I recently interviewed at a startup and they offered me the hilariously inflated title "Senior Member of Technical Staff". Couldn't get them to meet my comp expectations though, so I didn't take the job.
Isn't that just Senior? At least that's what Salesforce calls their Senior eng.
No, in some companies SMTS is a specific title a few ranks above “Senior Engineer” and a couple ranks below “Fellow” or “Partner” or whatever the company calls the ultimate rank.
Other companies use “Member of Technical Staff” as a generic job description in place of “Software Engineer”, “IT Analyst”, etc. Then the promotion ranks are called “MTS 1”, “MTS 2”, etc.
Other companies use “Member of Technical Staff” as a generic job description in place of “Software Engineer”, “IT Analyst”, etc. Then the promotion ranks are called “MTS 1”, “MTS 2”, etc.
No such thing as “staff” when the headcount is 2.
It's ego and job security. Rather than teach all engineers their Jedi mind-tricks, they keep it in their own special group. Now only they can be hired to do the super secret fancy stuff, and they get paid more.
Some times it even more unrelated to skill. Uber recently changed senior title to staff for everyone
This sounds interesting, and something that apparently doesn't exist at my current company (Engineer, Senior Engineer, otherwise it's only management beyond that point).
But am I the only one disappointed that as a book it's only available in paperback? The hardback of "An Elegant Puzzle" is _beautiful_ in both binding and print quality, it wouldn't be a hard decision to spend extra for this one.
But am I the only one disappointed that as a book it's only available in paperback? The hardback of "An Elegant Puzzle" is _beautiful_ in both binding and print quality, it wouldn't be a hard decision to spend extra for this one.
Good timing as I contemplate whether I want to go the Engineering manager vs. Individual contributor route.
Being at the Senior engineer level now, I find this resource a nice counterbalance against the abundance of existing material aimed at engineering management and the vast ocean of material for Junior engineers.
Being at the Senior engineer level now, I find this resource a nice counterbalance against the abundance of existing material aimed at engineering management and the vast ocean of material for Junior engineers.
I don't think it's a definitive choice. I've jumped from one to the other and vice versa based on opportunities and contexts, and it continues to serve me well.
Really, it is only 2 different ways to contribute to a product and engage in a team. If you can be good at both, why force a career-long choice?
Really, it is only 2 different ways to contribute to a product and engage in a team. If you can be good at both, why force a career-long choice?
https://charity.wtf/2017/05/11/the-engineer-manager-pendulum... is a great read on this.
I went the IC route (Sr. Principal or an IC7). It's difficult to get there but rewarding. In either route, you're still a leader. Managers have formal power, and deal with a lot of process (budgets, pay, promotions, etc.).
Tech leads are influencers, we focus a lot more on technology and growth of the team in a different way. You forgo all the messy (boring for me) details of project management, and focus more on the technology and getting the right people to move projects forward, but this requires persuasion. There's not one way to do this job, you have to find your own. The hardest part is probably that of picking the right thing to delegate, to maximize growth and project success.
There's some overlap with managers especially as you climb the ladder and your focus is more strategic than tactical.
Tech leads are influencers, we focus a lot more on technology and growth of the team in a different way. You forgo all the messy (boring for me) details of project management, and focus more on the technology and getting the right people to move projects forward, but this requires persuasion. There's not one way to do this job, you have to find your own. The hardest part is probably that of picking the right thing to delegate, to maximize growth and project success.
There's some overlap with managers especially as you climb the ladder and your focus is more strategic than tactical.
These role level names are just nonsense of the highest order (Staff, Senior, L2, etc). People are given titles to fixate on as a substitute for things which actually matter:
1. The opportunity to have meaningful impact 2. Important, fulfilling work 3. Recognition of value (including good comp but not just that)
etc
1. The opportunity to have meaningful impact 2. Important, fulfilling work 3. Recognition of value (including good comp but not just that)
etc
Matters for the next job-jumping, compensation issues
and honestly, even respect one gathers
and honestly, even respect one gathers
My last job before retiring last year there were virtually zero promotions in the greater department during my nearly six years there, besides a manager and a director who got multiple promotions. I had the same title (lead) I started with, yet my team and the greater department had high visibility in the (not FAANG but similar sized) company and was tasked with complex projects that affected company revenue. Other than one person made architect, the highest title any programmer had was lead despite there being several dozen employee programmers and nearly 100 contractors. The best improvement in status was a few contractors being offered employee. So while the work might meet the definition of whatever staff is (one of my responsibilities was being in charge of code that made 9 figures a year), and there being 3 levels of programmer titles above lead, no one ever was promoted any higher.
Sometimes the work and the title do not match, if the company or department is uninterested in rewarding people with fancier titles. But I knew another org far removed from ours where the manager was a senior director and all of his (half dozen) team had the top programmer titles, yet did not do anything different than we did, and none of it was revenue related.
Sometimes the work and the title do not match, if the company or department is uninterested in rewarding people with fancier titles. But I knew another org far removed from ours where the manager was a senior director and all of his (half dozen) team had the top programmer titles, yet did not do anything different than we did, and none of it was revenue related.
I joined a company that IPOd somewhat recently and recruits lots of folks from Big Tech (esp Google it seems). Literally everything is driven by promotions and “expectations for your level”. I actually don’t mind having explicit minimum expectations for your job but when that’s all anyone cares about it becomes really dispiriting.
I’ve met “staff” engineers who were just above “junior” at best, and architects who couldn’t actually write code but man, could they talk your ear off about design patterns that any good programmer should know anyway.
Often titles are a reflection of who’s been at the company the longest or who toots their own horn the most. I have no faith in titles, they’re mostly meaningless.
Often titles are a reflection of who’s been at the company the longest or who toots their own horn the most. I have no faith in titles, they’re mostly meaningless.
Agreed about horn tooting design astronauts.
There's a flip side to consider, though. I've seen brilliant people waste years of their energy and talent on technology ideas that go nowhere due to a lack of ability to ship to a community and gain mindshare among relevant technologists. Folks should dismiss vanity and puffery, but broadcasting opportunities and successes (and interesting challenges that need solutions, even) is undervalued among certain engineers. And it's a critical part of "shipping" for certain kinds of projects.
There's a flip side to consider, though. I've seen brilliant people waste years of their energy and talent on technology ideas that go nowhere due to a lack of ability to ship to a community and gain mindshare among relevant technologists. Folks should dismiss vanity and puffery, but broadcasting opportunities and successes (and interesting challenges that need solutions, even) is undervalued among certain engineers. And it's a critical part of "shipping" for certain kinds of projects.
I think this is probably a small-company problem. I've literally never met a staff engineer at Google that wasn't clearly better than the average Senior.
This one is cultural, and a meritocracy is one kind of culture.
I don't know how typical Google is, but it expressly tries to maintain a consistent bar for a given ladder/level[*] and L5 -> L6 SWE promos are pretty tough. It's often said that L6 SWE is a different job and not just L5++, and I think there's a lot of truth in that.
[*] Consistency is a great goal, but is clearer getting harder and harder to achieve as the company is getting bigger and more diverse in terms of product areas, engineering and other skills etc.
[*] Consistency is a great goal, but is clearer getting harder and harder to achieve as the company is getting bigger and more diverse in terms of product areas, engineering and other skills etc.
The problem has been fairly extreme at all of the companies I've worked at. I would even say that, if you exclude the new grads, there's actually an inverse relationship between someone's level and how much I would want to work with them.
I expect the problem is most severe at mid-sized companies that don't have highly-technical business problems to solve. I think the root cause looks something like this:
- A long chain of relatively non-technical managers exists in the engineering org.
- Promotions, especially to staff, become very political, ie the decision-makers likely haven't worked directly with the candidates for promotions.
- The criteria for promotion to staff effectively becomes whether they contribute to highly-visible, high-level engineering efforts
- If the domain doesn't require them, these highly-visible efforts are likely either lateral shifts or actively unhelpful. The company probably doesn't need to be reinventing the wheel with some staff IC's pet project, especially if the mid-level IC's know what they're doing and can keep the lights on.
- The best engineers eventually leave for greener pastures. Of the engineers that stick around, the ones most likely to get promoted are the ones who are the most enthusiastic about designing (or just talking about) systems that no one wants or needs
I expect the problem is most severe at mid-sized companies that don't have highly-technical business problems to solve. I think the root cause looks something like this:
- A long chain of relatively non-technical managers exists in the engineering org.
- Promotions, especially to staff, become very political, ie the decision-makers likely haven't worked directly with the candidates for promotions.
- The criteria for promotion to staff effectively becomes whether they contribute to highly-visible, high-level engineering efforts
- If the domain doesn't require them, these highly-visible efforts are likely either lateral shifts or actively unhelpful. The company probably doesn't need to be reinventing the wheel with some staff IC's pet project, especially if the mid-level IC's know what they're doing and can keep the lights on.
- The best engineers eventually leave for greener pastures. Of the engineers that stick around, the ones most likely to get promoted are the ones who are the most enthusiastic about designing (or just talking about) systems that no one wants or needs
It sounds like the problem is more or less summarized as "No one knows how to evaluate work, so loud people get promoted."
Not biasing towards loud people is difficult, but at least at Google, the process is pretty harshly designed to avoid it. The criteria for promotion is clear. The people deciding on it are considering many different promotions at once, so they have a decent sample to look at. The people with incentive to promote don't get to make the decision or they play only a small role in it. There is a strong demand to see evidence that the person's work fits the job ladder description that they are trying to promote to, etc.
It's a lot of overhead and everyone hates it, but it seems to be pretty robust at avoiding arbitrary promotion.
Not biasing towards loud people is difficult, but at least at Google, the process is pretty harshly designed to avoid it. The criteria for promotion is clear. The people deciding on it are considering many different promotions at once, so they have a decent sample to look at. The people with incentive to promote don't get to make the decision or they play only a small role in it. There is a strong demand to see evidence that the person's work fits the job ladder description that they are trying to promote to, etc.
It's a lot of overhead and everyone hates it, but it seems to be pretty robust at avoiding arbitrary promotion.
There are many comments here about title inflation/the increasing interest in "staff" engineers/etc - I tend to agree with the arguments in this article [0] (from Gokul Rajaram) that argues titles distract from what you should actually care about, celebrate, and recognize at a company - scope and impact.
[0] https://medium.com/@gokulrajaram/the-one-thing-ceos-should-d...
[0] https://medium.com/@gokulrajaram/the-one-thing-ceos-should-d...
Interesting that almost all comments here are completely dismissive of the meaning of staff+ titles, to the point of not even discussing the content of the articles.
Yes, it's true that your title is not your role, and your role is not your job, and your job is not your professional identity. But your title is part of your professional identity, and it's the best shorthand to communicate your status with future employers, or even just with a colleague in a distant branch of your company.
Our profession is young, so it's still in the early phases of defining itself. I'm sure other professions have title bloat too. You still need to play the game, even if you don't like the rules.
Yes, it's true that your title is not your role, and your role is not your job, and your job is not your professional identity. But your title is part of your professional identity, and it's the best shorthand to communicate your status with future employers, or even just with a colleague in a distant branch of your company.
Our profession is young, so it's still in the early phases of defining itself. I'm sure other professions have title bloat too. You still need to play the game, even if you don't like the rules.
>your title is part of your professional identity
Sometimes. I don't even use my actual title. (Mostly because I don't really do what my title says I do so I use something more generic.)
Sometimes. I don't even use my actual title. (Mostly because I don't really do what my title says I do so I use something more generic.)
My company makes me free to use any title of my choosing except CEO. It's up to me whether I use it to accurately describe my job or use it as promo pull when changing jobs, and I see people using it both ways, and I think both ways do work.
MD and VP in finance companies
I have this book. I enjoyed the previous book by the author much more. This one in particular focuses around a title, but my take away is “how to be a better knowledge worker”.
There are so many great tips in this book ranging from leading without role power, daily tactics to drive results, and even when you should make a push for the title whether that is staying or leaving.
The stories are okay and are half the book, but no single story of getting the promo is similar enough. It does help you realize you may not need a “SNAP” project to obtain an prestigious position.
If the book had another hundred pages of being more efficient and strategic, I think it would be a better read. Stories in most tech books are not very helpful at least to me. I find them hard to relate to, but every once in a while a story will match my situation and help me grow.
There are so many great tips in this book ranging from leading without role power, daily tactics to drive results, and even when you should make a push for the title whether that is staying or leaving.
The stories are okay and are half the book, but no single story of getting the promo is similar enough. It does help you realize you may not need a “SNAP” project to obtain an prestigious position.
If the book had another hundred pages of being more efficient and strategic, I think it would be a better read. Stories in most tech books are not very helpful at least to me. I find them hard to relate to, but every once in a while a story will match my situation and help me grow.
What is a "SNAP" project? I have never heard this jargon and it's also impossible to Google.
Someone needs a promotion.
It’s work that isn’t meaningful, but has leadership buy in and visibility.
It’s work that isn’t meaningful, but has leadership buy in and visibility.
What a depressing concept.
Very. It is why there are product graveyards though. Usually compelling ideas that never were validated with product market fit.
https://killedbygoogle.com/
https://killedbymicrosoft.info/
The other side is internal initiatives that become priority number 1 for a team and then die over the next year or so.
https://killedbygoogle.com/
https://killedbymicrosoft.info/
The other side is internal initiatives that become priority number 1 for a team and then die over the next year or so.
I wonder if the idea is to find and promote people who could in principle lead development of a new product, by making them develop a (toy) new product.
Just my experience, but most of the people who "climb the ladder with SNAP projects" end up leaving very quickly or dial down their ambitions to maintain the title for the remainder of their tenure at the company.
Have you ever considered what percentage of software that gets written actually stands the test of time? Failed companies, products, teams, projects, ideas. Sometimes it's great software that's replaced by something worse because of economic forces out of their control. It is depressing.
This seems to be split pretty clearly down a "promotion criteria" line.
At small companies, where basically everything is arbitrary, sample sizes are small and there's not enough data to be data driven, titles are perceived as mostly meaningless.
At large companies that do a good job of standardizing how promotion works and what is required to get it, titles are not perceived to be meaningless.
At small companies, where basically everything is arbitrary, sample sizes are small and there's not enough data to be data driven, titles are perceived as mostly meaningless.
At large companies that do a good job of standardizing how promotion works and what is required to get it, titles are not perceived to be meaningless.
There is a tension here I want to explore. Basically I have a theory that coders are the new managers (goes with my software literacy idea). Look at books on management ala Drucker in the 60s. These people (big managers) are a special species bestriding the world, aligning corporations to build better world. Recently google published a book on how to be a great manager which boiled its eight points down to "be nice to your coders so they stay"
Companies are becoming programmable - machines that are slow AI and slowly speeding up that AI and that needs control via code. And the coders build that.
So my theory is that each release of code is effectively a new company (machine). And that the people we call software engineers are writing the rules for those companies - but the non coding managers are not going to let go without a fight.
Staff engineering roles are the front line for this battle. If it's all influence and social respect (like say Linus) then the future of empire building managers is shaky.
Companies are becoming programmable - machines that are slow AI and slowly speeding up that AI and that needs control via code. And the coders build that.
So my theory is that each release of code is effectively a new company (machine). And that the people we call software engineers are writing the rules for those companies - but the non coding managers are not going to let go without a fight.
Staff engineering roles are the front line for this battle. If it's all influence and social respect (like say Linus) then the future of empire building managers is shaky.
My main frustration with IC levels is that the promotions often come down to questionable criteria like:
- Have you worked on highly-visible, high-level, cross-org projects?
Are these efforts really needed? Should your organization be reinventing the wheel? I've seen staff IC's get unreasonably attached to their own pet projects and keep pushing them despite universally negative feedback from the engineers that would be affected. The right level of high-level abstraction should come from the actual requirements of the business, not artificially pumped up by engineers because it's required to get promoted.
- Do you mentor other engineers?
Do the engineers on your team actually need mentoring? Most of the people on my current team are not senior (IC2) and the best group of engineers I've ever worked with. We all have 5-10 years of experience. But the IC4 recently assigned to our team feels the need to give use engineering 101 lectures on every single topic, and it's been extremely frustrating.
- Have you led projects?
This one makes sense I know. But it's also often just a proxy for your time at the company if you need to patiently wait your turn to wear the tech lead hat. Glacial promotion opportunities often lead to the best engineers leaving
- Have you worked on highly-visible, high-level, cross-org projects?
Are these efforts really needed? Should your organization be reinventing the wheel? I've seen staff IC's get unreasonably attached to their own pet projects and keep pushing them despite universally negative feedback from the engineers that would be affected. The right level of high-level abstraction should come from the actual requirements of the business, not artificially pumped up by engineers because it's required to get promoted.
- Do you mentor other engineers?
Do the engineers on your team actually need mentoring? Most of the people on my current team are not senior (IC2) and the best group of engineers I've ever worked with. We all have 5-10 years of experience. But the IC4 recently assigned to our team feels the need to give use engineering 101 lectures on every single topic, and it's been extremely frustrating.
- Have you led projects?
This one makes sense I know. But it's also often just a proxy for your time at the company if you need to patiently wait your turn to wear the tech lead hat. Glacial promotion opportunities often lead to the best engineers leaving
High visibility sometimes is confused with strategic importance. Tech leadership roles in a sane org. focus more and more on the strategic than on the tactical. Help keep focus on needed projects that cannot be delivered in a short time frame, but are nevertheless needed, sometimes even essential. The ability to deliver short-term value while not derailing long-term goals takes experience to hone, and is one of the tells of a true staff+ engineer.
Mentoring is complex. It's not giving lectures (although, sometimes it may help). It's usually more subtle and is typically related to delegation: pick the correct thing to delegate, choose wisely what to do yourself. The trick is to maximize learning and accomplishment of more junior engineers while at the same time not risking team/company objectives. Besides that, providing emotional support and guidance in a way that most managers cannot. You walked the walk, so you help them think on how improve and get where they want to get (even sometimes help figure out what they want).
Leadership can also be subtle. Managers tend to equate it with project management (i.e. scrum/whatever, task assignment). On a tech ladder role, leadership is much more about influence than actually telling people what to do. You nudge them in the right direction so the goals are met and they grow (see: mentoring).
The best tech leads (staff+ or whatever), get shit done in a way that's sometimes non-obvious, until you miss them. Which makes promotion hard.
Mentoring is complex. It's not giving lectures (although, sometimes it may help). It's usually more subtle and is typically related to delegation: pick the correct thing to delegate, choose wisely what to do yourself. The trick is to maximize learning and accomplishment of more junior engineers while at the same time not risking team/company objectives. Besides that, providing emotional support and guidance in a way that most managers cannot. You walked the walk, so you help them think on how improve and get where they want to get (even sometimes help figure out what they want).
Leadership can also be subtle. Managers tend to equate it with project management (i.e. scrum/whatever, task assignment). On a tech ladder role, leadership is much more about influence than actually telling people what to do. You nudge them in the right direction so the goals are met and they grow (see: mentoring).
The best tech leads (staff+ or whatever), get shit done in a way that's sometimes non-obvious, until you miss them. Which makes promotion hard.
Also - any pyramid has less jobs at top than below. By definition, you can have 100 people be as awesome as you like but if there is only one open position 99 will be disappointed. As such it's not about the qualities of the candidates it's about the internal politics of the organisation.
Once "it's about the internal politics of the organisation" rules it's time to tear down the organisation.
Once "it's about the internal politics of the organisation" rules it's time to tear down the organisation.
Staff-level tends to happen if you are able to stay motivated to keep finding and fixing problems for a long enough time. You will naturally build expertise in whatever field you're in as you iterate on that, until eventually you just know all the ins-and-outs of the systems in which you're working that you can "see around walls" when more junior people waltz in and try doing stupid sh*t. Your proactive criticism of their ideas and code will be seen as technical leadership -- well, because it kind of is.
The only people I know who got stuck at Senior as they got older were the ones who let themselves get to the point where all they wanted to do was pull a paycheck until they could retire. They stopped giving a fsck when they saw stupid sh-t happening around them and just let it happen.
The only people I know who got stuck at Senior as they got older were the ones who let themselves get to the point where all they wanted to do was pull a paycheck until they could retire. They stopped giving a fsck when they saw stupid sh-t happening around them and just let it happen.
Staff is the entry level of the serious technical leadership ladder. It's a pivot point for many (i.e. a phase change if you like).
As a technical leader, you don't have direct reports (if you have, you're a manager) and your job is one of leadership through influence rather than formal power (you're -in a sense- an "influencer").
You sell ideas, you nudge people in the right direction, you mentor and help others grow and you help people think clearly and relax in difficult technical situations.
The higher you get on the ladder, the more strategic your work becomes. You look farther in the future, projects take years to crystallize, you build blocks that buy us something now, but work as a stepping stone for a larger goal in the future.
With this type of leadership, comes a surprise to many tech-minded types: your work becomes a lot more about emotions than technology.
You need to project calm, help people think things out. Guide them without giving them the solution so they can grow. Help them through crises and so on.
This applies even to managers above you in the hierarchy. The relationship becomes different, you're no longer a subordinate, you're now a peer (even if the org chart says otherwise).
As you may imagine, it takes a while to get there from just a strong technical background.
As a technical leader, you don't have direct reports (if you have, you're a manager) and your job is one of leadership through influence rather than formal power (you're -in a sense- an "influencer").
You sell ideas, you nudge people in the right direction, you mentor and help others grow and you help people think clearly and relax in difficult technical situations.
The higher you get on the ladder, the more strategic your work becomes. You look farther in the future, projects take years to crystallize, you build blocks that buy us something now, but work as a stepping stone for a larger goal in the future.
With this type of leadership, comes a surprise to many tech-minded types: your work becomes a lot more about emotions than technology.
You need to project calm, help people think things out. Guide them without giving them the solution so they can grow. Help them through crises and so on.
This applies even to managers above you in the hierarchy. The relationship becomes different, you're no longer a subordinate, you're now a peer (even if the org chart says otherwise).
As you may imagine, it takes a while to get there from just a strong technical background.