What I Wish I Knew About Onboarding Effectively

eugeneyan

eugeneyan

С чего начать Статьи Выступления Прототипирование Обо мне

What I Wish I Knew About Onboarding Effectively

Что я хотел бы знать об эффективном онбординге

[ mechanism career ] · 11 min read

[ mechanism career ] · 11 мин чтения

Onboarding to a new role can be scary. You want to start things on the right foot and so much rides on your first few months. Though I don’t have it all worked out, here are some guidelines that served me well. This post is intended for tech folks in mid to senior roles. We’ll start with discussing mindset before planning for the first 100 days.

Онбординг на новой должности может пугать. Хочется начать всё правильно, и от первых месяцев зависит очень многое. Хотя у меня нет готовых ответов на всё, вот несколько правил, которые сослужили мне хорошую службу. Этот пост рассчитан на технических специалистов среднего и старшего уровня. Сначала мы обсудим образ мышления, а затем — планирование первых 100 дней.

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.

Взять ответственность означает прояснять ожидания рано и часто. Составьте свой план на 100 дней и получите обратную связь в течение первой недели. Время от времени возвращайтесь к нему, чтобы проверить, не изменились ли ожидания — особенно если вы в быстро развивающейся команде. Пересматривать ожидания важно, если вы пришли извне и пока не понимаете культуру. Если план онбординга подготовлен, но ему не хватает деталей или он слишком сложный — говорите об этом! Просите разъяснений или помощи и не стесняйтесь вносить изменения — никто не хочет, чтобы вы провалились.

Taking ownership also means you’re responsible for making relationships work. Don’t expect your manager and peers to proactively reach out to introduce themselves or offer support. Everyone’s likely busy themselves. It’s a bonus if they do but you should assume the onus is on you to take the first step. Most people are happy to have a 30-min intro chat or lend a helping hand if you’d just ask.

Взять ответственность также означает, что именно вы отвечаете за то, чтобы отношения складывались. Не ждите, что менеджер и коллеги сами проявят инициативу, представятся или предложат поддержку. Скорее всего, все заняты своими делами. Хорошо, если они это сделают, но исходите из того, что первый шаг — за вами. Большинство людей с радостью согласятся на 30-минутный знакомый разговор или помогут, если вы просто попросите.

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. Sometimes that’s true, such as when we’re hired into a younger org to spin up the same function we led in our previous org. But even then, it’s unlikely we can copy-paste everything and expect it to work. We’ll need to adjust to the unique circumstances of the team and org. We might need to stop doing what worked and pick up new capabilities.

Тем, у кого есть опыт в похожем домене или техническом стеке, не стоит цепляться только за то, что вы уже знаете. Мы часто предполагаем, что добиться успеха в новой роли — значит делать то же, что и в прежней, только больше и лучше; в большинстве случаев это предположение ошибочно. Иногда оно верно — например, когда нас нанимают в более молодую компанию, чтобы запустить ту же функцию, которой мы руководили на прошлом месте. Но даже тогда вряд ли получится скопировать всё и ожидать, что это сработает. Придётся подстраиваться под уникальные обстоятельства команды и организации. Возможно, понадобится перестать делать то, что работало раньше, и освоить новые навыки.

Don’t be the person that comes in with “the answer” and doesn’t make any effort to understand the idiosyncrasies of the team and org. You can tell who these people are. They tend to say “when I was at BrandedCo this was how we did it” and “we should change things to be just like my old place”, which brings us to our next principle…

Не будьте тем, кто приходит с «готовым ответом» и не прилагает усилий, чтобы понять особенности команды и организации. Таких людей легко распознать. Они обычно говорят: «когда я работал в BrandedCo, мы делали это вот так» и «нужно всё изменить так, как было на моём прежнем месте», что подводит нас к следующему принципу…

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.

Сопротивляйтесь желанию что-то менять. «Уважай то, что было до тебя» — один из принципов Principal Engineering в Amazon. Он означает понимание ценности работающих систем и тех уроков, что в них заложены.

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.

В первую неделю вы можете обнаружить 10 вещей, которые кажутся вам неправильными. Возможно, система сборки слишком сложна, а машинное обучение слишком примитивно. Не спешите судить и вносить изменения! Запишите их где-нибудь и упорно работайте над тем, чтобы опровергнуть свои убеждения. Возвращайтесь к этим заметкам примерно раз в месяц и замечайте, как меняются ваши первоначальные гипотезы.

