8 ms·

Being Glue

187 points by monsieurpng 6y ago

anonytrary 6y ago
They are not talking about writing "glue code" (misleading title perhaps). They are talking about engineering management and senior responsibilities: > You'd like to have time to code, but nobody else is onboarding the junior engineers, updating the roadmap, talking to the users, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction... If this describes you, congratulations: you're the glue. Edit: Looks like the title was changed to "Being Glue" which is probably a better title.
- app4soft 6y ago
  > They are not talking about writing "glue code" (misleading title perhaps). They are talking about engineering management and senior responsibilities > > ... If this describes you, congratulations: you're the glue. > Edit: Looks like the title was changed to "Being Glue" which is probably a better title. This what I though first just after sew previous title for this HN thread! And "being glue" is mostly my way in contributing to opensource projects which I'm involved in ;) FTR, As a background, I have master's degree in PM.
mikewarot 6y ago
I like the point she makes at the end... if you don't know how to do the glue work, communicating effectively, onboarding others, etc... you're not well rounded... and shouldn't be promoted until you learn those skills as well.
- ozim 6y ago
  That is funny thing, where people think that someone will come over and "promote them to senior". Reality is when you do "glue work" more and more you become senior and only then you should be promoted to reflect reality.
  - CaptArmchair 6y ago
    I think the term "glue work" somewhat hides the importance of building strong professional relationships and being able to develop as a human within your peer group. That ability, though, hinges entirely on the affordances provided by an equitable social context. That is: mutual respect, acceptance, understanding, open mindedness and so on. In that regard, the earning the title "senior" isn't just a reflection of your own maturity, who is awarded that title is just as much a reflection of workplace culture, it's values and the available opportunities.
Twirrim 6y ago
It's only really in the last year, maybe two, that I've become comfortable with this being my role. I'm a jack of all trades, so I fill in the gaps within my team. About as much of my job is about ensuring everyone else on the team is able to be their most productive, as it is applying my skills and experience to a project of my own. Sometimes that means working with engineers in my team directly on stuff, or acting as a sounding board. Other times that's getting involved in certain meetings to be able to present a more detailed technical response, and potentially head things off at the pass. As I've learned to take a step back from things, I can see just how much my influence has effect within the group. I do still love getting my hands dirty, I love solving problems. I've no intention of ever stepping away from that kind of work. I don't really have to, either, even with the seniority.
helltone 6y ago
I am someone who enjoys/excels at being a "glue", I'm not quite an engineering manager yet but I don't write tons of code anymore either. I have been struggling to find a job. Every job I see is either entry level individual contributor or senior manager. Where do I find companies that value and seek glue/leads?
- BossingAround 6y ago
  I don't know about job ads you've seen, but senior manager is often a dream/wish of companies who'll hire the first person that won't make them facepalm during the interviews after 6 months of not finding the right senior. > Where do I find companies that value and seek glue/leads? I think most companies value such work; it's just important to find the language they use. For example, in my BU, we have agile scrum masters. They are doing essentially the same work as technical project managers in my previous BU from the same company. I'd just advise reading the ad language and deciding whether that's "glue you like" or not...
- deleted 6y ago
  [deleted]
- trevyn 6y ago
  Get in the door as IC and then gradually and informally be social, ask to be in meetings, and do "free" glue work. If you're good at it and it's valued, over a few months you'll naturally be spending more time on that and slowly be assigned fewer and fewer IC tasks, after which you'll have a conversation with your manager about which direction you'd like to take, and then you're defacto glue even if that's not your job title. (I'm sure you could get a job title change if you wanted, but SWE may be a slightly higher pay scale than TPM. ;) N.B. this advice is really for "normal" times; if you're remote it may be harder or easier to do the social part necessary, I have no idea.
