Оставить заявку
Как на самом деле оценить IT-руководителя
IT-руководителя оценивают не по стеку, годам в профессии и умению решать алгоритмические задачи у доски, а по построенным командам и системам: кого он нанял и вырастил, какие процессы выстроил, как вёл команду через горящие релизы и ночные инциденты, как договаривался с бизнесом про техдолг. Сильный инженер и сильный руководитель — это разные роли. Первый отвечает за свою задачу, второй — за чужой результат, найм, приоритеты и предсказуемость. Глубокая техническая экспертиза — полезное условие, но не доказательство того, что человек умеет руководить.
Универсальная методика проста по идее и требовательна на практике: переводите разговор с технологий и общих рассуждений на конкретные команды, релизы и инциденты, а каждый ответ разворачивайте уточняющими вопросами до фактов — что лично сделал, какие цифры изменились, чем это подтверждается. Этой логике подчинена методика МАРКЕР ниже — семь шагов, которые помогают за один-два разговора отличить управленца от сильного исполнителя, которого красиво пересадили в кресло руководителя.
Почему IT-руководителя нельзя оценить по стеку и резюме
С IT-руководителем стандартное интервью почти всегда даёт искажённую картину. Формальные признаки — громкий стек, годы в разработке, известные продукты — легко принять за управленческую силу, хотя они говорят лишь о том, что человек был хорошим инженером. Ниже три причины, из-за которых оценка «по технологиям» подводит чаще всего.
Сильный инженер — не значит сильный руководитель
Лучшего разработчика часто повышают в руководители как награду. Но писать код и строить команду — разные навыки: один отвечает за свою задачу, другой — за найм, приоритеты и чужой результат.
Стеком и терминами легко создать видимость
IT-язык насыщен, а модный стек звучит весомо. Перечисление технологий и архитектурных паттернов создаёт ощущение зрелости, даже если за словами нет ни одной выстроенной команды и ни одного выстроенного процесса.
Результат руководителя размыт и отложен
Успех релиза зависит от многих людей, а ценность выстроенной системы видна, только когда что-то идёт не так. Легко присвоить себе общий результат команды, не сделав в нём ключевого управленческого вклада.
Управленец или исполнитель: как отличить за один разговор
Основа честной оценки — разговор не о технологиях вообще, а о конкретных управленческих ситуациях. У настоящего руководителя за каждым направлением стоят реальные люди, релизы и решения, за которые он отвечал. Ниже грани, по которым проходит водораздел между управленцем и сильным исполнителем в кресле руководителя.
«Я сделал» против «я организовал»
Исполнитель рассказывает, что написал и починил сам. Управленец — как настроил так, чтобы это делали другие. Просите по каждому кейсу отделить личный код от управленческого решения: где он работал руками, а где руками команды.
Найм и рост людей
Кого он нанял лично и кто из его людей вырос — до сеньора, до тимлида. Управленец помнит этот путь и свою роль в нём; исполнитель отвечает, что «команда сама подобралась», и не называет ни одной истории роста.
Приоритеты под давлением
Как он выбирает между сроком, объёмом и качеством, когда всё горит. Управленец называет развилки и их цену; исполнитель уходит в «надо просто поднажать» и в технические детали задачи, теряя картину команды.
Диалог с бизнесом
Умеет ли он объяснять технику на языке бизнеса и защищать решения — про техдолг, про сроки, про людей. Управленец переводит сложное в понятное; исполнитель прячется за жаргоном и обижается, что его «не понимают».
Системы вместо героизма
Чем он гордится: выстроенными процессами или личным героизмом в аврале. Управленец делает так, чтобы авралов было меньше; исполнитель раз за разом спасает релиз ночью и считает это нормой и поводом для гордости.
Четыре кейса: горящий релиз, ушедший лид, инцидент, техдолг
Управление лучше всего видно не в спокойных рассказах, а в ситуациях, где приходится выбирать. Дайте кандидату четыре сценария и слушайте не «правильный» ответ, а ход мысли: какие варианты он видит, какие риски называет первыми и как балансирует между людьми, сроками и качеством.
Горящий релиз: не успеваете к сроку
За день до релиза ясно, что команда не успевает. Что он делает: режет объём, двигает срок, добавляет людей? Управленец думает про ожидания бизнеса и цену каждого варианта; исполнитель — только про то, как успеть дописать код.
Ушедший лид: уходит ключевой инженер
Увольняется человек, на котором держался сервис. Как он реагирует в моменте и что делает, чтобы это не повторилось? Управленец видит риск концентрации знаний и выводы про систему; исполнитель реагирует обидой и паникой.
Инцидент в проде: ночью лёг сервис
Боевой сервис упал ночью. Кто и как действует в моменте и как разбирают причины потом? Управленец описывает роли, эскалацию и разбор без поиска виноватых; исполнитель рассказывает, как героически чинил всё сам.
Техдолг: бизнес хочет только фичи
Как он доказывает бизнесу, что часть времени нужно тратить на инфраструктуру, а не только на новые функции? Управленец переводит техдолг в язык рисков и денег; исполнитель жалуется, что «бизнес не понимает важности».
Как проверить построенные команды и системы
Сказать «я построил сильную команду» легко, поэтому каждое утверждение нужно разворачивать в кейс. Принцип один: реальный управленческий опыт выдерживает несколько уточняющих вопросов подряд, а пересказ общих заслуг — рассыпается. Ниже способы быстро отличить одно от другого прямо в разговоре, даже без технического образования у того, кто спрашивает.
Команда: имена, найм и рост
Сколько человек было и стало, кого он нанял лично, кто вырос до сеньора или лида, какой была текучесть. Реальный руководитель помнит этот путь по именам; тот, кто был рядом, ограничивается «команда у нас была сильная».
Система: метрики до и после
Какую архитектуру или процесс он внедрил и как изменились цифры — скорость релизов, время восстановления после сбоя, доля инцидентов. За эффектным «навели порядок» должна стоять измеримая разница.
Просите объяснить решение простыми словами
Попросите объяснить архитектурный выбор без жаргона, на языке бизнеса. Тот, кто понимает суть, легко переводит технику на человеческий язык. Тот, кто прикрывается терминами, не может объяснить, зачем решение бизнесу.
Спрашивайте про провалы и выводы
Просите рассказать проваленный релиз или ушедшего сильного человека и что он из этого вынес. Реальный руководитель честно разбирает свою роль и выводы; тот, кто украшает резюме, винит бизнес, команду или прошлое руководство.
Методика МАРКЕР: семь шагов оценки IT-руководителя
Чтобы оценка не превратилась в обмен заготовленными формулировками, интервью стоит вести по продуманной логике. Методика МАРКЕР — семь шагов, каждый из которых соответствует одной букве названия. Она помогает за один-два разговора перейти от приятного впечатления к обоснованному решению — и работает даже без технического бэкграунда у того, кто оценивает.
Модель задачи — определите, какой руководитель нужен
До интервью сформулируйте задачу: тимлид одной команды, руководитель разработки нескольких команд, IT-директор всей функции или продуктовый лидер. Под разные роли и стадии нужен разный опыт, и мерить кандидата надо именно под вашу задачу.
Анамнез контекста — разберите прошлые места
Сначала поймите, где и над чем он руководил: продукт или аутсорс, стадия компании, размер команд, стек и масштаб нагрузки. Это рамка, без которой любой кейс кандидата невозможно правильно прочитать.
Реальные команды и системы — на язык конкретики
Спросите про конкретные команды, релизы, инциденты и внедрённые процессы. Не довольствуйтесь тем, что кандидат «руководил разработкой» — просите назвать людей, цифры, развилки и итог.
Контроль глубины — разворачивайте кейсы вглубь
Каждый значимый кейс превращайте в историю по схеме «что было — что лично сделал — что получилось — чем подтверждается» и задавайте по три-четыре уточняющих вопроса подряд, включая «какие были альтернативы и почему выбрали это».
Единоличный вклад — отделяйте «я» от «мы»
Уточняйте, что в результате он сделал как руководитель, а что — команда, соседние отделы или удача рынка. Вопрос «что бы сломалось, если бы вас не было» быстро показывает, был ли кандидат автором результата или его свидетелем.
Разбор практического кейса
Дайте короткую задачу под вашу специфику: спланировать горящий релиз, разобрать инцидент или защитить техдолг перед бизнесом. Смотрите не на идеальность ответа, а на ход мысли и то, какие риски и развилки он видит первыми.
Релевантность — сверьте опыт с вашей задачей
В финале честно сопоставьте опыт кандидата с вашим контекстом: что совпадает, что будет новым — другая стадия, масштаб или культура — и как он планирует закрывать разрыв. Решение принимайте по совокупности фактов, а не по уверенности тона.
Красные флаги на интервью с IT-руководителем
Часть сигналов видна сразу, если знать, на что смотреть. Главный из них — когда на управленческие вопросы человек отвечает как инженер, уходя в технические детали вместо разговора о людях и решениях. Ниже типичные красные флаги и то, почему каждый из них стоит воспринимать всерьёз.
Технические детали вместо решений
На вопрос про команду и приоритеты кандидат сваливается в стек и архитектуру. Знание технологий — не то же самое, что умение нанимать, расставлять приоритеты и вести команду через горящий релиз.
Гордится героизмом, а не системой
Истории про то, как он лично спасал релиз по ночам, — признак, что процессы не выстроены. Сильный руководитель гордится тем, что авралов стало меньше, а не тем, что он снова всех спас.
Винит бизнес, команду или прошлых
Если во всех провалах виноваты бизнес, прежнее руководство или «слабая команда», а своей роли кандидат не видит — это сигнал. Реальный управленец первым делом разбирает, что мог сделать иначе сам.
Только «мы», никогда «я»
Постоянное «мы зарелизили», «у нас в команде» без перехода к личному вкладу маскирует отсутствие собственной роли. Уточняющий вопрос про «я» либо проясняет картину, либо обнажает пустоту.
Как оценить, подойдёт ли руководитель под вашу стадию и стек
Сильный IT-руководитель на одной стадии может не сработать на другой. Запуск с нуля в стартапе и управление зрелой платформой — это разные навыки, как и команда из пяти человек против нескольких десятков. Прежде чем оценивать «силу» кандидата, важно понять, под какую задачу вы его меряете.
Стадия совпадает с вашей задачей
Запуск с нуля, кратный рост или наведение порядка в зрелой системе требуют разного опыта. Уточняйте, на какой стадии он руководил плотно, а не сколько вообще «был в IT».
Масштаб команды и нагрузки
Управлять одной командой и держать несколько команд через тимлидов — разные задачи. Важно не громкое название, а реальный размер людей и систем, за которые он отвечал.
Продукт или аутсорс — под ваш формат
Руководитель из продуктовой команды и из аутсорса работают по-разному: один отвечает за долгий продукт и его метрики, другой — за поток проектов и сроки. Спросите, в каком формате он силён.
Честно отделяет знакомое от нового
Спросите, что в вашей задаче для него привычно, а что — новое, и как он будет в этом разбираться. Честное признание зон роста надёжнее уверенности, что «управление везде одинаковое».
По каким критериям сравнивать IT-руководителей
Приоритеты лучше расставить так: сначала совпадение опыта с вашей стадией и масштабом, затем доказанный результат в командах и системах, затем способность вести людей под давлением и говорить с бизнесом, а не только с инженерами. Ниже то, что помогает отличить сильного руководителя от уверенного собеседника.
Опыт совпадает с задачей
Руководил именно на той стадии и масштабе, которые актуальны для вас, а не «работал в IT вообще».
Думает командой, а не кодом
Свободно разбирает найм, приоритеты и процессы с итогом, а не прячется за стеком и архитектурой.
Кейсы выдерживают проверку
Разворачивает истории вглубь, чётко отделяет личный вклад от командного и спокойно говорит о провалах и выводах.
Ведёт людей под давлением
Держит горящий релиз и ночной инцидент через роли и приоритеты, а не через личный героизм и переработки.
Говорит с бизнесом
Объясняет технику и техдолг на языке рисков и денег, вместо позиции «бизнес всё равно не поймёт».
- Помнит свою команду по именам и объясняет, кого нанял и вырастил.
- Разворачивает кейсы вглубь и спокойно отвечает на уточнения.
- Переводит технику на язык бизнеса, а не прячется за жаргоном.
- Под давлением думает приоритетами и людьми, а не только кодом.
- Опыт по стадии и масштабу совпадает с вашей задачей.
- Сваливается в стек и детали вместо разговора о команде.
- Не помнит цифр по своим релизам и текучести команды.
- Говорит только «мы» и уходит от вопроса о личном вкладе.
- Гордится ночным героизмом, а не выстроенными процессами.
- Опыт с чужой стадии и масштаба без понимания вашего контекста.
Чек-лист: что подготовить до собеседования с IT-руководителем
Качество оценки во многом определяется до встречи. Если заранее не сформулировать задачу и кейсы, интервью легко превращается в обмен названиями технологий, где выигрывает тот, кто увереннее говорит. Этот чек-лист помогает прийти на встречу подготовленным.
- Задача роли: тимлид, руководитель разработки, IT-директор или продуктовый лидер — и под какую стадию компании.
- Четыре кейса для разбора: горящий релиз, ушедший лид, ночной инцидент и защита техдолга перед бизнесом.
- Два-три направления для разбора по схеме «что было — что лично сделал — что получилось — чем подтверждается».
- Короткое практическое задание под вашу реальную задачу, проверяющее ход мысли, а не выносливость.
- Профиль вашего контекста: стадия, масштаб команд, стек и тип задач, с которыми кандидата нужно сопоставить.
Как не нанять «сильного инженера» вместо настоящего руководителя
IT-руководитель — один из самых сложных кандидатов для оценки именно потому, что формальные признаки — громкий стек, годы в разработке, известные продукты — легко принять за управленческую силу. По опыту Work&Wolf, самая частая ошибка работодателя — оценивать руководителя по технической глубине и уверенности тона, а не по построенным командам и системам, которые выдерживают несколько уточняющих вопросов подряд.
Если вы хотите оценить IT-руководителя надёжно и не тратить десятки часов на интервью наугад, разумный шаг — опереться на тех, кто проверяет таких управленцев каждый день. На странице услуги можно подробнее посмотреть, как мы ищем кандидатов прямым поиском и оцениваем их по командам, релизам и инцидентам под вашу стадию, стек и тип задач.
Частые вопросы по теме
Как отличить управленца от исполнителя на собеседовании?
Сильный исполнитель рассказывает, что он сделал руками: написал сервис, разобрал инцидент, закрыл задачу. Управленец рассказывает, что он построил систему, в которой это делают другие: как нанял и вырастил команду, какие процессы выстроил, как принимал решения чужими руками и отвечал за чужой результат. Простой тест — спрашивайте «что бы сломалось, если бы вас не было». У исполнителя сломается конкретная задача; у руководителя — найм, приоритеты, взаимодействие команд и предсказуемость релизов. Просите разворачивать любой кейс до личного вклада: тот, кто реально руководил, легко отделяет «я сделал» от «я организовал, чтобы сделали», а исполнитель в роли руководителя сбивается на технические детали и теряет картину команды целиком.
Какие вопросы-кейсы задавать IT-руководителю на интервью?
Берите ситуации, в которых проявляется именно управление, а не код. Горящий релиз: что вы делаете, когда за день до релиза понятно, что не успеваете — режете объём, двигаете срок, добавляете людей? Ушедший лид: уходит ключевой инженер, на котором держался сервис — как реагируете и что делаете, чтобы это не повторилось? Инцидент в проде: ночью лёг сервис — кто как действует, как разбираете причины потом? Техдолг: как вы доказываете бизнесу, что часть времени нужно тратить на инфраструктуру, а не только на фичи? По каждому кейсу слушайте не «правильный» ответ, а ход мысли: какие варианты он видит, какие риски называет первыми, как балансирует между людьми, сроками и качеством.
Как проверить, что IT-руководитель действительно строил команды и системы?
Просите развернуть каждое утверждение в кейс по схеме «что было — что лично сделал — что получилось — чем подтверждается». Команда: сколько человек было, когда он пришёл, и сколько стало, кого он нанял лично, кто из его людей вырос до сеньоров или лидов, какая была текучесть. Система: какую архитектуру или процесс он внедрил, какую проблему это закрыло, как изменились метрики — скорость релизов, время восстановления после сбоя, доля инцидентов. Реальный руководитель помнит имена, цифры и развилки, на которых выбирал; тот, кто находился рядом, отвечает общими словами «мы построили сильную команду» и плывёт на третьем-четвёртом уточняющем вопросе.
Какие красные флаги на интервью с IT-руководителем?
Главный флаг — когда на управленческие вопросы человек отвечает как инженер: вместо разговора о людях и приоритетах уходит в технические детали и стек. Тревожно, если он говорит только «мы» и не может выделить личный вклад; винит в провалах бизнес, команду или прошлого руководителя, не видя своей роли; гордится переработками и героизмом вместо выстроенных процессов; не помнит цифр по своей команде и релизам; на вопрос про ушедшего сильного инженера реагирует обидой, а не выводами. Ещё один сигнал — выбор стека или архитектуры «потому что модно», без связи с задачей бизнеса. Это признаки, что перед вами сильный специалист, которого повысили, но управлять командой и системами он по-настоящему не научился.
Нужна ли техническая экспертиза, чтобы оценить IT-руководителя?
Глубокая техэкспертиза помогает, но не обязательна, и опираться только на неё опасно. Роль руководителя — это люди, процессы и решения, а не объём личного кода, поэтому большую часть можно проверить без программистского бэкграунда: как он строил команду, как принимал решения, как объяснял технику бизнесу. Хороший признак как раз в том, что IT-руководитель умеет объяснить сложное простыми словами без жаргона — если он понимает суть, он переведёт её на язык бизнеса легко. Техническую глубину, где она критична, разумно проверить отдельно: привлечь сильного инженера на одну встречу или дать кандидату разобрать реальный архитектурный кейс. Методика МАРКЕР в статье устроена так, что её шаги работают и без технического образования у того, кто оценивает.
Где найти и как нанять сильного IT-руководителя?
Сильные IT-руководители почти не откликаются на вакансии: их находят прямым поиском и по рекомендациям, а оценивают по построенным командам и системам, а не по стеку в резюме. Если оценивать управленца самим долго и рискованно, разумный шаг — опереться на тех, кто проверяет IT-руководителей каждый день. На странице услуги подбора IT-руководителей видно, как мы ищем кандидатов прямым поиском, проверяем их по реальным командам, релизам и инцидентам, отличаем управленца от сильного исполнителя и подбираем под вашу стадию, стек и тип задач — от тимлида и руководителя разработки до IT-директора и директора по продукту.
Что открыть после статьи, если задача уже назрела
Если после чтения хочется перейти от методики к действию, ниже три понятных варианта: посмотреть все IT-роли в хабе или разобраться в конкретной позиции — IT-директоре, руководителе отдела разработки или директоре по продукту.
IT-директор
Кому отдать всю IT-функцию: как проверить IT-директора по выстроенным процессам, бюджету и диалогу с бизнесом, а не по громкому стеку в резюме.
Перейти к подбору: IT-директорРуководитель отдела разработки
Кому поручить разработку: как оценить руководителя по построенным командам, предсказуемости релизов и умению вести инженеров через инциденты и техдолг.
Перейти к подбору: руководитель отдела разработкиДиректор по продукту
Когда нужен продуктовый лидер: как проверить директора по продукту по запущенным продуктам, метрикам и умению связывать команду с ценностью для бизнеса.
Перейти к подбору: директор по продукту