Q&A

Avoiding the 'Being Glue' Trap: Recognizing and Rebalancing Non-Promotable Work

• By David Ramel
• 12/10/2025

Editor's note: We have received word this session has been canceled. As the article has already been disseminated in newsletters and social media posts, we haven't removed it because of all the 404s that would result. We apologize for the inconvenience.

Every development team has that one person who always steps up to coordinate the launch, update the documentation, schedule the meetings, and chase down cross-team approvals. These are the unsung efforts that keep projects running smoothly -- but they're also the kind of work that often goes unnoticed when it comes to career advancement.

This phenomenon, known as "glue work," was coined by Tanya Reilly and refers to the essential, yet often non-promotable, tasks that hold teams and projects together. While these responsibilities are crucial to organizational success, they can quietly sideline a developer's technical growth and delay career progression -- especially if not managed with intention.

In an upcoming session titled How I Sidestepped "Being Glue" at the Visual Studio Live! Las Vegas developer conference in March, senior software engineer Fatima Taj will unpack this common dynamic and share personal lessons learned from nearly getting stuck in the glue trap. Through candid storytelling and practical strategies, Taj's talk will help attendees recognize when glue work is quietly taking over, and how to rebalance workloads in a way that supports both team health and individual advancement.

Whether you're a senior engineer who's become the go-to problem solver or a junior developer feeling pigeonholed by coordination duties, this session will offer tools for navigating glue work without derailing your growth trajectory.

We caught up with Taj ahead of the event to hear more about her journey, the warning signs to watch for, and what engineers -- and their teams -- can do to ensure glue work becomes a shared strength rather than a hidden setback.

VisualStudioMagazine: What inspired you to present on this topic?
Taj: I kind of stumbled into this topic the hard way -- by realizing I was getting stuck in the trap of "being glue."

I was working on a big "break up the monolith" migration. The rollout phase required a ton of coordination: running other teams' analytics tools, checking metrics, chasing down approvals, debugging odd results, and keeping everyone in the loop across multiple Slack threads. I found myself doing a lot of these coordination tasks repeatedly, across multiple projects. In the beginning, I was over the moon! I was becoming the "go-to" person for these projects, my visibility across teams was getting better. As great as that felt, I had this nagging feeling though that there's something off here. How come I'm a mid-career engineer and most of my work is spent doing these less technical tasks? Shouldn't I be doing more technical work? I think the universe kinda conspired and one day, for no reason at all, I came across this article by Tanya Reilly titled "Being Glue" which instantly made me go "OOOH, THAT"S ME!'

I still remember the panic I felt when I first read the article but over the course of the next couple of months, I actively worked myself out of this trap, which is what inspired this talk: how do you recognize that dynamic early, rebalance, and help your manager and org see it too.

What's a subtle sign that you might be doing too much glue work, even if no one's explicitly said so?
A few subtle signs:

• You're the only person who knows "how things actually get done" for a recurring process (launches, rollouts, incidents, team rituals/processes).
• Your calendar is full of coordination work: setting up meetings, taking notes, chasing approvals, keeping docs up to date, writing TL;DRs for long threads.
• Your brag document or promo packet is heavy on "kept everyone aligned" and light on "designed/implemented X system."

None of those are bad on their own. The red flag is imbalance: if you're doing a lot of that and struggling to find time for deep technical work, you're probably in glue-work territory.

How do you recommend approaching your manager about redistributing glue work without sounding like you're avoiding responsibility?
It's important to frame it as a risk and growth conversation, a collaboration, and not a complaint.

Example script:

"I've become the default owner for <rollout / launch / process>. I'm glad I can help, but right now it's taking a big chunk of my time, and I'm worried I'm not getting enough opportunities to do the deeper technical work we discussed for my growth. I'd love your help to:

• Spread knowledge about this process so I'm not a single point of failure, and
• Make sure my project mix includes some higher-impact technical work this quarter."

This does three things:

• Highlights the risk of one person doing all the glue work (single point of failure, knowledge silo).
• Ties the conversation to your career goals and the expectations for your level.
• Invites the manager to partner with you on solutions: rotations, clearer role definitions, or re-balancing projects. This benefits the entire team, not just you.