metaphor 6y ago
Video of the talk: https://www.youtube.com/watch?v=KClAPipnKqw https://www.youtube.com/watch?v=KClAPipnKqw
2rsf 6y ago
I like the term glue, I am a senior tester but a lot of my work is around just that- gluing things together, although sometimes it is more about un-sticking things. I enjoy the large variety in my day to day work, it helps me build a large network of people and until now it made me a more essential and valued employee
- hnick 6y ago
  I'm more of a coder (and highly prefer adhoc/throwaway POC coding) but slipped into the same thing. By being someone who fixes the annoying problems I've bumped into useful people in various departments which helps bring things together when I need to. Of course, they now have processes to avoid favours and such so we all have to go through the same internal ticketing and scheduling system and it's completely random whether you will get someone useful and helpful or not. You don't even see a name on the reply most times. I knew an older guy who retired a few years ago and he also called himself glue at the time. He'd long abandoned coding (he secretly admitted to me that he could do a bit, but publicly claimed ignorance) but had a good handle on what the company could do and who was doing it, which helped him talk to the right people to design feasible solutions for customers.
red_admiral 6y ago
Great talk - I have a feeling she'd get on well with rachelbythebay, whose blog has a lot of posts on the same theme. The sad fact in some places is that as a woman, your choices for skirt length are "too prude" or "too slutty", and your choices for the amount of glue work you do are "not technical enough" or "not a team player". Some of these places then act really really surprised when their women leave - sometimes leave the field entirely. My humble contribution of the day for managers, if you've tried everything else and your equality metrics are still not going up: 1. Who is the glue keeping your team together? 2. Promote them. (Not move them into management, promote them to your equivalent of senior engineer.)
- BossingAround 6y ago
  > Promote them. (Not move them into management, promote them to your equivalent of senior engineer.) I think this is controversial. If you have a software engineer being promoted to senior software engineer (1 -> 2) without at least intermediate knowledge of the codebase, that'll make other seniors suspicious/wary. Personally speaking, if you hire a software engineer that does mainly/only glue work, you mis-hired. What you meant to hire was a technical project manager. Move that person to a TPM if they want to (and are great at what they do) instead of having a senior software engineer who hasn't really shipped anything noteworthy.
  - red_admiral 6y ago
    I can see your point, but it depends on how technical their glue work is, if you like. In the post, she mentions for example: > The manager has a bunch of teams and is starting to rely on Engineer to know what's going on with this one. Hey, Awesome Coder seems blocked. Do you know what the deal is? > > Our Engineer investigates, discovers that Awesome Coder needs information from another team but is mired in a three week long email thread. She talks to some people in real life, figures out what the confusion is, sorts it out. Awesome Coder is unblocked. He says thank you, writes thousands of lines of code. This sounds to me like she knows exactly what's going on in the relevant part of the codebase to be able to get the information to unblock Awesome Coder. > A customer comes in with a request: they want data that the API really should be able to provide but the team hasn't prioritised this feature yet. Our friend here spends a couple of days manually getting the data the customer needs. The customer is overjoyed. Again, it looks like she's perfectly fine writing productive code when you let her. I've worked with several great people in the past who exactly fit the description of "glue person" - although most of them were male - and I found that mostly, while the Awesome Coder types had an excellent understanding of their own part of the code, the glue people were the only ones who really understood how things worked together. So you got someone in team A saying why not replace libX with libY because it makes our Z easier, and the glue person speaks up and says actually I worked with someone on Team B last week, and they're using feature W of libX. Tanya herself admits that "is this person a Senior Engineer" is controversial. But I'd say that someone who is glue in a way that clearly demonstrates a deep technical understanding of the codebase should qualify, even if that understanding is not demonstrated by writing her own code.