You might find that, after learning more about the existing systems, only 2 out of the initial 10 observations are valid. If you had tried to change all 10 things, you would have been a bull in a china shop. By deferring judgment and collecting more data, you’ve narrowed the list down to the two things that matter and can put more wood behind fewer arrows.

Возможно, вы обнаружите, что после более глубокого знакомства с существующими системами лишь 2 из первоначальных 10 наблюдений оказались верными. Если бы вы попытались изменить все 10, вы были бы как слон в посудной лавке. Отложив суждения и собрав больше данных, вы сузили список до двух действительно важных вещей и можете направить больше сил на меньшее число задач.

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.

Суть в том, чтобы не поддаваться императиву действия. Не чувствуйте необходимости действовать слишком резко и слишком быстро, чтобы оставить свой след в команде. Вместо этого примите ум новичка и сосредоточьтесь на обучении. Если мы слишком заняты действиями вместо изучения и диагностики, мы рискуем прописать неверное лекарство. Это ведёт к плохим решениям на раннем этапе, потере доверия и непреднамеренному формированию сопротивления любым нашим будущим идеям.

(Note: The above assumes you’re joining in a time of stability, which would apply to most teams. If however, you’re joining in a time of hypergrowth and need to widen your lead, or if everything’s on fire and you need a quick turnaround, act quickly and decisively!)

(Примечание: сказанное выше предполагает, что вы приходите в период стабильности, что справедливо для большинства команд. Однако если вы приходите в период гиперроста и нужно расширять отрыв, или если всё горит и нужен быстрый разворот ситуации — действуйте быстро и решительно!)

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.

Пример культуры — то, как разрешаются конфликты. Люди открыто не соглашаются друг с другом или конфликта избегают? Если конфликт надо разрешить, его эскалируют наверх или делегируют вниз? Когда решение принято, люди следуют принципу «не согласен, но выполняю» или ворчат и сопротивляются? Ещё одна культурная норма — как проводятся встречи. Команда использует PowerPoint или пишет документы? Новички в Amazon часто удивляются встречам, где первая половина проходит в молчаливом чтении и комментировании документа, а обсуждения начинаются только во второй половине.

For relationships, we tend to focus on vertical relationships such as our boss or direct reports, and don’t spend enough time with peers and stakeholders. This can lead to missed collaboration opportunities or duplicating a system that a sister team has built.

Что касается отношений, мы склонны сосредотачиваться на вертикальных связях — например, с начальником или подчинёнными — и уделяем недостаточно времени коллегам и стейкхолдерам. Это может привести к упущенным возможностям сотрудничества или дублированию системы, которую уже построила смежная команда.

One person I engage with is the voice of the customer. These people have strong intuition about what customers will or will not like and know where the paper cuts are. Thus, they’re a good sounding board for new ideas and features. Another person is the systems old hand. Relative to most people, they have a wider and deeper understanding of existing systems and their constraints. They know what can or cannot scale, how to reduce effort by reusing existing capabilities, and when something new needs to be built.

Один из тех, с кем я общаюсь, — это голос клиента. У таких людей сильная интуиция в отношении того, что клиентам понравится или не понравится, и они знают, где «болевые точки». Поэтому они хорошие собеседники для обкатки новых идей и фич. Другой человек — старожил систем. По сравнению с большинством, у него более широкое и глубокое понимание существующих систем и их ограничений. Он знает, что можно масштабировать, а что нет, как сократить усилия за счёт переиспользования имеющихся возможностей, и когда нужно строить что-то новое.

Planning for success in the first 100 days

Планирование успеха в первые 100 дней

Now that we’ve discussed mindset, let’s go through how to execute effectively in your first 100 days to earn trust and build strong relationships.

Теперь, когда мы обсудили образ мышления, давайте разберём, как эффективно действовать в первые 100 дней, чтобы заслужить доверие и выстроить прочные отношения.

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.

Напишите свой план на 100 дней. Если вы пришли в более зрелую организацию, у вашего менеджера, возможно, уже есть готовый план онбординга. Если нет — вы можете написать его сами. В любом случае пересматривайте ожидания и время от времени обновляйте план, чтобы все были согласованы.

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.

Вот примерный ориентир: в плане должны быть вехи для каждой из первых четырёх недель, для второго месяца и для третьего месяца. Для каждой из этих вех ставьте цели по: (i) обучению — какие внутренние инструменты, системы и механизмы освоить, (ii) отношениям — с кем стоит начать взаимодействовать, и (iii) поставкам — что вы должны выпустить.

