Promo case glue

Promotion Case for Glue-Heavy Engineers

Build a promotion-ready case for engineers whose impact is primarily through glue work — the coordination, documentation, unblocking, process improvement, and cross-team work that makes teams succeed but rarely appears as "technical accomplishments" on promotion packets.

Converts glue activities into ladder-aligned evidence by:

• Reframing glue tasks as technical leadership, system improvement, and force-multiplication work
• Identifying and collecting concrete artifacts that demonstrate ownership and outcomes
• Structuring the promotion narrative around "invisible technical impact"
• Providing manager-facing talking points to help advocates tell the story correctly
• Offering tactics for addressing the "not technical enough" bias head-on

When to apply

Trigger this skill when:

• The user says: "My manager says I need more technical accomplishments, but I spend all my time unblocking people and onboarding new hires."
• Preparing a promotion packet and the user's biggest impacts are non-code (documentation, process, coordination).
• The user has been told: "You're great at communication and soft skills, but we don't see you as an engineer."
• The user is a junior/midlevel who naturally stepped into glue roles and now needs to translate that into senior-level evidence.
• The user's team would collapse without their glue work, but the promotion committee doesn't recognize it as "technical."

Skip when:

• The user has clear code/design/production impact to showcase (use report-promo-case directly).
• The user is clearly on a management/TPM track and should change titles, not fight for an IC promotion.
• The company's ladder explicitly excludes glue work from senior IC criteria (unfair but real; this skill helps user either change the ladder perception or decide to pivot roles).

Prerequisites

First, run glue-audit to produce a recent inventory of glue tasks and their time allocation. The promo case builds directly on that inventory — it's the raw material.

The interview flow

1. Ladder context

• "What level are you targeting? (Senior, Staff, Principal?)"
• "Do you have access to your company's official engineering ladder? If yes, what dimensions are evaluated?"
• Typical ladder dimensions: Technical Fluency, Delivery, Architecture, Leadership, Mentorship, Business Impact, Cross-functional Influence.

The skill will later map glue work to these dimensions.

2. The glue inventory review

Read the user's latest glue-audit file. Confirm the top 5–7 glue tasks by impact and time spent.

For each top task, drill:

• "What was the specific outcome? (Not the activity, but the result.)"
• "What would have gone wrong if this hadn't been done?"
• "Who benefited and how?"
• "Is there a metric or qualitative signal that improved?"
• "What artifact exists? (doc, email, Slack thread, postmortem, design doc)"

3. Reframe each glue task into technical leadership language

Tanya Reilly's key insight: glue work is already technical leadership — you just have to translate it. Use these reframing patterns:

Glue task	Technical leadership frame
Onboarding new hires	Reduced ramp time from N weeks to M; built onboarding system; mentored 3 engineers to first solo ship
Documentation (ADRs, runbooks)	Institutional knowledge capture; reduced bus factor; enabled faster incident response; design clarity that prevented wrong builds
Design review (catching handwaves)	Architecture quality gate; risk identification; technical due diligence; raised issue that prevented P0 incident
Unblocking teammates stuck in email chains	Cross-team communication orchestration; removed bottleneck; enabled engineer to complete 3-week block
Process improvement (coding standards, testing guidelines)	Engineering systems improvement; reduced rollbacks by X%; accelerated code review velocity
Cross-team alignment meetings	System integration ownership; prevented duplicate work; aligned on shared interfaces
Keeping roadmap current	Product-technology coupling; priority clarity; reduced wasted engineering effort
Mentorship (informal)	Team capability building; retention; multiplied team output through knowledge transfer
Incident coordination	Reliability ownership; blameless postmortem; converted failures into process improvements
Hiring interviewer	Technical hiring craft; calibrated evaluation; reduced false negatives

The skill writes these reframings into the case document explicitly: "What someone might call 'just documentation,' we call 'system design clarity that prevented divergent implementations.'"

4. Artifact mining

For each reframed item, list concrete evidence:

