[darth_avocado]

Glue work doesn’t get rewarded. That I agree with. However I don’t agree with the conclusion.

Do Glue Work for projects that you are leading, projects that you are accountable for. As a senior+ engineer that is all your projects. So should you prioritize glue work for all of them?

From my experience, there is a delicate balance. There’s Glue work that you need to get right every time, else risk getting fired. E.g. Technical specifications for your project. There’s glue work that you need to put on the back burner every time until it becomes a visible problem that management will appreciate you take care of. E.g tech debt, addressing strands that are getting dropped. Then there is glue work that you do to make your own life easier. E.g. Onboarding docs, demos etc.

[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”