ch33zer 6y ago
This is accurate, not for me but for another person on my team. He struggled for years to get promoted because of a perceived lack of focus from upper management. In reality he was handling a big part of the TL's job and several other people's job. The happy part of the story is that he got promoted a few months ago.
inertiatic 6y ago
First, I don't get why diversity is given passing mention when there's nothing related specific to diversity or gender politics in the solid idea discussed by the article. I also tend to value this sort of work and I aspire to be this sort of person, but it's easy to see how a company would end up incentivizing their engineers to create more stuff. Creating stuff gives glue types their chance to optimize the small stuff. Meanwhile, it's genuinely harder to find someone who can rise to the occasion of high technical output after doing a good glue job, than it is someone who does great technical work and can also be this sort of glue person. Someone who does a lot of high impact technical work can identify bottlenecks and could very well do the same work as the glue person. The opposite isn't always true. It's also much harder to figure out if someone is just very nice and doing work that would be picked up by someone else in their absence or if they are indeed identifying pain points no one else could.
- BossingAround 6y ago
  > First, I don't get why diversity is given passing mention when there's nothing related specific to diversity or gender politics in the solid idea discussed by the article. If you can get promoted for many things in multiple ways, that means diverse promotion system, which means you'll get more diverse seniors and more diverse leadership. If your goal is to have a wide range of skilled people from various backgrounds in senior places, relaxing rules around promotions is definitely a way to get closer to that goal. If you have a strict promotion criteria, you might end up promoting very similar people. An extreme example: Only people from Ivy League schools can get to senior and above. Consequence: you'll end up with very heterogeneous leadership 5-10 years of such a policy (most likely even leadership that formed friendships while in university).
- DominikD 6y ago
  > First, I don't get why diversity is given passing mention when there's nothing related specific to diversity or gender politics in the solid idea discussed by the article. It links to the paper describing how non-promotable work is divided between genders in a mixed setting. This is clearly a diversity problem. If women take the bulk of work that won't get them promoted, you end up with women underrepresented in senior positions. Did you read the article?
tambeb 6y ago
My dog's name is Dotcom and I bought him the domain dotcom.dog. So, naturally I immediately concluded your link was going to be about a dog as well. Before clicking I even convinced myself that 'noidea' was most definitely your dog's cool and funky name.
- deleted 6y ago
  [deleted]
tareqak 6y ago
This post might as well be describing me to the point that I feel both happy and sad. It feels so “wrong” to me to not share knowledge that I know can help someone else on my team immediately to the point that it becomes difficult to do what I am supposed to do. I don’t know what I should do. Is there a book or a video that I can learn from? Maybe a mentor? Or, am I stuck being glue?
fooblat 6y ago
On my team, this glue work is the responsibility of the Product Owner. Essentially, it is the PO's responsibility to ensure that everyone on the squad knows what to do and how they should be doing it. If not, the PO calls a meeting and brings the right people together until a consensus is found. Having a full time PO on each squad lets the PO take up any work that isn't coding, but is blocking squad progress.
codingdave 6y ago
This role is often referred to as "Product Owner". If you have a senior engineer doing the work described in this article, then they have stepped into a Product Owner role. The only real problem with that is when it is done accidentally. If they want to continue to code and advance their technical career, this isn't the right move. If they want to move out of coding and into leadership, this is a good move. Either way, deliberately acknowledging that they are now a PO will help focus their efforts, as there is a wealth of information online about doing that role well.
- rubidium 6y ago
  I agree. Having flexible but well understood roles is key for good team management. This seems to be lacking in many orgs. Product Manager: responsible for technical and commercial product-market fit. Getting Voice of Customer. Understanding market size. Setting pricing. Electrical/hardware/software Engineer: technical producer of the code/hardware/etc.... unit that is used in the product. Systems Engineer: responsible for ensuring requirements of the project and product are met, tested, and giving confidence to the business that they have tested product, that will meet the user needs, will work in the environment where the product is used, and is ready for production. Product Owner: Ultimate decider for product features in real-time. Ensures during development that the right product is being built, everyone knows what should be known. Core team lead/ Project Manager: the person enabling the project to proceed. Manages business, timeline, requesting headcount, enabling critical path to move forward, etc... Engineering Manager: responsible for hiring and training engineers, ensuring engineers have appropriate workloads, ensuring engineers have desired career development. Depending on the size of the team and project, people may wear more than one hat. In many software shops they usually just split out Product Manager, People Manager, and Software Engineer. Thus the "glue" pieces are those roles missing above.