• Design docs with your comments — show your technical judgment in action
• Onboarding docs you wrote — show system understanding and teaching ability
• Email threads where you aligned teams — show influence without authority
• Postmortem/ADR where your intervention was cited — show incident leadership
• Metrics: onboarding time before/after, review cycle time, rollback rate, mean-time-to-resolution
• Testimonials: Slack messages, 1:1 email praise, performance review quotes (exact wording)

The skill creates an "Artifacts" section with file paths or excerpts.

5. Narrative construction

Assemble a three-act story:

Act 1 — The problem: The team had gaps in [onboarding, design quality, cross-team alignment]. This caused [slow ramp, rework, duplicated effort, incidents].

Act 2 — Your intervention: You did [specific glue tasks]. Not as "helping" but as owning the problem. Technical decisions you made: [choose standards, design the onboarding flow, set the review checklist].

Act 3 — The outcome: Quantified results: [shorter ramp, fewer rollbacks, faster incident recovery, aligned architecture]. The team is now [more productive, more reliable, better aligned]. You did this as an engineer through technical leadership, not project management.

6. Address the "not technical enough" objection head-on

Anticipate and pre-bunk common pushback:

Objection: "Your impact isn't sufficiently technical." Response: "My work prevented [quantify] hours of wasted engineering, reduced [metric] by X%, and directly enabled [feature/ship]. Those are engineering outcomes. I'm a systems thinker who operates at the coordination layer — that's senior/staff-level work."

Objection: "You didn't write enough code." Response: "I made the codebase more effective by improving the conditions under which code gets written. My artifacts — [list] — show the breadth of my technical contribution. The ladder values 'impact,' not just 'lines of code.'"

Objection: "This looks like project management." Response: "Project managers coordinate timelines. I solved technical problems: I designed the onboarding system, I set the technical standards, I identified architectural gaps in design reviews. Those are engineering judgments."

The skill writes a "Q&A prep" section with these exact talking points.

7. Manager advocacy guide

Provide the user's manager with a separate "how to tell this story" note:

• What to emphasize in calibration meetings
• Which artifacts to surface
• How to answer the "was this promotable?" question
• Preemptive language to neutralize "soft skills" dismissal

Output structure

The skill creates ~/bettersense-work-reflections/promo-cases/<level>-glue-<name>-<date>.md:

---
candidate: [name]
target_level: Senior | Staff | Principal
period: [date range]
summary: "[one-sentence impact claim]"
---

# Promotion Case: [Name] — [Target Level]

## TL;DR
[2–3 sentences: "I'm being evaluated on Technical Leadership, Delivery, and Architecture. My glue work is the vehicle for those dimensions: I built onboarding that cut ramp time 40%; I instituted design-review quality gates that caught 3 architectural gaps before implementation; I coordinated cross-team alignment that prevented duplicated effort on X integration."]

## Evidence by ladder dimension

### Technical Leadership
- **Task:** Onboarding system design
  - **What I did:** Wrote onboarding checklist, paired with 3 new hires, created runbook collection
  - **Outcome:** Average ramp from 6 weeks → 3.5 weeks; new hires shipping within 30 days
  - **Artifacts:** `docs/onboarding.md`, Slack thread `#eng-onboarding` (March–April), email from eng lead (May 2)
  - **Why this is senior work:** Onboarding is a systems problem; I treated it as such, not as ad-hoc help

### Delivery / Execution
- **Task:** Design review quality gate
  - **What I did:** Read every design doc, asked clarifying questions, surfaced missing edge cases in 4 reviews
  - **Outcome:** Two designs materially changed before build; one potential P0 security issue caught
  - **Artifacts:** Google Doc comments on [link], ADR-012 revised per my feedback, incident postmortem cites "lacking design review" as root cause (which we now have)
  - **Why this is senior work:** Architectural due diligence is a core IC responsibility at senior+

### Architecture / System Design
- **Task:** Cross-team service boundary definition
  - **What I did:** Led alignment meeting between Team A and Team B, produced shared interface contract
  - **Outcome:** Prevented two conflicting implementations; integration tested successfully first try
  - **Artifacts:** Meeting notes email (Apr 15), GitHub issue #456 with agreed spec
  - **Why this is senior work:** System thinking across team boundaries; influence without authority

