Мы в сообществе руководителей Management Hub выложили в открытый доступ майнд-карту про онбординг сотрудников, которая может быть полезна

Мы в сообществе руководителей Management Hub выложили в открытый доступ майнд-карту про онбординг сотрудников, которая может быть полезна всем, кто хочет выстроить осознанный процесс адаптации. А, чтобы еще больше поделиться с вами реальным опытом, сообщники раскрывают свои мысли про онбординг у себя в каналах. Если вам такое интересно, то все мысли собраны вместе ➡️ тут 👈 — читайте, подписывайтесь на тех авторов, чьи мысли откликаются.

Онбординг как инструмент для комитета

В крупных компаниях часто возникает — планово или стихийно — параллельная система управления качеством кода и единообразием инструментов. Обычно она оформляется в виде комитетов по стеку или профессии, либо внутренних сообществ: «Java-комитет», «бэкенд-сообщество» и т.п.

Это полезная и правильная практика: такие структуры формируют правила, отбирают инструменты и помогают выстраивать единую инженерную культуру. А в «лучших домах ЛондОна» — еще и системно развивают стажеров и джунов.

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

Хорошо выстроенный онбординг позволяет сразу задать стандарты: как в компании принято писать код, какие инструменты использовать, какие подходы считаются нормой. Это не просто вводный курс, а точка формирования привычек.

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

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

Если вы участвуете в профессиональном комитете внутри компании, стоит задать себе несколько вопросов:

🔘Что именно и как вы показываете новичку в онбординге?

🔘Есть ли рядом с ним человек, который помогает понять, «как у нас принято»? Бывает, что, например, единственный QA в команде фактически работает в изоляции. В одном подкасте это метко назвали «гномом в лесу» — их много, но из-за высокой травы они не видят друг друга.

🔘Когда вы в последний раз сами проходили свой онбординг? Не устарели ли инструменты и подходы? Не вредите ли вы компании уже на старте взаимодействия с новыми людьми?

А что в компаниях поменьше? Да все тоже самое, только вы(обычно тимлид) сами себе комитет по всем направлениям.