Don’t expect to have it fully fleshed out from day 1. Writing a 100-day plan should resemble agile more than waterfall. As you learn more about the org and existing systems, you’ll identify gaps in your plan and update it as well as gain the context to set longer-term goals. Plan as much as you can and get feedback from your manager, ideally within the first week.

Не ждите, что план будет полностью проработан с первого дня. Написание плана на 100 дней должно больше походить на agile, чем на waterfall. По мере того как вы узнаёте больше об организации и существующих системах, вы будете выявлять пробелы в плане и обновлять его, а также набирать контекст для постановки долгосрочных целей. Спланируйте столько, сколько можете, и получите обратную связь от менеджера — в идеале в течение первой недели.

Suggested timeline:

Предлагаемый график:

Конец недели 1: черновик плана на 100 дней с вехами для каждой из первых четырёх недель. Конец месяца 1: план на 100 дней с вехами для 2-го и 3-го месяцев.

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).

Подключитесь к человеческой сети. В рамках онбординга у вас должен быть список людей, с которыми стоит поговорить. Возможно, ваш менеджер подготовил этот список. Если нет — попросите подсказать, кто работает над похожими проектами (например, коллеги-учёные или инженеры) и кто из ключевых стейкхолдеров (например, инженерные или продуктовые менеджеры).

When you chat with these initial group of people, ask them to suggest one other person they think you should also talk to. This could be someone whose work is relevant to yours or someone you should collaborate with. Repeat as necessary. After engaging with a number of people you should have a brief overview of who’s engaged in similar work and who can be future collaborators and feedback providers.

Когда вы общаетесь с этой первой группой людей, попросите каждого подсказать ещё одного человека, с кем, по их мнению, вам тоже стоит поговорить. Это может быть тот, чья работа связана с вашей, или тот, с кем вам предстоит сотрудничать. Повторяйте по мере необходимости. Пообщавшись с рядом людей, вы получите краткий обзор того, кто занимается похожей работой и кто может стать будущими соавторами и людьми, дающими обратную связь.

If you hit it off with someone, consider keeping in touch via a recurring meeting where you can share updates and ask for feedback. These could be informal mentors who you want to keep in touch with and seek advice from, or peers doing similar work but in a different org (e.g., machine learning systems in a different vertical).

Если вы с кем-то сошлись, подумайте о том, чтобы поддерживать связь через регулярные встречи, где можно делиться апдейтами и просить обратную связь. Это могут быть неформальные наставники, с которыми вы хотите поддерживать контакт и спрашивать совета, или коллеги, занимающиеся похожей работой, но в другой организации (например, системы машинного обучения в другой вертикали).

Suggested timeline:

Предлагаемый график:

Конец недели 2: встретиться с людьми из первоначального списка. Конец недели 3: встретиться с дополнительными людьми, которых порекомендовали другие.

Suggested questions:

Предлагаемые вопросы:

Каким был ваш предыдущий проект и над чем вы работаете сейчас? Каковы ключевые цели и вызовы вашей команды? Каковы ваши интересы — на работе или вне её?

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).

Подключитесь к принятому порядку дел и обеспечьте ранние победы. Цель ранних поставок — использовать их как стимул, чтобы (i) узнать достаточно о существующих системах и механизмах, чтобы выпустить pull request, документ или фичу, и (ii) начать зарабатывать доверие. Если ваша работа связана с исследованиями и методом проб и ошибок — например, машинным обучением или продуктом — ранние победы стоит формулировать как проведённые эксперименты (то есть число A/B-тестов), а не как ожидаемый результат (то есть положительный A/B-тест).

An oft-cited example of an early win is having a new joiner merge a pull request within the first week. Beyond contributing via code, another early win could be taking the lead and proposing a one-pager or design document to solve a moderately sized problem. Having deliverables that you can demo to the team and get feedback on is a big plus.

Часто приводимый пример ранней победы — когда новичок мёрджит pull request в первую неделю. Помимо вклада через код, другой ранней победой может стать инициатива по предложению one-pager или дизайн-документа для решения задачи среднего размера. Иметь результаты, которые можно продемонстрировать команде и по которым можно получить обратную связь, — большой плюс.

Suggested timeline:

Предлагаемый график:

Конец недели 1: сделать и смёрджить pull request. Конец месяца 1: написать one-pager и получить обратную связь. Конец месяца 2: написать дизайн-документ и получить обратную связь. Конец 100 дней: выпустить новую фичу и запустить A/B-тест.

(Note: The timeline above depends on the team’s culture, mechanisms, and rate of iteration. Startups might expect an A/B test within the first few weeks while larger organizations necessitate learning more about the context and existing systems, proposing a design doc, and gathering feedback before implementation. Adapt accordingly.)