### Mentorship / Team Multiplier
- **Task:** Informal mentorship of 2 juniors
  - **What I did:** Regular pairing sessions, PR feedback, career guidance
  - **Outcome:** Both shipped first solo features; one received "high performer" quarterly recognition
  - **Artifacts:** Their thank-you messages, their PRs showing independent work, their promotion packets (they shared with me)
  - **Why this is senior work:** Multiplying team capability through teaching is a senior IC expectation

## Quantitative summary
- Estimated hours/week on glue work: 15–20 (out of 40)
- Outcomes attributable to glue work: onboarding time -42%, design rework avoided (2–3 designs), cross-team duplicate effort avoided (~1 engineer-week)
- Visibility: team-wide; documented in team retro (May), mentioned in manager's skip-level update

## Artifacts collected
[List with file paths or descriptions]

## Narrative — "The glue narrative"
[150-word story: "My technical contribution is making the team effective. I own the coordination layer that connects individual engineers to collective outcomes. That's why Team X shipped Y on schedule and with zero P1 incidents."]

## Q&A prep
- Q: "This looks like project management, not engineering."
  A: "Project managers manage timelines and dependencies. I solve technical problems: I designed the onboarding curriculum, I set the testing standards, I caught architectural gaps in design reviews. Those are engineering judgments."
- Q: "Where's your code?"
  A: "My work enabled others to write better code faster. The measure of an engineer isn't lines written; it's problems solved. I solved ramp, alignment, and quality problems that were blocking the team's code output."
- Q: "Are you technical enough?"
  A: "I participate in technical discussions, I review designs, I make architectural trade-off calls. I'm not 'less technical' — I'm *applied* technically at a different layer."

## Manager guidance
[Separate section addressed to the user's manager, with: suggested language for calibration, which artifacts to highlight, pre-bunking the "soft skills" dismissal, and a direct ask: "Please tell the committee: X's glue work is the reason Y outcome happened."]

## Risks & mitigations
- Risk: Committee still says "not technical enough."
  Mitigation: Plan B — temporarily reduce glue, increase core technical work for next cycle (see `boundary-negotiation` skill). But try this narrative first.
- Risk: User accused of "not wanting to code."
  → Mitigation: Emphasize that user *can* code; they choose to allocate time elsewhere for team multiplier effect.

Operating principles

• Frame glue as technical leadership, not "soft skills." The language matters: coordination not communication; system design not documentation; quality gate not code review.
• Visibility is half the battle. The user must have artifacts; if they don't, instruct them to start collecting now (for next cycle).
• Don't invent impact. Stick to what's real. The story is stronger when honest.
• Target the ladder, not vague "seniority." Use the company's actual rubric language.
• Use Tanya Reilly's thesis: doing glue work doesn't mean you're less technical; it means you're operating at a different (and necessary) technical layer.
• Allow for honest "not promotable here" conclusions. If the company truly doesn't value glue work at the IC level, help the user see that and consider role change — don't force a losing battle.

Composition with other skills

• glue-audit — prerequisite; consumes its output
• report-promo-case — this is a specialized mode of that skill; can route to it or compose
• user-profile — reads the user's current level and company context to calibrate ladder expectations
• wins-log — glue wins should be captured here too; cross-reference both files
• boundary-negotiation — if the user wants to reduce glue to focus on core work, that's Plan B; link the two skills

Anti-patterns to flag

• "I helped a lot" — too vague. Force specific outcomes and artifacts.
• Taking sole credit for team glue. Acknowledge collaborators where glue is shared.
• Listing tasks without technical framing. "I onboarded Bob" → "I designed and executed an onboarding flow that reduced Bob's ramp to production from 6 weeks to 3."
• Ignoring the company's actual ladder. If the ladder says "writes production code" as top criterion, this case may still fail — surface that reality.
• Waiting until promotion season to start collecting. The skill should suggest: "Start your artifact collection now for next cycle."