I find it interesting that a culture is being described here where Senior Engineers are considered lower level, with multiple higher levels above that. It just goes to show that titles mean different things at different companies, and you cannot generalize across this industry. I've had the "Staff Software Engineer" title once in my career. It was at IBM, in the 90s, where it was a was a title given to anyone who was not junior. I had it in my first ever coding role, while I was still learning to code. How the title changed from meaning "Generic Staff Member" in the 90s to "Above Senior" today, I have no idea.
In any case, the job described does mesh well with what I see most "Senior Engineers" doing. So the article in general is a good idea of where long-term growth as an engineer will take you.
My feeling is that it traces from the institution of staff officers in the military:
> General staff: in the military, a group of officers that assists the commander of a division or larger unit by formulating and disseminating his policies, transmitting his orders, and overseeing their execution. Normally a general staff is organized along functional lines, with separate sections for administration, intelligence, operations, training, logistics, and other categories.[1]
I always thought it was intended to differentiate “line” engineers (charged with the core work product) from “staff” engineers (focused on advising and supporting the org more broadly): https://en.m.wikipedia.org/wiki/Staff_and_line
> I only spend around half my time on tasks directly for my scrum team
That does not mean half her time is spent making tickets. This could be code writing, code reviews, testing, meetings, agendas, designing or ideating new systems or improvements, and, also, making tickets.
There’s a lot of asymmetry in leveling titles / nomenclature. A friend and I ended up building http://levels.fyi to help map these titles across different companies, they certainly don’t mean the same thing everywhere
There is nothing wrong with knowing what you like to do, and doing it. And having folk like you on a team is important - teams struggle whenever everyone is jockeying for a better position. So while "unambitious" can get a negative connotation, it deserves more respect - it gets the job done, and that is valuable.
Mmm, being the only non-striver on a team full of them also sounds like a bad time, a recipe for becoming under-valued.
There is a condescension to this thing where people say “hey, that’s ok too” when it’s actually not ok for themselves. I can accept that, it is what it is, but it’s definitely there.
Same. Just be who you are. The tech industry “growth expectations” culture is garbage.
Just as a personal anecdote everyone told me constantly that I would never make Staff Engineer at Google (roughly the 90th percentile rank) by just contributing to the code base. But that is what I did, and I was promoted to that rank. And I got the satisfaction of not participating in all the anti patterns of “leadership “ where one person gets promoted for taking credit for the work of many other people, or for solving problems they also created, etc.
In short I rather admire a trade like dentistry or carpentry where one just practices one’s skills to the best of their ability, and there is no such thing as “Senior Staff Dentist”.
Yes, well, at some point you get tired of seeing people make the same mistakes over and over. Those people might be senior engineers tasked with architectural design for the first time. Those people might be management with their heads up their....um, with misguided ideas.
So the Senior Staff position may involve less day-to-day coding/design, but a lot more heading off disaster, which I would argue adds huge value to the company, and personally I find satisfying. In fact, there is nothing less satisfying than failing to head off a disaster that you could see coming from miles away.
I remember a very senior IC at one company I worked at, named Gary. Gary basically wandered from meeting-to-meeting, only attending a few minutes because his calendar was routinely triple-booked. He would listen to a few minutes of argumentation, ask the one question that would slice the problem open like a sharp machete to a coconut, and then move on to the next meeting. Didn't design much any more, but his contributions had huge leverage.
Don't write off that some day you may want to be a Gary. It may come naturally at some point, when you frequently start thinking: "I've seen this movie before and it has a baaaad ending."
Yes, if “impact to the company” is an important metric to you, you should probably climb the ladder. I can’t identify with that, though. I just want to do my little piece and focus on the rest of my life.
It’s ok if the company ends up doing something it shouldn’t have. That is just what happens. When I was younger, I spent a lot of energy fretting about such things; people didn’t listen to me. I learned to make peace with that, rather than vow to have my opinions heard. Besides, who is to say that I wouldn’t have just steered the ship into a different iceberg.
I’m one of those crazy people who thinks unlimited vacation is a good idea and not a scam, done correctly of course.
I suppose you’re right that I could magically change my mind one day. Hasn’t happened yet, 15 years in.
You can be ambitious and still hate everything to do with career tracks and personal development as seen by large corporations.
I make sure I work somewhere that isn't too stressful, and pace myself as much as possible at the dayjob so I can work 20+ hours per week on my own business.
I wish I could have a 3-day workweek so the other 4 days I could be coding my own projects. After $100k why do people even want more money? I just want more time to work on my projects for a chance to have my own business. I'll never understand why so many people choose to be put into golden handcuffs.
I’m nowhere near Silicon Valley or the west coast - I’m on the opposite side of the country in Atlanta. Yes I know people here live a good life, have a house, go on trips etc with a household income of less than six figures, but making more gives you a lot more “Ands” and less “ors”.
You can have the nice house in the burbs, max out your 401K, enjoy decent date nights with your SO every pay period, save for vacations, pay other people to do stuff you don’t want to do (occasional meal prep, yard service, etc), and have enough left for the things that go bump in the night. Realistically, for all the “ands” it takes about $150K to $200K of household income. That’s without getting the biggest house, the nicest cars and the most expensive vacations.
Also, I see “having my own business” and “having a less stressful life” as being the opposite of each other.
I don’t have to worry about finding customers, budgets, marketing, and I have st least six weeks a year paid time off between vacation time and holidays.
If the company disappears tomorrow I get another job.
I'm sure this just suits some people's fancy but the idea of being in a "track" is so off putting and mind numbing to me. Ooh here is where I'll be exactly in 5, 10, 15 years. So exciting /s. So glad I went self employed almost a decade ago.
Yeah. I’m the same. Im sure it’s to my detriment that I hate the hoop jumping rat race nature of the modern workplace, but I think opting out has led to greater happiness.
I just know I would absolutely hate competing over positions and titles. The real beneficiaries of this are the owners of the businesses who make up these meaningless distinctions in order to get everyone grinding their lives away for shiny baubles.
This is what a union does. Lots of folks like these structures.
These mid-size and larger companies offer defined pay, bonus, perks, expectations, and many other predictable attributes. This structure is of a high value to folks who prize stability, to take care of things like their family.
It really does suck. In some ways they say that you just have to be doing x, y and z but it ends up being so vague and fuzzy that it's frustrating. They end up just saying "well you have done that, but not enough times or for long enough (with no specific details about those criteria)."
I think it works out fine for people with a good manager who for whatever reason thinks your style is good. But if they aren't good or don't quite care about you then you'll eat shit forever.
They end up just saying "well you have done that, but not enough times or for long enough (with no specific details about those criteria)."
Is they the internal decision makers or the HR/recruiters gatekeepers who kvetch about the 'talent shortage' in software engineering? Am I out of line here for feeling like that line could easily come from either group?
Asking as a guy who was rejected by a recruiting agency for my current job, and only got hired later on after discovering by complete and utter coincidence a friend (well, more of an acquaintance, a regular at my neighborhood pub) worked on the team, referred me to his boss who was absolutely delighted with my experience and qualifications, was a near instant-hire.
Sometimes I wonder (quite negatively and cynically) about the agency hiring model.
I mean, once you hit a certain salary more money doesn’t even appreciably increase your quality of life. And I think most good software engineers are already close to that asymptote
This has not been my experience. I can easily see ways to substantially increase my quality of life at $1 million per year, and at $10 million per year, neither of which I'm close to (unless my lottery tickets, I mean options, pay off).
Ignoring early retirement, consider that those salaries come with less free time, less brain cells to do what you like, and more stress.
A lot of the value you can gain from money (e.g. hiring a maid to clean & cook, buying better quality food) is about clawing back what you lost to get the extra money.
In the US maybe, but definitely not in most of Europe. Software engineers are not as valued here as they are in some parts of the US (SF bay area, Seattle, etc.). As a result, salaries here are pretty miserable.
I'm a very senior developer in my 30s who lives in Sweden. I have a "good salary" (make the same or more than every other dev that I know in my age bracket), which translates to a take-home pay of around 45k USD.
Sure, health care is free, education is free (no college fund for my kids) and employer-paid-for pension plans are quite decent, but housing is not cheap (450k USD for a simple 4 bed room family home, luckily I don't live in Stockholm where that costs an additional 200-300k USD) and we also pay 25% VAT on almost everything.
30 days paid vacation (not PTO) per year is pretty sweet and so is the lack of overtime (40 hours is 40 hours) and the parental leave (at home with your kids for a year as a father? no problem!). But man, these salaries that I see quoted here on HN regularly (200-300k) do sting a bit...
The grass is always greener. Earning those salaries usually means you're in the bay area, where the median home price is 1.5m USD and you most definitely won't get that 4th bedroom.
Not true of all of Europe. Irish salaries go as high as twice that for similar seniority.
Cost of living isn't lower, especially in Dublin, our healthcare system is a slightly worse, college isn't totally free (3k/year or so), and pensions less generous.
On balance though, you'd still be better off working here.
If you live in a major city in the US outside of the west coast or NYC where both the salary and the cost of living are lower, software developer salaries from my experience range from $60-$90 on the low end to $140-$155K on the high end. That for team leads, architects, principal developers or even low level managers.
You’re going to top out as a developer after about a decade if you’re semi aggressive. The only way I found to make the next jump is true consultancy (not staff augmentation).
I was more putting scale into perspective comparing the rest of the country to Silicon Valley. A 10-20% variance is believable. But still nowhere near SV/ west coast total comp.
Ok, person because of whom Sr Staff at Box was created :). There was a need for promo and I did not meet the bar for Principle ( have to be recognized in industry: books, conferences). So Sr Staff was born. I never did what is written in the article, just worked on systems (spending 80% of my time on coding related activities: design, code reviews but mostly emitting code). Pretty the same I did in most companies. Even being manager in one company I spent 50% of time coding (it is complicated as I built team around such principles , so very small “management “ activities were required).
I am really bad on interview so join each company (probably 7 now) with low level. Also, never asked about promo. Also, self taught and not a hardcore developer (it is not like i love and breath in code outside of work, it takes sometimes long hours to make it work). But almost always get to nearly top levels (top is impossible, English is super crappy and as I said, not a coding prodigy).
Being “senior staff” in many companies I found that two traits are important for “senior” developers :
1.sense of problem: where the most important problem is now. There is no real most important problem, all problems are not that important unless you are doctor/military/rescue and save lives. So it is a special skill to find one that will be foundation for changes, spark eyes of people around and will be accepted.
2. “lead by example “ , be hands dirty in all your decisions. A lot of things are good on paper but reality shows that changes are needed. The reality forces to have enough knowledge (chat with experts, books, reading others code) before making decisions and later finding that no two situations are the same. Being inside makes it is easy to fix.
I read the article once and thought, "So at Box a senior staff SWE is differentiated from a senior SWE by mentoring others, and in so doing, has a greater impact. And senior staff is still in the technical track, not the management track. What does the author (or, What do HN commentators) think are the differences between mentoring and managing? Other than the obvious of course."
I read it again--I liked the article--and saw that the article talks about too many kinds of staff-level contributions, including kinds of mentorship, for my question to be relevant.
I'm still interested enough to pose: I had thought elevation of the technical track to "equal" the management track was a response to technical employees "needing" to go-into-management-and-deal-with-people in order to advance their careers. So now it would seem to me that the technical track is absorbing some of the functions of the management track. That's assuming that mentoring is related to managing.
“We expect each person promoted to Senior SWE to have largely demonstrated competence in all areas (in our case, Technical Skills, Leadership, and Culture and Values) and to have met the bar in all areas, making the required skill set of all Senior SWEs fairly similar.”
The leadership and culture markers are _wildly_ subjective. I’m willing to bet managers are still paid more and still carry more favoritism and power and climbing the tech track ranks is very difficult.
Mentoring is providing technical guidance, the same as writing code and design documents. It's just a little more personal than other kinds of guidance. Managing includes things like:
* Interminable day-long budget meetings.
* Fighting with the recruiting department and other teams to get new hires.
* Mediating personnel issues, such as "I'm not considered senior and I think I should be" or "We're at loggerheads and can't reach consensus on this decision".
There's of course some wiggle room here, and a lot of people at the first leadership rung do end up with a kind of hybrid role. But by the next level up, management track people are generally spending 100% of their time on these kinds of things.
All of these level requirements are tacked on by the HR department because they are required for advancement in non-technical roles. Unfortunately they really foul up personal dynamics as some people believe they need to 'mentor' their colleagues in order to fulfill the responsibilities of their job title... how fucking condescending is that?
This seems like a really uncharitable view of mentorship.
I have never felt condescended to when I was being mentored by someone with more skills or experience in any of my jobs, and I certainly hope that the people I help through one on ones, code review, and pairing now don’t feel as though there’s any condescension in it. I think mostly, we all just want to become as good as we can be at our jobs.
If everyone wants to become as good as they can at their jobs then why call out mentoring as a special activity? People should already be helping their colleagues perform better at their jobs without incentivizing it as a checkbox for career advancement.
This sounds like an argument against rubrics or ladder requirements in general, not a particular problem with mentorship as a requirement.
If you want employees to mentor others, call it out as a thing to encourage. If you don't do that, people will be less inclined to do it, instead focusing on raw technical impact or whatever.
Why call out writing good code as a requirement for advancement if everyone should do it anyway? Well, not everyone values the same things. Making values explicit isn't bad.
I'd say my vision of an ideal technical career parallels an ideal academic career: the Juniors learn, grads do grunt work (but sometimes that's the most interesting stuff), post-docs do their own projects and lead small teams, and finally, professors get to pass on their knowledge all while contributing their valuable expertise to many different projects of their grads and post-docs. In this scenario, the difference between a post-doc and a professor is the difference between a senior SWE and a senior staff SWE.
The sad reality of both tracks, however, is that admin work eats your creative time more and more as you progress along your career path.
Where this has been implemented well, the limitation is essentially C-suite level, because those are the highest level and inherently management positions, however it's common for something along the lines of Principle/Fellow/Distinguished engineers (terminology differs) to be equivalent to the step down from C level. That said, while these roles don't include management, they may end up being mostly outreach rather than the individual contributions to the company codebase that a senior engineer might be doing.
I've never seen an organization both credibly claim that their tracks had equivalent benefits (e.g. similar compensation), and also have comparable leveling requirements for both tracks. The bar for going up the management track is always lower.
The difference at some companies is so stark that they sometimes feel the need to justify it with statements like "the title of fellow is reserved for truly world class engineers with a lifetime of achievement and wide-reaching industry acclaim" when no such requirement exists anywhere up the management ladder, including (and sometimes especially) in the C-suite.
Management is essentially gaslighting you into thinking that you're not as valuable as they are unless you're Linus Torvalds. That's a level at which any comparison is obviously laughable, but the break-even point is usually far lower than this, and the organization wants to do everything it can to keep you from figuring that out. The majority of highly paid managers at large companies simply don't provide much value compared to a reasonably productive engineer. The concept of an "equivalent technical track" is a bone they throw at you so that you don't rage quit.
So looking at this strictly as a numbers game, you're almost always worse off on the technical track. That doesn't mean you should go into management -- I just think it's important to know the true costs when making this sort of choice.
Fair point. I guess maybe it diverges at the point where need diverges?
All companies need managers of some sort, and at the size we're talking about all companies will need a hierarchy of managers. Not all companies need a "Distinguished Engineer".
I think this is still an aspect that can be done better. If the top level of management (before C-suite, not in reporting chain) is some sort of mentor status, I'm not a fan of the term but an "Agile coach", or some sort of expert like that, maybe that's a better equal to the Principle Engineer – still fairly optional, very high level, etc.
They're parallel in theory and get paid the same, but if you look at the ratio of high-level managers to high level ICs, climbing the management ladder is clearly easier.
Working for mostly smaller companies, titles haven’t really meant anything. My influence came mostly from using the other two levers in the organization - building relationships and building a reputation.
I have a lot more influence over the technical/infrastructure direction of the company I work for now as “just” a senior developer than I ever had at my last company where I was officially the Dev lead with dotted line reports.
There to get anything done I had to go through layers of red tape. Where I am now, I’ll use my own discretion on whether I should let the manager know or do everything in the Dev AWS Account (or create another account), do a proof of concept and let them know. Most of the time I either get the okay or a few tweaks or suggested.
And before I get the replies from the infrastructure gatekeepers. Yes, I’m qualified to make infrastructure decisions and I’ve been browbeaten enough across three jobs to know about compliance issues (HIPAA in our case) inside and out.
Compliance involves encryption at rest and in transit and with cloud providers making sure you only use HIPAA compliant services, getting BSA’s with external contractors, minimizing who is allowed access to data, etc.
It’s more complicated than this but this is a good overview.
I agree. I have only developed software for multinationals and did a stint of short term freelancing for same. Titles are important within orgs but don't really translate across them, in my opinion.
The follow-up blog she linked at the bottom is even better at describing the mindset of a technical leader, which will take you far in any organization no matter what your current title is.
The main supplier in the area I am working is a huge US company with many different divisions, including a software engineering one. I am working with more a couple of dozens people that have "Senior", "Staff", "Principal" and "Engineer" words in the title, in combinations of 2 or 3 of these words, but it totally makes no sense to me if I am looking at the expertise, effectiveness of their work and the influence/decision power they have: they are all skilled workers with fancy but meaningless titles.
sounds like the company is either crazy busy designing new breakthroughs in tech or there are so many (undocumented) skeletons in the closet that nobody who joined less than 5years ago can step without triggering a landmine.
68 comments
[ 4.3 ms ] story [ 129 ms ] threadIn any case, the job described does mesh well with what I see most "Senior Engineers" doing. So the article in general is a good idea of where long-term growth as an engineer will take you.
Indeed. I'm also curious about the change in identification over time.
> General staff: in the military, a group of officers that assists the commander of a division or larger unit by formulating and disseminating his policies, transmitting his orders, and overseeing their execution. Normally a general staff is organized along functional lines, with separate sections for administration, intelligence, operations, training, logistics, and other categories.[1]
[1] https://www.britannica.com/topic/general-staff
When used properly, it should refer to someone who supports front line roles.
The ratio of Staff to Line in IT is generally 7:1.
The OP cites spending ~50% of her time on creating scrum tasks; very much a staff function.
That does not mean half her time is spent making tickets. This could be code writing, code reviews, testing, meetings, agendas, designing or ideating new systems or improvements, and, also, making tickets.
There is a condescension to this thing where people say “hey, that’s ok too” when it’s actually not ok for themselves. I can accept that, it is what it is, but it’s definitely there.
- always fun to be around (a consequence of not being overloaded)
- the guy to say "the emperor has no clothes" (having time to look around does that)
- always accurate with his estimates (because he really doesn't want to work overtime)
- always high-quality with his output (because he's not rushed)
Done right, working at 80% speed means that you have 20% of your time to pick up the super-high-value tasks that might otherwise fall by the wayside.
Now, maybe he'll get promoted more slowly than his potential as a striver, but I don't actually think that's going to happen.
Just as a personal anecdote everyone told me constantly that I would never make Staff Engineer at Google (roughly the 90th percentile rank) by just contributing to the code base. But that is what I did, and I was promoted to that rank. And I got the satisfaction of not participating in all the anti patterns of “leadership “ where one person gets promoted for taking credit for the work of many other people, or for solving problems they also created, etc.
In short I rather admire a trade like dentistry or carpentry where one just practices one’s skills to the best of their ability, and there is no such thing as “Senior Staff Dentist”.
So the Senior Staff position may involve less day-to-day coding/design, but a lot more heading off disaster, which I would argue adds huge value to the company, and personally I find satisfying. In fact, there is nothing less satisfying than failing to head off a disaster that you could see coming from miles away.
I remember a very senior IC at one company I worked at, named Gary. Gary basically wandered from meeting-to-meeting, only attending a few minutes because his calendar was routinely triple-booked. He would listen to a few minutes of argumentation, ask the one question that would slice the problem open like a sharp machete to a coconut, and then move on to the next meeting. Didn't design much any more, but his contributions had huge leverage.
Don't write off that some day you may want to be a Gary. It may come naturally at some point, when you frequently start thinking: "I've seen this movie before and it has a baaaad ending."
It’s ok if the company ends up doing something it shouldn’t have. That is just what happens. When I was younger, I spent a lot of energy fretting about such things; people didn’t listen to me. I learned to make peace with that, rather than vow to have my opinions heard. Besides, who is to say that I wouldn’t have just steered the ship into a different iceberg.
I’m one of those crazy people who thinks unlimited vacation is a good idea and not a scam, done correctly of course.
I suppose you’re right that I could magically change my mind one day. Hasn’t happened yet, 15 years in.
I make sure I work somewhere that isn't too stressful, and pace myself as much as possible at the dayjob so I can work 20+ hours per week on my own business.
I wish I could have a 3-day workweek so the other 4 days I could be coding my own projects. After $100k why do people even want more money? I just want more time to work on my projects for a chance to have my own business. I'll never understand why so many people choose to be put into golden handcuffs.
You can have the nice house in the burbs, max out your 401K, enjoy decent date nights with your SO every pay period, save for vacations, pay other people to do stuff you don’t want to do (occasional meal prep, yard service, etc), and have enough left for the things that go bump in the night. Realistically, for all the “ands” it takes about $150K to $200K of household income. That’s without getting the biggest house, the nicest cars and the most expensive vacations.
Also, I see “having my own business” and “having a less stressful life” as being the opposite of each other.
I don’t have to worry about finding customers, budgets, marketing, and I have st least six weeks a year paid time off between vacation time and holidays.
If the company disappears tomorrow I get another job.
I just know I would absolutely hate competing over positions and titles. The real beneficiaries of this are the owners of the businesses who make up these meaningless distinctions in order to get everyone grinding their lives away for shiny baubles.
These mid-size and larger companies offer defined pay, bonus, perks, expectations, and many other predictable attributes. This structure is of a high value to folks who prize stability, to take care of things like their family.
I think it works out fine for people with a good manager who for whatever reason thinks your style is good. But if they aren't good or don't quite care about you then you'll eat shit forever.
Is they the internal decision makers or the HR/recruiters gatekeepers who kvetch about the 'talent shortage' in software engineering? Am I out of line here for feeling like that line could easily come from either group?
Asking as a guy who was rejected by a recruiting agency for my current job, and only got hired later on after discovering by complete and utter coincidence a friend (well, more of an acquaintance, a regular at my neighborhood pub) worked on the team, referred me to his boss who was absolutely delighted with my experience and qualifications, was a near instant-hire.
Sometimes I wonder (quite negatively and cynically) about the agency hiring model.
A track with 6-7 difficult rungs and +10% pay increase? nah, I'm good.
Not for my definitions of quality of life!
A lot of the value you can gain from money (e.g. hiring a maid to clean & cook, buying better quality food) is about clawing back what you lost to get the extra money.
I'm a very senior developer in my 30s who lives in Sweden. I have a "good salary" (make the same or more than every other dev that I know in my age bracket), which translates to a take-home pay of around 45k USD.
Sure, health care is free, education is free (no college fund for my kids) and employer-paid-for pension plans are quite decent, but housing is not cheap (450k USD for a simple 4 bed room family home, luckily I don't live in Stockholm where that costs an additional 200-300k USD) and we also pay 25% VAT on almost everything.
30 days paid vacation (not PTO) per year is pretty sweet and so is the lack of overtime (40 hours is 40 hours) and the parental leave (at home with your kids for a year as a father? no problem!). But man, these salaries that I see quoted here on HN regularly (200-300k) do sting a bit...
Cost of living isn't lower, especially in Dublin, our healthcare system is a slightly worse, college isn't totally free (3k/year or so), and pensions less generous.
On balance though, you'd still be better off working here.
You’re going to top out as a developer after about a decade if you’re semi aggressive. The only way I found to make the next jump is true consultancy (not staff augmentation).
(No longer with Box btw)
I read it again--I liked the article--and saw that the article talks about too many kinds of staff-level contributions, including kinds of mentorship, for my question to be relevant.
I'm still interested enough to pose: I had thought elevation of the technical track to "equal" the management track was a response to technical employees "needing" to go-into-management-and-deal-with-people in order to advance their careers. So now it would seem to me that the technical track is absorbing some of the functions of the management track. That's assuming that mentoring is related to managing.
The leadership and culture markers are _wildly_ subjective. I’m willing to bet managers are still paid more and still carry more favoritism and power and climbing the tech track ranks is very difficult.
* Interminable day-long budget meetings.
* Fighting with the recruiting department and other teams to get new hires.
* Mediating personnel issues, such as "I'm not considered senior and I think I should be" or "We're at loggerheads and can't reach consensus on this decision".
There's of course some wiggle room here, and a lot of people at the first leadership rung do end up with a kind of hybrid role. But by the next level up, management track people are generally spending 100% of their time on these kinds of things.
I have never felt condescended to when I was being mentored by someone with more skills or experience in any of my jobs, and I certainly hope that the people I help through one on ones, code review, and pairing now don’t feel as though there’s any condescension in it. I think mostly, we all just want to become as good as we can be at our jobs.
Because plenty of people won't do it naturally; teaching people things isn't always fun (or alternatively is less fun than coding).
If you want employees to mentor others, call it out as a thing to encourage. If you don't do that, people will be less inclined to do it, instead focusing on raw technical impact or whatever.
Why call out writing good code as a requirement for advancement if everyone should do it anyway? Well, not everyone values the same things. Making values explicit isn't bad.
The sad reality of both tracks, however, is that admin work eats your creative time more and more as you progress along your career path.
Had she gone into management after 5 years, how would the compensation, promotion opportunities, or job opportunities have differed?
I see many people go into management because they think it's the only way to continue to grow a career.
The difference at some companies is so stark that they sometimes feel the need to justify it with statements like "the title of fellow is reserved for truly world class engineers with a lifetime of achievement and wide-reaching industry acclaim" when no such requirement exists anywhere up the management ladder, including (and sometimes especially) in the C-suite.
Management is essentially gaslighting you into thinking that you're not as valuable as they are unless you're Linus Torvalds. That's a level at which any comparison is obviously laughable, but the break-even point is usually far lower than this, and the organization wants to do everything it can to keep you from figuring that out. The majority of highly paid managers at large companies simply don't provide much value compared to a reasonably productive engineer. The concept of an "equivalent technical track" is a bone they throw at you so that you don't rage quit.
So looking at this strictly as a numbers game, you're almost always worse off on the technical track. That doesn't mean you should go into management -- I just think it's important to know the true costs when making this sort of choice.
All companies need managers of some sort, and at the size we're talking about all companies will need a hierarchy of managers. Not all companies need a "Distinguished Engineer".
I think this is still an aspect that can be done better. If the top level of management (before C-suite, not in reporting chain) is some sort of mentor status, I'm not a fan of the term but an "Agile coach", or some sort of expert like that, maybe that's a better equal to the Principle Engineer – still fairly optional, very high level, etc.
I have a lot more influence over the technical/infrastructure direction of the company I work for now as “just” a senior developer than I ever had at my last company where I was officially the Dev lead with dotted line reports.
There to get anything done I had to go through layers of red tape. Where I am now, I’ll use my own discretion on whether I should let the manager know or do everything in the Dev AWS Account (or create another account), do a proof of concept and let them know. Most of the time I either get the okay or a few tweaks or suggested.
And before I get the replies from the infrastructure gatekeepers. Yes, I’m qualified to make infrastructure decisions and I’ve been browbeaten enough across three jobs to know about compliance issues (HIPAA in our case) inside and out.
It’s more complicated than this but this is a good overview.
https://www.hipaajournal.com/hipaa-compliance-checklist/