Engineering Manager Toolkit

ONE-ON-ONE MEETING STRUCTURE
==============================
Frequency: Weekly, 30-45 minutes (never skip, reschedule instead)
Owner: The direct report owns the agenda, you guide the conversation

AGENDA TEMPLATE:
  1. CHECK-IN (5 min)
     - How are you doing? (genuinely, not just work)
     - Anything on your mind this week?

  2. THEIR TOPICS (15-20 min)
     - What do they want to discuss?
     - What blockers need your help?
     - What decisions need your input?

  3. YOUR TOPICS (5-10 min)
     - Feedback (specific, timely, balanced)
     - Context from leadership or org changes
     - Project updates or priority shifts

  4. GROWTH AND DEVELOPMENT (5 min, at least biweekly)
     - Progress on career goals
     - Learning opportunities
     - Stretch assignments

  5. ACTION ITEMS (2 min)
     - What are you both committing to do before next 1:1?

QUESTIONS BY CATEGORY
======================

ENGAGEMENT AND SATISFACTION:
  - What is the most interesting thing you worked on this week?
  - Is there anything about your work that frustrates you?
  - On a scale of 1-10, how happy are you at work right now? Why?
  - What would make your work more enjoyable?

FEEDBACK AND GROWTH:
  - What feedback do you have for me?
  - Is there a skill you want to develop? How can I support that?
  - Do you feel you are growing in your role?
  - What is the biggest thing you learned recently?

TEAM DYNAMICS:
  - How is your relationship with the rest of the team?
  - Is there anyone you feel you work particularly well with?
  - Are there any interpersonal issues I should know about?
  - Do you feel your contributions are recognized?

BLOCKERS AND SUPPORT:
  - What is slowing you down right now?
  - Do you have everything you need to do your best work?
  - Are there meetings that feel wasteful to you?
  - How can I be more helpful to you?

CAREER AND FUTURE:
  - Where do you see yourself in 2 years?
  - Is there a role or project you are interested in that we should discuss?
  - Do you feel you are being challenged enough?
  - What would make you consider leaving? (ask periodically, builds trust)

PERFORMANCE REVIEW STRUCTURE
==============================
Frequency: Formal reviews every 6 months, continuous feedback always

DIMENSIONS TO EVALUATE:
  1. TECHNICAL EXECUTION (does the work)
     - Code quality and reliability
     - Technical decision-making
     - Meeting commitments and deadlines
     - Learning and adapting to new technologies

  2. IMPACT (moves the needle)
     - Scope and significance of contributions
     - Business outcomes influenced
     - Problem identification and resolution
     - Initiative and proactive improvements

  3. COLLABORATION (multiplies the team)
     - Code reviews and knowledge sharing
     - Mentoring junior team members
     - Cross-team communication
     - Documentation and knowledge capture

  4. LEADERSHIP (shapes the direction)
     - Technical leadership and influence
     - Process improvement initiatives
     - Recruitment and onboarding contributions
     - Handling ambiguity and driving alignment

RATING SCALE:
  Exceeds Expectations: Consistently delivers beyond the level
  Meets Expectations:   Solid, reliable performance at level
  Developing:           Growing into the role, some gaps
  Below Expectations:   Not meeting the bar, needs improvement plan

CRITICAL RULE:
  Nothing in the review should be a surprise.
  If it is, you failed at continuous feedback.

FEEDBACK FORMULA: SBI + REQUEST
=================================
S = Situation: When and where
B = Behavior: What they specifically did (observable)
I = Impact: What happened as a result
R = Request: What to do differently (or continue)

POSITIVE EXAMPLE:
  "In last week's architecture review [S], you clearly presented the
  trade-offs between the two approaches and facilitated a decision
  the team aligned on [B]. This saved us at least a week of debate
  and the team felt confident in the direction [I]. Keep doing this
  on future design decisions [R]."

