Skip to content

Transitioning from Individual Contributor to Tech Lead

A practical guide to the shift from IC to tech lead: delegation, technical decision-making, one-on-ones and redefining productivity through your team.

5 min read
Diagram showing the transition from individual contributor work to team-multiplier work as a tech lead

The transition from individual contributor to tech lead is not a promotion in the traditional sense. It is a role change. The skills that made you an excellent IC — deep focus, fast coding, solving problems yourself — can actively harm you as a tech lead if you do not adapt them. Your job is no longer to write the best code. Your job is to make sure your team ships the best software.

This is the hardest part of the transition: redefining what a productive day looks like. A productive IC day means merged PRs and solved problems. A productive tech lead day might mean zero lines of code but three unblocked teammates, one architectural decision made, and one difficult conversation handled.

The First 90 Days

The first three months set the pattern. Most new tech leads make one of two mistakes: they either keep coding at the same rate (ignoring leadership responsibilities) or they stop coding entirely (losing technical credibility). The goal is a deliberate balance.

tstypescript
// ❌ 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
};

Delegation Is Not Abdication

The hardest skill to develop is delegation. As an IC, you knew that you could implement something faster than explaining it to someone else. As a tech lead, doing it yourself is a failure mode. Every task you do not delegate is a missed growth opportunity for your team.

tstypescript
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',
  };
}
markdownmarkdown
# ❌ 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."

Technical Decision-Making

As a tech lead, you are the final decision-maker for technical choices within your team's scope. This does not mean you make decisions alone. It means you ensure decisions get made, with the right people consulted, in a reasonable timeframe.

tstypescript
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.

Running Effective One-on-Ones

One-on-ones are your most important recurring meeting. They are not status updates — you have standups for that. One-on-ones are about the person: their growth, their blockers, their concerns, and their career trajectory.

markdownmarkdown
## 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]
tstypescript
// ❌ 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',
};

Managing Up and Across

Your relationship with your manager and peer tech leads becomes critical. You are the bridge between your team and the rest of the organization. Information flows through you in both directions.

markdownmarkdown
# 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

Staying Technical

A tech lead who stops writing code loses credibility and context. But your coding time is limited, so choose what you work on carefully.

tstypescript
// ❌ 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',
];

Key Takeaways

  1. Redefine productivity — your output is now measured by team throughput, not personal code output
  2. Delegate by default — only keep tasks that require your specific organizational context or architectural authority
  3. Protect your one-on-ones — they are your most important meeting; never cancel them for "something more urgent"
  4. Make decisions, don't delay them — a good decision now beats a perfect decision next month
  5. Stay technical intentionally — write prototypes, review code, and pair with your team; stop writing critical-path features
  6. Communicate in all directions — you are the information bridge between your team, your manager, and peer teams
Wilfredo Rujel

Wilfredo Rujel

Full Stack Software Engineer

Share this postX