Як ми створили інститут менторства джунів в компанії: челенджі найму та флоу впровадження кейсу

💡 Усі статті, обговорення, новини про HR — в одному місці. Приєднуйтесь до HR спільноти!

Привіт! Я Антон, і рекрутинг — це моя стихія вже понад 10 років. За цей час працював у fintech, IT та digital-галузі, збирав команди з нуля, налаштовував рекрутинг-процеси та допомагав бізнесам знайти «своїх» людей. Обожнюю будувати ефективні команди та завжди дивлюся на рекрутинг із бізнес-підходом — адже цифри та результати говорять голосніше за слова.

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

Ми працюємо в досить специфічному IT-секторі — дистрибуції. Наша ніша — кібербезпека. Це одна з ключових галузей технологічної індустрії, адже ми, як дистрибʼютори, просуваємо рішення і паралельно закриваємо питання, пов’язані із кібербезпекою та IT-інфраструктурою в цілому. Зазначу, що наша компанія ніколи не продає IT-рішення клієнтам напряму, а взаємодіє з ними через партнерську мережу.

Як Head of Recrutiment можу підтвердити, що хайринг інженерів до команди — завжди челендж. Кандидати не повсякчас розуміють глибину проєктів, які реалізує наша компанія. Зазвичай це великі проєкти у сегментах B2B, Enterprise та B2G, що потребують високого рівня залучення інженера.

Інколи люди хочуть бути просто інженерами, а нам цього не вистачає. Нам потрібні tech-євангелісти, які розуміють ці продукти та вірять у них. І водночас постійно самовдосконалюються. Таких людей важко знайти на поверхні.

Я прийшов в момент, коли бізнес активно розвивався, і перед нами постав непростий виклик. Ми вже мали знання та експертизу заходу в цільові регіони, але потребували масштабування команд, бо заходили нові проєкти. Менеджмент розумів: щоб збільшити обсяги бізнесу — треба мати інженерів on-site.

Челендж полягав у тому, що всі наявні в штаті інженери вже були залучені до поточних проєктів. У технічних командах працювали тімліди, але на той час їхнє завдання полягало не у тому, щоб менеджерити джунів — вони сапортили вже готових інженерів.

Крок 1. Наймаємо мідлів, але не отримуємо бажаних результатів

Одразу зазначу, що інженерів Senior-рівня з рішень в межах наших ринків — дуже мало, адже продукти заводимо на ринок саме ми. Наприклад, є американський вендор, маловідомий на українському ринку. Компанія запускає його, будує центр компетенцій і самостійно прокачує інженерів до необхідного скілу.

На той час вийшла така історія: джунів ми не могли собі дозволити, бо тоді не готові були витягувати тімлідів з бізнесу для навчання новачків, а сеньйорів нашого стека — майже не існувало. Ми почали набирати мідлів, які досить чітко розуміли, куди бажають рухатися.

Та отримали ми не те, на що очікували: у нас виріс поріг костів при досить непрогнозованих результатах в довгостроковій перспективі, а рівень лояльності нових співробітників зріс не набагато.

Поясню унікальність наших інженерів. Інколи ці спеціалісти — єдина точка компетенції з продукту в країні. Ми не продаємо напряму клієнту, натомість завдяки інженерам закриваємо інші потреби:

— Надання розуміння гравцям на ринку країни, в чому рішення класне, чому воно вже 5 років продається в США, використовує значно сучасніший стек технологій і тепер несе інновації на новий ринок. Чому після його встановлення ви прокачаєте свій сервіс?

— Надання цього ж розуміння партнеру, який взаємодіє з бізнесом, а також побудова партнерських стосунків, що базуються на довірі, бо вся технічна сторона імплементації продукту може бути на нас.

І знову ми повернулися до того, з чого почали. Однак ми вже давно на ринку і дуже любимо експериментувати. Інколи це виходить, інколи не дуже, але практика показує: якщо не спробувати, то змін очікувати не варто!

Тому команда рекрутингу проаналізувала, що роблять інші компанії (не з нашого сектору ІТ), адаптувала їхній досвід та запропонувала бізнесу інший підхід: інвестувати в навчання джунів.

