Technical Leadership Patterns & Decision Making

1// === TECHNICAL LEADERSHIP IN PRACTICE ===
2
3// 1. RFC (Request for Comments) for significant changes
4/*
5# RFC: Migrate to React Navigation 7
6
7## Background
8We're on React Navigation 5 (2 major versions behind). Benefits of v7:
9- Type-safe navigation (reduces runtime crashes by ~15%)
10- Static API (better tree-shaking, faster builds)
11- Preloading screens (faster navigation transitions)
12
13## Proposed Approach
14Phase 1 (Week 1-2): Upgrade to v6 (smaller jump, intermediate step)
15Phase 2 (Week 3-4): Upgrade to v7
16Phase 3 (Week 5): Enable type-safe navigation for all screens
17
18## Risk Assessment
19- Risk: Third-party navigation libraries may be incompatible
20  Mitigation: Audit dependencies before starting
21
22- Risk: Custom navigators may break
23  Mitigation: Identify and update in Phase 1
24
25## Rollback Plan
26If critical issues found: revert commit. Navigation state is ephemeral —
27no data migration needed.
28
29## Open Questions
301. Do we adopt the static API for new screens immediately or after full migration?
312. Should we take this opportunity to restructure our navigator hierarchy?
32*/
33
34// 2. Mentoring pattern: Pull Request as teaching moment
35/*
36REVIEW COMMENT on a PR that uses useEffect for derived state:
37
38> Instead of:
39> useEffect(() => {
40>   setFilteredItems(items.filter(i => i.active));
41> }, [items]);
42>
43> Consider using useMemo:
44> const filteredItems = useMemo(
45>   () => items.filter(i => i.active),
46>   [items]
47> );
48>
49> **Why:** useEffect for derived state is an anti-pattern because:
50> 1. It causes an extra render cycle (render → effect → setState → render again)
51> 2. There's a brief moment where filteredItems is stale/empty
52> 3. useMemo computes during render — no extra cycle, always consistent
53>
54> Reference: https://react.dev/learn/you-might-not-need-an-effect
55*/
56
57// 3. Technical decision framework
58function evaluateTechnicalDecision(options) {
59  const criteria = {
60    // Weight: 1-5 (5 = most important)
61    teamExpertise:        { weight: 4, description: 'Team can use it effectively' },
62    maintenanceBurden:    { weight: 5, description: 'Long-term maintenance cost' },
63    communitySupport:     { weight: 3, description: 'Active community & docs' },
64    performanceImpact:    { weight: 4, description: 'Runtime performance' },
65    migrationCost:        { weight: 3, description: 'Cost to adopt/migrate' },
66    bundleSizeImpact:     { weight: 2, description: 'Impact on app size' },
67  };
68  
69  // Score each option on each criterion (1-5)
70  // Calculate weighted score
71  // Decision = highest weighted score + team consensus
72  
73  // Document in ADR with scores visible
74}
75
76// 4. On-call runbook template
77/*
78# Runbook: High Crash Rate Alert
79
80## Trigger
81Crash-free rate drops below 99% (normal: 99.7%)
82
83## Immediate Actions (within 15 minutes)
841. Check Sentry for top crash
852. Determine if crash is in JS or Native
863. Check if crash correlates with recent release (within 48h)
874. If yes: consider rollback or CodePush fix
885. If no: investigate root cause
89
90## Escalation
91- JS crash: Mobile team lead
92- Native crash: Platform engineer on-call
93- Backend-caused: Backend team lead
94- If > 5% crash rate: VP of Engineering (potential app store removal)
95
96## Communication
97- Post in #incidents Slack channel
98- Update status page if user-facing
99*/