4. understand strategic decisions, align your decision making process with the team

3. known issues may have be chosen not to be fixed by the team - work out why! understand tactical decisions

2. learn the workflow of the new team, get into code but start with small changes

1. being new is a great time to ask questions. respect what came before and assume best intentions

Daniel Tomko’s onboarding series:

Push back on ambiguous/controversial changes that could result in you getting blocked

You want to try avoid sidequests where you can and stay focused on getting wins

Pairing is great for seeing how other people work + forces you to verbalise what you’re thinking

The biggest mistake engineers make is excessively reading code and documentation

they can introduce you to people and lend you their social capital

Ask high quality questions: make it easier for the other people to share the knowledge you need

talking about emotions is how you have deeper conversations

figure out your support channels!

they help you with technical questions and be your first stop for issues

having an onboarding buddy is really important

Within a group of people (e.g., your team)

Within a certain domain (the build system)

Within a certain time (e.g., a week)

You can become more knowledgeable than anyone

how often do you want feedback

what’s your preference for written vs verbal updates, and the format?

how often do you want to meet?

Talk to your manager/teammates on how they want to work together

who else should you talk to?

active experiemnts

major pain points

time spent breakdown

code contributions - prs opened and reviewed

weekly/quarterly priorities

Talk: get a sense for the challenges your team is facing

Observe: understand prioritiries and patterns by seeing how people work

actions speak louder than words

engineering rubric/career matrix (expectations per level)

It’s good to have urgency when you’re onboarding and push to start contributing quickly

starter project ideas

expectations + milestones (specific, measurable goals)

team charter and missions

most people fall into either: (1) panicked noob (2) complacent noob

write an onboarding doc

e.g., rahul is the kindest engineer I’ve ever worked with

instead of “thanks for the pointer”, write more specific, “thanks for helping me, you unblocked a critical milestone of this project”

not many people do this but it’s one of the best ways you can help someone for helping you

recurring thank you

thank in gchat for other people to see

let their manager know

write a heartfelt thank you note (a paragraph or more)

thank them in person or over a call

building relationships is key to having people vouch for you

thanking people is very important

“what could I start or stop doing to ramp up more quickly?

this is much better

this is useless, people will just respond yes/no

“do you have any feedback for me?”

feedback is a gift, it’s better to hear something earlier so you can adjust

one of the key principles with feedback is that you shouldn’t be surprised

Meta: What’s the best way for us to share feedback with each other?

Behavioural: What’s something I do well I should do more of?

Task specific: what’s one thing that would have made this better?

asking for specific feedback

things to talk about in 1:1s

ask for opportunities or resources

reflect on what’s going well and not going well for you

a couple of times a year you should talk about career/performance review

brainstorm ideas of projects you could tackle or ways the team could improve

give feedback or ask for specific feedback

reflect on what’s going well and not going well for the team (and the team’s goals)

recommended structure for manager 1:1s

1. pursue awkward 1:1s, be willing to be vulnerable

2. Go beyond status updates, talk about emotions and feedback

3. Take notes (so you can look back and reference later)

uplevel your 1:1s!

to get more detailed feedback, bring situations to them and try to see what they think you should have done or what you could do better next time

working with your manager is all about having a recurring meeting to get to know each other and build trust + ask for specific feedback

Average tenure at tech companies (at least in SF) is only 1.5-2 years

Trust is the currency through which you grow your career.

three pillars of onboarding

learning the codebase

building relationships

Why does onboarding matter?

You can have a lot of impact by making onboarding easier for newer engineers