На той момент ми вже мали усвідомлення, що дорогий інженер зі сформованим стеком міг бути зрештою неефективним в екосистемі нашої компанії. Бізнес з цим вже стикався, і це був найбільший геп, бо компанія витрачала свої ресурси на інженера, який міг не розумітися на винятково нашому стеку.

Крок 2. Найм джунів. Визначення челенджів для рекрутинг-команди

Я та команда рекрутингу виступили ініціаторами внутрішнього проєкту: створити інституцію менторства в компанії під хайринг джунів. Позиції наших менторів — Senior Pre-sales Engineer з продажів рішень кібербезпеки. Джунів ми наймали з позицій Junior+ System Administrator, Junior Network Engineer — на посаду Junior Pre-sales Engineer.

Ми чітко знали, які базові скіли джунів потрібні, однак було проблематично знайти вільні години тімлідів, які могли б стати менторами. Усі наші інженери виявилися залученими у робочі проєкти. Побутував навіть такий стереотип: якщо інженер працює з джуном, то в нього знижується мотивація та ефективність.

Тож перед запуском проєкту, ми окреслили проблематику реалізації нашого кейсу.

Нереально одразу побачити весь потенціал Juinior Engineer, адже наші проєкти можуть тривати кілька років. Робота з вендором — дуже велика відповідальність. Інженери мають бути скілові, залучені, вмотивовані, ототожнювати свій розвиток з технологіями цього вендора. Наприклад, є вендор, але в нього не один, а дванадцять продуктів, які ми просуваємо. Щоб дослідити їх, зрозуміти технологічний стек — інженеру, звісно, потрібен час. Тому нам треба були кандидати з високим рівнем лояльності до компанії, готові працювати з нами рік і більше.

Ми розуміли, що не можемо пропонувати роль ментора Pre-sales інженерам, які працювали в нас менше року. Навички зрілого спеца інженер набуває за півтора-два роки після початку виконання своїх обов’язків у компанії. За цей час експерт проходить усі стадії навчання по своєму вендору (Associate-сертифікації, тести та практичні заняття). Людина, яка ще сама навчається — не має глибоких знань про продукт.

Потенційні ментори спочатку не хотіли навчати джунів. По-перше, тому що наші інженери були дуже скілові та сильні, сфокусовані виключно на своїх задачах та проєктах. Спочатку вони не розуміли додаткових value для себе — емоційних, фінансових, тому що початково ці бенефіти ніхто для них не підсвітив. Цю задачу взяла на себе моя команда.

Проблема проведення інтерв’ю інженерами з джунами. Моїй команді треба було донести інженерам такі моменти: на співбесіди треба виділяти час, про проєкти кандидатам варто розповідати цікаво, структуровано, доступними словами. Адже кандидатів ми набирали серед молоді, в них — трохи інші драйвери, ніж в інженера 35+ років. Тому слід було надихнути команду змінити суху подачу проєктів технічною мовою на більш жваву, креативну.

І водночас ми радили підкреслювати перспективи зростання для джунів в межах співпраці з компанією. Зрештою моя команда отримала дуже позитивний фідбек від менторів: вони навчилися проводити віртуозні інтерв’ю, і в деяких моментах ми як рекрутери навіть не модерували співбесіду.

Крок 3. Створення інституції менторства та опис запуску проєкту

Після декількох раундів обговорення ідеї з інженерами та представниками бізнесу, формування розуміння доцільності ініціативи та усвідомлення потенційних бенефітів, вмотивовані ментори знайшлися. А стейкхолдери з боку бізнесу повірили в кейс найму та навчання джунів й інвестували в цю ідею кошти та час.

Компанія почала будувати внутрішню інституцію тімлідів. У них були свої зони впливу та розвитку в межах груп джунів за сформованим Performance Review.

Ми потребували часу, щоб перебудувати саму концепцію менторства, до якої звикли тімліди. Тобто початково вони менторили готових, самостійних мідлів. Ми ж надали перевагу навчанню не готових, але дуже вмотивованих джунів.

От як виглядав флоу реалізації кейсу з боку менторів:

