Mentoring Engineers — Growing the People Around You

As a tech lead, your output is no longer just your code.
Your output is the code your team writes — multiplied across all team members.

The multiplier effect:
  If you are 2x as productive as average and mentor nobody:
    → Team output = your output + N × average

  If you are 1.5x as productive but make each person 1.3x more effective:
    → Team output = 1.5 + N × (average × 1.3)
    → For a 5-person team: 7.5 units vs 5 + 5 units = 7.5 vs 6.5
    → Even modest mentoring multiplies more than individual heroics

Common mistakes new tech leads make:
  → Doing the work instead of teaching — faster now, no growth long-term
  → Giving answers instead of asking questions — engineer doesn't learn to reason
  → Only mentoring when someone asks — growth needs proactive investment
  → Treating all engineers the same — different experience levels need different approaches

Effective mentoring:
  → Identify what each person needs to grow (skills gap, confidence gap, knowledge gap)
  → Match your approach to their current level
  → Create space for them to struggle productively — not long enough to drown
  → Give the minimum guidance needed, then let them drive

The coaching approach: ask before telling

Scenario: Junior engineer is designing a prescription search feature inefficiently

BAD: "No, that approach has an N+1 problem. Do it like this: [writes code]"
  → Engineer does not understand why
  → Engineer doesn't learn to recognise N+1 in future code
  → Tech lead has done the work, not the engineer

BETTER: Guided questions
  → "Walk me through how this will execute for a ward with 150 patients."
  → [Engineer explains] → "How many database queries does that generate?"
  → [Engineer realises: one per patient] → "What do you think the impact is?"
  → [Engineer: "150 queries per page load — that's going to be slow"]
  → "What options do you know for fetching related data in one query in EF Core?"
  → [Engineer: "Include()?"] → "Try it and let me know what the generated SQL looks like."

The engineer arrives at the solution. They understand why.
They will recognise this pattern in their own code next time.

The coaching question structure:
  1. Describe the situation back to me (what are we doing and why?)
  2. What options have you considered?
  3. What are the trade-offs of each?
  4. What would you do if I wasn't here?
  5. What's stopping you?

Question 4 is the most powerful — it surfaces confidence gaps vs knowledge gaps.
If the engineer says "I'd do X" and X is correct — they needed confidence, not instruction.
If they say "I have no idea" — they needed knowledge.

Junior engineers (under 2 years experience):
  → Needs: foundations (naming, structure, SOLID principles), fast feedback loops,
            psychological safety to ask "stupid questions"
  → Your role: pair programming, frequent check-ins, detailed code review explanations
  → Watch for: getting stuck silently (pride or anxiety — both block progress)
  → Growth metric: can they ship a small feature end-to-end with minimal supervision?

Mid-level engineers (2–5 years):
  → Needs: architectural thinking, cross-cutting concerns, ownership of larger features
  → Your role: assign whole features (not just tasks), review architecture not just code,
               give context on why (not just what)
  → Watch for: solving locally without considering system-wide impact
  → Growth metric: can they scope and deliver a feature from requirements to production?

Senior engineers:
  → Needs: technical leadership opportunities, influence beyond their immediate work,
           visibility with stakeholders
  → Your role: involve them in architecture decisions, give them design ownership,
               advocate for their work with leadership
  → Watch for: "brilliant jerk" behaviour — high technical output, low team lift
  → Growth metric: are they making the engineers around them better?

One size does not fit all.
What motivates a senior engineer (autonomy, impact, influence) can overwhelm a junior.
What supports a junior (close feedback, clear tasks) can feel micromanaging to a senior.

1-on-1s: weekly 30-minute conversations, engineer drives the agenda

Structure that works:
  → First 20 minutes: engineer's topics (blockers, concerns, wins, questions)
  → Last 10 minutes: your topics (feedback, context, upcoming changes)

Questions to build a habit of asking:
  → "What's going well that we should do more of?"
  → "What's getting in your way?"
  → "What are you working on that you're finding most interesting?"
  → "Is there anything you're worried about that we haven't talked about?"
  → Periodically: "What would you like to be doing more of in 6 months?"

What 1-on-1s are NOT for:
  → Status updates (get those elsewhere)
  → Bombarding them with your agenda
  → Only giving critical feedback (saves up for difficult conversations)

The most common 1-on-1 mistake:
  Cancelling them. Especially when busy.
  The signal: "When things are hard, my 1-on-1 gets cancelled."
  Engineers learn not to rely on you when they need support most.
  Protect 1-on-1s. Move them, but don't cancel.

Writing down what you discussed:
  Keep brief notes (a few bullets, not a transcript).
  Follow up on things said in previous 1-on-1s — "last week you mentioned X..."
  This shows you listened. Engineers notice.

The SBI model for feedback (Situation, Behaviour, Impact):

Situation:  specific moment or context
Behaviour:  observable action (not interpretation)
Impact:     effect on the team, product, or clinical users

Example — positive:
  BAD:  "Good job on the prescription approval feature."
  GOOD: "In yesterday's sprint review [Situation], you walked the clinical team through
         the new INR validation [Behaviour]. The lead pharmacist said it was exactly
         what they needed and it built their confidence in the system [Impact].
         That kind of user-facing communication is something I want to see more of."

Example — constructive:
  BAD:  "You need to communicate more."
  GOOD: "In the architecture discussion on Tuesday [Situation], you had a concern about
         the event store approach but didn't raise it in the meeting [Behaviour].
         We spent 2 days on an implementation that your concern would have flagged earlier [Impact].
         I want to make sure the team hears your perspective — what would make it easier
         to raise concerns in group discussions?"

Rules:
  → Give feedback soon after the event — not 3 weeks later
  → Private for constructive, can be public for positive
  → One topic at a time — don't stack three things into one conversation
  → End constructive feedback with a question — invite their view

The transition from engineer to tech lead is the hardest career shift in software engineering.

What changes:
  Your success metric is no longer the quality of your code alone.
  It is the quality of what your team ships together.

What doesn't change:
  You still need to be technically credible — you need to keep coding,
  even if less than before. If you stop writing code, you lose:
  → Context for reviewing others' code
  → Credibility when making technical recommendations
  → Shared experience with the team ("I know that problem")

The hardest things about the transition:
  1. Letting go: watching someone else do something slower than you could
     → The instinct is to take over. Resist it. They need to grow.
  2. Invisible work: architecture discussions, decisions, mentoring don't produce PRs
     → Your "output" is harder to see — this can feel uncomfortable
  3. Accountability without authority: you're responsible for team outcomes
     but you don't control everyone's priorities, decisions, and timelines
  4. Context switching: juggling code + reviews + architecture + stakeholders
     → Your flow time is fragmented. Protect dedicated code time.

What makes tech leads successful long-term:
  → They grow the people around them
  → They make good technical decisions and communicate them clearly
  → They shield the team from unnecessary noise while keeping them connected
     to the right context
  → They know what they don't know — and hire or build for the gaps