Трудности начинающих руководителей. Какие четыре ошибки объединяют молодых лидов и как над ними работать

В какой-то точке карьерного пути может наступить момент, когда приходится примерить абсолютно новую для себя роль — руководителя. В этой статье я расскажу о своем опыте управления небольшой командой из трёх датасаентистов. Расскажу о трудностях, с которыми столкнулся на этом пути, о допущенных ошибках на старте, работе над этими ошибками и выводах.

Немного о себе. В Ростелеком я пришел в 30 лет и до этого не имел опыта управления командой. За плечами у меня было почти десять лет работы в сфере аналитики данных. Последние несколько лет я работал в Data Science.

Я считал, что у меня есть отличный стартовый технический бэкграунд – я хорошо себе представлял работу датасаентиста. И, вооружившись вагоном слепой уверенности, я решил стать отличным руководителем. Мне в прямое подчинение были вручены 2 датасаентиста, 1 свободная ставка для подбора. И гордая подпись в почте «руководитель направления».

Когда я был ML-разработчиком, то основным критерием успеха был качественно написанный код, решающий поставленную задачу. Задача обычно ставилась вполне конкретно, и всегда был человек (руководитель), который был обязан разъяснить возникающие непонятки. Но с новой подписью в почте условия работы кардинально поменялись.

Больше не было четко поставленных задач и прозрачных приоритетов. А все возникающие непонятки должен быть разъяснять я сам.

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

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

Для этого нужно было анализировать хотелки заказчиков по разным параллельным проектам, трансформировать бизнес-хотелки в бэклог технических задач, проводить разнообразный research и искать возможности решения задач, анализировать узкие места и варианты их преодоления.

Кроме этого нужно было разрабатывать решения (писать код), оценивать эффективность моделей перед запуском решения в пилот, передавать решения заказчику, собирать обратную связь, контролировать сопровождение, доработки…

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

Я был overwhelmed огромным потоком входящей информации и не знал за что хвататься. А самое неприятное лично для меня — ощущение, что я теперь «двоечник», ничего не успеваю в срок, вечно оправдываюсь. Это конечно же дизморалило.

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

Записи делал по настроению, хаотично заводил какие-то тикеты в Jira и Trello (чтобы потом на них благополучно забить). Это приводило к хаосу в задачах, негативу от заказчиков и команды. Ни у меня, ни у других не было прозрачного понимания над чем мы сейчас работаем, какие у нас планы на ближайшую перспективу. А работа превратилась в тушение пожаров – это прибавляло стресса и снижало мотивацию команды.

Потребовалось время, чтобы методом проб и ошибок все-таки выработать работающую систему менеджмента всего входящего информационного потока.

Эта система включает четыре основных поинта:

1. Записывать абсолютно всё в лог — просто список записей, не структурированный по темам или задачам. Плохой карандаш лучше острой памяти;
2. Проводить ежедневную работу по мини-планированию. Нужно пробежаться по логу, трансформирую записи в задачи (карточки в Trello в моем случае), назначить исполнителя и приоритет, разделить по категориям;
   
3. Контролировать задачи на исполнителях. Разумеется, бОльшую часть задач руководитель делегирует команде или другим подразделениям. Важно ежедневно пробегаться по списку таких задач и не стесняться пинговать при наступлении дедлайна всех и вся. Держать в тонусе, постоянно напоминать, что ты ждешь фидбэк. Спрашивать о сложностях и проблемах, предлагать варианты решения;
   
4. Фиксировать свои собственные задачи в карточках Trello с приоритетами и дедлайнами. Не все задачи можно делегировать, и, если не зафиксировать собственные задачи, о них можно благополучно забыть.
   

Это определенно не rocket science, но потребовалось более шести месяцев хождения по разнообразным граблям, чтобы к этому прийти. Проблема была даже не в том, чтобы понять, что делать – а сделать это ежедневной привычкой и рутиной.

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

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

Разработчик может себе позволить быть немного «аутистом». Руководитель, который вырос из разработчика должен убить в себе «аутиста» и научиться работать с командой – собирать и обрабатывать обратную связь, разговаривать, наставлять и снова разговаривать. Первое время очень хочется «уйти в себя», хочется, чтобы все сами понимали свои задачи. Сами понимали, где они не правы и как с этим быть. Но это прямой путь к развалу команды и провалам в проектах.

В начале я не проводил code review, пренебрегал правилами обязательного проведения sanity check результатов (в нашем случае, разработанных ML-моделей). Мог отдать самоуверенному джуну важный кусок проекта без контроля. И это лишь малая часть очевидных (сейчас) косяков, которые я допускал. Добавим сюда отсутствие регулярного менторинга команды, нежелание погружаться самому в технические детали и игнор психологического состояния сотрудников.

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

Перечислю основные выводы, которые точно работают и актуальны:

1. Нельзя пускать команду на самотек. Даже если все очень компетентны, нужно обязательно чекать промежуточный результат. Если не каждый день, то 2 раза в неделю минимум. Если руководитель не уделяет внимания задаче, то исполнителю начинает казаться, что задача не нужна – и он сам не нужен команде и компании. А это повод открыть HH;
2. Нужно научиться быть гибким, уметь находить подход к разным людям. С кем-то нужно ежедневно проводить статус, кого-то нужно наоборот больше отпустить. С опытом общения с разными людьми начинаешь понимать их мотивацию и учишься выстраивать наиболее эффективное взаимодействие;
   
3. Нужно передавать часть управленческих функций сотрудникам, которые к этому готовы. Это позволяет повысить сплоченность и компетентность команды. Отличным пример такого делегирования – наставничество. Не обязательно самому вводить в курс дел новичков. Лучше, чтобы более опытные сотрудники команды делились опытом в тех или иных областях. Это полезно и для самих сотрудников – они развивают в себе навыки руководителя, и помогает быстрой адаптации новичков – им проще обратиться с вопросом к менее «именитому» сотруднику, чем к «большому» руководителю;
   
