Cómo navegar la política organizacional como Staff Engineer

// ❌ Assuming decisions follow the org chart
interface OrgChartAssumption {
  // "I'll propose this at the architecture review,
  //  the CTO will approve it, teams will adopt it"
  proposal: TechnicalDecision;
  approval: "architecture-review";
  adoption: "mandated-by-leadership";
}
// This almost never works for cross-cutting changes

// ✅ Mapping actual decision influence
interface DecisionInfluenceMap {
  formalAuthority: string[];     // People who can say "yes"
  informalInfluence: string[];   // People whose opinion
                                 // shapes the "yes"
  implementers: string[];        // People who must execute
  blockers: string[];            // People who can say "no"
                                 // or slow-walk
  champions: string[];           // People who will advocate
                                 // when you're not in the room
}
 
function mapStakeholders(
  proposal: string
): DecisionInfluenceMap {
  // For a database migration proposal:
  return {
    formalAuthority: ["VP Engineering", "CTO"],
    informalInfluence: [
      "Staff engineer on Platform team",
      "DBA who's been here 8 years",
      "SRE lead who handles incidents",
    ],
    implementers: [
      "Backend team leads",
      "Individual contributors on each team",
    ],
    blockers: [
      "Product managers with frozen roadmaps",
      "Team that just finished a painful migration",
    ],
    champions: [
      "Senior engineer who hit scaling limits last quarter",
      "New hire from company that already did this",
    ],
  };
}

// The socialization process for a technical proposal
interface ProposalPhase {
  name: string;
  activities: string[];
  duration: string;
}
 
const proposalPlaybook: ProposalPhase[] = [
  {
    name: "Research & Draft",
    activities: [
      "Write the proposal document",
      "Include cost-benefit analysis with real numbers",
      "Identify 3 alternative approaches you considered",
      "Make the risks section the strongest part",
    ],
    duration: "1-2 weeks",
  },
  {
    name: "One-on-One Socialization",
    activities: [
      "Share draft with 2-3 trusted peers first",
      "Incorporate their feedback before going wider",
      "Meet individually with each team lead affected",
      "Ask: 'What would make this work for your team?'",
      "Identify and address concerns privately",
    ],
    duration: "1-2 weeks",
  },
  {
    name: "Broader Review",
    activities: [
      "Present at architecture review with pre-aligned leads",
      "No surprises — every concern was already discussed",
      "Frame as 'we've been discussing this' not 'I propose'",
      "Offer concrete first step, not a big bang",
    ],
    duration: "1 week",
  },
  {
    name: "Incremental Adoption",
    activities: [
      "Start with one willing team as pilot",
      "Document what you learn and share updates",
      "Adjust the approach based on real-world feedback",
      "Let success attract the next adopter",
    ],
    duration: "Ongoing",
  },
];

// Framework for navigating technical conflicts
interface TechnicalConflict {
  positions: Map<string, string>;    // What teams say they want
  interests: Map<string, string[]>;  // Why they want it
  constraints: Map<string, string[]>;// What they can't compromise on
}
 
function analyzeAPIConflict(): TechnicalConflict {
  return {
    positions: new Map([
      ["Team A", "We should standardize on GraphQL"],
      ["Team B", "We need REST endpoints"],
      ["Team C", "We already use gRPC everywhere"],
    ]),
    interests: new Map([
      [
        "Team A",
        [
          "Reduce over-fetching in mobile app",
          "Flexible queries for varied clients",
        ],
      ],
      [
        "Team B",
        [
          "Simple protocol for constrained devices",
          "Broad tooling support",
          "Low implementation overhead",
        ],
      ],
      [
        "Team C",
        [
          "Type safety across service boundaries",
          "Performance for internal communication",
          "Investment protection",
        ],
      ],
    ]),
    constraints: new Map([
      ["Team A", ["Cannot accept N+1 query patterns"]],
      ["Team B", ["Devices can't run GraphQL clients"]],
      ["Team C", ["Six months of work can't be thrown away"]],
    ]),
  };
}
 
// Resolution: focus on interests, not positions
// Internal services: gRPC (protects Team C's investment,
//   gives Team A type safety)
// External APIs: REST (works for Team B's devices)
// Client-facing BFF: GraphQL gateway over gRPC services
//   (gives Team A flexible queries)

## Structure of an effective technical strategy doc
 
### 1. Context & Problem Statement (1 page max)
- What is happening today?
- Why is it a problem? (Use metrics, not opinions)
- Who is affected and how?
 
### 2. Goals & Non-Goals
- Goals: Specific, measurable outcomes
- Non-Goals: Things this proposal explicitly does NOT address
  (prevents scope creep in discussion)
 
### 3. Options Considered (most important section)
- Option A: Description, pros, cons, estimated effort
- Option B: Description, pros, cons, estimated effort
- Option C: Description, pros, cons, estimated effort
- Each option should be genuinely viable — strawmen
  undermine your credibility
 
### 4. Recommendation
- Which option and why
- What trade-offs you're accepting
- What would change this recommendation
 
### 5. Migration Plan
- Phase 1: Pilot with willing team (2-4 weeks)
- Phase 2: Expand to low-risk services (4-8 weeks)
- Phase 3: Full adoption with support (ongoing)
- Rollback plan at each phase
 
### 6. Open Questions
- What you don't know yet
- What feedback you specifically need

// ❌ One-shot influence attempts
function pushForChange(proposal: string): void {
  writeProposal(proposal);
  presentAtArchReview(proposal);
  wonderWhyNothingChanged();
}

// ✅ Compounding influence through consistent delivery
interface InfluenceActions {
  shortTerm: string[];
  mediumTerm: string[];
  longTerm: string[];
}
 
const influencePlaybook: InfluenceActions = {
  shortTerm: [
    "Help other teams when they're stuck",
    "Give thorough, constructive code reviews outside your team",
    "Write clear post-mortems that focus on systems, not blame",
    "Share context in Slack that helps people do their jobs",
  ],
  mediumTerm: [
    "Drive one cross-team project to completion",
    "Mentor an engineer who later drives their own initiatives",
    "Build a tool or library that other teams voluntarily adopt",
    "Write documentation that becomes the reference",
  ],
  longTerm: [
    "Develop a reputation for honest technical assessment",
    "Become the person leaders consult before making tech decisions",
    "Build a network of trusted peers across engineering",
    "Shape the engineering culture through consistent example",
  ],
};