1. Ми наймали кандидатів з крутим досвідом інженера.
2. Компанія створювала усі умови для розкриття спеціалістів: сертифікації, спочатку — часткове, а потім — повне залучення у проєкти.
3. Ми додавали до їх Performance Review необхідність досягти високого скіла в менторстві.
4. Інженери зростали як експерти, трансформуючись в амбасадорів того чи іншого вендора з нашого портфеля. Тобто ставали справжніми, прокачаними Senior Pre-sales Engineer, які мали великий вплив на свій проєкт. Окрім технічних завдань, наші інженери просувають комунікаційні навички, адже тісно співпрацюють з замовниками. Вони проходять курси та тренінги для спікерів, лекторів, тому що мають презентувати технологічні продукти не сухо, а цікаво. Цей досвід допоміг інженерам стати справжніми менторами для джунів надалі.
5. Ми пропонували цим прокачаним інженерам менторити джунів та запустили процес. Найкращий час для пітчингу їм ідеї менторства наставав саме з моменту їх зростання зі звичайного інженера до Pre-sales Engineer.

А от флоу реалізації кейсу з боку джунів:

1. Ми наймаємо джуна, який вже має досвід роботи зі схожими рішеннями. Дуже часто вони приходили до нас з ринку того самого класу рішень, який просуваємо і ми. Такі кандидати мають ентузіазм, але не розуміються на глибині продукту.
2. Рекрутинг-процес. Під час запуску ініціативи з наймом джунів ми робили досить кропіткий рекрутинг. Технічно тестові завдання могли бути трохи легшими, ніж для мідлів, але етапи інтерв’ю, зокрема захист ТЗ, — не були простими. У якийсь момент ми набирали інженерів ближче до Junior+ і могли закрити очі на певний брак досвіду у разі наявності мотивації.
3. Метч залученого джуна з інженером Pre-Sale. В нашого інженера є розуміння глибини продукту та усіх нюансів. Однак через те, що він працює з великою кількістю замовників, та враховуючи плинність проєктів — найменші деталі про продукт можуть вислизати з його фокусу.
4. Синергія між ментором та джуном. З цього виходить дуже цікавий, реальний кейс співпраці між Senior Pre-sales Engineer та Junior Pre-sales Engineer. Ми бачили, як джун під керівництвом інженера, що має глибоке розуміння tech-екосистеми, потреб замовника та прокачані навички менторства, знаходить додаткові, цікаві ініціації проєктів, які ментор не помітив. Джуни надають наставникам свіже бачення.
5. Наступний етап — зростання джуна в межах компанії до Pre-sales тімліда невеличкої команди.

Адаптація джунів у середовищі компанії та результати проєкту

Зазвичай у тімліда було 3-4 джуни максимум. На той момент джуни розділялися на три категорії:

  • суперзалучені, але технічно більш слабкі;
  • сильні, але менш залучені;
  • сильні та залучені.

Другі програвали першим. Сильний джун зберігає свою силу протягом нетривалого періоду. Наприклад, настає момент, коли він вичерпав свої знання, а до нових не готовий через низьку мотивацію. Тоді перевагу отримує залучений джун, який більш зацікавлений в сертифікаціях, знаннях, проєктах. Звісно, третя категорія джунів (сильні та залучені) мала найбільші шанси.

Ми створили всі можливості для самостійного зростання та вдосконалення своїх знань. Зокрема, сертифікації від вендорів відіграють величезну роль у формуванні експертизи молодих спеціалістів.

Навчання відбувається у кілька етапів. Процес — максимально самостійний, ментори залучені у нього на рівні радників:

  1. Базова сертифікація Associate Engineer. Це знайомство з продуктом, курс триває до 3 місяців.
  2. Робота з рішенням. Отримання вже більш практичних навичок роботи з продуктом для технічних користувачів системи.
  3. Навчання на рівні Майстра системи. Інженер має розуміння, як допилювати додаткові функції, як відповідати на дуже складні запитання щодо технічної сторони рішення.
  4. Сертифікація до рівня Спікера або Амбасадора рішення, який має найбільшу експертизу.

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

Про результати

Цей проєкт тривав близько двох років. Завдяки його реалізації вдалось посприяти поширенню менторства та створення можливостей для джунів, і водночас розбудові лідерства всередині команди.

