Как управлять 70 айтишниками и не сойти с ума: рецепты от IT-топ-менеджера
Роман Тамашевский почти десять лет строит и возглавляет инженерные команды в IT-инфраструктуре. В крупной кипрской компании он прошёл путь от руководителя пяти инженеров до IT-топ-менеджера, под началом которого 70 специалистов, 12 направлений и до 2,5 тысячи закрытых задач в месяц.
В интервью Роман рассказывает, почему методы управления, которые работают с пятью людьми, ломаются на семидесяти, зачем нужен понятный owner у каждой системы, помогает ли AI программистам на самом деле и какую ошибку совершают сильные Senior-инженеры, когда становятся руководителями.
— Вы вырастили команду с 5 до 70 человек. Как не потерять управляемость и качество при таком росте инженерного отдела?
Самая большая ошибка при росте команды – пытаться управлять 70 людьми теми же методами, которыми управлял пятью.
С командой из пяти человек руководитель знает практически всё и участвует почти во всех решениях. С 70 сотрудниками так уже не выходит. Если все решения идут через одного человека, он сам становится главным тормозом организации.
Поэтому моей задачей стало не управление отдельными инженерами, а построение системы управления. Мы разделили инфраструктуру на направления, назначили лидов и наладили процессы между командами. Руководителям направлений мы передавали не только задачи, но и право принимать решения, делегирование без полномочий не работает. Моя роль сместилась вверх. Вместо «как настроен сервер» появились вопросы «зачем нам этот класс серверов», «что будет с платформой через два года». При этом важно периодически спускаться на уровень ниже и разговаривать с инженерами.
Масштабирование управления это не увеличение контроля, а создание системы, которая требует его меньше.
— Чтобы управлять 70 сотрудниками, вы разделили их на 12 направлений. Как вы делили обязанности, чтобы люди не путались и не мешали друг другу?
Главный принцип в том, что у каждой системы и зоны ответственности должен быть понятный owner. В инфраструктуре легко получить ситуацию, когда Kubernetes ведёт одна команда, сеть другая, мониторинг третья, базы четвёртая. При инциденте на стыке технологий вдруг оказывается, что за результат формально никто не отвечает.
Поэтому мы делили направления не только по технологиям, но и по ответственности за сервис. Условно, Cloud, Kubernetes, Databases, Network, CI/CD, Observability и другие. У каждого направления был свой scope, технический лидер и набор сервисов.
Но границы провести недостаточно, важнее то, что происходит на стыке команд. Нужно заранее понимать, кто принимает архитектурное решение, кто эксплуатирует систему, кто реагирует на инцидент и когда задача переходит другой команде. У задачи должен быть owner, критерии готовности и понятный результат. Если изменение затрагивает production, должны быть понятны способ проверки и возможность rollback. Корпоративная бюрократия чаще всего появляется не потому, что менеджеры любят процессы, а там, где плохо определена ответственность. Если люди точно понимают, кто за что отвечает, им нужно меньше согласований.
— На что вы обращаете внимание при выборе ключевых специалистов, помимо их технических навыков? Как понять, что человек впишется в коллектив?
Для Senior-инженера технические знания это необходимое условие, но не достаточное. Мне интереснее понять, как человек думает, когда нет готового ответа. Поэтому на интервью я разбираю реальные ситуации, а не только вопросы вроде «как работает Terraform». Production деградирует без очевидной причины, что вы будете делать? Важен не столько ответ, сколько логика рассуждений: какие данные человек запросит, какие гипотезы сформулирует, понимает ли риски.
Ещё важны способность сказать «я не знаю», если дальше следует «но я знаю, как это выяснить», отношение к ошибкам, интереснее услышать про реальную ошибку и что человек после неё изменил, чем историю про безупречные десять лет, и умение работать с людьми: сильный инженер, после общения с которым падает эффективность окружающих, для большой команды может быть скорее вреден.
Мне не близко «впишется в коллектив» в смысле похожести. Мне не нужны 70 одинаковых людей, важнее профессиональная совместимость, умение аргументировать позицию, слышать других и не превращать разногласия в личные конфликты.
— Ваша команда закрывала по 2,5 тысячи задач в месяц. Как заставить такой огромный механизм работать чётко, чтобы люди не выгорали, а начальник не стоял у каждого за спиной?
Слово «заставить» описывает подход, который плохо масштабируется. Контролировать лично несколько тысяч задач в месяц невозможно. Если система требует постоянных напоминаний, проблема в самой системе управления. При таком масштабе всё держится на прозрачности и понятных правилах. У задачи должен быть owner, должно быть ясно, зачем она нужна и что считается результатом. Если задача заблокирована, это видно сразу, а не выясняется через две недели.
Я стараюсь минимизировать ручной контроль, хороший процесс сам показывает исключения: где задачи зависают и где команда систематически не успевает. Менеджмент должен работать как хороший monitoring, привлекать внимание, только когда показатели выходят за норму.
Количество закрытых задач само по себе не показатель эффективности. Можно закрывать тысячи тикетов и не создавать ценности, поэтому я смотрю ещё и на результат, что стало быстрее, дешевле, стабильнее, сколько инцидентов удалось предотвратить. С выгоранием, на мой взгляд, лучше борется не тимбилдинг, а устранение постоянного хаоса. Если человек каждый день тушит пожары и не понимает, за что отвечает, никакие мероприятия это не компенсируют.
— Сейчас все говорят про нейросети. Вы проверяли, как AI помогает программистам в реальной работе. Есть ли от него настоящая польза?
Польза от AI реальная, но я бы не сказал, что он теперь программирует вместо инженеров. Скорее это очень быстрый дополнительный инструмент. Он хорошо справляется с рутинным кодом, тестами, документацией, анализом логов, SQL-запросами, Terraform, Ansible, CI/CD-конфигурациями. Особенно заметна разница на небольших задачах, которые раньше занимали по 15–30 минут. Я сам активно использую его в разработке, можно описать архитектурную идею и быстро получить прототип.
Здесь есть парадокс. Чем сильнее инженер, тем больше пользы он получает от AI. Получить код сейчас легко, сложнее понять, хороший ли это код, какие у него побочные эффекты и что будет с ним в production. AI может очень убедительно предложить неправильное решение.
Поэтому я вижу в нём усилитель инженера, а не замену экспертизы. Senior с AI становится продуктивнее, junior с AI пишет больше кода, но это не значит, что система станет лучше. Главный эффект AI, скорее всего, не в замене программистов, а в том, что один сильный инженер сможет решать задачи, для которых раньше требовалось несколько специалистов.
— Вы регулярно проводите встречи один на один с сотрудниками. Как сделать эти разговоры полезными для развития человека, чтобы они не превращались в скучную формальность?
Главная ошибка, это превратить one-to-one в status meeting. Если половина встречи про «что с этой задачей» и «когда будет готово», это уже не one-to-one, для этого есть таск-трекер и рабочие встречи.
На one-to-one мне интереснее то, что обычно не видно. Что мешает человеку работать, что его раздражает, чему он хочет научиться, понимает ли он мои ожидания и видит ли свой следующий шаг. Иногда самый полезный результат такой встречи, узнать о проблеме, которую я вообще не видел, например что команда месяц выполняет бессмысленную ручную операцию по привычке.
Развитие человека я стараюсь обсуждать не абстрактно, вроде «стань более senior», а через конкретное изменение поведения. Сейчас ты хорошо решаешь задачи, которые тебе дают, следующий уровень, самому находить проблему и доводить решение до production. Обратная связь должна идти в обе стороны, я тоже спрашиваю, что могу делать лучше как руководитель.
— Какую главную ошибку совершают сильные Senior-инженеры при переходе на роль руководителей?
Самая частая ошибка, это продолжать быть главным инженером команды. Человек становится руководителем, но по-прежнему берёт себе самые сложные задачи, решает их быстрее всех, сам принимает архитектурные решения, а если инженер сделал что-то не так, садится вечером и переписывает.
Какое-то время это даже даёт хорошие результаты, но команда перестаёт расти. Все сложные решения принимает один человек, остальные привыкают приходить к нему за ответами, и сам руководитель становится bottleneck. Особенно тяжело это даётся сильным инженерам, ведь раньше их ценность определялась тем, насколько хорошо они сами решают задачи. После перехода в менеджмент метрика меняется. Твоя задача не написать лучший код, а создать команду, которая без тебя напишет код лучше, чем ты один. Хороший тест для руководителя, что будет, если завтра я исчезну на месяц? Если команда продолжит принимать решения и решать инциденты, система работает. Если всё остановится в ожидании моего возвращения, то это была не команда, а группа помощников.
Для меня переход от Senior-инженера к руководителю происходит именно тогда, когда перестаёшь измерять свою эффективность количеством решённых задач и начинаешь измерять эффективностью людей и системы, которую построил.
Автор: Мария Минская
