Being Glue (2019)(noidea.dog)
noidea.dog
Being Glue (2019)
https://noidea.dog/glue
16 comments
> 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.
Careful here. A lot of small startups have an element of "my company, my way" from the founders (for good reasons, at times) and thinking you will "drive alignment" maybe be a recipe for frustration and burnout.
Careful here. A lot of small startups have an element of "my company, my way" from the founders (for good reasons, at times) and thinking you will "drive alignment" maybe be a recipe for frustration and burnout.
Very true
"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.
Related:
Being Glue - https://news.ycombinator.com/item?id=25120504 - Nov 2020 (43 comments)
Being Glue - https://news.ycombinator.com/item?id=19846720 - May 2019 (42 comments)
Being Glue - https://news.ycombinator.com/item?id=25120504 - Nov 2020 (43 comments)
Being Glue - https://news.ycombinator.com/item?id=19846720 - May 2019 (42 comments)
kinda crazy, i was looking for a previous discussion on this article just last night.
https://hn.algolia.com/ is a great way to find discussion on articles. You can usually just paste the URL and they show up.
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."
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.
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.
> 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
This is the whole problem. You can have the technical chops to back up your project management work but if you have not "demonstrated" them then it's as though they don't exist.
It's relatively difficult to "demonstrate" your skills the way people want them to be demonstrated in a corporate environment unless you have a very supportive manager who helps you write your promo packet and goes in to bat for you.
This is the whole problem. You can have the technical chops to back up your project management work but if you have not "demonstrated" them then it's as though they don't exist.
It's relatively difficult to "demonstrate" your skills the way people want them to be demonstrated in a corporate environment unless you have a very supportive manager who helps you write your promo packet and goes in to bat for you.
On the contrary, once upper management realise that your projects are succeeding because you’re doing all the mysterious ‘other stuff’ that nobody else on the team even knows needs doing, you can never be promoted. They want those projects to succeed, after all.
I remember one client saying to me something like "So and so does a lot of X, and such and such is really churning out Y. What exactly would you say your focus is in this project?" At the time I gave a very unsatisfactory answer, but looking back, a lot of what I was doing was glue work and working across the stack. This looks like a great resource to help me next time I have trouble articulating such things.
I haven't not seen someone be promoted because they are writing such good code despite being a poor communicator. Glue people get promoted
Really good presentation and article!
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.