Лідери компанії визнали успіх інвестиції в нашу ініціативу та підтримали ідею її поширення на інші ринки. Тепер в усіх країнах, де ми оперуємо, маємо сильний технічний склад та гарне розуміння органічного розвитку команд, які вже пройшли навчання у свого ментора та досягли кар’єрного зростання. Темп найму за цим кейсом не зменшується, і відбувається рекрутинг у міжнародні команди.

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Скільки ж Джунов набрали минулого року і скільки плануєте цього?

У 2024 році ми найняли 16 джунів: 12 в Україні та 4 в інших країнах. Цією інформацією ми також ділилися на DOU: dou.ua/...​cles/hiring-juniors-2024
У 2025 році 100% продовжимо наймати, але, за моїми прогнозами, на 25-30% менше, ніж у 2024, з більшим фокусом на міжнародні ринки. Це зумовлено укомплектованістю команд та гарним сетапом. За це окремий респект HR-команді та техлідам (*моя команда відповідає тільки за рекрутинг).

Интересно какая текучка на проекте, если предпочтение отдавать джунам. Как это сказалось на выгорании опытных сотрудников когда на них навешали доп. обязанности? Что с выгоранием внутри команды? У меня есть просто негативный пример, хочется понять как тут справились

За структурою ми більше схожі на продуктову компанію, тому не практикуємо набір людей під проєкт. Ви влучно підмітили додаткове навантаження — це було особливо помітно на старті. Водночас не було мети реалізувати проєкт «за будь-яку ціну», тому ті, кому він не зайшов, мали можливість комфортно перейти на більш зрозумілий для них флоу.
Щодо вигорання — без нього в ІТ нікуди, але нам трохи пощастило)). Оскільки ми працюємо з великими B2B та B2G проєктами у різних країнах, наші інженери не прив’язані до одного замовника чи задачі, що зменшує ризик професійного вигорання. Також додам, що ми також працюємо в класичних умовах проєктів, дедлайнів, бюджетів, і болі в нас такі самі, але намагаємося уникати перегинів. Компенсуємо залученість інженерів додатковими бонусами — як за успішно закриті проєкти, так і за витрачений час.

Хто може зрозуміти підхід і сам проект, так це той, хто потрапив саме під цю хвилю, як недосвідчений, але з певним бекграундом, вмотивований навчитись чомусь новому, вийти з зони комфорту для особистого розвитку — простий системний адміністратор, де IT-департаменту був лише на етапі зародження або ж зона відповідальності була занадто обмежена.

Ментори є всюди, тільки десь це обовʼязок, що надходить просто наказом керівника, а тут — це логічний розвиток кожного спеціаліста своєї справи, що дасть буст мотивації, динаміку в роботі, власне досвід менторства та всі супутні бенефіти. Головне, щоб всі етапи були описані для всіх залучених сторін.

Так і сталось, я пройшов не відразу в компанію, я вже мав досвід роботи сісадміна, тобто технічне підгрунтя вже було, але через власні побоювання та обмеженої зони відповідальності, важко було зрушити з певного оманливого комфорту, шукати нові довгострокові перспективи.

Недостача певних скілів спочатку завадила пройти відбір на вакансію. Але через півроку зʼявилась ще одна позиція, де успішно виконав тестове завдання. Дійсно з зірочкою: поринути в продукт, зрозуміти базові моменти, підготувати презентацію та провести її. Якщо вдасться підкреслити на будь-якому етапі щось нове для потенційного роботодавця, то за це буде окремий плюсик в карму для успішного старту.

Тож Антон ввів мене в цю ідеологію, пояснив ще на березі, як відбувається зростання Pre-Sale Engineer-а, попередив про важкий, але цікавий шлях кандидата. Перший рік — це справжнє випробування для людини, яка вважала себе інтровертом, а тепер «тільки спробуте мене зупинити!»). Щоб ще довше не описувати кожну деталь (але так вже не вдасться), маю сказати, що досвіду тут можна отримати максимально і навіть більше. Грейд — це не просто назва посади чи підвищення ЗП, це відчуття власного зростання, як інженера, як спікера, як комунікабельної особистості, це розуміння в ході проектів величезної кількості бізнес-процесів та їх тонкощів, досвіді роботи з іншими компаніями (партнерами, замовниками, вендорами), навчання нових спеціалістів.

