What I Wish I Knew About Onboarding Effectively

eugeneyan

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

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

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

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

Начните с правильного образа мышления

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

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

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

Сохраняйте ум новичка. Как новичок, вы можете разыгрывать карту «я здесь недавно». Я бы пользовался этим и задавал столько вопросов, сколько нужно. Это клише, но стоит повторить: глупых вопросов не бывает. Ваш свежий взгляд ценен, и ваши вопросы могут подтолкнуть команду к лучшим способам работы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• • •

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

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

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

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

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

Yan, Ziyou. (May 2022). What I Wish I Knew About Onboarding Effectively. eugeneyan.com. 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/} }

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