CONSTRUCTIVE EXAMPLE:
  "During sprint planning yesterday [S], you committed to 3 stories
  without flagging the dependency on the API team [B]. This created
  a blocker by Wednesday that the team had to scramble around [I].
  Going forward, please flag cross-team dependencies during planning
  so we can address them upfront [R]."

FEEDBACK PRINCIPLES:
  - Give feedback within 48 hours (timeliness matters)
  - Be specific (avoid "good job" or "needs improvement")
  - Focus on behavior, not character
  - 3:1 ratio of positive to constructive (minimum)
  - Feedback is a conversation, not a lecture
  - Ask: "How did you see that situation?" before giving your view

TEAM HEALTH CHECK (run quarterly)
===================================
Score each dimension 1-5 (anonymous team survey)

PSYCHOLOGICAL SAFETY
  "I feel safe taking risks and admitting mistakes"         [ ]
  "I can disagree with my manager without fear"             [ ]
  "My mistakes are treated as learning opportunities"       [ ]

CLARITY
  "I understand our team's top priorities"                  [ ]
  "I know what is expected of me"                           [ ]
  "I understand how my work connects to company goals"      [ ]

AUTONOMY
  "I have enough freedom to do my work effectively"         [ ]
  "I am trusted to make decisions in my area"               [ ]
  "I do not feel micromanaged"                              [ ]

GROWTH
  "I am learning and growing in my role"                    [ ]
  "I see a clear path for career advancement"               [ ]
  "My manager invests in my development"                    [ ]

WORKLOAD
  "My workload is sustainable long-term"                    [ ]
  "I rarely work weekends or late nights"                   [ ]
  "I can take PTO without guilt"                            [ ]

COLLABORATION
  "I enjoy working with my teammates"                       [ ]
  "We communicate well as a team"                           [ ]
  "We help each other succeed"                              [ ]

SCORING:
  4.0+:    Healthy team, maintain and refine
  3.0-3.9: Some areas need attention, create action plan
  2.0-2.9: Significant issues, prioritize team health
  < 2.0:   Crisis mode, address immediately

PSYCHOLOGICAL SAFETY PRACTICES
================================
AS A MANAGER, MODEL THESE BEHAVIORS:

1. ADMIT YOUR OWN MISTAKES PUBLICLY
   "I made the wrong call on X. Here is what I learned."
   This gives permission for others to be honest about errors.

2. ASK FOR FEEDBACK ON YOURSELF
   "What could I do better as your manager?"
   Act on what you hear. If you ask and ignore, trust erodes.

3. RESPOND TO BAD NEWS WITH CURIOSITY, NOT BLAME
   Instead of: "Why did this happen?"
   Try: "What can we learn? What would we do differently?"

4. CELEBRATE LEARNING FROM FAILURES
   In retros, highlight what was learned, not who was wrong.
   "This incident taught us X, which makes us better."

5. MAKE IT SAFE TO SAY "I DON'T KNOW"
   When someone says they do not know, thank them.
   Punishing honesty guarantees you will stop hearing the truth.

6. PROTECT YOUR TEAM FROM BLAME CULTURE
   Shield them from external blame.
   "My team made a decision and I supported it. Here is our plan."

CONFLICT RESOLUTION FRAMEWORK
================================
STEP 1: IDENTIFY THE TYPE
  Technical disagreement:  Architecture, approach, technology choice
  Interpersonal friction:  Communication style, personality clash
  Role ambiguity:          Overlapping responsibilities, unclear ownership
  Values conflict:         Different principles about quality, speed, etc.
  Resource conflict:       Competing for headcount, budget, or priority

STEP 2: ASSESS SEVERITY
  Low:    One-off disagreement, no pattern
  Medium: Recurring tension, affecting collaboration
  High:   Active conflict, affecting team morale or output

STEP 3: INTERVENE APPROPRIATELY
  Low:
    - Coach both parties individually in 1:1s
    - Provide frameworks for resolving technical disagreements
    - "Have you talked to them directly about this?"

  Medium:
    - Facilitate a structured conversation between parties
    - Set clear expectations and boundaries
    - Follow up to ensure resolution holds

  High:
    - Mediate directly, hear both sides separately first
    - Establish ground rules for the conversation
    - Define specific behavior changes required
    - Set timeline for improvement
    - Involve HR if pattern continues

