The Glue Work Promotion: How One Staff Engineer Made the Invisible Visible

The Glue Work Promotion: How One Staff Engineer Made the Invisible Visible

The Problem No One Wanted to See

Sarah had been a Senior Software Engineer at a fast-growing fintech company for three years when she noticed something troubling: the engineering organization was scaling rapidly—from 30 to 150 engineers in 18 months—but delivery velocity was actually decreasing.

Sprint commitments were missed regularly. Cross-team projects took 3x longer than estimated. Incidents were more frequent, and the same issues kept reoccurring. Junior engineers felt overwhelmed and directionless. Yet when leadership asked “why aren’t we shipping faster with more people?”, the answer was always “we need more engineers.”

Sarah saw the real problem: the organization lacked connective tissue. There was no shared understanding of system architecture, no consistent engineering practices, no clear ownership boundaries, and no systematic knowledge sharing. Teams were islands, and the water between them was getting wider.

The Glue Work Begins

Sarah started doing what Tanya Reilly famously called “glue work”—the unsexy, often invisible work that holds organizations together:

• She created an architecture decision record (ADR) process and template
• She facilitated cross-team design reviews before major projects kicked off
• She documented the organization’s key systems in a living architecture diagram
• She started a weekly “engineering office hours” where anyone could get technical help
• She created onboarding documentation that actually reflected how the systems worked
• She identified patterns in recurring incidents and championed long-term fixes

None of this was in her job description. None of it resulted in visible features or metrics that leadership tracked. And for six months, none of it seemed to help her career.

The Career Risk of Glue Work

At her performance review, Sarah’s manager praised her impact but said something concerning: “Your architectural thinking is excellent, but you’re not shipping enough features. The promotion to Staff requires demonstrating technical leadership through code delivery.”

Sarah realized she’d fallen into a trap that catches many senior engineers, especially women and underrepresented minorities: doing critical work that keeps the organization functional, but because it’s not “technical enough” or visible enough, it doesn’t count toward advancement.

She had two choices:

1. Stop doing glue work, focus on shipping features, and watch the organization continue to struggle
2. Find a way to make the glue work visible and recognized as technical leadership

She chose option 2, but it required a deliberate strategy.

Making the Invisible Visible

Sarah took three critical steps to reframe her glue work as technical leadership:

1. Quantify the Impact

She started tracking metrics that demonstrated the value of her work:

• Time-to-first-commit for new engineers (decreased from 2 weeks to 3 days after onboarding docs)
• Cross-team project delivery time (improved from 3x over-estimate to 1.2x after design review process)
• Repeat incidents (reduced by 60% after systematic root cause documentation)
• Architectural decisions made without considering system-wide impact (decreased from ~70% to ~20% with ADR process)

Key lesson: Glue work creates value, but you have to measure it to make it visible.

2. Create Artifacts and Systems, Not Just One-Off Help

Rather than just answering questions in Slack or helping teams individually, Sarah built systems:

• The ADR process wasn’t just her reviewing designs—it was a self-service template with examples that teams could use independently
• Architecture diagrams weren’t just documents—they included runbooks, ownership information, and were maintained in code
• Engineering office hours evolved into a rotation where senior engineers from different teams contributed, scaling her impact

Key lesson: Glue work that creates reusable systems and scales beyond your individual effort is technical leadership.

3. Connected Her Work to Business Outcomes

Sarah learned to speak her manager’s and executive team’s language:

• “The ADR process reduces project risk and prevents costly architectural mistakes” became “We avoided an estimated $500K in refactoring costs by catching design issues before implementation”
• “Better onboarding docs help new engineers” became “We increased engineering capacity by 15% without hiring by getting engineers productive faster”
• “Cross-team design reviews improve collaboration” became “Project delivery predictability improved 40%, increasing our ability to commit to product roadmap timelines”

Key lesson: Technical leadership must be connected to business value to be recognized by non-technical leadership.

The Promotion and Beyond

Eight months after her disappointing performance review, Sarah was promoted to Staff Engineer. Her promotion packet didn’t emphasize lines of code or features shipped. Instead, it highlighted:

• Technical Strategy: Established architectural governance processes that scaled with the organization
• Multiplier Impact: Created systems that improved productivity across 8 teams (~60 engineers)
• Organizational Leverage: Reduced project delivery variance, enabling more reliable planning and roadmap execution
• Knowledge Sharing: Built documentation and onboarding systems that decreased ramp-up time by 80%

Her manager’s promotion justification read: “Sarah demonstrates technical leadership not through individual code contributions, but through systems thinking, organizational design, and force multiplication. She makes everyone around her more effective.”

Lessons for Aspiring Staff Engineers

Sarah’s story illustrates several critical insights about the Staff Engineer path:

1. Glue Work Is Technical Leadership—But It Must Be Framed That Way

Organizational effectiveness, knowledge sharing, and process improvement are legitimate forms of technical leadership, but they must be:

• Measurable
• Systematic and scalable
• Connected to business outcomes

2. Visibility Is Not Optional

Senior IC roles require demonstrating impact to people who may not directly observe your work. This means:

• Writing design docs and RFCs that get distributed widely
• Speaking at team meetings and engineering all-hands
• Creating artifacts (docs, systems, processes) that carry your name and ideas
• Getting sponsors and allies who can advocate for your work

3. Balance “Pushing the Codebase Forward” With “Pushing the Organization Forward”

Staff Engineers need both:

• Technical depth: Demonstrated through architecture decisions, complex implementations, or deep technical expertise
• Organizational impact: Demonstrated through multiplier effects, process improvements, or strategic initiatives

Doing only glue work can stall your career. Doing only coding can limit your impact. The sweet spot is both.

4. Don’t Wait for Permission to Lead

Sarah didn’t wait to be promoted to Staff before doing Staff-level work. But she also didn’t martyr herself doing invisible work without ensuring it was recognized.

The key is to:

• Identify high-leverage problems no one else is solving
• Propose solutions and get buy-in from leadership
• Execute and measure impact
• Communicate results widely

5. Know When to Say No

One of Sarah’s key realizations: not all glue work is valuable glue work. Some requests are just other people’s work being delegated to you. Staff Engineers must:

• Prioritize glue work that has multiplier effects
• Decline or delegate low-leverage tasks
• Protect time for deep technical work

The Bigger Picture

Sarah’s promotion wasn’t just a personal win—it signaled a cultural shift at her company. By making glue work visible and valued, she created a template for others to follow. Within a year, two more engineers were promoted to Staff using similar justifications.

Her story demonstrates that Staff Engineer is not just “Senior Engineer Plus More Code.” It’s a fundamentally different role that requires:

• Systems thinking about both technology and organizations
• The ability to create leverage through other people
• Strategic judgment about where to apply effort
• Communication skills to make technical and organizational work visible

If you’re a senior engineer doing glue work and wondering if it will help your career, the answer is: it depends on whether you make it count.

Action items for senior engineers doing glue work:

1. Audit your time: What percentage is glue work? Is it multiplier work or just “helping”?
2. Measure your impact: What metrics demonstrate the value of your glue work?
3. Create systems, not just solutions: Are you building reusable processes or doing one-off work?
4. Make it visible: Who knows about your work? Are you documenting and communicating it?
5. Connect to business value: Can you translate your work into outcomes leadership cares about?

The path to Staff Engineer through glue work is real—but it requires intention, measurement, and visibility. Sarah’s story proves it’s possible, and shows exactly how to do it.