Being Glue originated as a comment on an internal Google Plus post when I worked at el Goog. I’d used the expression “glue work” in passing, and someone asked what I meant by it. The reply became a standalone post and then an internal document (which as far as I know is still being circulated). A couple of years later, I proposed it as a talk for Write/Speak/Code NYC. I’d left Google by then and wasn’t even sure it would resonate with folks in other companies. Apparently it did :-)

Slides are on Slideshare (or embedded here —> ).

I’m giving this talk at a bunch of other places. Check out the talks page, or mail me if you want it at a meetup or company near you.

Athenahealth invited me to give the talk at their office and the video is on YouTube.

Abstract: Your job title says "software engineer", but you seem to spend most of your time in meetings. You'd like to have time for code, but nobody else is unblocking the junior engineers, maintaining the relationship with your sister team in the other office, updating the roadmap, talking to teams whose projects overlap with yours, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction. If you stop doing those things, the team will function less well. But now someone's suggesting that 'you might be happier in a less technical role'.

'Glue' work often lands on the only woman on the team, and it needs to be framed carefully. If you display this kind of leadership early in your career, there's a real risk of being seen as 'not technical enough' and getting pushed into a career path that wasn't your first choice. If you'd like to be a senior engineer, being good with humans does not close that door. If you'd prefer to do something else, you should choose your path deliberately.
Here’s a talk about how to get you recognised as the technical leader that you are.