Influence & Negotiation — Khi Code Không Đủ Để Thắng

Staff Engineer:
  → Không có direct reports
  → Không control budget
  → Không quyết định ai làm gì (đó là EM)
  → Không có organizational power

Nhưng cần:
  → Thuyết phục team khác adopt standard của bạn
  → Drive technical change cross-org
  → Dừng bad technical decisions (diplomatically)
  → Align 5 teams theo 1 direction

Contradiction? Không. Influence ≠ Authority.
  Authority: "Làm cái này vì tôi bảo."
  Influence: "Làm cái này vì nó đúng, và đây là evidence."

1. Technical Credibility
   → Bạn đã ship things that work → people trust your judgment
   → Build credibility = YEARS. Destroy = 1 bad call.

2. Relationships
   → Bạn biết đúng người ở đúng team
   → 1:1 relationships > mass emails
   → "Tôi đã nói chuyện với Hoa ở Platform team, 
      cô ấy cũng thấy approach này hợp lý"

3. Communication Clarity  
   → RFC rõ ràng, data-driven
   → Present complex ideas đơn giản
   → "Tôi có thể tóm tắt trong 30 giây"

4. Track Record of Being Right
   → Không phải lúc nào cũng đúng, nhưng often enough
   → Quan trọng: PUBLICLY acknowledge khi bạn sai
   → "Tôi đã predict cái này sai lần trước, 
      nhưng lần này evidence khác vì..."

5. Generosity
   → Help người khác thành công → họ help bạn
   → Amplify team members' work
   → Credit người khác trước bản thân

One-way door decisions (khó reverse):
  → Technology stack change
  → Architecture fundamental
  → Data model design
  → API contract (public)
  → Hiring decisions
  
  → PHẢI disagree nếu bạn thấy sai
  → Nếu im lặng → complicit

Two-way door decisions (dễ reverse):
  → Library choice
  → Code structure
  → Testing approach
  → Naming conventions
  
  → Có thể disagree nhưng don't die on this hill
  → Let it go, revisit sau nếu cần

❌ Sai:
  "Cách này sai." (không constructive)
  "Đừng dùng X." (không alternative)
  "Tôi đã nói rồi mà không ai nghe." (blame)
  Im lặng trong meeting, rồi complain sau. (passive-aggressive)

✅ Đúng:
  1. Acknowledge: "Tôi hiểu reasoning đằng sau approach này..."
  2. Data: "Dựa trên data/experience, tôi thấy risk ở chỗ..."
  3. Alternative: "Approach khác tôi muốn đề xuất là..."
  4. Trade-offs: "Trade-off giữa 2 approaches..."
  5. Commit signal: "Nếu team quyết định đi hướng A, 
     tôi sẽ fully commit và help deliver."

Khi decision đã được made (và bạn đã disagree):

DO:
  ✅ Support decision 100% — không "told you so"
  ✅ Help make the decision succeed
  ✅ If it fails: post-mortem, learn, KHÔNG blame
  ✅ Document your concerns trước (email/doc) — in case 
     cần revisit later, có evidence bạn đã flag

DON'T:
  ❌ Sabotage (even passive)
  ❌ "Tôi đã nói rồi" khi nó fail
  ❌ Refuse to help implement
  ❌ Complain to others behind the decision-maker's back

Mature disagreement:
  "Tôi disagree với approach X vì reasons A, B, C.
   Tôi đã documented concerns ở đây [link].
   Nhưng tôi understand decision đã được made, 
   và tôi sẽ fully commit vào delivery."

Mistake phổ biến:
  → Viết RFC 20 trang
  → Present trong meeting 30 người
  → 5 teams push back → proposal dies
  → 2 tháng effort = 0

Cách Staff Engineer làm:
  → 1:1 với key stakeholders TRƯỚC meeting
  → Hiểu concerns của từng team
  → Adjust proposal trước khi present
  → Khi meeting xảy ra: "Tôi đã discuss với team X, Y, Z.
     Họ có concerns A, B mà proposal đã address..."
  → Proposal đã có supporters, giảm surprise pushback

Cho mỗi technical initiative:

  Power (ảnh hưởng decision)
    │
    │  Manage Closely    │   Keep Satisfied
    │  (CTO, VP Eng)     │   (Director không 
    │                    │    directly involved)
    ├────────────────────┤
    │  Keep Informed     │   Monitor
    │  (Team leads,      │   (Other teams)
    │   senior engineers) │
    └────────────────────┴─── Interest
                              (stake in outcome)

Actions:
  High power + High interest: 1:1 meetings, co-create solution
  High power + Low interest: Executive summary, decision points
  Low power + High interest: Regular updates, involve in design
  Low power + Low interest: Newsletter/email updates

Executives đọc email/doc trong 30 giây.
Nếu 30 giây không đủ để hiểu key message → they move on.

Structure (TL;DR first):

❌ Sai (chronological):
  "Tuần trước team phát hiện performance issue...
   Sau đó chúng tôi investigate...
   Rồi thử 3 approaches...
   Cuối cùng chọn approach B vì..."

