[scarface_74]

As a former “architect” and now a “staff” engineer who is pulled in a million directions, I purposefully don’t pull any stories off the board or assign myself to any work in the critical path of getting something to production. Either I will miss my commitments or working extra hours when everyone else is off of work to get time to do “deep work”.

I will do “glue work” that’s important. But not urgent that I can squeeze in between my other obligations without blocking anyone.

I need to make sure I am “working at my level”. But I don’t need to constantly be worried about promotions.

[ta_1138]

That's why the riskiest moment in an engineer's career is the jump up from senior: The things that get you a strong senior review and the things that get you promoted to architect/principal/staff are completely different. You can end up in a situation where you've done a little too much glue, but not good enough to claim you were doing architect work, while that time meant you did less than expected of a senior doing heads down work. Try to do this with a bad manager, and you are heading for a Pip.

Which gets us back to the most important rule of a software engineer's career: make sure that the person writing your reviews really likes you.

[scarface_74]

Why is Senior to staff such a step change for a software engineer in a product company/department?

To be honest, before 2020 aa a software engineer, I spent my entire career working in unknown companies with no real leveling guidelines.

I fell into my only role in BigTech as an L5 (mid level) cloud application architect at AWS Professional Services in 2020 and now a Staff Software Architect (5th and highest IC) at a smaller consulting company.

The leveling guidelines for a “staff” where I am now are about the same as a “Senior” at AWS ProServe or a similar position at GCP

That being said, the leveling guidelines at AWS for my department were straightforward

- L4 junior - expected to be able to complete tasks/storues with little guidance

- L5 mid level - expected to be able to complete work streams and lead a work stream where the business requirements are well defined. But the technical requirements aren’t and you work with the customer to complete the requirements. You were expected to be a subject matter expert in one or more verticals.

- Senior - more ambiguous - neither the business or technical requirements are well defined and you have to work with the customer to discover the business problems/opportunities, define strategies and then plan an implementation and coordinate multiple work streams with the project manager, customer, etc. They could also be over multiple projects.

- staff - over multiple seniors, usually a team lead and they deal with strategies over a practice (https://aws.amazon.com/professional-services/)

I’ve had one offer as a staff engineer for a product company (as oppose to a consulting company) at the company that acquired the startup I worked at before going to AWS. I would have been over strategy for all of the acquired companies.

I ended up turning it down. I understood the requirements of operating at that level in cloud consulting. But not product development. The technical requirements didn’t bother me as much as the organizational requirements.

[darth_avocado]

I agree with this so much. Too less Glue work for staff+ will get you “Not performing at a Staff level PIP. Do too much Glue Work, you’re suddenly get compared to Senior productivity. You’re on a fast track to PIP unless your manager and your skip likes you. Because doing just the right amount of Glue Work is impossible because the standards are subjective.

[scarface_74]

I would rather get an anal probe with a cactus than ever go back to BigTech or any large company.

I’m 50 and I just don’t have the shit tolerance to put up with the politics.

I know what my responsibilities and expectations are as a “staff” and as long as my clients (cloud consulting) are happy and the projects I’m leading are done, on time, on budget and meets requirements, everyone is happy.

There is a clear dollar amount assigned to my work and downstream revenue.

[dhosek]

I think at the staff level, the key is to focus on multiplying the efforts of the team at the expense of your own individual productivity.

[darth_avocado]

That will get you PIP at half the companies

[scarface_74]

That’s literally your job as spelled out in the leveling guidelines. Doing any sort of coding or work that can be delegated to a mid level or senior developer is specifically considered “working below your level”