Привет!
Меня зовут Андрей и я руковожу IT-подразделением. Около 5 последних лет я работаю в бигтехе с командами от единиц до сотен инженеров. Так сложилось, что команд я потрогал много и разных: некоторых руководителей время от времени перемещают по частям компании и зонам ответственности и я – не исключение.
За свой, может быть, не самый продолжительный, но очень интенсивный карьерный трек я увидел большое количество разных управленцев. Часть – я вырастил из своих ребят до уровней M1 и M2 (руководителей групп и служб). Часть – нанял. Часть – достались мне в наследство.
Мы вместе с моими подчинёнными и руководителями наступали на множество граблей: ошибки найма, ошибки увольнения, ошибки делегирования, ошибки планирования, ошибки проектирования, ошибки в организации вечеринок и..подставь сюда любую, приходящую тебе в голову.
Я хочу поделиться с читателем (предположительно – начинающим или уже опытным руководителем) школой мысли, которая снижает вероятность большинства известных мне видов ошибок. Фреймворк – очень простой концептуально и широко применимый. Я был бы рад, получив его в начале своего карьерного пути и буду счастлив, если эта статья поможет хотя бы одному руководителю стать лучше.
Ну что, поехали?
Часть 1. Особенность управленческого карьерного трека
У работы руководителя в IT есть одно интересное различие от работы IC (Individual Contributor):
Разработчики, меняющие компанию каждый год – обычное дело. Я знаю пачку кейсов, когда регулярная смена работы помогала людям сильно расти в деньгах и в должности за короткий промежуток времени. Этот подход известен как джоб-хоппинг и, не смотря на нападки со стороны части коммьюнити, тяжело отрицать, что он может хорошо работать. Я своими глазами видел и пробовал :)
Даже если не менять компанию – в большинстве случаев, разработчик может прийти к своему руководителю со словами:
Слушай, я устал от своего проекта. Я что-то полгода пилю биллинговую систему и видеть уже не могу этот домен, присущие ему костыли и баги и прочее. А можно мне что-то другое?
Если сотрудник ценен для компании – он почти всегда действительно получит после этого что-то другое. Так что..разработчиков, которые годами варятся в одном и том же домене и/или сервисе – очень немного. Это необязательно, а иногда – неприятно и невыгодно
У руководителей так не работает. В большинстве случаев тимлид (а тем более –руководитель более высокого уровня) – это человек, который проводит с командой и доменом много времени. Руководитель почти никогда не растет в должности за один год. За год или менее банально очень тяжело совершить качественный скачок в своём домене (например, вырастить gmv своего продукта на 10%; сделать систему в 10 раз надёжнее; вырастить пачку синьоров и, среди них, своего заместителя). А ещё – разговор вида:
Слушай, что-то я заскучал в своём домене со всеми его бизнес-требованиям и костылями
От лида может звучать странно.
Дружище, ты ведь и есть тот самый человек, который должен мотивировать 10 других людей ковыряться в этом домене со всеми его бизнес-требованиями и костылями. Если ты потеряешь мотивацию и не будешь улучшать его год за годом – никто не будет!
Лично я, помимо прочего, по-разному воспринимаю линейных разработчиков, каждый год меняющих компанию, и руководителей, каждый год меняющих компанию. Разработчики у меня обычно вызывают 0 вопросов:
– По хардам чувак крутой? Крутой
– Коммуницирует адекватно? Адекватно
– Задачи мои делать хочет? Хочет– Ну, глядишь, годик поработает, а там, если ему надоест, дам другой проект. Берём.
А с управленцами история другая:
– Работает по году или меньше на каждом месте? Хмм..А успел ли он внести значимых технических изменений в систему, и удачными ли они были? (Дальше следует серия вопросов, ответы не всегда утешительны)
– А заместителей-то он успевает готовить за такое короткое время? Что, в каждом месте? (На практике тоже часто оказывается, что нет – дело это долгое и кропотливое)
– А как у него дела с удержанием и долгосрочной мотивацией/развитием сотрудников? Спрошу, наверное, как росли уровни и менялась год к году текучка людей в команде. А, погодите, статистики-то нет...
Короче говоря: приходя работать лидом, стоит ожидать, что зона ответственности с тобой надолго.
Понятное дело, что бывают исключения. Иногда твоя компания закрывается и выбора нет. Иногда – тебе пообещали одну работу, а дали – совсем другую и ты имеешь полное моральное право вернуться на рынок труда. Так что здесь речь не про разовый кейс в карьере человека, а именно про систему.
Часть 2. Примеры ошибок, которые совершают руководители
Рассмотрим несколько типовых ошибок, совершаемых руководителями разных уровней.
a. Жесткое вертикальное управление в команде
Один из подходов, к которым приходят руководители с определённым жизненным опытом и складом характера: плотно контролировать все решения, принимаемые и реализуемые в команде. Распространённая мотивация выглядит примерно так:
Я – самый крутой инженер в команде и справлюсь с любой задачей лучше любого своего подчинённого. Любой мой подчинённый, вероятно, примет менее эффективное решение, а я хочу приносить максимум пользы компании. Будет преступлением кому-то передавать ответственность
Подход неплохо работает "в моменте", если руководитель действительно крутой. Но он не эффективен на дистанции:
Люди в команде банально не дорастут до текущего уровня руководителя, если не будут самостоятельно (может быть, с его избирательным ревью) решать сложные задачи и разбираться с последствиями своих ошибок. Таким образом, команда вряд ли станет намного сильнее, чем есть сейчас
У людей формируется мышление: "все сложные решения примет руководитель, мне – достаточно быть хорошим исполнителем". В случае увольнения/отпуска/болезни руководителя, команда окажется "обезглавленной" (а голов в пределе могло бы быть столько, сколько людей в команде!)
b. Нерешительность в исправлении и расставании с андерперформерами
Бывает, что сотрудник откровенно недотягивает, но руководителю всё время его "жалко" или он просто избегает неприятного разговора.
Назовём такого сотрудника Петя.
У руководителей, которые тянут с расставанием или хотя бы с тем, чтобы максимально прямо поговорить с человеком о том, что дела идут плохо, часто возникают следующие рассуждения:
– Ну..польза-то для бизнеса всё равно есть. А нового человека – ещё искать/обучать и тд. Петя уже два года со мной, многое знает
– Ну..иногда же Петя начинает нормально работать. Я вот даю негативного фидбека, потом начинаю ежедневно проверять, как дела идут – и нормально. Спустя месяц, конечно, откатывается, но..это же только моя проблема, правда? Всем остальным – Петя полезен. Наверное, это вообще я не дожимаю
– Петя год назад отличился на проекте и ребята думают, что он крутой. Если я его уволю – мне придётся отвечать на неприятные вопросы и какое-то время успокаивать команду. А так – ну..можно же потерпеть, не так уж всё и ужасно
Такой подход приводит к следующим проблемам:
Нового сотрудника руководитель бы в итоге всё равно нашел и обучил – команда через полгода была бы в хорошей форме. А Петя может ни шатко ни валко тянуть свои таски годами (без шуток, такие люди в компаниях есть – они как раз не всегда джоб-хоппят тк не являются искателями быстрого роста)
Люди в команде – не идиоты. Если коллектив продолжительное время работает вместе, Вася обязательно узнает, что Петя получает примерно похожую сумму денег, но вот только работает в два раза меньше. После чего, не будь дураком, Вася либо сам поделит свою работу на два, либо банально пойдет работать в команду, где перформанс справедливо оценивают
В целом из (1) и (2) следует, что андерперформер – это не только головная боль руководителя, а головная боль всей команды, которую может решить только руководитель. Если этого не делать, команда будет деградировать
Важно: я говорю про ситуацию, когда руководитель уже давал обратную связь сотруднику и андерперформанс – систематический. Ни в коем случае не призываю к увольнениям людей за первую случившуюся провинность
c. Забивание на техдолг
Встречается у лидов, которые очень ориентированы на бизнес и очень любят команду или хотят быстрых и красивых результатов:
– Продакт попросил на месяц отказаться от техноквоты, чтобы быстрее запустить фичу? Ну, фича и правда ценная – а с багами мы ж жили всё это время..
– А, дальше ещё один важный проект? Ну, сейчас-сейчас, его дожмём, и техно займёмся
Этот подход порой действительно помогает принести красивых результатов на горизонте полугода, но потом команда, неожиданно, оказывается в болоте и красивые результаты заканчиваются. На выходе – останавливаешь продуктовую разработку, чтобы разгрести баги, ловишь кучу хейта от продактов, а ещё – кучу хейта от технической команды за то, что они – в болоте.
Остановимся на трёх примерах, чтобы не делать текст чересчур депрессивным :)
Часть 3. Что общего у этих проблем?
В каждую из описанных проблем (а подобных – ещё множество, докинь сюда кейсов из своего опыта) руководитель, на самом деле, не желает никому зла. Он просто хочет быстро и с наименьшим количеством боли получить хороший результат. Вот только есть нюанс: в отличие от позиции разработчика, на которой ты быстро получишь результат, а потом сменишь работу, при должности руководителя ты, скорее всего, останешься на том же компании в том же месте и увидишь, что последует за мгновенным результатом.
И..внезапно оказывается, что за некоторыми решениями, делающими жизнь одного человека (руководителя или менеджера) лучше "прямо сейчас" следует..ухудшение жизни всей команды на дистанции.
Часть 4. А что делать?
Способ мышления, который я предлагаю, формулируется просто:
Принимай решения так, чтобы команда через год была лучше, чем сейчас.
Такой фреймворк помогает предотвратить многие проблемы.
– Активнее делегировать и обучать ребят, или продумывать решения самому, оставляя подчинённым только их реализацию при моём жестком ревью? Мм..в первом случае – команда за год чему-то научится и вместо одной (моей) головы, голов будет штук пять. Вот это заживём! Попробую так и делать
– Расстаться с андерперформером, временно просадив перформанс и взяв больше работы на себя, или терпеть? А будет ли моя команда через год от этого лучше? Скорее всего, будет. Надо делать
И так далее.
Ограничение применимости фреймворка:
Применяя вышеописанный подход, стоит помнить:
Команда регулярно должна что-то выпускать
"Что-то" – зависит от конкретной команды. Это могут быть продуктовые фичи в приложении. Могут быть оптимизации поискового движка. Или новые функции софта для других разработчиков. Короче говоря – это то, ради производства чего, вообще говоря, существует твоя команда.
Чтобы не заиграться в оптимизации и, например, не отправив всех сотрудников команды на классное обучение длиной в год, улучшая будущее, помни, что надо всегда что-то выпускать. Локальные просадки (например, при заменах или обучении людей) – допустимы, но останавливаться совсем – нельзя.
Вместо послесловия
Принимать стратегические решения (=решения с оглядкой на будущее команды) – непросто. Они могут быть эмоционально сложны для тебя в моменте. Они могут быть не очевидны участникам команды или твоему руководству, если они не заглядывали так глубоко, как ты (и это – нормально, тебя ведь за этим и наняли!). В любой сложной ситуации – запасись терпением, выпей чайку и объясни людям, какие последствия ты ожидаешь на дистанции от своего решения, даже если оно – непопулярно.
Помни, что твоя работа – не принимать приятные и очевидные решения. Твоя работа – делать команду и компанию лучше со временем. Ты обязательно справишься!
А ещё, я недавно начал вести канал в телеге, тк физически не успеваю охватить лично всех лидов, которым хотел бы помочь. Если тебе интересно получить больше контента и обменяться опытом с другими лидами – приходи :) https://t.me/leadsnotes