Шаблон кар’єрної драбини

Кар’єрна драбина керівника розробки: шаблон

Чотири рівні від Engineering Manager до VP of Engineering і шість управлінських компетенцій.

Безкоштовний тариф · Банківська картка не потрібна

Ця драбина описує управлінський трек у розробці для компанії приблизно на 20–200 людей: від керівника, який уперше веде одну команду, до людини, що відповідає за всю розробку. Вона доповнює кар’єрну драбину розробника: керувати людьми — це інша робота, а не наступний щабель після senior-розробника. Найвищий рівень, VP of Engineering, — керівник усієї функції розробки, а інженери, які зростають без управління людьми, йдуть драбиною розробника.

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

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

Рівні коротко

Engineering Manager
Керує однією командою розробників і відповідає за її людей, випуск і здоров’я.
Масштаб
Одна команда приблизно з чотирьох–восьми розробників.
Senior Engineering Manager
Керує кількома командами або однією великою — часто через техлідів чи керівників-початківців.
Масштаб
Дві–три команди або 10–25 розробників, іноді разом із керівниками, які керують уперше.
Director of Engineering
Очолює департамент розробки й перетворює цілі компанії на його плани, структуру та найм.
Масштаб
Продуктовий напрям або департамент із кількох команд та їхніх керівників.
VP of Engineering
Очолює всю розробку й відповідає за її результати перед керівництвом компанії.
Масштаб
Уся інженерна організація, її бюджет і її роль у стратегії компанії.

Матриця компетенцій

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

Що означає кожна компетенція

Розвиток людей: Допомагати кожному зростати, давати чесний зворотний зв’язок і справедливо працювати з результативністю.
Реалізація та випуск: Домагатися, щоб команда випускала важливе передбачувано й у сталому темпі.
Здоров’я команди та найм: Будувати команди, до яких хочуть приходити й у яких хочуть залишатися.
Технічне лідерство: Зберігати достатньо технічного судження для добрих рішень, не стаючи вузьким місцем.
Стратегія та планування: Перетворювати цілі на плани, а плани — на правильну роботу.
Партнерство з іншими функціями: Працювати з продуктом, дизайном, продажами, підтримкою й керівництвом як одна команда.

Керівник розробки: очікування за компетенціями й рівнями
Компетенція	Engineering Manager	Senior Engineering Manager	Director of Engineering	VP of Engineering
Розвиток людей	Регулярно проводить зустрічі один на один із кожним підлеглим, дає конкретний зворотний зв’язок протягом днів, а не місяців, і щокварталу узгоджує з кожним ціль розвитку.	Коучить керівників-початківців і техлідів, калібрує оцінки між командами, щоб однакова робота отримувала однакову оцінку, і рано береться за проблеми з результативністю.	Вирощує в департаменті резерв керівників, стежить, щоб кожен розробник мав зрозумілий шлях на наступний рівень, і відповідає за рішення про підвищення в департаменті.	Визначає, як розробка вирощує людей, — кар’єрні драбини, оцінювання й підвищення — і розвиває директорів та керівників, які керують цією системою.
Реалізація та випуск	Вибудовує ритм планування й випуску команди, тримає зобов’язання реалістичними, попереджає про ризики до зриву термінів і захищає команду від постійної зміни пріоритетів.	Координує випуск кількох команд, знімає блокери між ними й веде кілька паралельних проєктів, не скочуючись у мікроменеджмент.	Задає підхід до реалізації в департаменті, балансує роботу за роадмапом із технічним боргом і надійністю та вимагає від керівників результату.	Відповідає за результати розробки з огляду на цілі компанії, звітує керівництву про прогрес і компроміси та усуває системні причини повільного випуску.
Здоров’я команди та найм	Рано помічає вигорання, конфлікти й втрату залученості та реагує на них, проводить ретроспективи, після яких щось змінюється, і проводить структуровані інтерв’ю за узгодженими критеріями на відкриті позиції команди.	Визначає структуру й склад кількох команд, тримає єдину планку найму в усіх інтерв’юерів і стежить, щоб новачки виходили на продуктивність у перші місяці.	Планує чисельність департаменту, проводить межі команд за зрозумілими зонами відповідальності й підвищує утримання, спираючись на те, що показують вихідні інтерв’ю та опитування залученості.	Відповідає за стратегію найму в розробку, організаційну структуру й культуру: що заохочується, з чим миряться, а що неприпустимо.
Технічне лідерство	Розуміє системи команди достатньо, щоб оцінювати компроміси, бере участь у дизайн-рев’ю й тримає технічний борг на виду та в планах.	Разом із техлідами та staff-інженерами працює над архітектурою на стику команд і стежить, щоб вагомі технічні рішення фіксувалися письмово й проходили рев’ю.	Разом зі staff- і principal-інженерами визначає технічний напрям департаменту й виділяє ресурси на платформну роботу та надійність, які жодна команда сама не поставила б у пріоритет.	Забезпечує, щоб розробка мала переконливу технічну стратегію й сильних технічних фахівців для її втілення, і ухвалює остаточні рішення щодо великих технологічних інвестицій.
Стратегія та планування	Перекладає продуктові цілі в квартальний план команди, пояснює, чому обрано саме ці пріоритети, і відмовляється від роботи, яка в них не вписується.	Складає плани на кілька команд, вибудовує порядок залежностей між ними й коригує план, коли змінюються цілі.	Пише річний план і бюджет департаменту, вирішує, куди спрямувати людей, і пов’язує роботу розробки з вимірюваними бізнес-результатами.	Формує стратегію компанії як член керівництва, задає річні цілі й бюджет розробки та вирішує, чим розробка займатися не буде.
Партнерство з іншими функціями	Працює на рівних із продакт-менеджером і дизайнером команди, чітко вибудовує очікування зацікавлених сторін і чесно повідомляє про стан робіт.	Керує очікуваннями кількох продуктових партнерів, розв’язує суперечливі запити між командами й ескалює з варіантами рішень, а не лише з проблемами.	Є головним партнером від розробки для одного чи кількох керівників функцій і домовляється про роадмап, обсяг і склад команд на рівні департаменту.	Представляє розробку в керівництві компанії та перед радою директорів, вибудовує довіру з колегами з усіх функцій і пояснює роботу розробки мовою бізнесу.

