Привет!

Меня зовут Андрей и я руковожу IT-подразделением. Около 5 последних лет я работаю в бигтехе с командами от единиц до сотен инженеров. Так сложилось, что команд я потрогал много и разных: некоторых руководителей время от времени перемещают по частям компании и зонам ответственности и я – не исключение.

За свой, может быть, не самый продолжительный, но очень интенсивный карьерный трек я увидел большое количество разных управленцев. Часть – я вырастил из своих ребят до уровней M1 и M2 (руководителей групп и служб). Часть – нанял. Часть – достались мне в наследство.

Мы вместе с моими подчинёнными и руководителями наступали на множество граблей: ошибки найма, ошибки увольнения, ошибки делегирования, ошибки планирования, ошибки проектирования, ошибки в организации вечеринок и..подставь сюда любую, приходящую тебе в голову.

Я хочу поделиться с читателем (предположительно – начинающим или уже опытным руководителем) школой мысли, которая снижает вероятность большинства известных мне видов ошибок. Фреймворк – очень простой концептуально и широко применимый. Я был бы рад, получив его в начале своего карьерного пути и буду счастлив, если эта статья поможет хотя бы одному руководителю стать лучше.

Ну что, поехали?

Часть 1. Особенность управленческого карьерного трека

У работы руководителя в IT есть одно интересное различие от работы IC (Individual Contributor):

Разработчики, меняющие компанию каждый год –  обычное дело. Я знаю пачку кейсов, когда регулярная смена работы помогала людям сильно расти в деньгах и в должности за короткий промежуток времени. Этот подход известен как джоб-хоппинг и, не смотря на нападки со стороны части коммьюнити, тяжело отрицать, что он может хорошо работать. Я своими глазами видел и пробовал :)

Даже если не менять компанию – в большинстве случаев, разработчик может прийти к своему руководителю со словами:

Слушай, я устал от своего проекта. Я что-то полгода пилю биллинговую систему и видеть уже не могу этот домен, присущие ему костыли и баги и прочее. А можно мне что-то другое?

Если сотрудник ценен для компании – он почти всегда действительно получит после этого что-то другое. Так что..разработчиков, которые годами варятся в одном и том же домене и/или сервисе – очень немного. Это необязательно, а иногда – неприятно и невыгодно

У руководителей так не работает. В большинстве случаев тимлид (а тем более –руководитель более высокого уровня) – это человек, который проводит с командой и доменом много времени. Руководитель почти никогда не растет в должности за один год. За год или менее банально очень тяжело совершить качественный скачок в своём домене (например, вырастить gmv своего продукта на 10%; сделать систему в 10 раз надёжнее; вырастить пачку синьоров и, среди них, своего заместителя). А ещё – разговор вида:

Слушай, что-то я заскучал в своём домене со всеми его бизнес-требованиям и костылями

От лида может звучать странно.

Дружище, ты ведь и есть тот самый человек, который должен мотивировать 10 других людей ковыряться в этом домене со всеми его бизнес-требованиями и костылями. Если ты потеряешь мотивацию и не будешь улучшать его год за годом – никто не будет!

Лично я, помимо прочего, по-разному воспринимаю линейных разработчиков, каждый год меняющих компанию, и руководителей, каждый год меняющих компанию. Разработчики у меня обычно вызывают 0 вопросов:

– По хардам чувак крутой? Крутой
– Коммуницирует адекватно? Адекватно
– Задачи мои делать хочет? Хочет

– Ну, глядишь, годик поработает, а там, если ему надоест, дам другой проект. Берём.

А с управленцами история другая:

– Работает по году или меньше на каждом месте? Хмм..А успел ли он внести значимых технических изменений в систему, и удачными ли они были? (Дальше следует серия вопросов, ответы не всегда утешительны)
– А заместителей-то он успевает готовить за такое короткое время? Что, в каждом месте? (На практике тоже часто оказывается, что нет – дело это долгое и кропотливое)
– А как у него дела с удержанием и долгосрочной мотивацией/развитием сотрудников? Спрошу, наверное, как росли уровни и менялась год к году текучка людей в команде. А, погодите, статистики-то нет...

