i.e. how to use more emotions than code, for people who use more code than emotions
1:1 basics for
i.e. how to use more emotions than code, for
people who use more code than emotions
VP Engineering at
Also the behind http://softwareleadweekly.com &
Until recently, 17 bi-weekly 1:1s (flat eng. org)
 People deserve great 1:1s.
 This is one of your best ways to
provide value (“unfair advantage”).
 This is one of the best ways to
build long-lasting trust.
Providing a mental framework
for running effective 1:1s:
- Preparing for 1:1s
- The 1st 1:1
- Strategic growth
- Is it working?
- Moooar!! (resources)
I will focus around mindset and
“Which questions should I ask” has
good coverage too (links at the end J)
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)
Strategy & tactics
• 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.
Principles/values, KPIs, roles, domain expertise, potential growth etc.
• Scheduling time
• Meeting description
• Getting ready for the meeting
• Summarizing 1:1 notes (+ utilize)
• 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).
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
• 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?
You can do better though:
Check the resources at
the end of the slides and
write down the questions
you liked. Make it yours.
• 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 &
• Gmail: one-on-one à [name] labels
Yes, it will feel awkward. So what?
100% explicit & honest
It will be awkward, get over 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 [...]”
• 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?)
Areas of growth
• Code quality
• Architecture + Design Reviews
• Reaching consensus
• Project Management
• Time management
• Delegating work
• Working well with others (lead with
strength, compensate for weakness)
• Career Path++ (à Architect, co-
founder, EM, CTO etc.)
1:1s to provide context
• 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)
& 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
Example: Junior Engineer
wants to level up
• Which books to read?
• How to ask “good questions” &
• 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”
• 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
• Building trust with their
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)
Engineer wants to be an
• 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
aka “works on my 1:1s”
Pitfalls & tips
Agree on an escalation policy in
advance, so 1:1s will be around
growth rather than putting out
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
• 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.
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.
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?”
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.
How do I
know if it’s
It’s ~simple. Observe. Ask.
• 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.
• 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?
Oren Ellenbogen ([email protected])
Resources to follow on https://bit.ly/oren1:1s