Der Wechsel vom Individual Contributor zum Tech Lead

// ❌ Week 1 as tech lead — still operating as an IC
const myWeek = {
  monday: 'Deep coding on feature X (8 hours)',
  tuesday: 'Deep coding on feature X (8 hours)',
  wednesday: 'Code review (1 hour), coding (7 hours)',
  thursday: 'Standup (15 min), coding (7.75 hours)',
  friday: 'Coding (6 hours), team retro I forgot about (1 hour)',
  // Team members are blocked, waiting for decisions
  // No one knows the technical direction
};
 
// ✅ Week 1 as tech lead — intentional time allocation
const myWeek = {
  monday: '1:1s with 3 reports (3 hours), architecture review (2h), coding (3h)',
  tuesday: 'Sprint planning (1.5h), unblock Maria on API design (1h), coding (5h)',
  wednesday: 'Code reviews (2h), coding on critical path (4h), doc writing (2h)',
  thursday: 'Cross-team sync (1h), mentor session (1h), coding (4h), hiring (2h)',
  friday: 'Retro (1h), tech debt review (1h), coding (3h), week planning (1h)',
  // Team is unblocked, direction is clear, lead still writes code
};

interface DelegationDecision {
  task: string;
  shouldDelegate: boolean;
  reason: string;
  delegateTo?: string;
  supportNeeded?: string;
}
 
function evaluateDelegation(task: Task): DelegationDecision {
  // Tasks only YOU should do as tech lead
  if (task.requiresOrgContext || task.isArchitecturalDecision) {
    return {
      task: task.name,
      shouldDelegate: false,
      reason: 'Requires organizational context or architectural authority',
    };
  }
 
  // Tasks you MUST delegate even if you could do them faster
  if (task.isGrowthOpportunity && task.matchesTeamMemberGoal) {
    return {
      task: task.name,
      shouldDelegate: true,
      reason: 'Growth opportunity aligned with team member career goals',
      delegateTo: task.bestFitTeamMember,
      supportNeeded: 'Pair on design, review implementation',
    };
  }
 
  // Tasks that are better done by someone with more context
  if (task.domainExpert !== 'you') {
    return {
      task: task.name,
      shouldDelegate: true,
      reason: 'Team member has deeper domain expertise',
      delegateTo: task.domainExpert,
      supportNeeded: 'Available for questions, review PR',
    };
  }
 
  return {
    task: task.name,
    shouldDelegate: true,
    reason: 'Default: delegate unless there is a reason not to',
    delegateTo: task.bestFitTeamMember,
    supportNeeded: 'Define success criteria, set check-in points',
  };
}

# ❌ Delegation anti-patterns
- "I'll just do it myself, it's faster" → Team never grows
- "Here's exactly how to implement it" → Micromanagement
- "Figure it out" with no context → Abdication, not delegation
 
# ✅ Effective delegation
- "Here's the problem and constraints. How would you approach it?"
- "I'd suggest starting with X, but I'm open to other approaches."
- "Let's check in Wednesday. If you're stuck before then, grab me."

type DecisionApproach =
  | 'directive'     // You decide, inform the team
  | 'consultative'  // Gather input, you decide
  | 'consensus'     // Team decides together
  | 'delegated';    // Someone else decides
 
function chooseApproach(decision: TechnicalDecision): DecisionApproach {
  // Urgent + low impact → just decide
  if (decision.urgency === 'high' && decision.impact === 'low') {
    return 'directive';
  }
 
  // High impact + team expertise varies → consult then decide
  if (decision.impact === 'high' && decision.teamExpertiseVaries) {
    return 'consultative';
  }
 
  // Affects everyone equally + team is experienced → consensus
  if (decision.affectsEntireTeam && decision.teamSeniority === 'high') {
    return 'consensus';
  }
 
  // Clear domain owner exists → let them decide
  if (decision.domainOwner) {
    return 'delegated';
  }
 
  return 'consultative'; // Default: gather input, then decide
}
 
// The key insight: a "good enough" decision made today
// beats a "perfect" decision made next month.
// Your job is to prevent analysis paralysis.

## One-on-One Template
 
### Opening (5 min)
- How are things going? (Open-ended, let them lead)
- Anything on your mind this week?
 
### Their Topics (15 min)
- What's blocking you right now?
- Any frustrations with process, tools, or collaboration?
- What do you need from me that you're not getting?
 
### Growth & Development (5 min)
- How is [current project] stretching your skills?
- Any areas where you want more exposure or responsibility?
- Progress on [previously discussed goal]?
 
### My Topics (5 min)
- Feedback on [specific recent work]
- Heads up on [upcoming changes that affect them]
- [Specific ask or context they need]

// ❌ Bad one-on-one patterns
const badOneOnOne = {
  frequency: 'canceled whenever something comes up',
  format: 'status update — "what are you working on?"',
  focus: 'your agenda, not theirs',
  followUp: 'none — same topics every week',
};
 
// ✅ Effective one-on-one patterns
const goodOneOnOne = {
  frequency: 'weekly, protected — only cancel for emergencies',
  format: 'their agenda first, always',
  focus: 'growth, blockers, and wellbeing',
  followUp: 'action items tracked and referenced next week',
};

# What to communicate UP (to your manager)
- Risks before they become problems
- Team capacity constraints and trade-offs
- Technical debt that affects roadmap commitments
- Team member growth and performance signals
 
# What to communicate DOWN (to your team)
- Organizational context behind priorities
- Why decisions were made (not just what was decided)
- Upcoming changes that affect their work
- Recognition — specific, public praise for good work
 
# What to communicate ACROSS (to peer leads)
- Cross-team dependencies and timelines
- Shared technical standards and patterns
- Lessons learned from incidents or migrations

// ❌ Code you should NOT write as a tech lead
const avoidCoding = [
  'Features on the critical path that block others if delayed',
  'Highly specialized work that only you can do (bus factor = 1)',
  'Anything you picked up because "it was faster to do it myself"',
];
 
// ✅ Code you SHOULD write as a tech lead
const priorityCoding = [
  'Prototypes and proof-of-concepts for architectural decisions',
  'Developer tooling and infrastructure that multiplies the team',
  'Complex bug investigations that require broad system knowledge',
  'Code reviews — reading code is more valuable than writing it',
  'Pairing sessions with junior engineers on tricky problems',
];