Короче говоря: приходя работать лидом, стоит ожидать, что зона ответственности с тобой надолго.

Понятное дело, что бывают исключения. Иногда твоя компания закрывается и выбора нет. Иногда – тебе пообещали одну работу, а дали – совсем другую и ты имеешь полное моральное право вернуться на рынок труда. Так что здесь речь не про разовый кейс в карьере человека, а именно про систему.

Часть 2. Примеры ошибок, которые совершают руководители

Рассмотрим несколько типовых ошибок, совершаемых руководителями разных уровней.

a. Жесткое вертикальное управление в команде

Один из подходов, к которым приходят руководители с определённым жизненным опытом и складом характера: плотно контролировать все решения, принимаемые и реализуемые в команде. Распространённая мотивация выглядит примерно так:

Я – самый крутой инженер в команде и справлюсь с любой задачей лучше любого своего подчинённого. Любой мой подчинённый, вероятно, примет менее эффективное решение, а я хочу приносить максимум пользы компании. Будет преступлением кому-то передавать ответственность

Подход неплохо работает "в моменте", если руководитель действительно крутой. Но он не эффективен на дистанции:

1. Люди в команде банально не дорастут до текущего уровня руководителя, если не будут самостоятельно (может быть, с его избирательным ревью) решать сложные задачи и разбираться с последствиями своих ошибок. Таким образом, команда вряд ли станет намного сильнее, чем есть сейчас

2. У людей формируется мышление: "все сложные решения примет руководитель, мне – достаточно быть хорошим исполнителем". В случае увольнения/отпуска/болезни руководителя, команда окажется "обезглавленной" (а голов в пределе могло бы быть столько, сколько людей в команде!)

b. Нерешительность в исправлении и расставании с андерперформерами

Бывает, что сотрудник откровенно недотягивает, но руководителю всё время его "жалко" или он просто избегает неприятного разговора.
Назовём такого сотрудника Петя.
У руководителей, которые тянут с расставанием или хотя бы с тем, чтобы максимально прямо поговорить с человеком о том, что дела идут плохо, часто возникают следующие рассуждения:

– Ну..польза-то для бизнеса всё равно есть. А нового человека – ещё искать/обучать и тд. Петя уже два года со мной, многое знает
– Ну..иногда же Петя начинает нормально работать. Я вот даю негативного фидбека, потом начинаю ежедневно проверять, как дела идут – и нормально. Спустя месяц, конечно, откатывается, но..это же только моя проблема, правда? Всем остальным – Петя полезен. Наверное, это вообще я не дожимаю
– Петя год назад отличился на проекте и ребята думают, что он крутой. Если я его уволю – мне придётся отвечать на неприятные вопросы и какое-то время успокаивать команду. А так – ну..можно же потерпеть, не так уж всё и ужасно

Такой подход приводит к следующим проблемам:

1. Нового сотрудника руководитель бы в итоге всё равно нашел и обучил – команда через полгода была бы в хорошей форме. А Петя может ни шатко ни валко тянуть свои таски годами (без шуток, такие люди в компаниях есть – они как раз не всегда джоб-хоппят тк не являются искателями быстрого роста)

2. Люди в команде – не идиоты. Если коллектив продолжительное время работает вместе, Вася обязательно узнает, что Петя получает примерно похожую сумму денег, но вот только работает в два раза меньше. После чего, не будь дураком, Вася либо сам поделит свою работу на два, либо банально пойдет работать в команду, где перформанс справедливо оценивают

3. В целом из (1) и (2) следует, что андерперформер – это не только головная боль руководителя, а головная боль всей команды, которую может решить только руководитель. Если этого не делать, команда будет деградировать