Прокрутіть таблицю вбік, щоб побачити всі рівні.

Завантажити CSV Відкривається в Excel, Google Таблицях і Numbers.

Engineering Manager: що очікується

Керує однією командою розробників і відповідає за її людей, випуск і здоров’я. Одна команда приблизно з чотирьох–восьми розробників.

Розвиток людей: Регулярно проводить зустрічі один на один із кожним підлеглим, дає конкретний зворотний зв’язок протягом днів, а не місяців, і щокварталу узгоджує з кожним ціль розвитку.
Реалізація та випуск: Вибудовує ритм планування й випуску команди, тримає зобов’язання реалістичними, попереджає про ризики до зриву термінів і захищає команду від постійної зміни пріоритетів.
Здоров’я команди та найм: Рано помічає вигорання, конфлікти й втрату залученості та реагує на них, проводить ретроспективи, після яких щось змінюється, і проводить структуровані інтерв’ю за узгодженими критеріями на відкриті позиції команди.
Технічне лідерство: Розуміє системи команди достатньо, щоб оцінювати компроміси, бере участь у дизайн-рев’ю й тримає технічний борг на виду та в планах.
Стратегія та планування: Перекладає продуктові цілі в квартальний план команди, пояснює, чому обрано саме ці пріоритети, і відмовляється від роботи, яка в них не вписується.
Партнерство з іншими функціями: Працює на рівних із продакт-менеджером і дизайнером команди, чітко вибудовує очікування зацікавлених сторін і чесно повідомляє про стан робіт.

Senior Engineering Manager: що очікується

Керує кількома командами або однією великою — часто через техлідів чи керівників-початківців. Дві–три команди або 10–25 розробників, іноді разом із керівниками, які керують уперше.

Розвиток людей: Коучить керівників-початківців і техлідів, калібрує оцінки між командами, щоб однакова робота отримувала однакову оцінку, і рано береться за проблеми з результативністю.
Реалізація та випуск: Координує випуск кількох команд, знімає блокери між ними й веде кілька паралельних проєктів, не скочуючись у мікроменеджмент.
Здоров’я команди та найм: Визначає структуру й склад кількох команд, тримає єдину планку найму в усіх інтерв’юерів і стежить, щоб новачки виходили на продуктивність у перші місяці.
Технічне лідерство: Разом із техлідами та staff-інженерами працює над архітектурою на стику команд і стежить, щоб вагомі технічні рішення фіксувалися письмово й проходили рев’ю.
Стратегія та планування: Складає плани на кілька команд, вибудовує порядок залежностей між ними й коригує план, коли змінюються цілі.
Партнерство з іншими функціями: Керує очікуваннями кількох продуктових партнерів, розв’язує суперечливі запити між командами й ескалює з варіантами рішень, а не лише з проблемами.

