Очень конкретная задача: мне нужно найти руководителя на важное направление.

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

Было сложно сравнить их между собой. Один был хорош в чём-то одном, другой — в чём-то другом.

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

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

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

Как инженер становится руководителем

Иногда никак, и это нормально. Если кто-то любит писать код, стал senior-разработчиком и ему становится тесно в команде — вовсе не обязательно делать его руководителем. Есть другие варианты, и про это отдельно уже рассказывал мой коллега. Сейчас же мы рассматриваем ситуацию, когда инженер хочет стать руководителем. Или думает, что хочет.

Почему это важно: в роли руководителя уже меньше задач что-то разработать своими руками. Или их не будет вовсе. Можно стать играющим тренером. Тогда получится, что человек выполняет свою функцию на 70% как руководитель и на 70% как разработчик. В результате он тратит 140% своего времени, что потенциально ускоряет выгорание.

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

Каждый раз есть выбор: растить технического специалиста либо брать готового руководителя со стороны. «Внешний» руководитель будет какое-то время вне контекста, внутренний же из senior-специалиста станет джуном-руководителем. Тоже повод для сравнения.

И вот здесь мы приходим к оценке того, как же выбрать кандидата.

Скелет руководства

Прежде чем искать руководителя, нужно ответить себе на вопрос, кто это такой? Для меня скелет понимания — это процессы, правила, мотивация.

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

Мотивация. Понятно, что команда должна постоянно достигать результата. Чтобы процессы и правила работали, нужно, чтобы люди хотели что-то делать. Я видел руководителя, который создавал отличные процессы, но у него была просадка в мотивации. Он то ли не хотел, то ли не умел мотивировать свою команду. Например, вбегал порой как «чайка-менеджер» к команде, что-то кричал и убегал. Команда дальше: «Хм… что это было? Мы что делаем? Ну, видимо, дальше работаем». Такая команда рано или поздно начинает сыпаться. Период полураспада зависит от изначального заряда команды. Обычно это год, полтора, максимум — два. Нужно стержневое понимание, что именно делает руководитель, чтобы был смысл в работе.

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

Повторюсь, это не всё, — остальное я считаю уже мясом. Например, чтобы создавать процессы и правила, нужно уметь «продавать» идеи, доносить их. Нужно, чтобы руководителю верили.

Должен ли руководитель быть разработчиком?

Если анализировать руководство как управление процессами, правилами и мотивацией, то не обязательно. Разбираться — да. Тот же тимлид не обязан глубоко погружаться в технику. Например, он не должен разгребать конфликты в git, разбираться с логами teamcity и код править. Для этого есть техлид и/или команда. У них более хардовые компетенции, навыки. Директор цирка не разбирается в акробатике, он разбирается в акробатах. Режиссёр фильма может знать, как снимать, но не бегает сам с камерой, для этого есть оператор.

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

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

Можно ли подтянуть софт-скиллы?

Это сложно. Нельзя что-то прочитать, допустим, и сказать: «Всё понятно. Я умею мотивировать людей. Я умею вести их за собой».

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

Софты важны. Предположим, что сотрудник не любит взаимодействовать с людьми, а для руководителя это нужно. Я однажды ставил таких руководить командами, рассуждая так: «Есть тренинги классные. Походи, посмотри видео. Ещё книжки есть, и много написано интересного. Сейчас тебе софт-мышцу потренируем, как на фитнесе, и будет всё ОК. Наверное, просто мало взаимодействия было». Результат предсказуемый. Людей менять тяжело. Я сделал выводы и не пытаюсь такое навязывать и тратить время обоих, лучше сфокусироваться на сильных сторонах.

Как понять, что сотрудник готов руководить?

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

Желание руководить и желание расти карьерно — разные. Чтобы отличить одно от другого, я наблюдаю за некоторыми признаками. Например, это готовность сотрудника засучить рукава и пойти в поля. По сути, сотрудник может пойти и выйти за свои рамки. Не каждый готов. Например, существует разработчик и он пишет свой код. Говорит: «Слушайте, что вы ко мне пристали? Я написал свой код. Это вот к нему вопрос». А другой выходит за рамки только своего и может, к примеру, пойти к QA и помочь им тестировать. Может пойти ещё в бизнес. Он может начать что-то делать, помогая остальным, когда нужно.

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