thrower123 6y ago
This appears to a failure of the product management staff, who are either incompetent, inadequate, or nonexistent.

187 points by monsieurpng 6y ago

They are not talking about writing "glue code" (misleading title perhaps). They are talking about engineering management and senior responsibilities: > You'd like to have time to code, but nobody else is onboarding the junior engineers, updating the roadmap, talking to the users, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction... If this describes you, congratulations: you're the glue. Edit: Looks like the title was changed to "Being Glue" which is probably a better title.

app4soft 6y ago
> They are not talking about writing "glue code" (misleading title perhaps). They are talking about engineering management and senior responsibilities > > ... If this describes you, congratulations: you're the glue. > Edit: Looks like the title was changed to "Being Glue" which is probably a better title. This what I though first just after sew previous title for this HN thread! And "being glue" is mostly my way in contributing to opensource projects which I'm involved in ;) FTR, As a background, I have master's degree in PM.

mikewarot 6y ago

I like the point she makes at the end... if you don't know how to do the glue work, communicating effectively, onboarding others, etc... you're not well rounded... and shouldn't be promoted until you learn those skills as well.

ozim 6y ago
That is funny thing, where people think that someone will come over and "promote them to senior". Reality is when you do "glue work" more and more you become senior and only then you should be promoted to reflect reality.
- CaptArmchair 6y ago
  I think the term "glue work" somewhat hides the importance of building strong professional relationships and being able to develop as a human within your peer group. That ability, though, hinges entirely on the affordances provided by an equitable social context. That is: mutual respect, acceptance, understanding, open mindedness and so on. In that regard, the earning the title "senior" isn't just a reflection of your own maturity, who is awarded that title is just as much a reflection of workplace culture, it's values and the available opportunities.

Twirrim 6y ago

It's only really in the last year, maybe two, that I've become comfortable with this being my role. I'm a jack of all trades, so I fill in the gaps within my team. About as much of my job is about ensuring everyone else on the team is able to be their most productive, as it is applying my skills and experience to a project of my own. Sometimes that means working with engineers in my team directly on stuff, or acting as a sounding board. Other times that's getting involved in certain meetings to be able to present a more detailed technical response, and potentially head things off at the pass. As I've learned to take a step back from things, I can see just how much my influence has effect within the group. I do still love getting my hands dirty, I love solving problems. I've no intention of ever stepping away from that kind of work. I don't really have to, either, even with the seniority.

helltone 6y ago

I am someone who enjoys/excels at being a "glue", I'm not quite an engineering manager yet but I don't write tons of code anymore either. I have been struggling to find a job. Every job I see is either entry level individual contributor or senior manager. Where do I find companies that value and seek glue/leads?

BossingAround 6y ago
I don't know about job ads you've seen, but senior manager is often a dream/wish of companies who'll hire the first person that won't make them facepalm during the interviews after 6 months of not finding the right senior. > Where do I find companies that value and seek glue/leads? I think most companies value such work; it's just important to find the language they use. For example, in my BU, we have agile scrum masters. They are doing essentially the same work as technical project managers in my previous BU from the same company. I'd just advise reading the ad language and deciding whether that's "glue you like" or not...
deleted 6y ago
[deleted]
trevyn 6y ago
Get in the door as IC and then gradually and informally be social, ask to be in meetings, and do "free" glue work. If you're good at it and it's valued, over a few months you'll naturally be spending more time on that and slowly be assigned fewer and fewer IC tasks, after which you'll have a conversation with your manager about which direction you'd like to take, and then you're defacto glue even if that's not your job title. (I'm sure you could get a job title change if you wanted, but SWE may be a slightly higher pay scale than TPM. ;) N.B. this advice is really for "normal" times; if you're remote it may be harder or easier to do the social part necessary, I have no idea.

metaphor 6y ago

Video of the talk: https://www.youtube.com/watch?v=KClAPipnKqw https://www.youtube.com/watch?v=KClAPipnKqw

2rsf 6y ago