Director of Engineering: що очікується

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

Розвиток людей: Вирощує в департаменті резерв керівників, стежить, щоб кожен розробник мав зрозумілий шлях на наступний рівень, і відповідає за рішення про підвищення в департаменті.
Реалізація та випуск: Задає підхід до реалізації в департаменті, балансує роботу за роадмапом із технічним боргом і надійністю та вимагає від керівників результату.
Здоров’я команди та найм: Планує чисельність департаменту, проводить межі команд за зрозумілими зонами відповідальності й підвищує утримання, спираючись на те, що показують вихідні інтерв’ю та опитування залученості.
Технічне лідерство: Разом зі staff- і principal-інженерами визначає технічний напрям департаменту й виділяє ресурси на платформну роботу та надійність, які жодна команда сама не поставила б у пріоритет.
Стратегія та планування: Пише річний план і бюджет департаменту, вирішує, куди спрямувати людей, і пов’язує роботу розробки з вимірюваними бізнес-результатами.
Партнерство з іншими функціями: Є головним партнером від розробки для одного чи кількох керівників функцій і домовляється про роадмап, обсяг і склад команд на рівні департаменту.

VP of Engineering: що очікується

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

Розвиток людей: Визначає, як розробка вирощує людей, — кар’єрні драбини, оцінювання й підвищення — і розвиває директорів та керівників, які керують цією системою.
Реалізація та випуск: Відповідає за результати розробки з огляду на цілі компанії, звітує керівництву про прогрес і компроміси та усуває системні причини повільного випуску.
Здоров’я команди та найм: Відповідає за стратегію найму в розробку, організаційну структуру й культуру: що заохочується, з чим миряться, а що неприпустимо.
Технічне лідерство: Забезпечує, щоб розробка мала переконливу технічну стратегію й сильних технічних фахівців для її втілення, і ухвалює остаточні рішення щодо великих технологічних інвестицій.
Стратегія та планування: Формує стратегію компанії як член керівництва, задає річні цілі й бюджет розробки та вирішує, чим розробка займатися не буде.
Партнерство з іншими функціями: Представляє розробку в керівництві компанії та перед радою директорів, вибудовує довіру з колегами з усіх функцій і пояснює роботу розробки мовою бізнесу.

Як адаптувати цю драбину

Залиште лише потрібні рівні
Компанії з 15 розробниками зазвичай потрібні один–два з цих рівнів, а не чотири. Запроваджуйте наступний рівень, коли така робота справді з’явилася, — наприклад, коли керівник починає керувати іншими керівниками. У багатьох компаніях такого розміру вершина цієї драбини — CTO, який поєднує рівень VP із відповідальністю за технічну стратегію; якщо у вас є обидві ролі, VP керує організацією, а CTO — технологіями.
Пов’яжіть її з драбиною розробника
Зіставте кожен управлінський рівень із рівнем розробника зі схожими масштабом і зарплатою, щоб перехід між треками був кроком убік. Поширена точка відліку — Senior-розробник поруч з Engineering Manager.
Вирішіть, наскільки технічними мають бути керівники
В одних компаніях керівники рев’юять код, в інших — зосереджені на людях і випуску. Запишіть свою відповідь у рядок «Технічне лідерство», щоб очікування було явним, а не мовчазно припущеним.
Збирайте зворотний зв’язок знизу за тією самою драбиною
Попросіть підлеглих і колег керівника дати зворотний зв’язок за тими самими компетенціями. Він розповість про розвиток людей і здоров’я команди більше, ніж самооцінка керівника.

Питання та відповіді

Питання про цю драбину

Чим керівник розробки відрізняється від техліда?

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

Коли компанії потрібен перший керівник розробки?

Зазвичай — коли в команді стає більше ніж шість–вісім розробників або коли засновник чи CTO вже не має часу на регулярні зустрічі один на один із кожним. Саме тоді люди починають недоотримувати зворотний зв’язок і розмови про кар’єру.

Перехід у керівники — це підвищення?

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

Як оцінювати роботу керівника розробки?

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

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

Для компанії на 20–200 людей вистачить трьох–чотирьох: керівник однієї команди, керівник кількох команд і один–два рівні керівництва вище. Додавайте нові, лише коли на кожному щаблі є реальна роль.

Створіть цю кар’єрну драбину в LadderKit — безкоштовно

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

Почати безкоштовно Відкрити демоверсію Без реєстрації