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)
- 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."
- 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.
- 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.
- 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."
- 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.
- 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 · Back: 00 — Master Index