During @shwetaneelsharma’s masterclass webinar: How To Build a Thriving QA/Testing Team With People-First Leadership, Jesper Ottosen (@jesper) asked:
Can you elaborate on the glue work you did originally that led you to the leadership path?
Will be interesting to hear more about the things we’ve all done to set ourselves up for jumping on the leadership path.
What “glue work” did you do that led you to a leadership path?
This doesn’t quite answer the question but I can share some glue work that has helped me as a leader and also (I think?) help me be seen as a leader before I had any sort of formal job title:
One thing I took from @shwetaneelsharma 's masterclass was:
if you are doing glue work to improve team interaction and help stuck people, you are already leading. Even if it’s not in your formal title.
Being glue originally came from Tanya Reilly’s Being Glue — No Idea Blog where she shared how glue work was often overlooked. I’m glad it has a more positive connotation as a path to leadership.
The opportunity is often to say “I could do that” of a work task within leadership. Stand in for your manager or lead once in a while - perhaps during their vacation/absence.
I love how Irina Stanescu frames it on LinkedIn: became a Tech Lead first in my head, and later in reality.
Consider checking out @jesper’s book.
Leading Testing Activities [ A Guidebook for New Leaders of Testing ]
Once upon a time, our protagonist set out on a quest to lead a testing activity. While they searched and searched across the world, they found no clear map to guide their quest. And there, my friend, is where this story begins.
At the time of writing, it’s in progress at “32% complete”.
Some great suggestions here, that anyone can do.
Sometimes people just need a nudge! I especially like connecting people who have similar (work) interests, because not only will they make a connection - but it prevents the awkward moment when they both present a complete solution to the same problem!
Interesting phrase, “glue work”, never came across it thus far!
As for my part, I was always the one buggering managers / leads / coworkers with a ton of questions and suggestions on how to do this and improve that. Usually nobody is even aware of the possibilities, or they don’t care.
Jira software is perfect example of that. Most people just use what they are given but are quick to b***h about how ineffective it is, manual work they need to do when doing their tasks etc. Even Jira admins were ineffective and unmotivated so instead of doing their job they rather gave me Jira admin rights too 
So I started exploring the possibilities and that ultimately led to myriad of small improvements but each helped to relieve few minutes of team member’s time each day.
I am also mostly the only weirdo taking meeting notes, updating documentation when it’s needed, updating task descriptions when new info comes out etc.
Upon re-reading her comment, basically all that @deament said in her post as well. Usually there would be a lot of so-called “knowledge silos” - each team knows something that the other team does not, and each team kind of “assumes” what other team knows, but they’re not sure. So when let’s say Team A needs knowledge that only Team B has, often times communication either fails or is ineffective so Team A usually does the unnecessary groundwork of acquiring that knowledge themselves. This is utterly pointless so I always strive to break down those knowledge silos by putting people together, syncing us together and trying to ask such questions that both teams understand and can connect to (aka finding the common grounds).
Hope someone understand what I tried to say, wrote it in a single breath ^^
The best kinda weirdos! Good on you for note taking and updating documentation. And bringing teams together via knowledge sharing. 