I don't think there's a single easy definition of "Staff Engineer" and it's usually just a title. But it might be still good to think about why those folks keep talking about this specific title.
From my observation, there is a certain inflection point in a senior level engineer's career where their expectation rapidly grows in that no one can realistically match it alone. The quality of your work will saturate and it's physically impossible to "work harder". Some extraordinary engineers could delay that point a bit but they will be eventually there.
At the moment, they will need to figure out a consistent, reproducible way to scale their contribution. If they want further career progression. The most direct way is becoming an engineering manager. Someone may develop a technical and organizational skill to influence high level decisions and prioritization. Or just become an engineering genius...
There are many other possible ways to achieve this, but the point is that further contribution at this point usually needs a radically different way. I do see that many companies tend to grant a title of "Staff Engineer" to those folks able to figure out how to handle this situation.
> There are many other possible ways to achieve this, but the point is that further contribution at this point usually needs a radically different way. I do see that many companies tend to grant a title of "Staff Engineer" to those folks able to figure out how to handle this situation.
In my own experience it's also entirely common for your comp and responsibilities to grow and grow until your working peers are all directors, VPs, and heads of this or that and you're meant to act as their API layer to an entire team of humans executing on your technical direction, but your title is just Senior Engineer.
Internally everyone understands this and treats you accordingly, but it sure looks bad on linkedin.
My experience is those are generally technically immature organizations. Everyone knows that "John" is consulted across departments and pulled in by senior leaders, that he's guiding the technical of multiple teams ands areas of the business. But management can't quite explain what it is so they give John more money and his title remains unchanged.
It’s possible to assign further ranks to subdivide titles appropriately.
e.g. The most important senior engineer, with an equivalent rank just one level below the CTO, would be the ‘First rank X Engineer’, then the next level below would be the ‘Second rank X Engineer’, and so on…
There are usually tech industry levels above senior like staff, principal, distinguished engineer. I think the OP's problem is they didn't get a title increase.
I have long encouraged engineers reporting to me to view the transition to Staff Engineer as not a promotion but a role change similar to the change of transitioning into being an engineering manager.
I think that what you said is only true in the same way "there's no single definition of a manager" is true.
Staff Engineers live on the critical path of implementation and directly contribute to their execution.
i think the idea here is that a staff engineer should be identifying what needs to be done, figures out how to do it, works to push the team and project in that direction, and provides insight to the org as to how it is going
In my view it's the responsibility of engineering management is to create alignment on what needs to be built, when, and how. You call your shot and then you have to hit it.
Managers need a lot of information to create this alignment, to set correct goals, and to allocate resources effectively.
The first part of a Staff Engineers job is to help provide that information. That might be through prototyping software to inform what is possible or the tradeoffs of taking different approaches. That might be through having an in depth knowledge of technical constraints, historical decision making, and business domain that the manager can query. That might be through seeing patterns with bugs or inefficiencies on the team and surfacing them. That might be through staying abreast of larger industry trends and thinking about how they apply to your team's software.
It's ultimately about removing unknowns so the manager can negotiate effectively on the teams behalf when setting goals and create a plan that will be successful to achieve those goals.
The second part of a Staff Engineers job is to help make sure those goals are met. That might be through solving complex issues when they arise in development. That might be through directly contributing code to projects that are behind because effort was underestimated. That might be through building frameworks to make the whole team more productive. That might be indirectly through setting an example for other team members to follow or consciously influencing team culture. That might be through picking up responsibilities for an overworked manager like coordinating between different teams or helping the team organize tasks. That might be teaching and up-leveling team members. That might be through providing a second set of eyes from a different perspective to the manager about how the work is going.
Unlike line engineers who are evaluated on if they completed the work assigned to them at a satisfactory level, Staff Engineers like managers are evaluated on if the team shipped the agreed upon software on time or not. But the levers they have to pull to achieve those results are different.
At least that's my take on the role and why I think it's not the path everyone should pursue.
I feel like the job and the skillset required to do it well are sufficiently different for it to be a different path that you need to consciously decide you want to go down.
I feel like once you reach Senior Software Engineer, you can stay there forever. There is no longer an automatic 'next' level you're trying to get prompted to.
> I have long encouraged engineers reporting to me to view the transition to Staff Engineer as not a promotion but a role change similar to the change of transitioning into being an engineering manager.
Does this imply that becoming a manager is also "not a promotion" in your organization?
At the risk of being obtuse, depends on what your definition of “promotion” is…
I’d classify the dimensions as:
- Compensation - obvious one. May vary by org
- Authority - are you officially allowed to give orders? Hire and fire?
- Respect and influence- in your org, do people specifically want EMs to be active in areas ICs are not, like strategy, etc. varies widely.
- Alignment with personal Career goals - some people hate management-type duties - so for them, this EM title change would be “not a promotion” to them
I’d say EM is a promotion in some of those ways and it varies a lot by org for sure.
There is also the alternative to accept, like companies exponential growth doesn't last forever, and maybe one should be happy where they are instead of pursuing growth paths that will ultimately make them unhappy while getting more money they cannot ever spend, every day thinking why go to the office.
Personally, I am happy to die as IC, having tasted management related roles.
I'm 19 years into my development career. I've been promoted to some sort of manager position twice. Currently, I'm 7 years into a management role. I don't hate every minute of it; but I sorely miss every minute I'm not coding.
I don't personally agree with the idea that senior is basically the end point of writing high level code. Perhaps it's just a difference in terms but I think of seniors at the high end of their capacity as being able to release high quality features. But if I needed a whole new app greenfielded, would I trust a senior to not only get the job done, but execute at a high level, with a clear vision, clean design system, beautiful code base, all the right choices of libraries, following all the best practices, linting, style, etc? Of course not.
To me, a staff engineer can deliver that application at that level, and can lead senior engineers in maintaining and enhancing it.
We also consider a level above that, the principal engineer, who is primarily focused on higher level and longer term thinking and less about individually jumping into tickets and features. They re-envision the entire approach to implementing the business logic and scale the business in ways that seniors are mostly helpless at. They do work through others much more, and I do personally see Staff Engineer as the highest level where you primarily are still coding day to day.
IMHO greenfield vs new features vs maintenance/tuning/scaling are different skill sets, not level dependent per se. Plenty of junior engineers can spin up a reasonable greenfield app, and plenty of staff/principal engineers never have had to.
The way I look at it is that levels only make sense within an organization that is big enough that a hierarchy is needed to scale. At that point staff+ IC levels are needed because you want purely technical people on the same pay scale and influence level as managers to counteract the incentives of empire building that can corrupt the entire architecture and lead to a Dead Sea effect of engineering talent if left unchecked.
From this perspective most staff+ work is in some way generating influence and impact across multiple teams and individuals. Outside of certain specialties and specific R&D roles I think it’s pretty hard to justify staff leveling on purely technical work.
Of course different companies calibrate levels differently, and they’re all subject to level inflation, but that’s my feeling for a traditional Google L6.
In my opinion, there is absolutely no way a junior / SWE1 could greenfield an app by doing anything other than following a youtube tutorial or similar step by step guide, and would have basically no understanding of the decisions made throughout. They would have no real experience with style, linting, no good opinion on libraries, no knowledge of accessibility, security, usability, nothing. They would end up with a basic 'hello world' application that would likely fall apart before you could even get your business logic in there.
If you have a SWE1 that can literally just greenfield an entire application and do it at a very high level, then they are a unicorn / 10X developer operating at a ~SDE4 level already.
I personally do not think the average SDE1 can meaningfully contribute to a quickly moving and efficient team. By the time they are even able to contribute regularly, they are SWE2/mid in my book.
I do have much less experience in giant beaurocratic slow moving organizations so I don't have an opinion on how all of that rigmarole works, I'm speaking more to highly focused small teams delivering at a high level quickly.
Sure, someone that is an entry level programmer will not have deep technical knowledge, that's not what I was trying to say though. My point is that levels only make sense in organizations that are big enough that tech leadership can't directly assess and compare ICs work because there's too much going on for any one technical expert to assess. Smaller organizations sometimes cargo cult leveling systems because it helps their ICs resumes and give a sense of progression even though the organizational problems that are the raison d'etre for staff+ levels don't exist at that scale.
To say it a different way: consider hobbyist developers who have spent a lot of time developing technical skills. These folks will tend to be very good at creating greenfield apps, and depending what they do, they may also have technical chops that are applicable to large companies as well. So they may be able to be hired as L4 or L5 (Google leveling) just based on technical chops. L6+ will be tough though, unless they have very deep specialist knowledge, because the most common L6+ work is about using technical knowledge to achieve outcomes that depend on navigating multiple teams and stakeholders in a way that the solo dev never has to deal with.
I concur. It was a eye opening experience to move into management and staff/prin levels after research. The focus was very much more on "doing through others" rather than "doing yourself". For me this felt unnatural. If someone had warned me prior, I'm not sure I'd have made this jump. I'm happily now doing direct RnD again.
For me if your a principal and you're only doing through others your either not looking at it right or doing it wrong. For basically everything I do, I ask myself the question: is this something that I should be doing directly, or something that other people should be doing, or something I should coach people up on doing train them, or build an organization around or whatever. In many cases I will build an organization and it will take 5 to 10 times longer than if I did it myself. But it keeps going for years after I move on to something else, as opposed to stopping the instant I stopped working on it.
What I say to a ton of mentees as they mature into staff/pe, is the important thing is to always figure out what is the highest leverage thing you could be doing. if it's coding, code. if it's writing a doc to explain to other people why other people should be coding, write a doc. if it is slowly nursing junior engineers through a multi-year arc that you could do in a week, maybe that's what you need to do tho I'm seconding guessing that one. But you definitely shouldn't be hanging up the keyboard as a tech ic.
Also as of this week at 9 years at a company, I have now shipped code in almost every language the company uses, and on all but: salesforce, an actual prod sagemaker model (all local prototypes), jira workflows, and SAP.
I remember learning back at the beginning of my career that at places like Bell Labs and IBM, everybody who was anybody had the title "Member, Technical Staff" which was designed to be a low key humblebrag with the uniformity designed to quell egotistical agitation/competition for more and better titles.
Then everybody who didn't work at those places wanted that title too.
In banking, the title is "Vice President". It means virtually nothing, there are hundreds of them in every bank, a reason I heard was "otherwise nobody will take your calls." Many people in their 20s who go to business school to get their MBA have already been VPs at banks.
There is a method behind this madness (... or rather title inflation). This webpage explains it pretty well (it is a bit tongue in cheek but it is Friday).
There’s a whole hierarchy of Assistant, Associate, Deputy Commissioners. Is it better to be a Special Assistant to the Associate Commissioner, or the Assistant Deputy Commissioner?
>I remember learning back at the beginning of my career that at places like Bell Labs and IBM, everybody who was anybody had the title "Member, Technical Staff" which was designed to be a low key humblebrag
Ha! I learned that when I was quitting a senior engineer job (around 2000) and my manager said if I they'd make me a "member of (the) technical staff".
Since I had never heard of such a title before (I would have been the first MTS at that company) my response was roughly "(a) aren't I part of the technical staff already? And (b) you're "offering" to strip my "senior" title? And my "engineer" title? WTF? I'm quitting already, you didn't have to be insulting about it"
The confusion was cleared up, eventually, but that conversation definitely didn't go the way my manager expected it to (and I still quit - no regrets).
Honestly, I still don't think the MTS/Staff Eng. labels make any sense. My last few & current employers use "principal eng." for the same job function, which just seems so much clearer.
When I started work, "Staff" in any title meant entry level. "Senior" was a higher grade title, but still mostly an IC position. Above that were various managment/lead titles where you actually had people reporting to you.
I only encountered it relatively recently, and I also thought it meant you were a entry level engineer. What they are using it for resembles "Software Architect" that was used at my past jobs. I know that the old perception of the "software architect" is someone who doesn't touch code, but by the time I started working, agile kind of turned those into individual contributors for better or worse.
You're not wrong. A Staff Engineer might manage people, but if that were their main desired focus, they probably would have the title Engineering Manager instead.
Not sure but I believe it’s possible you may have read the parent comment unintentionally in the inverse? I might be wrong but I believe you posited their desired focus is to manage people from parent comment, but I actually think it’s opposite. They don’t want to manage people (especially career wise), instead they want to manage and guide the work of teams and people across one or many teams.
My interpretation of it was to pursue the type of work and things you focus on as an Engineering Manager in terms of getting the most of out teams for the goals of the organization but doing so without the need to manage people directly. Which I would agree is nice since it’s really hard to wear the technical hat and also directly manage people, so separation of concerns makes for far less context switching and folks to naturally align doing the part of the job that they do best. I also agree with this definition since it’s how I think of it too.
I took the post you're replying to as to have interpreted the "doesn't want to be a manager or director" idea as that there are times others or a team may be foist upon them without such a people management role being the majority of the person's time during, say, a year.
I'd also add "team lead" to the list of possible titles that indicate a primary focus on people management vs. individual contribution.
> I took the post you're replying to as to have interpreted the "doesn't want to be a manager or director" idea as that there are times others or a team may be foist upon them without such a people management role being the majority of the person's time during, say, a year.
Yes, this. There may come a point in your career where your old manager is advancing and they need a new manager for your team. The position is offered to you, maybe repeatedly. It's clear that either you take it or you and your teammates will soon have a new manager who is fresh to the team or company. Maybe you've seen the latter go badly before. Maybe your outgoing manager expresses their own anxiety about that possibility. You finally get the hint and become a manager.
Now you can change from the engineering ladder to the management ladder, but you don't have to. You can be an Engineering Manager, commit all your time to this, and hope to advance to Engineering Director. Or you can stay a Staff (Software) Engineer and also manage a few people. With some help from say a good PM, you can be a good manager to a small team without giving up the technical aspects. (I assert part-time managers are actually better for small, high-performing teams; no idle time for micro management.)
> I'd also add "team lead" to the list of possible titles that indicate a primary focus on people management vs. individual contribution.
Maybe. At some companies (e.g. Google), a team's tech lead and manager can be two different people. If so, the tech lead doesn't have reports according to HR. At promo time, they don't do the manager reviews, although they likely put a fair bit of time into writing peer reviews and participate in the promo and calibration committees, so they're not entirely without what many smaller and/or more traditional companies would consider manager responsibilities.
> a team's tech lead and manager can be two different people
Yes, I've worked in an environment like that. I had a "functional manager" that took care of the HR side of things and a "team lead" that kind of led an effort for a specific project. They also interacted with each other about how things were going. I also agree that for small, high-performing teams it can be a very nice arrangement for everyone.
But my point was that the "team lead" role ends up requiring some amount of people management while not taking over as the primary focus for the person with that role, "no idle time for micro management" as you said. I may have been lazy with "a primary focus" as a construction because while I don't think it's >50% of time for a team lead in the structure I worked in or imagined in this discussion, I do think it can be around 20% for that person, depending on how they feel about people management, and the dynamics that exist between those involved, and the size of the team being led.
In companies I am familiar with, pay bands and total comp are roughly equivalent between:
senior engineer ≈ engineering team lead
staff engineer/tech lead ≈ engineering manager
principal engineer ≈ senior engineering manager
Reiterating that management is not a "promotion" from senior engineer, but a track switch.
That said, the maximum compensation ceiling is ultimately higher on the management track at director/vp level. Personally, no thanks, don't want that job. Staff+ IC is where it's at for me.
> Who makes more money, a "staff engineer" or an "engineering manager"?
I think engineering manager is the easier path to advancement. Compare for example Google Staff Software Engineer (L6) vs Engineering Manager (L6). [1, 2] The latter gets paid more but IMHO the ladder expectations are easier to meet, and even more so when advancing to L7.
This is admittedly cynical, but to some extent I think managers are often judged by the size of their empire, while engineers are judged by their (individual or team) accomplishments, which includes setting the overall project design and filling in gaps between the smaller pieces delegated to other engineers. Building a large empire is easier but can be counterproductive. To accomplish things you also need good design oversight, technical mentorship, etc. that managers aren't expected to deliver.
A lot of people who are passionate enough about software stay on the SWE ladder in spite of the relative difficulty. I know someone who switched to the management ladder then eventually (at great trouble) switched back; he nearly got down-leveled in the process.
There are great engineering managers out there of course, but I think in general the difference in expectations is real and unfortunate.
My belief is that while eng manager empire building was the easier path to get promoted before 2022, it's not anymore, for two main reasons:
1. HC doesn't accrue like that anymore.
2. Many organizations are looking to delayer; harder to promote up to director when your org went from 9 runs to 5.
I hear a lot of the focus going to Tech Lead Manager roles--fewer reports but more hand-on keyboard than EM roles of the past.
This just isn't correct. Along the entire career path from (just out of school) junior engineer to (industry famous) distinguished engineer, the biggest gap in job responsibilities is between the Sr. Eng and Staff/Principal Eng levels. Staff eng is not "more of the same".
It’s a title, nothing more. It means nothing, because there is no legal certification process for any of this. There is no guild of software engineers that puts requirements on what a staff engineer would need to be certified. There is no license you operate under that says you’re a staff engineer.
It’s just a title, if your work wants to call you a staff engineer, cool. But you should probably care more about pay and less about titles.
> It’s a title, nothing more. It means nothing, because there is no legal certification process for any of this.
I believe I understand where you are coming from. However, that's not entirely fair. Most jobs have "no legal certification process", but that doesn't make their job title meaningless. Not everyone who wants to define what a title means is doing so to gain or assign clout, many just want to understand what a person with that title typically does.
Granted, there are some titles (especially in technical roles, in some companies), that tell nothing more than "that person works in I. T." (or whatever your company calls it). For example, I've seen roles called "Systems Analyst", that varied greatly in responsibility -- some where all the person did was code all day, some where the person almost never wrote any code. Sometimes that was two people in the same group at the same company.
So yes, titles can hold only a very small amount of meaning, at times, but that doesn't make them entirely meaningless.
I always point these people to Hillel Wayne's Crossover Project [0]. His interviews with "real engineers" who switched over to software engineering (and vice versa) are very enlightening.
Also, watching Practical Engineering has had a huge impact on both my perception of "real engineering" and on my own work. He goes over a whole bunch of civil engineering topics and it's obvious that they're doing the same kind of work, just in a different domain, and with in most cases about as much due diligence as I have in my job. It's not a different universe, just a different neighborhood.
Some of us are both "real engineer"s (certified, legally protected, in Computer Science, etc, etc) and "staff engineer"s ;) But I'm definitely not looking to die on any hill.
I will always prefer the "developer" title, because I build things, I don't necessarily design them. I think there's a distinction and we should use it.
I never understood articles trying to put objective criteria on a system that’s as much a function of supply and demand as any inherent ability. Most companies have set percentages for titles and promotions, regardless of actual abilities.
I assume "staff engineer" parallels the concept of military staff [1], the people who serve directly under and advise the commanding officer.
So in theory a staff engineer has directly delegated authority/trust under the VP or whatever of a large engineering area.
And that reminds me of a quote from Rommel:
Men are basically smart or dumb and lazy or ambitious. The dumb and
ambitious ones are dangerous and I get rid of them. The dumb and lazy
ones I give mundane duties. The smart and ambitious ones I put on my
staff. The smart and lazy ones I make my commanders.
Yes, very much this, and the article misses this critical job responsibility that distinguishes the sr engineer from the staff engineer levels.
One of the responsibilities of a staff+ engineer is to be a high-judgement technical advisor to the leaders of large teams comprised of smaller teams. This role calls for high-level strategic thinking, talent development, as well as working with counterparts on peer teams to align the technical capabilities and strategies with the larger organization's objectives.
These articles always miss the core deliverable of a staff engineer.
Impact
The engineer who wrote the MVP of the product and grew it's customer base to hundreds of MM ARR -> staff.
The engineer who steers the ship for a 50 person org -> staff
The engineer working in a corner on a novel solution to the companies perf/accuracy/security challenges -> staff.
Everything that you do is in service of creating impact, but having a bunch of useless meetings or providing useless mentorship is exactly that - useless.
Leveling up other engineers through mentorship IS impactful. But I think you should have a roughly 1 level distance limit. Staff shouldn’t be mentoring junior engineers, they should be mentoring senior engineers.
An engineer who has been working some number of years, regardless of level of responsibility or skill, is a senior. If you've been working in the industry for 5 years and you're applying for junior positions then people are going to be really confused.
I expect seniors to deliver on smaller to medium projects without external help. If someone can’t do that they’re not senior and i don’t care if they have 2 or 20 yoe
From my cynical definition, it's a gate-kept level based on a senior engineer's actual sphere of influence within an organization. At any medium to large company, this role is usually the dividing line between someone who could be an EM, but doesn't want to be one, so instead given the same promotion (from HR's perspective) but get to remain in an IC role. "Leading without authority"
It's impossible to define in any generalized measurable way, because it's whatever the organization wants it to mean at that moment.
Usually, a staff engineer is hyper in-sync with the business needs and able to spot where the deficiencies are. They are also very diplomatic, great communicators, and people enjoy working with them. "Lifting you up, lifts me up."
This article feels a little bit pointless to me. ryandvm said it perfectly - a staff engineer is just what happens when you have a senior engineer who deserves a promotion, but wants to be a technical leader not a people leader. How that actually fits into the company varies heavily company to company, specifically size and maturity.
I feel like this article wants to talk about the performance matrix through the lens of four pillars, and just arbitrarily chose "staff" as the role to talk about since it's a very senior engineer.
A staff engineer is somebody who is providing enough value to the team that management has decided to give them a promotion and better pay to reduce the risk of them jumping ship.
Is this really true? There's usually quite the big difference for line manager vs director, Head of XXX where you operate on much bigger scope, plan budgets, etc.
For ICs it is true that many times "Staff Engineer" is basically the higher pay band for Senior Engineers. But many times from Staff+ you expect them to be able to lead projects or programs, act as an architect and advisor to management. In general bigger scope stuff than just being a specialist in a given technology.
I am not saying that the role of a senior engineer and a staff engineer is the same. I am saying that the primary --if not the only-- reason people get promoted is because management figures that the cost of paying them more is less than the risk of them leaving the team.
And, indeed, I believe that applies to every promotion up to something like the C-suite, where I have zero experience and can't comment.
Review: The article tries to define the staff+ role through the lens of 4 skills: technical, people, project, and product. The article then says that a Staff+ does all of them, both at architecture level and helping build up juniors in the team.
Finally it describes them as glue between different aspects of the company.
The article provides various blogs and a couple of books as reference for statements.
Now onto my opinion. The Staff that I've met in my life are more of the solitary type, the Individual Contributor class of person who have decades of experience in their expertise and supporting skills. Yes they may have the responsibility defining the work for others, but that mostly happens as an architect. They herd seniors not mentor juniors.
The article itself doesn't work hard enough to set the bar and explain to me why I should give the title to someone when in some companies these are just the responsibilities of a senior or at a stretch Principal.
With extremely rare exceptions, this has become position inflation for the sake of looking good when going to VCs.
Staff Engineer comes from the military. They are the advisors to the general. That means they have direct access to the highest office in an organization.
There are so many comments in this thread that amount to "it's just a fancy title". With respect, I think these comments (and also the original article) are missing the mark. Generally, the staff+ engineer role is accountable for the technical architecture and output of a large team over a long-term horizon.
How large a team? It varies but I'd say at least 25 and often much larger. How long a horizon? As far as the organization can plan. They generally report to someone with a title like Director or VP and advise that person and their staff (typically managers and other staff engineers) or do high-level technical work needed, like evaluating a new technology or system that the team wants to invest in or depend on.
The consequence of this is that the "day to day" of the role is highly variable based on what the org needs at the time. Sometimes it's hands-on development for tricky technical tasks, sometimes it's talent development, sometimes it's dealing with escalations or emergent issues.
I think this high degree of variability plus the fact that a lot of the "staff meeting" work is not visible to line engineers contributes to the confusion about the role.
From my observation, staff eng is a person that has the capability to handle many type of tasks, like what described in the article: Eng, Idea direction, project management, risk management, cross-function communication. Not every eng can grow into this role. Many engs hate politics, talking and meetings. I felt only the large tech organization needs this role. For the small companies, engineer manager who manages less than 4 engs usually do not need a staff eng.
> Eng, Idea direction, project management, risk management, cross-function communication.
I'd consider everything on here an important for senior engineers as well. (Just putting this in numbers, if a company engineering is ~40% senior engineers and ~10% staff or above, if all the things listed have to go through that 10%, that's a big bottleneck.)
I think that's called a wizard. Staff engineers are not allowed to cast spells themselves, they just help keep the wizard's staff in good order and troubleshoot technical issues.
From the manager’s side, when one of the engineers on my team was senior and looking towards staff, the way I would explain it was “staff engineers are leaders of their teams, in practice whether or not in title. So you have to understand what the company is trying to do, what the team is trying to do within the company, and how to help when the team isn’t succeeding or the company isn’t succeeding because of the team. The more team- and company-wide problems you’re able to effectively fix, the higher you’ll go.”
I liked the OP’s description of glue work because it matched my understanding of fixing problems. And I liked their discussion that glue work can’t be the only thing you do (I would argue that if it is, you haven’t actually fixed whatever problem created the glue work)
I’m a Staff Software Engineer and I don’t know what it is. This time last year my title was Analytics Architect Advisor. Before that I’ve had the Application and Solution architect titles. Between last year and now the company did one of those leveling exercises and wanted to match us with the industry. So now I’m a Staff Software Engineer. Almost feels like a demotion without my architect title, but I’m still paid the same.
I get what the author is saying, but I think they chose a way that's likely to be misunderstood.
A good >senior engineer:
- Understands the problem space
- Understands what the team has done
- Understands the value goal
- Has researched alternate approaches
- Finds and introduces the right people
- Guides the conversation productively
- Ensures everyone understands post-meeting
"The meeting" is a necessary but in no way solely sufficient component of that process. The staff engineer is providing value through all the other pieces.
tl;dr - Don't just schedule meetings: engineer productive exchanges.
100% agree, but I think the author was try to keep their description concise. I have worked with people who will readily schedule a meeting when an issue arises, but won't do the actual work to run that meeting, and it just ends up being a huge quagmire. Effective meetings require work to run, and someone needs to do it.
of that group of people who don't do the actual work to run the meeting, are an especially slippery group of people who don't intend to do any of the work that results from the meeting either; you can often identify them because the best of their breed will volunteer to handle communications with the bosses.
My take from this article: so basically, what separates a staff engineer from a freelancer or company owner is mainly uncertainty or risk adversity.
They must already have everything else it takes to succeed, since it's a requirement for the job. But the vision and drive to go in for themselves is not a requirement and if they don't have it, they will become a valued staff engineer.
I'm not sure I buy it, but that's how it comes across, since a staff engineer is supposed to be blessed with all these wonderful talents.
These kinds of discussions bother me because it always implies some kind of worthiness of the title. Maybe it’s just my work experience but I’ve found very little correlation with e.g. the success of an engineer’s career trajectory and the success of the projects they’re responsible for.
Going a little more off topic now but these discussions always leave me feeling a bit like how Richard Feynman describes his instinct to be repulsed by “honors” and everything like them:
I’ve held the staff engineer title some times and when the company did so my role was to be a sort of backup if some team could not solve something. When I was not allocated to a specific team I collaborated with other engineers on specs and higher level planning. We also worked on internal libraries and tools.
In my experience -- I'm a staff engineer -- it's basically a senior engineer in a technical leadership role, but not a manager. I spend 50% of my time working on code and providing technical direction for seniors. The rest of the time is spent in architecture and planning meetings. I don't do 1-on-1s. I don't do personnel reviews. My manager handles all of that.
A title companies give out like candy to retain engineers they don't want to leave. That's it. Naive people, and managers who want to manipulate you, and people who write books about being a staff engineer will tell you otherwise. Don't believe them. Same thing for any "senior" title.
From my observation, there is a certain inflection point in a senior level engineer's career where their expectation rapidly grows in that no one can realistically match it alone. The quality of your work will saturate and it's physically impossible to "work harder". Some extraordinary engineers could delay that point a bit but they will be eventually there.
At the moment, they will need to figure out a consistent, reproducible way to scale their contribution. If they want further career progression. The most direct way is becoming an engineering manager. Someone may develop a technical and organizational skill to influence high level decisions and prioritization. Or just become an engineering genius...
There are many other possible ways to achieve this, but the point is that further contribution at this point usually needs a radically different way. I do see that many companies tend to grant a title of "Staff Engineer" to those folks able to figure out how to handle this situation.
reply