Совет руководителям
говорят, посты с картинками — веселее!
Привет!
Меня зовут Андрей и я руковожу 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
