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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылка на полный фрагмент: 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.