I like the term glue, I am a senior tester but a lot of my work is around just that- gluing things together, although sometimes it is more about un-sticking things. I enjoy the large variety in my day to day work, it helps me build a large network of people and until now it made me a more essential and valued employee

hnick 6y ago
I'm more of a coder (and highly prefer adhoc/throwaway POC coding) but slipped into the same thing. By being someone who fixes the annoying problems I've bumped into useful people in various departments which helps bring things together when I need to. Of course, they now have processes to avoid favours and such so we all have to go through the same internal ticketing and scheduling system and it's completely random whether you will get someone useful and helpful or not. You don't even see a name on the reply most times. I knew an older guy who retired a few years ago and he also called himself glue at the time. He'd long abandoned coding (he secretly admitted to me that he could do a bit, but publicly claimed ignorance) but had a good handle on what the company could do and who was doing it, which helped him talk to the right people to design feasible solutions for customers.

red_admiral 6y ago

Great talk - I have a feeling she'd get on well with rachelbythebay, whose blog has a lot of posts on the same theme. The sad fact in some places is that as a woman, your choices for skirt length are "too prude" or "too slutty", and your choices for the amount of glue work you do are "not technical enough" or "not a team player". Some of these places then act really really surprised when their women leave - sometimes leave the field entirely. My humble contribution of the day for managers, if you've tried everything else and your equality metrics are still not going up: 1. Who is the glue keeping your team together? 2. Promote them. (Not move them into management, promote them to your equivalent of senior engineer.)

BossingAround 6y ago
> Promote them. (Not move them into management, promote them to your equivalent of senior engineer.) I think this is controversial. If you have a software engineer being promoted to senior software engineer (1 -> 2) without at least intermediate knowledge of the codebase, that'll make other seniors suspicious/wary. Personally speaking, if you hire a software engineer that does mainly/only glue work, you mis-hired. What you meant to hire was a technical project manager. Move that person to a TPM if they want to (and are great at what they do) instead of having a senior software engineer who hasn't really shipped anything noteworthy.
- red_admiral 6y ago
  I can see your point, but it depends on how technical their glue work is, if you like. In the post, she mentions for example: > The manager has a bunch of teams and is starting to rely on Engineer to know what's going on with this one. Hey, Awesome Coder seems blocked. Do you know what the deal is? > > Our Engineer investigates, discovers that Awesome Coder needs information from another team but is mired in a three week long email thread. She talks to some people in real life, figures out what the confusion is, sorts it out. Awesome Coder is unblocked. He says thank you, writes thousands of lines of code. This sounds to me like she knows exactly what's going on in the relevant part of the codebase to be able to get the information to unblock Awesome Coder. > A customer comes in with a request: they want data that the API really should be able to provide but the team hasn't prioritised this feature yet. Our friend here spends a couple of days manually getting the data the customer needs. The customer is overjoyed. Again, it looks like she's perfectly fine writing productive code when you let her. I've worked with several great people in the past who exactly fit the description of "glue person" - although most of them were male - and I found that mostly, while the Awesome Coder types had an excellent understanding of their own part of the code, the glue people were the only ones who really understood how things worked together. So you got someone in team A saying why not replace libX with libY because it makes our Z easier, and the glue person speaks up and says actually I worked with someone on Team B last week, and they're using feature W of libX. Tanya herself admits that "is this person a Senior Engineer" is controversial. But I'd say that someone who is glue in a way that clearly demonstrates a deep technical understanding of the codebase should qualify, even if that understanding is not demonstrated by writing her own code.

ch33zer 6y ago

This is accurate, not for me but for another person on my team. He struggled for years to get promoted because of a perceived lack of focus from upper management. In reality he was handling a big part of the TL's job and several other people's job. The happy part of the story is that he got promoted a few months ago.

inertiatic 6y ago

