$30 off During Our Annual Pro Sale. View Details »

1:1 basics for the introvert Engineering Manager

1:1 basics for the introvert Engineering Manager

i.e. how to use more emotions than code, for people who use more code than emotions

Oren Ellenbogen

March 28, 2017
Tweet

More Decks by Oren Ellenbogen

Other Decks in Programming

Transcript

  1. 1:1 basics for
    the introvert
    Engineering Manager
    @orenellenbogen
    i.e. how to use more emotions than code, for
    people who use more code than emotions

    View Slide

  2. @orenellenbogen
    VP Engineering at
    on
    Also the behind http://softwareleadweekly.com &
    http://leadingsnowflakes.coom
    About me?
    Until recently, 17 bi-weekly 1:1s (flat eng. org)

    View Slide

  3. AXIOMS
    [1] People deserve great 1:1s.
    [2] This is one of your best ways to
    provide value (“unfair advantage”).
    [3] This is one of the best ways to
    build long-lasting trust.

    View Slide

  4. Agenda
    Providing a mental framework
    for running effective 1:1s:
    - Purpose
    - Preparing for 1:1s
    - The 1st 1:1
    - Strategic growth
    - Pitfalls
    - Is it working?
    - Moooar!! (resources)

    View Slide

  5. FOCUS
    I will focus around mindset and
    healthy habits.
    “Which questions should I ask” has
    good coverage too (links at the end J)

    View Slide

  6. Purpose (Why 1:1?)
    • Building trust around mutual goals
    (company > team > individual)
    • Mentor: growth is a side-product,
    hyper-growth needs intentional practice
    • How is work being done? How do they feel
    about that? (versus “What are you working on?”)
    • Leverage peer pressure (i.e. standards)
    to build a cohesive team
    • Providing honest feedback
    (killing any passive-aggressive tension)

    View Slide

  7. 1:1s
    Preparations
    Strategy & tactics

    View Slide

  8. Strategy
    • Context: company’s goals, team’s
    goals, your goals, their goals.
    • Draft: Can you explain where they
    fit into the big plan, or at least
    start a discussion around it?
    Write all the things down. Share
    it with them early on, let them
    help drafting it.

    View Slide

  9. e.g.
    Principles/values, KPIs, roles, domain expertise, potential growth etc.

    View Slide

  10. Tactics
    • Scheduling time
    • Meeting description
    • Getting ready for the meeting
    • Summarizing 1:1 notes (+ utilize)

    View Slide

  11. Calendar
    • 30 minutes. Bi-weekly.
    • 45 minutes? Weekly?
    • Block 15 minutes after.
    • e.g. 11:00-11:30, next meeting at 11:45.
    • Meeting description should include
    previous Performance Review’s
    goals (reminder of growth).

    View Slide

  12. Getting ready (my trigger Qs)
    • Any relevant follow up on previous notes?
    • Any great achievement made since last 1:1?
    • Any improvement of their system understanding?
    • Any improvement of their code/design quality?
    • How many features they run in parallel now?
    How can they reduce it? How can you help?
    • How do they communicate progress? Are they
    active or you need to “pull” it from them?
    Talk about the importance of having them
    leading. It can be within feature or their
    weekly planning.
    • Do you feel they lack context? Do they
    understand why they are doing what they’re
    doing? Did they ask good questions?
    • Are they saying “NO!” enough times? Can you
    help them define when they should say no?

    View Slide

  13. Trigger
    questions
    You can do better though:
    Check the resources at
    the end of the slides and
    write down the questions
    you liked. Make it yours.

    View Slide

  14. Taking notes
    • Aim for TL;DR version, with clear action
    items in it. Include only must-have
    context for it.
    • Aim for them to take lead, but you
    should start to show structure &
    language.
    • Gmail: one-on-one à [name] labels

    View Slide

  15. Taking notes

    View Slide

  16. Taking notes

    View Slide

  17. Taking notes

    View Slide

  18. 1st time
    1:1
    Yes, it will feel awkward. So what?

    View Slide

  19. 100% explicit & honest
    It will be awkward, get over it &
    embrace it.
    Start with “well, that’s kind of
    awkward, right? It’s our first 1:1
    and I want us to make the most of it,
    so if you’re okay with it, I did
    prepare some questions [...]”

    View Slide

  20. Then…
    • How often would you like to do our
    1:1s based on previous experience?
    • What makes 1:1s valuable for you?
    • Can you share what worked well before so I
    could try to keep it?
    • What was missing that you hope I could add?
    • How would you like me to provide
    you with constructive feedback?
    (e.g. Slack? Email? Face-to-face?)

    View Slide

  21. Strategic
    growth
    It’s everywhere

    View Slide

  22. Areas of growth
    • Code quality
    • Architecture + Design Reviews
    • Reaching consensus
    • Project Management
    • Communication
    • Time management
    • Delegating work
    • Working well with others (lead with
    strength, compensate for weakness)
    • Career Path++ (à Architect, co-
    founder, EM, CTO etc.)

    View Slide

  23. 1:1s to provide context
    & expectations
    • Raise a mutual goal and explain an
    opportunity (them à company à team à them)
    • This is where you could set clear
    and explicit expectations:
    Behaviors, outcome, where to
    focus, pitfalls etc.
    (concrete examples to follow)

    View Slide

  24. Leverage opportunities
    & let them practice
    • Join someone else to see them
    leading Design Review à prod
    • Lead a feature
    • Lead an infra change (cross-teams)
    • Communicate with peers, PM &
    management (build org trust)
    • Become a service chief/owner
    • Lead a project

    View Slide

  25. Example: Junior Engineer
    wants to level up
    • Which books to read?
    • How to ask “good questions” &
    when?
    • How to learn from others (e.g.
    follow up on learnings)
    • How to measure “good pull request”
    • Who you should work with & why
    • How to measure “good code”

    View Slide

  26. Example: Senior
    Engineer during
    onboarding
    • Focusing on understanding the
    business and the system (context)
    • Reduce fear of “proving value”
    • Who they should work with & why
    • Make their strength explicit (both
    sides)
    • Building trust with their
    teammates

    View Slide

  27. Example: IC wants to be
    EM as new career path
    • Being positive & driving momentum
    towards quick valuable releases
    • Improving their Project Management
    skills (so they can teach later)
    • Mastering communication with peers
    & management (status, risks)
    • Figuring out if they enjoy
    interactions with others, and
    making others better (vs code)

    View Slide

  28. Example: Senior
    Engineer wants to be an
    Architect/Principal
    • Understand the business lifecycle
    and what moves the needle
    • Being positive (we can do X,
    versus “this is not the way to…”)
    • Explain tradeoffs vs making a
    decision or “trying to win”
    • Building relationships, so they
    could technically amplify team
    • Building a network outside of work

    View Slide

  29. Pitfalls &
    tips
    aka “works on my 1:1s”

    View Slide

  30. Pitfalls & tips
    Agree on an escalation policy in
    advance, so 1:1s will be around
    growth rather than putting out
    immediate fires.

    View Slide

  31. Pitfalls & tips
    • 1:1s should not be status meetings. It’s
    easy to go there, so be careful. Prefer
    to focus on “How they feel about the
    work” rather than “What they’re working
    on”.
    • You can schedule a “status meeting” if
    this is needed, or agree on a different
    method for that purpose.
    Status meeting is a “1:1 smell”. It often
    happens as you’re not prepared to lead it.

    View Slide

  32. Pitfalls & tips
    • If you need to move your 1:1, set it
    to the earliest time available that
    protects preferences on both sides.
    For example, you might want to have 1:1s at 14:00, as
    people feel less productive then. If you need to move, move
    it to 14:00 the next day. Avoid moving it later that day as
    you might impact (their) productivity.
    • Also, verify & notify on Slack. Say
    you’re sorry and why it needs to
    move. This shouldn’t happen often.

    View Slide

  33. Pitfalls & tips
    No, you don’t have to solve their
    problems. Not at first.
    Learn to ask more questions:
    “Can you explain more?”
    “Do you have any thoughts about how
    to handle it?”
    “Do you need my help here? How?”

    View Slide

  34. Pitfalls & tips
    Small talk is important, but not
    sufficient for hyper-growth.
    Building trust works if you invest
    time, empathy and effort where it
    really matters to both sides.
    Knowing their “personal story” is
    nice to have. It’s not an indicator
    for high trust.

    View Slide

  35. How do I
    know if it’s
    working?
    It’s ~simple. Observe. Ask.

    View Slide

  36. • They tell you it’s helpful
    • They feel motivated to push
    themselves harder, i.e. energy++
    • They have clearer understanding of
    their role (fit the puzzle)
    • They understand what is expected
    from them (alignment)
    You should explicitly ask for the
    above every now and then.

    View Slide

  37. Resources
    • Questions for our first 1:1
    • The Art of the Awkward 1:1
    • On 1:1s
    • Peer 1:1s
    • How to have an honest 1:1 with an employee
    • 101 Questions to Ask in One on Ones
    • What's next?

    View Slide

  38. @orenellenbogen
    Oren Ellenbogen ([email protected])
    Ask Me
    Anything J
    Resources to follow on https://bit.ly/oren1:1s

    View Slide