Це також і командна робота і залученість як на рівнях керівник-працівник, так і на «є ідея, давайте всі її розвинемо, використовуючи зусилля та зону відповідальності кожного». І головне, що цей спільний успіх дозволить кожному закрити власні ключові пункти для отримання вищого грейду.

Вартує також відмітити, що це робота з топовими в своєму класі виробниками IT-рішень по кібербезпеці. Це кращі практики в IT, безперервне прокачування говоріння англійською, покращення мультизадачності та багато іншого.

Тож бажаю кожному знайти себе, знайти комфортне місце для зростання, компанію, що має адекватне бачення власного розвитку та з її цінностями, які притаманні і вам самим!
Дякую за увагу!

Макс,
дуже влучно сказано!

Про результати
Цей проєкт тривав близько двох років. Завдяки його реалізації вдалось посприяти поширенню менторства та створення можливостей для джунів, і водночас розбудові лідерства всередині команди.

Лідери компанії визнали успіх інвестиції в нашу ініціативу та підтримали ідею її поширення на інші ринки. Тепер в усіх країнах, де ми оперуємо, маємо сильний технічний склад та гарне розуміння органічного розвитку команд, які вже пройшли навчання у свого ментора та досягли кар’єрного зростання. Темп найму за цим кейсом не зменшується, і відбувається рекрутинг у міжнародні команди.

Типове бла-бла-бла. Єдине, що можна виміряти, це «темп найму», але важко сказати, як він взагалі пов’язаний з інститутом менторства.

Вітаю!
Звісно, збільшення темпу найму — це вимірюваний, маркерний показник, і наша ініціатива позитивно вплинула на нього. Однак не менш вагомим досягненням проєкту стала побудова культури лідерства всередині компанії. Це та цінність, носіями якої є люди, і вона безумовно важлива для нас. Ми ставили собі цей KPI і досягли його, завдяки чому збільшився якісний внесок наших співробітників в задачі бізнесу загалом.

Звісно, збільшення темпу найму — це вимірюваний, маркерний показник, і наша ініціатива позитивно вплинула на нього.

Ну... а чому така впевненість, що саме це вплинуло? Новий замовник вплине набагато більше. Навіть темпи звільнення більш показовий.

Однак не менш вагомим досягненням проєкту стала побудова культури лідерства всередині компанії.

Як на мене, успіх рішення компанії вимірюється в доларах, а не у таких декларативних речах.

Нам, як спільноті, цікаве інше.
Ми подивилися фото офісу с Українськими флагами, флагами Азову.
Як вдається згладжувати протиріччя між цим і офісами в Грузії, Азербаджані, Узбекистані і Москві на Лужниках?
moskva.miltor.ru/company/bakotek-2622018

Добрий день!

Одразу зазначу, що:
— Будь-які бізнес-стосунки з рф ми припинили ще задовго до повномасштабного вторгнення.
— Ми не маємо офісу в росії та не володіємо акаунтом, про який ви згадуєте.
— Актуальний список країн, у яких ми працюємо, завжди доступний на нашому офіційному сайті: bakotech.com. Наш сайт — це єдине офіційне та достовірне першоджерело інформації про нашу компанію.

Саме тому жодних протиріч немає — ми працюємо в тих країнах, де можемо розвивати чесний бізнес, враховуючи всі наші принципи та цінності)

Окремо дякую вам, що поділилися лінком. Ми вже працюємо над тим, щоб видалити профіль нашої компанії з сайту.

— Будь-які бізнес-стосунки з рф ми припинили ще задовго до повномасштабного вторгнення.
Окремо дякую вам, що поділилися лінком. Ми вже працюємо над тим, щоб видалити профіль нашої компанії з сайту.

З веб-архіву ще бажано видалити ) Бо в квітні 2022 офіси в РБ ще є.
web.archive.org/...​031/https://bakotech.com

Так, ми вже зафіксували це, дякую

так а що відбувалося з «просто інженерами», які не хотіли приймати участі в цій ярмарці? їх звільняли?

Вітаю!
Дякую за коментар. Інженери, які не долучилися до ініціативи продовжили виконувати свої функції в межах технічних відділів та рухатися за своїми напрямами. Інститут менторства отримав достатньо підтримки всередині компанії, нам вистачало ресурсів для реалізації проєкту.

Підписатись на коментарі