Следующая важная черта — уметь фокусироваться на главном. Скажем так, бизнес или руководитель иногда ставит задачу в очень абстрактном виде из разряда «хочу такого слона». Возникает вопрос, а если у него не будет хвоста, то это будет слон? Если у него будут такие маленькие уши и хобот? Если у него не будет хобота и бивней? У тех, кто может фокусироваться на важном здесь и сейчас, как правило, получается слон без хвоста или с маленькими ушами. Но получается. Да, он корявый, но его можно продавать. А кто хочет красивого слона — получает его через год, но на современном рынке такой слон зачастую уже никому не нужен.

Главное в этом то, что руководитель может выделить важное и сосредоточиться на этом. Хорошо, когда он может чётко объяснить, как действовал, почему именно так стояла задача изначально. На чём он фокусировался. Как выбрасывал неважное. Почему он действовал именно так. Это можно проверить по тому, что инженер на текущей должности может объяснить про свою работу. Важно услышать, как он это объясняет.

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

Это связано с умением планировать проект. Руководителю редко дают конкретные инструкции по шагам. Если сотрудник привык работать по инструкциям — это не то. Например, он классно пишет код. Замечательно. Но он говорит: «Так было в ТЗ написано, и я так сделал». В хорошем случае для потенциального руководителя сотрудник попытается выяснить, зачем это надо. Он может сходить в бизнес спросить, поговорить, пропустить через свой опыт, и у него получается даже более масштабируемый/ чистый код. Он старается не делать того, что не нужно, пытается выяснить: «Вы уверены, что это надо? Кажется, это булшит, и вот почему…». Я видел, как такие специалисты экономили ресурсы компании и сами предлагали реально крутые идеи.

Важно проверить понимание и открытость. Пример: вы приходите, ставите задачу. Он говорит: «Всё понятно. Я знаю, как делать. Всё будет классно». У него на всё есть готовый ответ. С ним как-то даже комфортно коммуницировать. У меня после тридцатого такого разговора начало возникать некоторое подозрение. Я видел очень много эффективных руководителей, у которых эффективная команда, но не всегда был на всё готовый ответ. Видел обратную сторону руководителей, которые отвечают с ходу: «Всё понятно». Взаимодействуя с такими руководителями, которым всегда всё понятно, выясняется, что там дальше нет глубины. Когда вы спрашиваете: «Хорошо, а что с этим нюансом мы будем делать?». И оказывается, что всё-таки было непонятно. По сути дела, такие сотрудники тянут одеяло больше на себя и пытаются показаться не тем, кто они есть на самом деле.

С другой стороны, хорошо, когда и сотрудники, и руководитель открыто вам говорят о проблемах, открыто чем-то делятся. Причём могут даже прислать артефакты, типа презентации/письма со всякими пояснениями и предложениями, а не просто крики ужаса. И вот тут бывает видно, что человек не заморачивается мыслями «сейчас скажу и буду выглядеть идиотом, лучше помолчу». Потому что у него действительно болит за команду/ компанию, и он делится этой информацией. Между руководителями, которые доверяют друг другу, образуется более крепкая связь, по которой быстрее ходит информация. Я предлагаю сфокусироваться на тех, кто больше делится, больше даёт информации, а не тех, кто «всё понятно, есть готовый ответ», а дальше ничего.

Понимание через примеры неэффективности

