Leading Without Authority: Influence for Senior Engineers

// ❌ How engineers destroy credibility
interface CredibilityAntiPattern {
  behavior: string;
  consequence: string;
}
 
const credibilityKillers: CredibilityAntiPattern[] = [
  {
    behavior: "Over-promising timelines to appear productive",
    consequence: "Repeated misses erode trust in all future estimates",
  },
  {
    behavior: "Advocating for technology without understanding trade-offs",
    consequence: "Perceived as trend-chasing, not engineering",
  },
  {
    behavior: "Criticizing others' code publicly without proposing alternatives",
    consequence: "People avoid collaborating with you",
  },
  {
    behavior: "Taking credit for team achievements",
    consequence: "Team stops sharing information and supporting your ideas",
  },
];
 
// ✅ How engineers build credibility
interface CredibilityBuilder {
  practice: string;
  mechanism: string;
  timeframe: string;
}
 
const credibilityBuilders: CredibilityBuilder[] = [
  {
    practice: "Under-promise, over-deliver on estimates",
    mechanism: "People learn your estimates are reliable",
    timeframe: "3-6 months of consistent delivery",
  },
  {
    practice: "Present trade-offs honestly, including for your preferred option",
    mechanism: "People trust you are optimizing for the team, not ego",
    timeframe: "Immediate effect, compounds over time",
  },
  {
    practice: "Give credit generously and specifically",
    mechanism: "People want to work with you and support your initiatives",
    timeframe: "Weeks to see reciprocity",
  },
  {
    practice: "Admit when you are wrong, publicly and promptly",
    mechanism: "Counterintuitively builds more trust than never being wrong",
    timeframe: "Immediate when done authentically",
  },
];

interface TechnicalDocument {
  type: string;
  purpose: string;
  audience: string[];
  structure: string[];
  influenceMechanism: string;
}
 
const highImpactDocuments: TechnicalDocument[] = [
  {
    type: "RFC / Design Document",
    purpose: "Propose a technical decision and gather feedback",
    audience: ["Engineers", "Tech leads", "Staff engineers"],
    structure: [
      "Context: Why are we discussing this now?",
      "Problem: What specific problem are we solving?",
      "Proposal: What do you recommend and why?",
      "Alternatives: What else did you consider?",
      "Trade-offs: What are the costs of this approach?",
      "Migration: How do we get from here to there?",
    ],
    influenceMechanism:
      "Frames the discussion around your analysis, making your recommendation the default",
  },
  {
    type: "Post-Implementation Review",
    purpose: "Document what was learned after a project ships",
    audience: ["Current team", "Future engineers", "Leadership"],
    structure: [
      "What we built and why",
      "What went well",
      "What we would do differently",
      "Quantified impact",
    ],
    influenceMechanism:
      "Demonstrates learning orientation and provides reusable institutional knowledge",
  },
  {
    type: "Technical Strategy Brief",
    purpose: "Align the team on long-term technical direction",
    audience: ["Engineering leadership", "Product managers"],
    structure: [
      "Current state assessment",
      "Target state vision",
      "Gap analysis",
      "Proposed roadmap with milestones",
      "Resource requirements",
    ],
    influenceMechanism:
      "Positions you as someone who thinks strategically, not just tactically",
  },
];

interface ConsensusProcess {
  phase: string;
  actions: string[];
  pitfalls: string[];
}
 
const consensusWorkflow: ConsensusProcess[] = [
  {
    phase: "1. Private Conversations",
    actions: [
      "Meet individually with key stakeholders before proposing anything",
      "Ask questions: What problems do YOU see? What constraints matter to you?",
      "Identify shared concerns and hidden constraints",
      "Incorporate their input into your proposal",
    ],
    pitfalls: [
      "Skipping this step and surprising people in a meeting",
      "Having a fixed proposal and pretending to ask for input",
    ],
  },
  {
    phase: "2. Shared Problem Definition",
    actions: [
      "Write up the problem statement incorporating everyone's input",
      "Get agreement on the problem before proposing solutions",
      "Share data that quantifies the problem's impact",
    ],
    pitfalls: [
      "Jumping to solutions before agreeing on the problem",
      "Framing the problem to only support your preferred solution",
    ],
  },
  {
    phase: "3. Collaborative Solution Design",
    actions: [
      "Present multiple options with honest trade-off analysis",
      "Facilitate discussion to surface objections early",
      "Modify your proposal based on feedback—visibly",
      "Let others own parts of the solution",
    ],
    pitfalls: [
      "Presenting one option as the only viable approach",
      "Dismissing concerns as uninformed",
    ],
  },
  {
    phase: "4. Decision and Commitment",
    actions: [
      "Summarize the decision and its rationale in writing",
      "Acknowledge trade-offs and who bears the costs",
      "Define clear next steps and owners",
    ],
    pitfalls: [
      "Leaving the decision ambiguous",
      "Not documenting dissent respectfully",
    ],
  },
];

interface DisagreementStrategy {
  situation: string;
  approach: string;
  template: string;
}
 
const disagreementStrategies: DisagreementStrategy[] = [
  {
    situation: "You think the technical direction is wrong",
    approach: "Disagree with data, propose an experiment",
    template:
      "I see the reasoning for X. My concern is [specific risk]. Would it make sense to [run a small experiment / build a prototype] to validate assumption Y before committing?",
  },
  {
    situation: "Leadership wants to ship faster than quality allows",
    approach: "Make the trade-off explicit and let them choose",
    template:
      "We can ship by [date] if we defer [specific items]. The risk is [concrete consequence]. Want me to document the trade-offs so we can make an informed call?",
  },
  {
    situation: "A peer is advocating for a technology you think is wrong",
    approach: "Ask questions that reveal trade-offs rather than asserting",
    template:
      "How does [their technology] handle [specific edge case in your system]? I want to understand if it fits our [specific constraint].",
  },
];

interface MentoringApproach {
  type: string;
  investment: string;
  reach: string;
  influenceReturn: string;
}
 
const mentoringStrategy: MentoringApproach[] = [
  {
    type: "Code review as teaching",
    investment: "10-15 min per review with explanatory comments",
    reach: "Every engineer whose PR you review",
    influenceReturn: "Team adopts your quality standards organically",
  },
  {
    type: "Pair programming on hard problems",
    investment: "1-2 hours per session",
    reach: "1 engineer at a time, deep impact",
    influenceReturn: "Creates strong allies who understand your methodology",
  },
  {
    type: "Internal tech talks",
    investment: "2-4 hours preparation per talk",
    reach: "Entire engineering org",
    influenceReturn: "Establishes expertise and shapes team practices at scale",
  },
  {
    type: "Architecture decision documentation",
    investment: "1-2 hours per ADR",
    reach: "Current and future team members",
    influenceReturn: "Your reasoning becomes the institutional baseline",
  },
];