Вы когда-нибудь приходили на позицию руководителя в новую для вас команду?
Если да, вы понимаете, насколько это сложно, и сколько всего вам свалится на голову. Сложнее только, если вы становитесь руководителем других руководителей, у которых свои взгляды на жизнь, команду и процессы.
Вас ждет небольшой Cookbook по непростым ситуациям и вариантам их решения.
Упор делаю на процессы и людей — именно эти 2 “стула” вам предстоит осилить.
Немного обо мне
Груздев Александр
Head of Core Development, Karuna
Меня зовут Александр, и я работаю руководителем отдела разработки в компании Каруна. Также в прошлом я – инжиниринг менеджер, тимлид и Java разработчик. Хотя почему в прошлом. Если надо, могу и закодить. Но как ответственный технический менеджер стараюсь этого не делать.
Анекдот
Заходит как-то руководитель в бар новую команду...
Все сотрудники напряженно смотрят на него, ожидая первых слов. Руководитель молча подходит к доске и рисует две параллельные линии.
— Что это значит? — спрашивает один из сотрудников.
— Это две железные дороги, — отвечает руководитель. — Одна из них — ваш проект, другая — сроки. И они никогда не должны пересекаться.
Сотрудники хором вздохнули с облегчением, поняв, что новый руководитель — человек с чувством юмора и пониманием их трудностей. А новая команда взялась за работу с удвоенным энтузиазмом, зная, что с таким начальством ей по плечу любые задачи.
Обязательно прочитай
Вы прочитали анекдот, написанный на 99 процентов chatGPT. Видите, даже нейросеть уловила напряжение, которое возникает между командой и совершенно новым руководителем.
Интро
В прошлой статье "Зародыш, франкенштейн или корпорация — почему важно точно знать, где ты сейчас работаешь?" я описал путь продуктовой компании, точнее то, как я это вижу. Так что не кидайтесь тряпками, не дочитав до конца.
Основной посыл той статьи был в том, что компания от идеи и до полноценного функционирования с высокой прибылью проходит множество фаз, и за это время процессы и состав компании меняются. Вы как руководитель можете прийти на любом из этих этапов и вы должны быть готовы вести этих людей в светлое будущее. Или, как часто бывает, для начала взять фонарик и спуститься в эту кроличью нору.
И вот, докопавшись до истины и получив на большинство вопросов ответы вроде “Так исторически сложилось”, начинаете свой путь изменений.
Далее я сделаю упор на два основных вектора, в которые сразу погружается руководитель (если не считать продукт): процессы и люди.
Начнем, пожалуй, с более понятной темы.
Процессы
Пункт номер один для большинства руководителей. Нам же первым делом необходимо понять, как функционирует текущая команда/команды, каким правилам следуют, каким способом они производят результат: головой или руками. Хотя руки, знаете ли, тоже разные бывают.
И вот тут множество вариантов, что вы можете обнаружить.
Вариант 1: процессы “есть” и устраивают команду
Выглядит, что прошлый лид постарался, адаптировался к изменениям. Применил эффективные инструменты, и команда продолжает пользоваться всем этим набором и даже не жалуется.
Какие могут быть подводные камни?
Процессы есть только для вида. То есть команда усердно трудится не покладая рук, переваривая огромный поток задач, который сама же и генерирует. У команды может быть всегда актуальная борда с задачами, хороший лид тайм, но чем занимается эта команда, одному бывшему лиду известно.
Что делать: понять цель этой команды, что она должна делать и для чего. Если это работа на продукт — понять, на какие продуктовые метрики направлены задачи. Если это техническое направление — понять, насколько эти задачи влияют на существующие KPI/SLA. Если это украшательства или переписывание с одного фреймворка на другой по три раза — лучше прикрыть временно эту лавочку и провести ревью с командой.
После ревью текущих задач нужно построить стратегию развития команды. Взять цели и метрики для команды (это ещё один сложный вопрос, откуда взять эти магические цели) и выделить 3-4 направления, которые могут повлиять на это.
Инструментарий
Можно использовать простой список или mindMap, чтобы зафиксировать всё во время брейншторма. У меня обычно простой список с подсписками превращается в табличку, так как нужно где-то указать приоритет, где-то — особенности или зависимости на другие команды, где-то приложить ссылки на текущие гайды и описание. Впоследствии это можно легко положить на инструментарий типа джира плана, разбив на инициативы, эпики и юзер стори с более детальным описанием.
После того, как вы прогрумите новый бэклог и запланируете задачи наперёд — процессы действительно заработают. Ведь процессы нужны для того, чтобы команда эффективнее достигала своих целей и целей компании, а не для того, чтобы про эти процессы рассказывать на Тимлид конф или в очередном инфоцыгнском чатике в телеге.
Вывод по 1 варианту: не ставьте красивый процесс ради процесса, ставьте амбициозные цели и ищите процессы, чтобы их максимально эффективно достигать.
Вариант 2: команда сама жалуется на неработающие процессы
Команда чаще всего жалуется на неработающие процессы в двух случаях: когда новые процессы спущены сверху, или когда старые процессы, давно принятые в компании, перестают работать.
Первый случай нельзя решать в лоб, придя в команду и стукнув кулаком по столу.
Однажды на собеседовании...
За последний год я провёл десятки собеседований Скрам мастеров/Проджект менеджеров, и знаете, что я слышал в некоторых ответах на вопрос: а что делать, если команда сопротивляется изменениям?
Человек в кейсе с сопротивлением предложил объяснить лиду, что в их компании так принято, что сверху говорят, как всем работать, и не задавай лишних вопросов, Вася. Либо, что ещё хуже, когда человек говорил, что ОН-то всё понимает, но вот начальство… Типа мы с тобой, Вася, хорошие, а они там все ку-ку, но давай мы с тобой так поработаем, а потом что-нибудь придумаем. Тут сразу две проблемы: выстраивание оппозиции руководству компании, плюс несбыточные обещания.
План-капкан
Выслушать фидбек команды об её текущем процессе и спросить, что команде не нравится в новом. Обязательно задавайте вопрос о последствиях. Какие проблемы возникнут, если в моменте принять новые правила? Что сломается? Что им нравится в текущем процессе? Это может быть формат командной ретроспективы, личных 1-1 с опытными инженерами или руководителем команды.
Далее нужно проанализировать, насколько команда объективна. Факты из прошлого пункта помогут оценить, насколько команда перестраховывается. Иногда всё сопротивление строится на том, что сейчас все понятно и работает, а будет непонятно и не факт, что заработает. То есть команда не хочет выходить из пресловутой зоны комфорта даже при том, что “сейчас” и нет никаких процессов, а то, что они ими называют — это привычки и пережитки стартапа, когда всем всё разрешено, и нет никаких границ ответственности. Ну кто же хочет, чтобы ему порезали права, заставили на API документацию писать или, не дай бог, начали считать, а сколько команда делает задач за спринт.
Если в прошлом пункте вы убедились, что сопротивление не обосновано, нужно вооружиться конкретными аргументами и по возможности не прибегать к варианту “это нам сверху спустили, так что работаем”. Подсветите преимущества для команды, для вас как руководителя и для компании в целом. Покажите, что это будет на пользу всем, и вы принимаете риск, что производительность команды первое время будет страдать.
Альтернативный вариант — когда команда действительно отстаивает свои процессы не из вредности/непонимания, а приводит конкретные аргументы или результаты прошлых “экспериментов”. Например, двухнедельные спринты не будут работать, так как в рамках такого спринта приоритеты поменяются 3 раза и scope creep будет выше 100%. В этом случае стоит подробнее изучить особенности команды и собраться для обсуждения с другими руководителями или техническими экспертами. И тут надо определить, какие будут накладные расходы на поддержание разномастных процессов, как это ложится на стратегию компании по дальнейшему росту, и т. д. Если это сервисная команда, которая хорошо справляется со своими задачами, и все стейкхолдеры довольны результатом — возможно, стоит сделать паузу и дать команде время, чтобы показать, что все справляются со старыми подходами в новых реалиях.
Вариант с устаревшими процессами тоже часто встречается. Компании растут, меняют подходы к разработке, релизам, и т. д. Все это приводит к тому, что от команд требуют новых результатов, но текущими инструментами этого не добиться.
Если увеличить количество команд в 3 раза и посадить писать код в том же монолите, можно не мечтать о приросте фич в 3 раза за то же время.
Можно скорее получить в два раза меньше фич из-за постоянных мерж конфликтов, багов в интеграции, занятых окружениях для тестирования.
Scrum/SAFE — тут не панацея, есть множество других фреймворков, которые способствуют эффективной работе множества команд. Даже с ними, НО без технических изменений это будет бессмысленно. И, скорее всего, вам придётся хорошенько подумать и начать делить ваш монолит на сервисы, начать писать автотесты, организовать канареечные релизы или поднять пару дополнительных окружений для новых команд. Все это в совокупности и даст необходимый эффект, когда команда поймет, что компания в курсе, из чего строится результат, и сделает все необходимое, чтобы команды максимально эффективно прикладывали усилия.
Вывод по 2 варианту: не судите только по своему прошлому опыту и не принимайте сходу необдуманных решений.
Вариант 3: процессов нет и не трогай
Этот вариант — для менеджера 80лвл. Встречается так же часто как единорог, и так же трудно понять, а что теперь с этим делать.
В чём сложность?
Как это прийти в команду, где нет процессов, и не начать что-то внедрять? Да быть того не может, что сейчас всё работает — и это без скрама, канбана, квартального планирования и подсчета велосити?! Им срочно нужны диаграммы ганта, вип лимиты и деплой фриз по пятницам.
Но вот не всегда это нужно в моменте. Данная “уникальная” команда может существовать довольно давно, и в ней настолько все приросли друг к другу и к своим инструментам и подходам, что, поменяв даже минимально значимую часть, можно получить на выходе демотивированных сотрудников, ухудшение перфоманса в разы. Или, чего хуже, команда разом встанет и уйдёт в закат, оставив вас разгребать не только процессы, но и бэклог задач.
Почему такая команда может перформить лучше, чем с процессами?
А тут могут быть особенности направления, в котором она работает — например, в случае, если работа немного выходит за рамки айти. Ну вот будете ли вы бригаде электриков во главе с Дядей Ваней рассказывать про аджайл? А то, что ему надо отчет составлять каждую неделю? Очень сомневаюсь, что это будет действенно. Я утрирую, но у вас в отделе могут быть такие команды-бригады, для которых нужен свой подход, а иногда нужно вообще погрузиться в их прикладную область и понять, что ими движет. По примеру с электриками это могут быть и финансисты, и строители/архитекторы, и даже просто команда матерых ДБА, которым нафиг не сдались ваши оценки.
Вывод: иногда вместо того, чтобы приходить и приносить процессы, будет достаточно прийти и зафиксировать то, что уже есть на бумаге (в конфлюенс). Это поможет в случае поиска новых сотрудников быстрее их заонбордить и ввести в курс дел. А, возможно, после того, как вы прозрачно опишете существующие процессы, сама команда-единорог увидит проблемные зоны и сдвинется с мертвой точки в направлении изменения подходов к работе.
С разминкой в виде процессов закончили, переходим к самому трудному.
Люди
Ох уж эти люди, скажет каждый второй руководитель. В любой самой сложной и отлаженной системе всегда слабым звеном будет человек. Код можно написать один раз, и он будет неизменно выполнять то, что написано*.
* про код
в коде тоже могут встречаться коллизии, даже при полноценном тестировании и при отсутствии изменений долгое время. Но такая вероятность
В джире можно автоматизировать процессы, и они будут работать так, как описано. Но человек даже пять раз, выполнив одну и ту же задачу, на шестой раз может её выполнить вообще не так, как ты ожидаешь. А всё потому, что его с утра облила проезжающая машина, он поругался с женой или наоборот — он счастлив, что у него родилась дочь. Очень много неопределенности.
С этой неопределенностью нам приходится работать каждый день, поэтому важно по максимуму расширять свой кругозор различными кейсами, изучать типы сотрудников, проводить 1-1, и желательно записывать всё, что вы замечаете. Или складывайте в чертоги разума, если вы всё ещё доверяете своей памяти.
Далее попробую описать те кейсы, с которыми можно столкнуться, придя в устоявшуюся команду.
Вариант 1: Непримиримый Джо (он же человек-сопротивление)
Работа с сопротивлением не зря так часто встречается в качестве требований к кандидатам в роли руководителя, ведь сопротивление — довольно частое явление.
Когда вы приходите в новую команду, скорее всего, у неё уже существуют устоявшиеся правила и традиции. Стоит вам только заикнуться об улучшениях, как сразу же найдутся те, кому что-то не будет нравится. И вам повезёт, если они открыто выражают свое недовольство, ведь так вы будете знать, на ком стоит сосредоточиться.
Основная ваша задача на этом этапе — понять причину недовольства. Как вы это будете делать, сильно раскрывать не буду. Скажу лишь одно: 1-1 митинг. 1-1 с лидом этого человека, 1-1 с членами команды, 1-1 с самим человеком.
Первая причина: недовольство именно вашими подходами
Человек привык работать по устоявшимся правилам и любое изменение встречает в штыки.
Что делать? Объяснить цель ваших изменений, чем текущее положение дел вас не устраивает. Если человек готов предложить другое решение проблем — выслушайте и дальше примите решение. Если человек готов пробовать и решать проблему самостоятельно - дайте ему время на проработку. Если ничего не получится, он сам к вам придет с пониманием, что не всё так просто. А если он не может предложить решения лучше или вообще не готов в этом участвовать, объясните ему, как со стороны выглядит его недовольство, и дайте понять, что вы готовы прислушиваться к сотрудникам, если они действительно хотят принимать участие в работе над процессами.
Вторая причина: недовольство всем подряд
Скорее всего, человек ворчит на всё подряд. Он привык сидеть и писать код, а тут к нему приходят и требуют писать тесты. Как отреагирует человек, который сроду не писал тестов, потому что целью было скорее доставлять новые фичи? Скорее всего, он будет возмущаться, что вы замедляете его работу, что он вообще пишет идеальный код, на который никто не жаловался, и т. д. А что, если QA ещё и баги в трекере заводить будут в рамках разработки и кидать на этого разраба? Тут уже конфликт может вспыхнуть и внутри команды.
С такими ребятам все непросто. Скорее всего, на исправление человека может уйти не один месяц, и с вероятностью процентов 80 это ещё и не приведет ни к чему хорошему. Бывают такие люди от природы. И если вы не готовы вкладывать в этого человека огромное количество ресурсов и времени, стоит с ним честно пообщаться и показать, что если ему самому тяжело даётся всё новое, и ему чужда ваша корпкультура — наверно, ему стоит поискать место, где будет комфортно ему и его новой команде.
Плохой совет
Можно пытаться найти ему место подальше от своей команды (переместить в соседний отдел), изолировать от процессов, и так далее — но так вы только переложите ответственность на чужие плечи, ну, или на свои же, но в будущем.
Вариант 2: Капитан Игнор (Человек — и так сойдет)
Лайтовый вариант человека-сопротивление. Данный типаж открыто не выражает недовольство и не пытается вас подставить, он просто не использует преимущества новых подходов и инструментов, продолжая всё делать по-старому. Ну, ведь работает же?
Пример. Вы приняли решение использовать новый инструмент для мониторинга сервисов.
Команды высказались за, взяли задачки себе в бэклог и добавили этот функционал. По мере необходимости используют новый тул. Но не наш кандидат. Он по-старому продолжает смотреть на логи, говорить, что всё ок, error-ов нет и, собственно, его сервис пашет как надо. Это и не сопротивление, ведь он честно сделал, что от него требовали — добавил в сервис библиотечку. Просто он не пользуется этим, так как не считает это необходимым.
Что делать?
Понять мотивацию человека. Это просто нежелание тратить время на изучение чего-то нового или, может, эти изменения прошли мимо него?
В первом случае нужно объяснить, что ему может дать этот инструмент. Конкретно ему.
Во втором — привлечь эксперта и провести пару тренингов на тему использования какого-либо инструмента. Будет полезно и другим сотрудникам, а этот человек сможет повариться в кругу активных участников и дальше, вероятно, не захочет отставать от других.
Вариант 3: IT отшельник (Отчаявшийся)
Это такие подвыгоревшие сотрудники, которые решили не уходить из компании, а сосредоточиться на том, что у них хорошо получается, и что не требует обоснования.
В своё время они пытались что-то менять: приносить новые идеи, технологии. В начале это могло работать, ведь никто не спрашивал: а что это такое? А что это даст? На фазе развивающейся компании легко втаскивать всё, что плохо лежит. А вот дальше появляются эти самые менеджеры, которые задают странные вопросы и не дают делать, что хочешь конкретно ты. Начинают жонглировать приоритетами, ограничивать техдолг, и прочее.
Ну, и человек вроде всё ещё лоялен компании, но уже не готов идти против ветра: собирать аргументы, доказывать реальную ценность того, что он предлагает.
Хотя, на самом деле, такой человек может видеть систему насквозь, и не стоит его идеи откладывать на дальнюю полку.
Что делать?
Начать потихоньку его разбалтывать на 1-1. Спрашивать, а что у него получилось внедрить из последнего? А как ему это удалось, и какой профит принесло? Это должно его сфокусировать на успешных кейсах. Только после того, как человек начнет открываться, можно перейти к проектам, которые по его мнению могли бы помочь, но сейчас лежат в самом пыльном бэклоге.
Начать формировать техническую группу по принятию решений. Нужно дать понять, что любое решение получит объективную оценку, что у сотрудника есть коллеги, кто его поддержит или объяснит, почему это технически нерационально.
В будущем стоит отлавливать тот момент, когда начинают появляться такие “отчаявшиеся”. Они могут возникать не только среди ваших прямых подчиненных, но и на следующем уровне от вас. Поэтому постарайтесь хотя бы раз в полгода проводить 1-1 с сотрудниками команд и организовывайте периодически ретроспективы, где все могут поделиться идеями или накидать, с чем им хотелось бы поработать.
Вариант 4: Кибер-шашлычок (человек на грани выгорания или уже за ней)
То же проявление, что и у “Отчаявшегося”, но разные причины текущего состояния.
Третий вариант сам пытался брать инициативу в свои руки, но сдался, а четвертого не спрашивали, хочет ли он действительно делать все то, что ему поручали.
Причин, почему так случается, может быть уйма, но основные это:
Отсутствие у руководителя времени или желания на чекапы (1-1) сотрудников. Это может быть связано с быстрым ростом компании, когда на одного руководителя может приходиться по 20-30 сотрудников. Спустя какое-то время в таком формате люди неожиданно начинают выгорать или вовсе покидать компанию.
Сотрудник не смог освоить делегирование. Частый кейс, когда молодой тимлид пытается вытащить на себе всю команду и забывает, что у него не только две руки, а целая команда.
Сотрудник гипер-ответственный и не может сказать нет. Вариант редкий, но и проработать этот случай сложнее.
Что делать?
Как бы тупо ни звучало — поговорить. Выяснить причину.
Если про человека просто забыли, нужно его снова “зажечь”. Найти мотивацию и дать стимул. Например, вытащить из бэклога интересный и важный проект и показать, что, выполнив этот проект, человек внесёт офигенный вклад в развитие компании и сам прокачается в ведении сложных проектов. В рамках этого “проекта” давать почаще обратную связь. Это покажет ваш интерес к развитию сотрудника и то, что ему не стоит боятся новых обязательств.
В проблемах с делегированием разобрать причину. Может, реально некому было делегировать (набрали команду джунов). Если всё же было, кому — решать уже старую добрую проблему. Квадрат Эйзенхауэра в помощь.
Если человек не мог никому сказать “нет” — работаем с его зонами ответственности. Попросите его рассказать, почему он брался за те или иные активности? Спросите, мог ли кто-то ещё заняться этим проектом? Скорее всего, человек воспринимал любую задачу компании как личную ответственность и погружался с головой. А набрав сразу с десяток активностей, человек распылялся и не видел результата, что, собственно, его привело к выгоранию.
Вариант 5: Перфекционист-Затейник (он же идеалист)
Человек хочет все делать на 100 процентов, с максимальной проработкой каждой детали или граничного случая. В любом обсуждении вы слышите от него:
“А что если…? “
“А вот в таком случае (одном из миллиона) это не будет работать… “
“Вы забыли учесть вот это …“
“Мне кажется, можно сделать лучше“
“Правильно будет вот так и только так“
Ну и хуже всего: “я же говорил”, когда кто-то столкнется с проблемой, которую обсуждали заранее.
В итоге он только накидывает на вентилятор (идей и проблем) и ничего не может закончить в планируемый срок.
Хуже всего, если этот человек — менеджер, ведь тут будет страдать ещё и его команда, и, скорее всего, именно вам придётся решать все последующие проблемы.
Что делать тут?
Обозначить контекст решаемой проблемы более точно. Если вы не строите космический корабль, а разрабатываете онлайн-библиотеку, то один запрос из миллиона, упавший на невозможности десериализовать кривое тело запроса, не будет стоить недели разработки команды или даже одного синьора. И это надо явно донести до человека, а не предполагать, что все и так это понимают.
Этому человеку надо ставить сроки явно и без домыслов: типа — принести решение в понедельник, в 15:00.
Донести, что любое решение, хоть и должно максимально соответствовать требованиям, но не надо эти требования додумывать за другого. Если возникает вопрос, делать или нет, стоит его адресовать непосредственно заказчику и только после ответа прорабатывать этот вариант и давать оценку по срокам.
Скорее всего, этот процесс затянется, так как полностью перестроиться за пару недель не получится. Но главное — не сдаваться, и тогда этот сотрудник сможет реально направить свою требовательность и инициативу в нужное русло.
Подытожим
Можно долго и упорно пытаться описать все случаи, и как конкретно с ними жить или бороться, но реальность обычно другая:
Один человек может сочетать в себе сразу несколько описанных типов.
Прошлый руководитель мог поставить нереалистичные цели, и теперь вам их нужно отформатировать, поставив под сомнение его экспертизу.
У вас вообще никогда не было опыта работы в такой компании, и вы сходу будете менять все на привычное и знакомое вам.
Люди в компании не будут вас поддерживать не из-за того, что вы им не нравитесь, а просто потому, что привыкли жить в своём мире, или уже устали от таких как вы (если вы у них не первый реформатор за последний год).
Мне данная тема близка, потому что я сам совершал похожие ошибки, будучи как на стороне руководителей, так и инженеров. И это нормально, главное впоследствии проанализировать своё поведение и понять, как можно было поступить иначе.
Главный смысл статьи
Когда приходите в новую команду — придержите внутреннего Ван Дамма. Не вышибайте дверь с ноги, а аккуратно постучите и поинтересуйтесь, зачем вас позвали.
Ваш непосредственный руководитель должен дать первые ЦУ — с «какого стула» начать.
А далее будьте открыты к обратной связи, задавайте вопросы, но и приготовьтесь отвечать на вызовы.
P.S. Самый последний совет.
Если есть возможность познакомиться с коллегами оффлайн — тащите их в офис, бар, боулинг. Личное общение дает намного больше информации о человеке, чем видеозвонок.
Ну и подходим к опросу...
