What I wish I knew about onboarding effectively

https://eugeneyan.com/writing/onboarding/

Starting with the right mindset

Own your onboarding. How successful your onboarding is lies with you. While your manager may have an initial onboarding plan, you own it and should feel empowered to update it as necessary. Treat the onboarding like any other project you’re tasked to lead.

Taking ownership means clarifying expectations early and often. Define your 100-day plan and seek feedback within week one. Revisit it occasionally to check if expectations have changed, especially if you’re in a fast-moving team. Revisiting expectations is important if you’re an external joiner and don’t understand the culture yet. If an onboarding plan has been prepared but is lacking in details or is too challenging, speak up! Request for clarification or help, and don’t hesitate to make changes—no one wants to see you fail.

Most people are happy to have a 30-min intro chat or lend a helping hand if you’d just ask.

Have a Beginner’s mind. As the new joiner, you get to play the “I’m new here” card. I would take advantage of it and ask as many questions as needed. It’s cliché but it bears repeating that there are no stupid questions. Your fresh perspective is valuable and your questions may nudge the team into better ways of doing things.

For folks with experience in a similar domain or tech stack, don’t just stick to what you know. We often assume that achieving success in the new role means doing what we did in the previous role, only more of it and better—most of the time, this assumption is wrong.

Resist the urge to change things. “Respect what came before” is one of Amazon’s Principal Engineering Tenets. It means appreciating the value of working systems and the lessons they embody.

In your first week, you might find 10 things that seem wrong to you. Perhaps the build system is too complex or the machine learning too simple. Don’t be too quick to judge and make changes! Make a note of it somewhere and work hard to disconfirm your beliefs. Revisit these notes every month or so and notice how your initial hypotheses change.

The point is, don’t fall prey to the action imperative. Don’t feel the need to take action too hard and too quickly to put your stamp on the team. Instead, adopt a Beginner’s mind and focus on learning. If we’re too busy taking action instead of learning and diagnosing, we risk prescribing the wrong medicine. This leads to making bad decisions early on, losing trust, and inadvertently building resistance to any future ideas we have.

Invest time in culture and relationships too. Being in a technical role, during onboarding, I tend to focus on the technical aspects (e.g., tools, systems, code) and neglect the cultural and social aspects. After all, the explicit is easier to see and learn than the implicit. However, it helps to have a grasp of team culture, relationships, and mechanisms, especially if you’re in a more senior position.

An example of culture is how conflict is resolved. Do people disagree openly or is conflict avoided? If conflict has to be resolved, is it escalated upwards or delegated downwards? Once a decision is made, do people disagree and commit, or grumble and resist? Another cultural norm is how meetings are conducted. Does the team use powerpoint or write documents? New joiners in Amazon are often surprised by meetings where the first half is spent silently reading and commenting on a doc before discussions in the second half.

Planning for success in the first 100 days

Write your 100-day plan. If you’ve joined a more mature organization, your manager may already have an onboarding plan prepared. If not, you can write one yourself. Either way, review expectations and update the plan occasionally so everyone’s aligned.

Here’s a rough guideline: It should have milestones for each of the first four weeks, the second month, and the third month. For each of these milestones, set goals for (i) learning—what internal tooling, systems, and mechanisms to pick up, (ii) relationships—who you should start engaging with, and (iii) deliverables—what you should have shipped.

Plug into the human network. As part of onboarding, you should have a list of people to talk to. Your manager may have prepared this list. If not, ask for suggestions on people who work on similar projects (e.g., fellow scientists or engineers) and key stakeholders (e.g., engineering or product managers).

Plug into the way of doing things and ship early wins. The intent of shipping early is to use it as a forcing function to (i) learn enough about existing systems and mechanisms to ship a pull request, document, or feature and (ii) start earning trust. If your work involves research and trial and error, such as machine learning or product, early wins should be framed as experiments conducted (i.e., number of A/B tests) instead of expected performance (i.e., positive A/B test).

Improve the onboarding experience for the next person. One of the highest leverage things you can do is to improve the onboarding process so future joiners take less time to become productive. If your team is scaling up rapidly, building or improving the onboarding process will likely have higher leverage than any code you write.