Важно: я говорю про ситуацию, когда руководитель уже давал обратную связь сотруднику и андерперформанс – систематический. Ни в коем случае не призываю к увольнениям людей за первую случившуюся провинность

c. Забивание на техдолг

Встречается у лидов, которые очень ориентированы на бизнес и очень любят команду или хотят быстрых и красивых результатов:

– Продакт попросил на месяц отказаться от техноквоты, чтобы быстрее запустить фичу? Ну, фича и правда ценная – а с багами мы ж жили всё это время..
– А, дальше ещё один важный проект? Ну, сейчас-сейчас, его дожмём, и техно займёмся

Этот подход порой действительно помогает принести красивых результатов на горизонте полугода, но потом команда, неожиданно, оказывается в болоте и красивые результаты заканчиваются. На выходе – останавливаешь продуктовую разработку, чтобы разгрести баги, ловишь кучу хейта от продактов, а ещё – кучу хейта от технической команды за то, что они – в болоте.

Остановимся на трёх примерах, чтобы не делать текст чересчур депрессивным :)

Часть 3. Что общего у этих проблем?

В каждую из описанных проблем (а подобных – ещё множество, докинь сюда кейсов из своего опыта) руководитель, на самом деле, не желает никому зла. Он просто хочет быстро и с наименьшим количеством боли получить хороший результат. Вот только есть нюанс: в отличие от позиции разработчика, на которой ты быстро получишь результат, а потом сменишь работу, при должности руководителя ты, скорее всего, останешься на том же компании в том же месте и увидишь, что последует за мгновенным результатом.

И..внезапно оказывается, что за некоторыми решениями, делающими жизнь одного человека (руководителя или менеджера) лучше "прямо сейчас" следует..ухудшение жизни всей команды на дистанции.

Часть 4. А что делать?

Способ мышления, который я предлагаю, формулируется просто:

Принимай решения так, чтобы команда через год была лучше, чем сейчас.

Такой фреймворк помогает предотвратить многие проблемы.

– Активнее делегировать и обучать ребят, или продумывать решения самому, оставляя подчинённым только их реализацию при моём жестком ревью? Мм..в первом случае – команда за год чему-то научится и вместо одной (моей) головы, голов будет штук пять. Вот это заживём! Попробую так и делать

– Расстаться с андерперформером, временно просадив перформанс и взяв больше работы на себя, или терпеть? А будет ли моя команда через год от этого лучше? Скорее всего, будет. Надо делать

И так далее.

Ограничение применимости фреймворка:

Применяя вышеописанный подход, стоит помнить:

Команда регулярно должна что-то выпускать

"Что-то" – зависит от конкретной команды. Это могут быть продуктовые фичи в приложении. Могут быть оптимизации поискового движка. Или новые функции софта для других разработчиков. Короче говоря – это то, ради производства чего, вообще говоря, существует твоя команда.

Чтобы не заиграться в оптимизации и, например, не отправив всех сотрудников команды на классное обучение длиной в год, улучшая будущее, помни, что надо всегда что-то выпускать. Локальные просадки (например, при заменах или обучении людей) – допустимы, но останавливаться совсем – нельзя.

Вместо послесловия

Принимать стратегические решения (=решения с оглядкой на будущее команды) – непросто. Они могут быть эмоционально сложны для тебя в моменте. Они могут быть не очевидны участникам команды или твоему руководству, если они не заглядывали так глубоко, как ты (и это – нормально, тебя ведь за этим и наняли!). В любой сложной ситуации – запасись терпением, выпей чайку и объясни людям, какие последствия ты ожидаешь на дистанции от своего решения, даже если оно – непопулярно.

Помни, что твоя работа – не принимать приятные и очевидные решения. Твоя работа – делать команду и компанию лучше со временем. Ты обязательно справишься!

А ещё, я недавно начал вести канал в телеге, тк физически не успеваю охватить лично всех лидов, которым хотел бы помочь. Если тебе интересно получить больше контента и обменяться опытом с другими лидами – приходи :) https://t.me/leadsnotes