✅ Đúng (conclusion first):
  "RECOMMENDATION: Migrate auth service to new framework.
   IMPACT: Reduce auth latency 80%, unblock enterprise feature.
   COST: 3 engineer-weeks, 0 downtime.
   RISK: Low (reversible, gradual rollout).
   
   [Details below for those interested...]"

S — Situation (context everyone agrees on):
  "Auth service hiện tại handle 10K req/s, p99 = 800ms"

C — Complication (the problem):
  "Enterprise customers cần SSO, nhưng current auth 
   architecture không support SAML. Adding SAML vào 
   current codebase sẽ tăng complexity 3x."

Q — Question (what needs to be decided):
  "Nên refactor auth service hay build new?"

A — Answer (your recommendation):
  "Build new service, strangler fig migration.
   3 engineer-weeks, 0 downtime, risk: low."

Scenario: Senior engineer đề xuất architecture mà bạn 
thấy sẽ fail ở scale.

❌ Sai:
  "Cái này không scale được." (vague, dismissive)
  
✅ Đúng:
  "Tôi appreciate effort bạn đã bỏ vào design này.
   Tôi có 1 concern về scalability mà tôi muốn discuss:
   
   Với current design, khi traffic tăng 10x, 
   single database sẽ hit connection limit ở ~5K QPS.
   [Data/evidence]
   
   Có 2 options tôi thấy:
   1. Add read replicas (simpler, works tới ~50K QPS)
   2. Shard by tenant_id (complex, works tới 500K QPS)
   
   Bạn nghĩ traffic projection 12 tháng tới là gì?
   Từ đó mình có thể quyết định."

Principles:
  → Start with what's GOOD about the proposal
  → Be specific: numbers, scenarios, evidence
  → Offer alternatives (don't just criticize)
  → Ask questions (maybe THEY know something you don't)
  → Frame as "we" problem, not "your" problem

PM: "Chúng ta cần ship feature này trong 2 tuần."
Bạn biết: Realistic estimate = 6 tuần.

❌ Sai: "Không thể." (defensive)
❌ Sai: "OK." (rồi crunch + ship buggy code)

✅ Đúng:
  "Tôi hiểu urgency. Để tôi break down scope:
  
   Full feature: 6 weeks
   ├── Core flow: 2 weeks ← có thể ship MVP
   ├── Edge cases + error handling: 2 weeks
   └── Testing + monitoring: 2 weeks
   
   Options:
   A) Ship MVP trong 2 tuần, iterate sau (risk: edge cases)
   B) Full feature trong 6 tuần (lower risk)
   C) Cut scope: drop feature X, ship trong 3 tuần
   
   Recommendation: Option A nếu business urgency cao.
   Nhưng cần align rằng edge cases sẽ được address 
   trong sprint tiếp theo."

1. Create urgency
   "Hệ thống hiện tại cost $X/tháng downtime"
   → Data, không opinions

2. Build coalition
   Pre-align với key engineers và managers
   
3. Create vision
   "Trong 6 tháng, deploy sẽ mất 5 phút thay vì 2 giờ"
   → Concrete, measurable
   
4. Communicate vision
   RFC, tech talk, 1:1s — repeat, repeat, repeat
   
5. Remove obstacles
   → Migration guides, tools, pair programming
   → Đừng chỉ nói "dùng cái mới" — help teams migrate
   
6. Create short-term wins
   → "Team A đã migrate, deploy time giảm 80%"
   → Early adopters = proof of concept
   
7. Build on change
   → Onboard thêm teams, iterate based on feedback
   
8. Anchor in culture
   → New approach becomes "how we do things"
   → Document, train, make it the default path

Innovators (2-3%): Tech enthusiasts → early RFC reviewers
Early Adopters (13%): Trusted engineers → pilot teams
Early Majority (34%): Wait for proof → need case studies
Late Majority (34%): Skeptical → need org mandate/support  
Laggards (16%): Resist → need migration tools/deadline

Strategy:
  Phase 1: Win innovators + early adopters (proof of value)
  Phase 2: Document success → win early majority
  Phase 3: Make new way the default → late majority follows
  Phase 4: Migration deadline + support → laggards migrate

BATNA (Best Alternative To Negotiated Agreement):
  → Trước khi negotiate, biết fallback option của bạn
  → "Nếu team X không agree, plan B là gì?"
  → Stronger BATNA = stronger negotiation position

Interest-based Negotiation:
  → Don't argue positions → explore interests
  
  Position: "Tôi muốn dùng Kafka"
  Interest: "Tôi cần message durability và replay capability"
  
  → Maybe Redis Streams đủ tốt cho interest đó?
  → Find solution that meets BOTH sides' interests

Anchoring:
  → First number/proposal sets the frame
  → "Feature này cần 8 tuần" (anchor high)
  → Negotiate down → land at 5-6 tuần (realistic)
  → Nếu anchor thấp: "3 tuần" → end up at 2 tuần (crunch)

Influence Toolkit:

  □ Build credibility: Ship things, be right (mostly)
  □ Pre-align: 1:1 trước meetings, không surprise
  □ Disagree constructively: Data + alternatives
  □ Commit after disagree: No "told you so"
  □ Write clearly: TL;DR first, SCQA framework
  □ Give hard feedback: Specific, offer alternatives
  □ Push back on timelines: Options, not "no"
  □ Lead change: Start small, prove value, scale up