Being Glue (2019)

"The Staff Engineer’s Path" which the author wrote is a decent book. It covers all the things I don't like about working on software development (or being a SWE) and that's exactly why it's worth a read.

Some great points in the article. I think gaining recognition for acting in your team's best interests and long term efficiency is even harder in bigger companies (like Squarespace in this article). People won't understand why you're committing to such endeavours as an IC, even if you're past the senior level.

There are now more and more cross functional roles that would better fit this sort of skillset, for example technical programme management or product operations.

I also think any good lead or engineering manager should know how to "be more glue". If it becomes a vocation and you don't feel like stopping (or if no one who's in control at your company feels like rewarding you for it), it's maybe time to start looking elsewhere. I feel like the people I've seen embodying these skills are more likely to take on lead roles.

Moving to a startup could also help as you'd be able to drive alignment quicker with these skills and still get to dive in more technical tasks.

Imagine, your company has hired you as an engineer to design software systems & write code. Your performance at the company is measured by your ability to design software systems & write code. You've decided to take on the job of a project manager instead and not write code. Your contributions might be valuable, but why would you get promoted as an engineer?

You say this, but the role of staff+ engineers often is being a project manager. Not all the time, but at least sometimes.

The difference in responsibilities between levels is somewhat to blame for this. If you are at a particular level doing this kind of project management work is what looks good on a promo packet, because it's cross-functional and you're leading a bunch of people, etc. But if you're not at that level people think you're bad at your role.

E.g. imagine a mid level engineer doing this work vs a staff engineer.

Great article that explores this more and even references the posted article: https://apenwarr.ca/log/20201227.

"People in group #2 weren't supposed to exist. They were doing some hard jobs - translating business problems into designs - with great expertise, but these accomplishments weren't interesting to the junior-level promotion committees, who had been trained to look for "exactly one level up" attributes like deep technical knowledge in one or two specific areas, a history of rapid and numerous bug fixes, small independent launches, and so on. Meanwhile, their peers who couldn't (yet) architect their way out of a paper bag rose more quickly through the early ranks, because they wrote reams of code fast.

Tanya Reilly has an excellent talk (and transcribed slides) called Being Glue that perfectly captures this effect. In her words: "Glue work is expected when you're senior... and risky when you're not."

...

People who are naturally excellent at glue work often stall out early in the prescribed engineering pipeline, even when they'd be great in later stages (staff engineers, directors, and executives) that traditional engineers struggle at. In fact, it's well documented that an executive in a tech company requires almost a totally different skill set than a programmer, and rising through the ranks doesn't prepare you for that job at all. Many big tech companies hire executives from outside the company, and sometimes even from outside their own industry, for that reason."

Sure, some amount of project management type work is expected when you're an engineer at a higher level (senior, staff, principal, etc). However, that's not the entire role. Before you reach those levels you should have a deep technical knowledge of how to write code and design systems.

If you don't have those fundamental skills, then you're not going to make a good engineer at higher levels.

If you do have those fundamental skills, but have never demonstrated them because you're too busy doing project management work, then why would anyone believe that you have those skills? Demonstrate them somehow.

If you want a role where project management type tasks are the whole role, then become a PM.