# Promo Case Glue > Use when an engineer who does significant glue work (onboarding, documentation, unblocking, cross-team alignment, process improvement) needs to build a promotion packet that frames that work as technical leadership. Trigger phrases include "promotion case for glue work", "I do a lot of glue work how do I get promoted", "frame my non-code work for promotion", "my manager says I need more technical accomplishments", "I'm a glue person how do I get senior". Works alongside or as a specialized mode of `report-promo-case`. Produces a promotion-ready narrative that translates glue tasks into ladder-appropriate evidence, with artifact collection guidance and manager talking points. - Skill: `shwetank/promo-case-glue` (Agent Skill) - Install (CLI): `npx skillmds@latest add shwetank/promo-case-glue` - Raw SKILL.md: https://api.skillmd.com/api/skills/shwetank/promo-case-glue/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: shwetank (https://skillmd.com/u/shwetank) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/shwetank/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/-glue--.md`: ```markdown --- 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."