> 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)
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.
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).
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?
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
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 [...]”
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?)
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.)
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)
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 …
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”
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
• 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)
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
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.
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.
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?”
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.
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.