# 01 — Visibility & Influence **Goal:** be seen for the right things without self-promotion, and shape decisions (PM, QA, Backend, Management) in your favor. > **The core principle:** *Visibility is an artifact problem, not a personality problem.* Bragging is talking about work; visibility is **leaving durable artifacts** that make the work obvious. You never have to say "I did X" if X is documented, linked, and referenced by others. --- ## Part 1 — Consistent visibility without bragging ### 1.1 The artifact-first rule Every week, produce at least one of these. **One. Every. Week.** | Artifact | Format | Where it lives | Why it beats talking | |---|---|---|---| | **Decision record (ADR)** | 1 page: context → options → decision → consequences | `docs/adrs/` in the repo | Future engineers cite it; it becomes *the* reference | | **Before/after metrics note** | 1 paragraph + a chart or table | PR description + team channel | Numbers are un-arguable and get quoted in reviews | | **Demo recording** | 3–5 min Loom, narrated, real product | PR or sprint review doc | Stakeholders watch async; your work is *seen*, not described | | **Tech note / lesson** | 1 page on a bug you killed or a pattern you proved | Team wiki or `docs/` | Positions you as the person who *teaches* | | **RFC / proposal** | 1–2 pages with options + recommendation | #architecture channel | You are shaping decisions before they happen | **The 10-line discipline:** any of these can be written in 10 focused lines of substance + links. If you cannot write the artifact in 30 minutes, you do not yet understand the work — which is itself a signal to go deeper before claiming done. ### 1.2 Visibility channels that cost ~zero political capital - **PR quality is your loudest channel.** A PR with a clear description (problem, approach, screenshots, test evidence, metrics) is read by reviewers, QA, and PMs. Treat every PR as a mini-document. - **Ship notes in your team's async channel** (Slack/Teams thread per release): 3 bullets — what shipped, what it moves, what's next. No adjectives; just facts. - **Review other people's code visibly.** Good reviews (specific, kind, technical) are noticed by authors and managers more than your own code. - **Mentor one person** (even informally). Teaching is the highest-status visibility that never reads as bragging. - **Run one internal session per quarter** (30 min: "how we did X"). Record it. Now it is an artifact, not an event. - **Present at demo/review meetings with a 2-slide max** and a live artifact — the artifact does the talking. ### 1.3 The visibility trap list (what quietly kills your reputation) - **Claiming credit for collaborative work** — always name the pair/team; the generous person gets remembered, the grabber gets audited. - **Visibility only in crisis** — if the org only sees you firefighting, they classify you as a firefighter. Weekly artifacts prevent this. - **Volume over signal** — 5 low-quality updates < 1 excellent one. Spam trains people to mute you. - **Working in silence for weeks** then surfacing a giant PR — the org cannot see you if there is no trail. Ship in reviewable slices. - **Technical arrogance in reviews** ("this is obviously wrong") — influence requires that people *want* to agree with you. --- ## Part 2 — Negotiating & influencing stakeholders ### 2.1 Stakeholder map: what each person actually wants Negotiation starts with the other side's **incentives**, not your argument. | Stakeholder | Their real incentives | What you trade | Their language | |---|---|---|---| | **PM** | Ship dates, scope, user outcomes, their roadmap credibility | Realistic sequencing, risk visibility, quick wins they can demo | Dates, outcomes, "what can we ship by X" | | **QA** | Finding bugs, being heard, not being the release blocker | Early test plans, your own pre-QA gate (see 04), fast triage | Reproducible steps, severity, "what changed" | | **Backend** | Contract stability, their own deadlines, fewer surprises | Contract-first API design, early integration points, honoring schemas | OpenAPI/types, payloads, error codes | | **Management** | Predictability, headcount leverage, risk reduction, your growth (they own it) | Options + recommendation, honest estimates, escalation discipline | Effort vs impact, risks, "what do you need" | ### 2.2 The negotiation framework (use for every disagreement) 1. **Separate position from interest.** PM says "ship by Friday" (position). Interest: "demo to leadership Thursday." If you know the interest, you can offer *Thursday demo with a feature-flagged partial* — a better answer than "can't do Friday." 2. **Bring options, not demands.** Never walk in with one solution. Present 2–3 options with **cost/benefit per option and your recommendation** (and why). Decision-makers buy recommendations they could have chosen differently. 3. **Pre-align before the meeting.** The meeting is where decisions get *confirmed*, not made. Send the one-pager 24h ahead; collect the two strongest objections privately and address them. Never surprise a stakeholder in public. 4. **Frame with cost of inaction.** "Do nothing" is always an option — quantify it. "We can skip the design-system work this quarter; the cost is ~3 dev-days/month of duplicated UI and inconsistent a11y, compounding." 5. **Know your BATNA and your walk-away line.** For architecture: if they refuse the ADR, what's the smallest version you'll accept (a pilot, a scoped POC)? Pre-decide; never negotiate from improvisation. 6. **Make the other side win.** The best architecture deal is one where PM gets a demo-able slice, QA gets a test plan, backend gets contract stability, and you get the architectural shape. Design the deal so everyone reports a win. ### 2.3 Influencing decisions upward (the technical lever) - **Write the ADR before the decision is forced.** By the time the deadline arrives, the decision should already exist in document form with your analysis. You are then *referenced*, not *arguing*. - **Smallest-vote-first:** get one respected engineer to agree with your approach privately before the group discussion. Coalitions of two beat solo crusades. - **Use data, not taste.** "I prefer X" loses; "X removes 40% of this class of runtime errors (see the incident log) and cuts the bundle by 120KB" wins. - **Escalate with a recommendation.** When you escalate a blocker to management, always include: what you tried, what you need (decision/resource), and the cost of waiting. Management responds to crisp asks. - **Public credit, private disagreement.** Disagree with a proposal in a DM or small group; once decided, support it publicly. This buys you the right to disagree next time. ### 2.4 Negotiating your own advancement (the meta-game) - **Negotiate scope, then salary follows scope.** A Principal grows by acquiring *system-level ownership* (the design system, the platform, the frontend architecture), not by doing more tickets. Ask for the ownership, not the title. - **Use the quarterly review as a pre-negotiated checkpoint**, not a surprise: set the goal at the start of the quarter (05), show artifacts weekly, and the review becomes a formality. - **One ask per conversation.** Multiple asks dilute. Know the single most important thing you want before every 1:1. --- ## ✅ The visibility checklist (run Fridays) - [ ] One artifact produced this week (ADR / metrics note / demo / tech note) - [ ] All PRs this week had descriptions with screenshots + test evidence - [ ] Reviewed ≥2 others' PRs with specific, kind, technical comments - [ ] Async update posted (3 bullets) for anything user-facing - [ ] Impact ledger updated (one line) - [ ] No silent weeks: gap > 10 days without an artifact → write one today → Next: [02 — Architectural Mastery](02-architectural-mastery.md) · Back: [00 — Master Index](00-master-index.md)