(Примечание: график выше зависит от культуры команды, её механизмов и темпа итераций. Стартапы могут ожидать A/B-теста уже в первые недели, тогда как более крупные организации требуют сначала больше узнать о контексте и существующих системах, предложить дизайн-документ и собрать обратную связь перед реализацией. Адаптируйтесь соответственно.)

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.

Улучшите опыт онбординга для следующего человека. Одна из самых высокорычажных вещей, которые вы можете сделать, — улучшить процесс онбординга, чтобы будущим новичкам требовалось меньше времени, чтобы стать продуктивными. Если ваша команда быстро растёт, построение или улучшение процесса онбординга, скорее всего, даст больший рычаг, чем любой написанный вами код.

Nonetheless, you might be neck-deep in work after your onboarding and can’t contribute much. That’s fine. Try to set aside a few hours to reflect on your own onboarding and focus on the top pain points. What did you spend a disproportionate amount of time on and how did you overcome it? Can you share—perhaps on an internal wiki—your solution (e.g., shell scripts, configs) that new joiners can reuse? Alternatively, share your 100-day plan and onboarding notes so others can follow in your footsteps.

Тем не менее после онбординга вы можете с головой уйти в работу и не сможете много вложить в это. Это нормально. Постарайтесь выделить несколько часов, чтобы отрефлексировать собственный онбординг и сосредоточиться на главных болевых точках. На что вы потратили непропорционально много времени и как с этим справились? Можете ли вы поделиться — например, во внутренней вики — своим решением (например, shell-скриптами, конфигами), которое новички смогут переиспользовать? Как вариант, поделитесь своим планом на 100 дней и заметками по онбордингу, чтобы другие могли пойти по вашим следам.

• • •

• • •

The worst thing you can do while onboarding is to be a loose cannon and force changes from day one (top left of image below). But the other extreme, spending too much time learning with nothing to show for it isn’t much better (bottom right). Ideally, we want to be in the top right of the 2x2 where we learn quickly and take action to ship and earn trust.

Худшее, что можно сделать во время онбординга, — быть неуправляемой пушкой и продавливать изменения с первого дня (верхний левый угол изображения ниже). Но другая крайность — потратить слишком много времени на изучение, ничего при этом не показав (нижний правый угол), — не намного лучше. В идеале мы хотим оказаться в правом верхнем углу матрицы 2x2, где мы быстро учимся и действуем, чтобы выпускать результаты и зарабатывать доверие.

Avoid investing too little in learning or just learning without taking action.

Избегайте как слишком малых вложений в обучение, так и обучения без действий.

You can avoid the first extreme by coming with a Beginner’s mind and resisting the urge to change things. You can avoid the second extreme by taking ownership and writing a strong 100-day plan. Investing in learning and relationships helps with making good decisions and shipping early wins; shipping early wins earns trust and builds strong relationships. This leads to a virtuous cycle. I hope this advice makes your first 100 days more effective. All the best with your new role!

Первой крайности можно избежать, придя с умом новичка и сопротивляясь желанию всё менять. Второй крайности можно избежать, взяв ответственность на себя и написав сильный план на 100 дней. Вложения в обучение и отношения помогают принимать хорошие решения и обеспечивать ранние победы; ранние победы зарабатывают доверие и выстраивают прочные отношения. Это ведёт к благотворному циклу. Надеюсь, этот совет сделает ваши первые 100 дней более эффективными. Удачи на новой должности!

Thanks to Yang Xinyi for reading drafts of this.

Благодарю Yang Xinyi за чтение черновиков.

If you found this useful, please cite this write-up as:

Если этот материал оказался полезным, пожалуйста, цитируйте его так:

Yan, Ziyou. (May 2022). What I Wish I Knew About Onboarding Effectively. eugeneyan.com. https://eugeneyan.com/writing/onboarding/.

Yan, Ziyou. (May 2022). What I Wish I Knew About Onboarding Effectively. eugeneyan.com. https://eugeneyan.com/writing/onboarding/.

or

или

@article{yan2022onboarding, title = {What I Wish I Knew About Onboarding Effectively}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2022}, month = {May}, url = {https://eugeneyan.com/writing/onboarding/} }

@article{yan2022onboarding, title = {What I Wish I Knew About Onboarding Effectively}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2022}, month = {May}, url = {https://eugeneyan.com/writing/onboarding/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателям, получающим апдейты о машинном обучении, RecSys, LLM и инженерии.