Building Resilient Engineering Teams

resilient_team_traits:
  psychological_safety:
    - Speak up without fear
    - Admit mistakes openly
    - Ask questions freely
    - Challenge ideas respectfully

  adaptability:
    - Pivot when needed
    - Learn from failure
    - Embrace change
    - Experiment willingly

  shared_purpose:
    - Clear mission
    - Understood priorities
    - Connected to impact
    - Meaningful work

  trust:
    - Rely on each other
    - Assume positive intent
    - Deliver commitments
    - Support in difficulty

distinction:
  heroics:
    appearance: One person saves the day
    reality: Unsustainable, creates dependency
    aftermath: Burnout, single point of failure

  resilience:
    appearance: Team handles challenges together
    reality: Sustainable, distributed capability
    aftermath: Stronger team, better systems

safety_practices:
  leader_behavior:
    model_vulnerability:
      - Admit your mistakes first
      - Share what you don't know
      - Ask for help publicly

    respond_well:
      - Thank people for speaking up
      - Don't punish the messenger
      - Act on feedback

    encourage_dissent:
      - Ask for disagreement explicitly
      - Devil's advocate roles
      - Reward constructive challenge

  team_practices:
    blameless_postmortems:
      - Focus on systems, not people
      - What happened, not who did it
      - Action items, not blame

    learning_from_failure:
      - Celebrate learning
      - Share failures openly
      - Extract lessons systematically

safety_indicators:
  positive:
    - Questions in meetings
    - Disagreement expressed
    - Mistakes reported early
    - Help requested freely

  negative:
    - Silence in discussions
    - Agreement without conviction
    - Surprises in postmortems
    - Blame deflection

knowledge_distribution:
  documentation:
    architecture_decisions:
      - Record why, not just what
      - Include context and constraints
      - Update when decisions change

    runbooks:
      - Step-by-step procedures
      - Common issues and solutions
      - Updated after each incident

    onboarding:
      - Learning paths
      - Context building
      - Hands-on exercises

  practices:
    pairing:
      - Regular pair programming
      - Cross-team pairing
      - Onboarding through pairing

    rotation:
      - On-call rotation
      - Feature work rotation
      - System ownership rotation

    reviews:
      - Mandatory code review
      - Architecture review
      - Post-incident review

bus_factor:
  assessment:
    - List critical systems
    - Identify primary experts
    - Count people who can maintain
    - Target: 3+ for critical systems

  improvement:
    - Scheduled knowledge transfer
    - Shadow sessions
    - Documentation sprints
    - Cross-training time

incident_readiness:
  before:
    - Runbooks for common scenarios
    - Escalation paths defined
    - Communication templates
    - On-call training

  during:
    - Clear roles (IC, communication, etc.)
    - Regular status updates
    - Decision authority clear
    - Focus on resolution

  after:
    - Blameless postmortem
    - Action items with owners
    - Learning shared broadly
    - Systems improved

sustainable_oncall:
  rotation:
    - Minimum team size for rotation
    - Maximum frequency (1 in 4-6)
    - Weekend compensation
    - Handoff procedures

  quality:
    - Meaningful alerts only
    - Runbooks for every alert
    - Track interrupt frequency
    - Invest in reducing pages

  support:
    - Secondary on-call
    - Escalation paths
    - Mental health consideration
    - Time off after heavy shifts

stress_management:
  recognition:
    - Watch for burnout signs
    - Regular check-ins
    - Workload monitoring
    - PTO encouragement

  prevention:
    - Realistic commitments
    - Buffer in schedules
    - Saying no to low-priority
    - Protecting focus time

  support:
    - Mental health resources
    - Manager training
    - Peer support
    - Professional help access

change_resilience:
  communication:
    - Early and often
    - Honest about uncertainty
    - Clear about what's known
    - Acknowledge difficulty

  participation:
    - Involve team in decisions
    - Explain rationale
    - Listen to concerns
    - Adapt based on feedback

  stability:
    - Preserve what can stay same
    - Maintain routines where possible
    - Celebrate continuity
    - Anchor in purpose

effective_retros:
  frequency: Every 2 weeks

  format:
    what_worked: Celebrate successes
    what_didnt: Identify problems
    action_items: Specific, owned, timebound

  principles:
    - Prime directive (assume best intent)
    - Equal voice
    - Focus on systems
    - Follow through on actions

  variations:
    - Start/stop/continue
    - 4Ls (liked, learned, lacked, longed for)
    - Timeline retrospective
    - Sailboat (wind, anchor, rocks)

celebration_practices:
  why_it_matters:
    - Builds positive momentum
    - Reinforces good behavior
    - Creates team identity
    - Balances criticism

  what_to_celebrate:
    - Launches and completions
    - Learning from failures
    - Helping teammates
    - Overcoming challenges

  how_to_celebrate:
    - Public recognition
    - Team gatherings
    - Personal thanks
    - Symbolic rewards