Зростання команди втричі зазвичай означає втрату контролю за якістю. Ось система, що цього не допустила.
Команда PM виросла з 4 до 12 без жодної існуючої системи найму, оцінки чи розвитку — все довелось будувати паралельно із самим зростанням.
Найм, онбординг, оцінка, розвиток — від початку до кінця.
Кожна система нижче існує саме тому, що цього вимагало потроєння команди.
Не було структурованого способу наймати, оцінювати чи розвивати PM — усе несистемно.
Не було спільного визначення ролі PM чи того, що означає "добре".
Команда, що втричі зростала, не мала запасу міцності на ранні звільнення чи повільний вихід на продуктивність.
З ростом команди я делегував функцію менторингу більш досвідченим PM-ам, замість того щоб тримати її централізовано на собі — вбудувавши менторський рівень у саму команду, щоб розвиток не залежав від однієї точки.
Від самостійно розробленого AI-інструменту технічного скринінгу до структурованих перших двох тижнів — масштабування команди втричі без жодного раннього звільнення.
Повний кейс: Система найму та онбордингу5-рівнева драбина грейдів, матриця на 50 компетенцій і квартальний цикл review, що перетворили розвиток PM-ів на прозору, керовану систему.
Повний кейс: Система оцінки та розвитку PM-івЩотижнева програма внутрішнього навчання — я сам готував і проводив кожну сесію, перекладаючи теорію проектного менеджменту на наші внутрішні процеси. Кожна сесія записувалась, формуючи спільну базу знань, щоб знання не залишались замкненими в голові однієї людини.