First, I don't get why diversity is given passing mention when there's nothing related specific to diversity or gender politics in the solid idea discussed by the article. I also tend to value this sort of work and I aspire to be this sort of person, but it's easy to see how a company would end up incentivizing their engineers to create more stuff. Creating stuff gives glue types their chance to optimize the small stuff. Meanwhile, it's genuinely harder to find someone who can rise to the occasion of high technical output after doing a good glue job, than it is someone who does great technical work and can also be this sort of glue person. Someone who does a lot of high impact technical work can identify bottlenecks and could very well do the same work as the glue person. The opposite isn't always true. It's also much harder to figure out if someone is just very nice and doing work that would be picked up by someone else in their absence or if they are indeed identifying pain points no one else could.

BossingAround 6y ago
> First, I don't get why diversity is given passing mention when there's nothing related specific to diversity or gender politics in the solid idea discussed by the article. If you can get promoted for many things in multiple ways, that means diverse promotion system, which means you'll get more diverse seniors and more diverse leadership. If your goal is to have a wide range of skilled people from various backgrounds in senior places, relaxing rules around promotions is definitely a way to get closer to that goal. If you have a strict promotion criteria, you might end up promoting very similar people. An extreme example: Only people from Ivy League schools can get to senior and above. Consequence: you'll end up with very heterogeneous leadership 5-10 years of such a policy (most likely even leadership that formed friendships while in university).
DominikD 6y ago
> First, I don't get why diversity is given passing mention when there's nothing related specific to diversity or gender politics in the solid idea discussed by the article. It links to the paper describing how non-promotable work is divided between genders in a mixed setting. This is clearly a diversity problem. If women take the bulk of work that won't get them promoted, you end up with women underrepresented in senior positions. Did you read the article?

tambeb 6y ago

My dog's name is Dotcom and I bought him the domain dotcom.dog. So, naturally I immediately concluded your link was going to be about a dog as well. Before clicking I even convinced myself that 'noidea' was most definitely your dog's cool and funky name.

deleted 6y ago
[deleted]

tareqak 6y ago

This post might as well be describing me to the point that I feel both happy and sad. It feels so “wrong” to me to not share knowledge that I know can help someone else on my team immediately to the point that it becomes difficult to do what I am supposed to do. I don’t know what I should do. Is there a book or a video that I can learn from? Maybe a mentor? Or, am I stuck being glue?

fooblat 6y ago

On my team, this glue work is the responsibility of the Product Owner. Essentially, it is the PO's responsibility to ensure that everyone on the squad knows what to do and how they should be doing it. If not, the PO calls a meeting and brings the right people together until a consensus is found. Having a full time PO on each squad lets the PO take up any work that isn't coding, but is blocking squad progress.

codingdave 6y ago

This role is often referred to as "Product Owner". If you have a senior engineer doing the work described in this article, then they have stepped into a Product Owner role. The only real problem with that is when it is done accidentally. If they want to continue to code and advance their technical career, this isn't the right move. If they want to move out of coding and into leadership, this is a good move. Either way, deliberately acknowledging that they are now a PO will help focus their efforts, as there is a wealth of information online about doing that role well.

rubidium 6y ago
I agree. Having flexible but well understood roles is key for good team management. This seems to be lacking in many orgs. Product Manager: responsible for technical and commercial product-market fit. Getting Voice of Customer. Understanding market size. Setting pricing. Electrical/hardware/software Engineer: technical producer of the code/hardware/etc.... unit that is used in the product. Systems Engineer: responsible for ensuring requirements of the project and product are met, tested, and giving confidence to the business that they have tested product, that will meet the user needs, will work in the environment where the product is used, and is ready for production. Product Owner: Ultimate decider for product features in real-time. Ensures during development that the right product is being built, everyone knows what should be known. Core team lead/ Project Manager: the person enabling the project to proceed. Manages business, timeline, requesting headcount, enabling critical path to move forward, etc... Engineering Manager: responsible for hiring and training engineers, ensuring engineers have appropriate workloads, ensuring engineers have desired career development. Depending on the size of the team and project, people may wear more than one hat. In many software shops they usually just split out Product Manager, People Manager, and Software Engineer. Thus the "glue" pieces are those roles missing above.

thrower123 6y ago

This appears to a failure of the product management staff, who are either incompetent, inadequate, or nonexistent.