Is there ever a case where taking on glue work can actually help with visibility or promotion?
Yes -- in moderation and when it's clearly tied to outcomes.

The irony is that glue work is often exactly the kind of thing we assess for at senior levels: communication, collaboration, and consensus-building. These are extremely common signals that we're being assessed on at the senior and senior+ levels.

Successfully coordinating a complex rollout, unblocking cross-team dependencies, or fixing a broken process can be a strong promotion signal if:

• It's aligned with your level's expectations, and
• You can directly connect it to business and technical impact (e.g., "This launch unblocked deprecating the monolith and reduced risk for future migrations").

The trap is when glue work is all you're doing, or when it's invisible. If you're going to lean into it, make sure:

• It's shared across the team, not just you.
• You're also owning some clearly technical pieces.
• Your manager understands the scope and includes it in performance conversations.

What's one strategy you used to transition glue work to others without hurting team dynamics?
I leaned into knowledge sharing and role clarity.

Once I realized I was doing too much glue work, I did a couple of things:

• Documented the process. Funnily enough, to transition glue work to others, you may have to do some additional glue work like writing extensive documentation.
• Trained the team. I ran small training sessions showing other engineers how to use the tools and made it clear anyone could take a turn.
• Learned to politely say no. Another irony about glue work is that if you're good at it, you'll naturally be asked to do more of it. Learning to say no is an important skill here. For example, if you're the default person on your team that organizes team socials and you don't want to be stuck doing this every time, open up this opportunity to the rest of the team by posting/asking for volunteers in a public team channel instead of volunteering to do it every time.
• Sometimes, you might be doing glue work because roles aren't well defined on your team. If you're doing the job of a scrum master in addition to your work as an engineer, then maybe a dedicated scrum master role should be created!

Steps like these help keep relationships positive because you're not 'dumping' work; you're up-leveling the team.

How can junior engineers push back on glue work when they feel they have less leverage?
Junior engineers often feel they can't say no, but they still have options.

Some tactics:

• Ask for pairing, not solo ownership.
  "I'm happy to help with notes/coordination this time -- can we rotate this so I also get chances to own small technical pieces?"
• Tie it to learning goals.
  "I'd love to get more hands-on with backend work this quarter. Is there a way to balance this meeting-heavy work with some implementation tasks so I can keep growing technically?"
• Use your brag document as evidence.
  If your brag doc is mostly glue work, bring it to your 1:1 and say: "I notice most of my wins are coordination-oriented. Can we adjust my responsibilities so I get more technical depth?"

And it's okay for juniors to practice a simple "no":

"I've taken notes the last few meetings -- could someone else grab it this time so I can stay focused on the implementation work we scoped for me?"

That's not avoiding responsibility; it's asking for a balanced workload.

What role can peer allies play in helping someone rebalance their workload and reduce glue work?
Peer allies are huge here.

They can:

• Volunteer for glue work when they notice the same person always doing it: "I can take notes this time; I know ABC handled them last week."
• Support rotational systems. Suggest rotating facilitators, notetakers, on-call leads, etc., so glue work is explicitly shared.
• Amplify and credit technical contributions from teammates who do a lot of glue work: "By the way, ABC didn't just organize the rollout -- they also designed the new retry strategy that made it safe."
• Back you up in manager conversations or retrospectives: "We rely on ABC a lot for coordination; we should spread that load so they can focus on the technical pieces we need for the next milestone."

Allies help turn this from "one person's problem" into a team health issue.

How can attendees learn more about this topic and also prepare for your session?
A few suggestions:

• Read Tanya Reilly's "Being Glue." That article was the original spark for my own realization and gives great language for this problem.
• Audit your own work. Before the session, spend a couple of minutes looking at your calendar from the last 2-4 weeks and your brag document or a list of "wins." Highlight what's glue work vs technical work. Are you happy with that mix?
• Bring one example. Come with one situation where you were doing glue work, how it went, if you were able to free yourself from the trap.

Note: Those wishing to attend the session can save money by registering early, according to the event's pricing page. "Save $500 when you register by the Year-End Savings deadline of Dec. 19," said the organizer of the event, which is presented by the parent company of Visual Studio Magazine.