Як ми створили інститут менторства джунів в компанії: челенджі найму та флоу впровадження кейсу
Привіт! Я Антон, і рекрутинг — це моя стихія вже понад 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 тімліда невеличкої команди.
Адаптація джунів у середовищі компанії та результати проєкту
Зазвичай у тімліда було
- суперзалучені, але технічно більш слабкі;
- сильні, але менш залучені;
- сильні та залучені.
Другі програвали першим. Сильний джун зберігає свою силу протягом нетривалого періоду. Наприклад, настає момент, коли він вичерпав свої знання, а до нових не готовий через низьку мотивацію. Тоді перевагу отримує залучений джун, який більш зацікавлений в сертифікаціях, знаннях, проєктах. Звісно, третя категорія джунів (сильні та залучені) мала найбільші шанси.
Ми створили всі можливості для самостійного зростання та вдосконалення своїх знань. Зокрема, сертифікації від вендорів відіграють величезну роль у формуванні експертизи молодих спеціалістів.
Навчання відбувається у кілька етапів. Процес — максимально самостійний, ментори залучені у нього на рівні радників:
- Базова сертифікація Associate Engineer. Це знайомство з продуктом, курс триває до 3 місяців.
- Робота з рішенням. Отримання вже більш практичних навичок роботи з продуктом для технічних користувачів системи.
- Навчання на рівні Майстра системи. Інженер має розуміння, як допилювати додаткові функції, як відповідати на дуже складні запитання щодо технічної сторони рішення.
- Сертифікація до рівня Спікера або Амбасадора рішення, який має найбільшу експертизу.
Водночас завдяки створенню інституції менторства всередині компанії розкрилися не лише джуни, але й наші тімліди. Це класний кейс нетворкінгу, обміну досвідом, визначення взаємних слабких та сильних сторін. Найвагоміше — вдалося сформувати кістяк команди та засетапити процес.
Про результати
Цей проєкт тривав близько двох років. Завдяки його реалізації вдалось посприяти поширенню менторства та створення можливостей для джунів, і водночас розбудові лідерства всередині команди.
Лідери компанії визнали успіх інвестиції в нашу ініціативу та підтримали ідею її поширення на інші ринки. Тепер в усіх країнах, де ми оперуємо, маємо сильний технічний склад та гарне розуміння органічного розвитку команд, які вже пройшли навчання у свого ментора та досягли кар’єрного зростання. Темп найму за цим кейсом не зменшується, і відбувається рекрутинг у міжнародні команди.
15 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів