Skip to content

Mentoring & Tech Leadership

Key Points

  • Senior = multiplier of others, not just individual code output.
  • Mentoring patterns: pair programming, deliberate code review, "teach the learning", growth conversations.
  • Influence without authority: build credibility; argue evidence; own outcomes.
  • Pick battles: which decisions are worth pushing on; which to let go.
  • "Grow the next senior" is a senior's KPI, even if unspoken.

Mentoring patterns

Pair programming

For a hard problem, pair with a junior. Two modes:

  • Driver/navigator: junior types; you guide.
  • Ping-pong: alternate writing test + impl.

When NOT pair: routine work; junior is in flow; one-on-one fatigue.

Deliberate code review

Use review as teaching:

  • Praise good patterns (reinforce).
  • Explain WHY for changes (not just WHAT).
  • Link to docs / ADRs.
  • Set up follow-up if pattern recurs.

Teach the learning

When a junior asks "how do I X?": - Don't just answer — show how to find out. - "Have you tried [specific search / book / colleague]?" - They build the muscle.

Avoid: pre-cooked answers. Encourages dependency.

Growth conversations

Quarterly with each report / mentee:
- What's going well?
- What's blocking you?
- What do you want to learn?
- What's one thing I can help with?

15-30 min. Not status; growth.

Document → archive → automate

When you teach the same lesson twice, write it down. Three times, automate the answer.

Senior actions

Set the bar

Code, reviews, design docs you produce define the team's quality bar.

Invest in juniors

Their growth = your leverage. A senior with 5 mid-level reports outputs more than a 10x senior IC.

Disagree well

"I disagree because [reason]. What's making you choose X?"
"I'm not sure; have you considered Y? But I trust your call."
"Strong disagreement; let's escalate to lead."

Disagree-and-commit. Document objections in ADR.

Own outcomes

When something fails, take share. Even if not your code. "I should have caught this in review."

This builds trust + license to push back.

Pick battles

Don't fight every fight. Triage:

Major (architecture, security, ship-blocking) → push hard.
Medium (best practice violation) → comment; defer to author.
Minor (style) → automate or let go.

Spending political capital on small things → no capital left for big things.

Influence without authority

You're often not anyone's manager. To influence:

Build credibility

  • Ship things that work.
  • Be reliable.
  • Follow through.
  • Take harder problems.

Credibility cashed in for influence.

Argue with evidence

"X is faster" → not enough.
"BenchmarkDotNet shows X is 30% faster on our workload" → compelling.

Numbers > opinion.

Frame your contribution

Don't say "I built X". Say "I helped the team ship Y by enabling X". Subtle; powerful.

Make others look good

Highlight team's wins. Senior who steals credit doesn't last.

Reading the room

When to push hard

  • Security risk.
  • Architectural drift.
  • Decision will be expensive to undo.

When to let go

  • Style preferences.
  • Unfamiliar tooling that's working.
  • Disagreement on choice that's reversible.

When to escalate

  • Repeated quality issues from individual → 1:1.
  • Cross-team blocker → engineering manager.
  • Compliance issue → leadership.

Tech lead vs IC senior

Role Focus
Senior IC Hard problems; multiplier through review/mentoring
Tech Lead Team's technical direction; people coordination

Some seniors prefer pure IC; others move into TL. Both legitimate paths.

Difficult conversations

Underperforming colleague

Don't dance around. Use STAR: - Situation: "In review last week..." - Task: "I expected..." - Action: "What I observed..." - Result: "Here's the impact and what I'd like to see..."

Specific; actionable; kind.

Pushback on proposal

"I appreciate the analysis; I'm not convinced because [reason].
Can we [alternative] OR see [test] before committing?"

Path forward, not just "no".

Burnout management

Self: - Boundaries on hours. - Vacation actually taken. - Hobbies outside work.

Team: - Spot signs (cynicism, withdrawal, sloppy work). - 1:1 conversation. - Workload reset.

Senior responsibility — even if not manager.

Reading list

  • The Manager's Path (Camille Fournier).
  • Staff Engineer (Will Larson).
  • Senior Engineer's Workbook (various).
  • Crucial Conversations.

Anti-patterns

  • ❌ Senior who hoards problems (no growth for team).
  • ❌ Senior who owns NO code (lost technical credibility).
  • ❌ Senior who blocks every PR with nits.
  • ❌ Senior who never says "I don't know".

Senior considerations

  • Output via others: your IC output ceiling is bound; team's isn't.
  • Default to teaching: question first; answer if needed.
  • Ship steadily: maintain technical chops.
  • Take on growing the next senior as personal goal.

Cross-references