4. Очень важно объяснять команде для чего именно они разрабатывают те или иные инструменты. Какие бизнес-метрики мы улучшаем и как это монетизируется. Обязательно показывать результаты использования, делиться отчетам и выводами. Когда сотрудник пишет код, только ради кода и не видит, какую пользу его код приносит компании и обществу, это часто приводит к потере мотивации и увольнениям
   

Эти выводы я сделал благодаря негативному фидбеку, который я получал от команды. Самый болезненный и важный фидбек был от тех сотрудников, которые увольнялись и рассказывали о причинах ухода честнее и откровеннее.

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

Когда в 2011 году я после универа пришел на свою первую работу аналитиком, то был весьма эмоционально нестабильным человеком. Различного рода «несправедливости» в работе заставляли меня буквально закипать. Еще в те времена я получил очень мудрый совет от своего руководителя. Звучал он примерно так. Когда ты приходишь работать на стройку, то одеваешь каску. На голову неизбежно падает штукатурка, но именно поэтому ты одеваешь каску.

Думаю, никто не будет спорить, что именно в роли менеджера ты больше всего сталкиваешься с различными ситуациями, от которых подгорает. Кажется, что ты теперь отвечаешь абсолютно за все, все вокруг случается из-за тебя и все с большим вниманием следят за тем – справляешься ли ты с ролью руководителя. От такого внутреннего напряжения любая мелочь начинает казаться очень важной. Нужно не забывать «надевать каску» во время работы и быть в меру пофигистом. К сожалению, выводящие из равновесия ситуации — это неизбежная часть работы руководителя.

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

Первая задача – научиться контролировать неконструктивные эмоции.

На практике это происходит примерно так:

1. Столкнулся с ситуацией, которая бесит, провоцирует на эмоциональную реакцию (несправедливые выводы руководства, вредный неудобный заказчик, неизбежные бюрократические проволочки и т.п.).

2. Осознал, что сейчас ты тильтуешь и готов к неразумным поступкам (например, написать «обидчику» в ответ резкое письмо или сделать громкое заявление руководителю).

3. Задействовал алгоритм выхода из тильта.

В качестве такого алгоритма часто достаточно просто взять таймаут на 1-2 дня и уже после вернуться к неприятному вопросу с холодной головой.

Но очень важно осознать, что мы не в силах на 100% контролировать вспышки различных неконструктивных эмоций. И если уж эмоции не получилось подавить, то лучше вернуться к разговору с человеком с холодной головой и сгладить ситуацию.

Вторая задача – снизить количество ситуаций, от которых «подгорает».

Любой эмоциональный всплеск отбирает огромное количество времени и ресурсов – эмоции нужно пережить, ситуацию проанализировать, обсудить трабл с друзьями, сделать выводы, успокоиться и вернуться к работе. Это может занять от нескольких часов до нескольких дней. И далеко не каждая ситуация заслуживает, чтобы я уделял ей так много времени и сил.

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

Со временем я выработал внутренние правила оценки ситуаций:

1. На сколько масштабны последствия «драмы»?

Приведу две гипотетические ситуации.

• Первая. Заказчик написал резкое письмо. Последствия – мне не приятно. Эта «драма» не сильно влияет на результаты работы проекта и на бизнес Ростелекома. Можно не нервничать;
• Вторая. Заказчик хочет вывести на прод ML-модель, которая не до конца готова. Последствия – возможны бизнес-ошибки. Это влияет на прибыль Ростелекома. Сразу брать в работу.
  

1. Могу ли я изменить ситуацию?

Рассмотрим на примере тех же гипотетических ситуаций.

• Первая. Заказчик написал резкое письмо. Могу ли я повлиять на мысли и поведение заказчика, команды, свои собственные эмоции? Прямого механизма влияния нет – можно не нервнивать;
• Вторая. Заказчик хочет вывести на прод ML-модель, которая не до конца готова. Я не просто могу на это повлиять. Я должен на это повлиять – это моя работа.
  

В дополнение к сказанному приведу фрагмент из книги Массимо Пильюччи «Счастливая жизнь» про стоицизм.

Ссылка на полный фрагмент: https://www.forbes.ru/forbeslife/429395-ne-prodavay-svoyu-dushu-deshevo-chemu-uchit-stoicizm-po-kotoromu-shodit-s-uma

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

Когда я после долгого перерыва наконец стал что-то делать руками, то испытал настоящий «кайф бегуна». Постепенное восстановление технических скиллов определенно добавило не только уверенности, но и эффективности в менеджерской части. Лишняя пара рук, пусть и всего на 25% времени, определенно усилила общий перфоманс. И, что немаловажно, я стал испытывать на порядок больше удовольствия от работы.

Стала появляться та самая гармония, которая была утеряна при переходе на полностью менеджерский функционал. Разумеется, появилось чувство большей «защищенности» в ситуациях, если вдруг придется выходить на рынок труда и искать что-то новое.

Обычно я выделяю 2-3 часа утром на самостоятельную работу с кодом, резервирую время в своем календаре. Встречи переношу на вторую половину дня. Оставшегося рабочего времени без проблем хватает на решение менеджерских вопросов.

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

Прочтение подобных опусов разве что может дать небольшую карту трудностей, которые встретятся на менеджерском треке. Карта эта будет неполной и неразборчивой, но основные векторы скорее всего укажет верно. Желаю всем начинающим менеджерам как можно скорее наступить на все необходимые грабли и прокачаться, т.к. впереди ждет много новых граблей J.