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