MEDIATION CONVERSATION STRUCTURE:
  1. "I have noticed tension between you two. I want to help resolve it."
  2. "Each of you will have 5 minutes to share your perspective uninterrupted."
  3. "What do you both agree on?"
  4. "What specific changes would improve the situation?"
  5. "Let's agree on 2-3 concrete actions each of you will take."
  6. "I will check in with both of you in two weeks."

CAREER LADDER OVERVIEW
========================
INDIVIDUAL CONTRIBUTOR TRACK:
  Junior Engineer (L1-L2):
    Scope: Task-level, guided by senior engineers
    Impact: Completes well-defined work items
    Growth: Building fundamental skills

  Mid-Level Engineer (L3):
    Scope: Feature-level, increasingly independent
    Impact: Designs and delivers features end-to-end
    Growth: Developing judgment and ownership

  Senior Engineer (L4):
    Scope: System-level, leads technical efforts
    Impact: Designs systems, mentors others, improves processes
    Growth: Technical leadership, cross-team influence

  Staff Engineer (L5):
    Scope: Multi-team, sets technical direction
    Impact: Solves ambiguous problems, defines architecture
    Growth: Organizational influence, strategic thinking

  Principal Engineer (L6+):
    Scope: Org-wide or company-wide
    Impact: Shapes technical strategy, industry influence
    Growth: Vision setting, external thought leadership

MANAGEMENT TRACK:
  Engineering Manager:  Manages 5-8 engineers, one team
  Senior EM:            Manages 2-3 teams or managers
  Director:             Manages a function or large group
  VP Engineering:       Manages multiple directors
  CTO:                  Sets company-wide technical vision

KEY PRINCIPLE:
  IC and management tracks should have equal prestige and compensation.
  Management is not a promotion; it is a career change.

CAREER DEVELOPMENT CONVERSATION (quarterly)
=============================================
1. WHERE ARE YOU NOW?
   - Current level and key strengths
   - What work energizes you most?
   - What are your biggest gaps relative to next level?

2. WHERE DO YOU WANT TO GO?
   - IC or management track? (revisit periodically)
   - What does success look like in 1-2 years?
   - Are there specific roles, projects, or skills you want?

3. HOW DO WE GET THERE?
   - What stretch assignments can we find?
   - What skills need development? (create a plan)
   - Who could mentor you in those areas?
   - What conferences, courses, or resources would help?

4. ACTION PLAN
   Goal:                 ___________________________
   Key skill to develop: ___________________________
   Action step 1:        ___________________________  By: ________
   Action step 2:        ___________________________  By: ________
   Check-in date:        ___________________________

TECHNICAL DEBT FRAMEWORK
==========================
CATEGORIZE:
  Critical:     Causes outages, data loss, or security vulnerabilities
  High:         Slows development significantly (>20% velocity impact)
  Medium:       Creates friction but workarounds exist
  Low:          Cosmetic or nice-to-have improvements

ALLOCATION STRATEGY:
  Recommended: Dedicate 15-25% of sprint capacity to tech debt
  Approaches:
    - "Tech debt Fridays" (one day per sprint)
    - Rotating tech debt champion per sprint
    - One full tech debt sprint per quarter
    - Include tech debt in every feature estimate (+20% buffer)

COMMUNICATING TO STAKEHOLDERS:
  Do NOT say: "We need to refactor the codebase"
  DO say: "Feature X takes 3 weeks with current debt. With a 2-week
  investment in Y, it drops to 1 week, and all future features in
  that area get faster. Net: 2 weeks saved this quarter."

  Frame tech debt in business terms:
  - Velocity impact (stories/sprint before vs. after)
  - Incident risk (outage probability and cost)
  - Hiring impact (good engineers avoid messy codebases)
  - Feature speed (time to ship with vs. without investment)