Senior Developer:
• Writes high-quality code independently
• Solves complex technical problems
• Mentors junior developers
• Reviews PRs and gives good feedback
• Responsible for their own deliverables

Tech Lead:
• Sets technical direction for the team
• Removes blockers so others can ship
• Makes or facilitates architectural decisions
• Communicates technical context to stakeholders
• Responsible for the team's collective deliverables

• Establish coding standards and review expectations
• Choose patterns and libraries (and explain why)
• Decide what to build vs buy vs defer
• Write Architecture Decision Records (ADRs) for major choices
• Identify technical debt that needs addressing and prioritize it

• Notice when someone has been stuck for too long — ask before they spiral
• Review PRs promptly (a stale review is a blocked developer)
• Escalate unclear requirements before the team wastes a sprint on the wrong thing
• Resolve cross-team dependencies early
• Make the hard decisions that are slowing down the team

// Bad: making all decisions yourself
if (techLead.MakesAllDecisions())
    team.WaitsAndGetsFrustrated();

// Good: structured decision-making
var options     = team.ProposeSolutions();
var tradeoffs   = techLead.AnalyzeTradeoffs(options);
var decision    = team.DecideWithContext(tradeoffs);
var adr         = techLead.WriteADR(decision);  // document for future reference

Stakeholders ask: "Can we add X feature by Friday?"
Bad answer:       "Sure." (creates crunch and broken promises)
Bad answer:       "No, that's technically impossible." (not helpful)
Good answer:      "We can ship a version of X by Friday that handles 80% of cases.
                   The full version with edge cases would take 2 more weeks.
                   Which matters most to the launch?"

Week 1-2: Listen
  • 1:1 with every team member — what's slowing them down?
  • Read the codebase, not to judge, but to understand
  • Find the most pressing pain point

Month 1: Fix one visible problem
  • Pick the thing that's slowing the team down most
  • Fix it, and make sure the team knows it's fixed
  • Build trust by delivering, not planning

Month 2-3: Set direction
  • Document decisions being made ad-hoc (create ADRs retroactively)
  • Establish a regular team rhythm: standups, retros, planning
  • Define what "done" looks like for your team's code

Mistake 1: Staying the hero coder
  You write all the hard code yourself because it's faster.
  Result: bottleneck, team doesn't grow, bus factor = 1.
  Fix: assign hard tasks with support, not with you doing it.

Mistake 2: Never saying no
  Every request from product becomes a commitment.
  Result: overcommitted team, broken trust with stakeholders.
  Fix: "Yes, and here's what we'd have to defer" or "Not this sprint, here's why."

Mistake 3: Making decisions in a vacuum
  You architect the whole system and present it as done.
  Result: team has no ownership, misses important context.
  Fix: involve the team in the design, especially for decisions that affect them daily.

Mistake 4: Avoiding conflict
  You let low-quality PRs through to avoid the awkward conversation.
  Result: codebase degrades, team standards drift.
  Fix: have the feedback conversation early and often. Specific, not personal.

Read:
  • "The Manager's Path" — Camille Fournier
  • "An Elegant Puzzle" — Will Larson
  • "Staff Engineer" — Will Larson
  • "Accelerate" — Forsgren, Humble, Kim

Practice:
  • Run a technical design session before you write any code
  • Write an ADR for your next significant architectural decision
  • Ask your team what's blocking them — and then go fix one thing