Как определить неэффективность? Через некоторое время появляются разные шаблоны. Паттерн неэффективности под номером один. Это когда ваш руководитель говорит: «Этот человек не делает то, что я от него хочу. Иди, пожалуйста, разберись с ним». Возникает вопрос, зачем тогда мне руководитель? Почему ты не попытался разобраться? Нужен такой специалист, который сначала попробует сам и только уже побитый придёт на уровень выше. Если это интеграционный проект и у него есть какая-то зависимость, он может сам прийти к инженеру, с ним договориться. Сказать: «Миша, давай быстрее. У нас проект сейчас подгорает. Давай с этим разберёмся». Не сразу бежать к тимлиду с какими-то жалобами, что он не делает то, что ему надо. Важно, чтобы он пробовал работать на своём уровне сначала. Тут правда есть нюанс: с опытом надо уже понимать, когда разборки на своём уровне уж сильно затянулись.

И вот через такие примеры, которые вы в команде видеть не хотите, можно делать выводы кто вам нужен.

Что делать с новым руководителем?

Нужно создать безопасную среду прежде, чем предлагать должность. Первое: «Если ты откажешься, то это нормально». Я, создавая такую среду, видел, что сотрудник уже гораздо более расслаблен. Нет у него этого груза, что сейчас обо мне что-нибудь не то подумают. Почему это важно? Потому что вы сможете определить ситуацию, когда сотрудник действительно мотивирован, но у него где-то внутри синдром самозванца сидит. Его нужно просто подтолкнуть, рассказать, что к чему. Вторая ситуация, когда сотрудник не особо мотивирован и как раз опасается.

Второе: выдать кредит доверия. Когда кто-то становится руководителем, то у него может возникать страх сделать ошибки. «Вот, он меня сейчас уволит сразу за эту ошибку и всё». Это ведёт к тому, что у такого руководителя и его команды нет творчества. Ещё в команде могут быть неформальные лидеры, которые могут не доверять и сопротивляться изменениям. Ему предстоит решать эту дилемму. Кредит доверия можно выдать, представив его перед командой и другими руководителями: «Это классный руководитель. Я в него верю. У него большой опыт». От себя можете выдать, сказать: «Вот тебе карт-бланш. Действуй». Даже если он ошибся, то можно специально перед командой сказать: «Да, ты ошибся. Но ты рискнул. Молодец. Действуй ещё раз». За счёт этого будет повышаться кредит доверия. Даже если внутри возникает какое-то опасение, вы ничем не рискуете. Вы его уже взяли. Всё. Кредитом доверия вы, по сути, улучшаете его онбординг в команду.

Третье. Разберитесь с ответственностью, чтобы не слышать разных отмазок. Руководитель взял на себя ответственность? Он должен её принять и нести до конца. За счёт этого у руководителя больше креатива. Он пытается найти ресурсы, варианты. Но бывает, что вы берёте начинающего эксперта или руководителя, который раньше запрашивал ресурсы, а теперь ими владеет. Здесь важно убедиться, что вы дали все полномочия. К примеру, начинающий эксперт может побояться, не очень понять, где его полномочия. Сеньор, конечно, придёт и скажет сразу: «Я не сделаю тебе этот продукт двумя разработчиками. Ты что от меня хочешь?». Договоритесь сразу, какую ответственность вы делегировали и какой результат ожидаете. Тогда будет проще отличить отмазки и не отмазки.

Итог

Пока вы не сколотите хорошую команду, вы не сделаете продукт и прибыль. Две самые важные составляющие бизнеса — это продукт и прибыль. Но на первом месте всё-таки люди.

Итак, смотрим на следующее:

1. Умение строить процессы.
2. Мотивировать.
3. Насколько человек хочет руководить и готов переключиться.
4. Не избавляются ли от него на прошлом месте его работы.
5. Делает ли он уже какие-то элементы будущей работы, например, изучает ли какие-то менеджерские вещи?
6. Вникает ли он в суть того, что делает и зачем.
7. Насколько он открыт и конструктивно говорит о проблемах.
8. Дальше, если вы провели ассесмент и поставили человека руководить — дайте ему кредит доверия. Кстати, это не означает, что он волен творить, что хочет — ваши с ним синхронизации никто не отменял. Но в глазах остальных он должен точно знать, что делает.
9. Определите зоны ответственности, даже если вам кажется, что там всё очевидно.

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