Привет, Хабр!

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

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

Итак, рассмотрим ситуацию, когда в команду разработки (или в командЫ разработки) приходит новый руководитель, о котором самим участникам команды ничего не известно. И этот руководитель — вы.

Встреча с предыдущим IT-руководителем. Разведка местности

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

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

Для чего это надо?

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

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

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

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

• Получить информацию о внешних лицах, влияющих на проект (стейкхолдерах) — представителях бизнеса и смежных подразделений), — с которыми придётся часто взаимодействовать. Можно сразу взять контакты этих людей. С ними нужно будет познакомиться отдельно.

• Оценить вашу с ним «похожесть» по мировоззрению и риторике. Зафиксировать стилистику его речи. В редких случаях это может помочь в построении коммуникации с командой.

• Попросить его о помощи и о возможности обращаться к нему за советом в ближайшие несколько месяцев.

Чего делать не стоит:

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

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

• Также помните, что есть немалая вероятность, что о вашем с ним разговоре узнает команда.

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

Знакомство с командой

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

• Если в компании нет какого-то единого справочника, то заведите его себе отдельно (хотя бы в том же Excel). Выпишите в него всех членов команды с телефонами и email.

• Занесите себе телефоны всех участников команды в записную книжку сотового (ох, как же часто у меня не было под рукой номера нужного разработчика).

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

• Выясните наличие каких-то дополнительных регалий (благодарственных писем от генерального директора, сертификатов и т.д.) или предупреждений (выговоров), касающихся членов команды.

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

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

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

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

На встрече я рекомендую вам сделать следующее:

• Формально представиться. Рассказать о своём профессиональном опыте.

• Максимально открыто рассказать о своей семье, хобби и увлечениях. Такой шаг демонстрирует определенный уровень доверия с вашей стороны и всегда воспринимается положительно.

• Уверить команду в том, что никаких революционных изменений не будет, и вы, как руководитель, сначала в полной мере погрузитесь в работу команды и проекта. Даже если возникнет потребность в сильных изменениях в процессе работы команды, её составе или целях, пообещайте изначально открыто обсудить все новшества с командой.

• Похвалить проект. Даже если вы на самом деле так не считаете. Текущее состояние проекта — это результат работы команды и внешних обстоятельств. Если даже при реализации проекта принимались какие-то неудачные на ваш взгляд решения, вероятно, на то были причины.

• Уточнить расписание всех периодических командных мероприятий (стендапов, дневных митингов, итераций планирования, ретроспектив и прочего).

• Попросите добавить вас в общие командные чаты, если такие будут. Зафиксируйте потом, кто именно это делает. Косвенный признак неформального лидерства.

• Попросите каждого члена команды представиться и кратко рассказать о себе. Постарайтесь построить свою фразу с этой просьбой так, чтобы явно не указывать человека, которому надо представиться первым. Если кто-то сам возьмёт инициативу и начнёт рассказывать о себе — зафиксируйте его. Это ещё один признак неформального лидерства.

• По ходу представления задавайте каждому несколько очевидных вопросов, не слишком интимных. Я рекомендую вопросы вида «А как давно ты работаешь в компании?», «Какое у тебя хобби?», «Какие книги/фильмы/сериалы нравятся?», «Какая самая крутая фича, которую ты делал?». Всё это нужно, по сути, для разрядки ситуации, чтобы команда почувствовала себя комфортнее. Ну и, возможно, вы найдёте какие-то точки общих интересов, на основе которых можно будет установить более доверительный контакт в будущем.

• После того, как все представятся, предложите команде задать вопросы вам. Зафиксируйте, кто задаст первый вопрос, и характер вопроса.

  • Если вопрос с подковыркой и ставит под сомнение вашу компетенцию или опыт — это тоже признак неформального лидерства. Такое может произойти, когда неформальный лидер в команде хочет занизить ваш авторитет, чтобы сохранить свой. На самом деле это хороший признак. Значит, в команде неформальный лидер хотя бы есть.

  • Если вы не можете ответить сейчас на вопрос, то лучше пообещайте его записать и вернуться с ответом персонально к задавшему вопрос (тут главное сдержать обещание).

  • Если вопросы касаются нейтральных моментов (например, «Есть ли у вас домашние животные»), то честно на них отвечайте, это хороший признак, команда тоже ищет точки соприкосновения.

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

Если все косвенные признаки неформального лидерства указывают на одного человека — поздравляю, вы нашли местного кардинала Мазарини (человека, во многом определяющего мнение команды). Осталось перетянуть его на свою сторону.

Чего не нужно делать на встрече-знакомстве с командой:

• Нельзя критиковать членов команды и стейкхолдеров. Даже обоснованно. Если сама команда открыто говорит о ряде проблем в проекте, не выясняйте виноватых. Лучше использовать фразы вроде: «Уверен, совместными усилиями мы преодолеем эту сложность».

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

• Не ведитесь на провокации и токсичные вопросы, и при этом не обостряйте конфликт. К примеру, если вам задали вопрос: «А почему вас назначили на позицию руководителя, а не кого-то другого (читай между строк — более достойного)». Плохой ответ: «Потому что я такой вот хороший профессионал, много умею и знаю». Это сразу ставит вас в позицию оправдывающегося. Лучше ответить: «Надеюсь, в ближайшее время я своей работой докажу вам справедливость этого решения». Но задавшего такой вопрос зафиксируйте — вероятно, это неформальный лидер коллектива.

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

Встречи с бизнес-частью команды

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

На встрече рекомендую выяснить следующую информацию:

• Формально представиться и определить себя как основную точку решения IT-вопросов. При этом оговорить, что «пока» ничего в процессах не меняется, поскольку вы входите в курс дел.

• Похвалить проект и его идею. Доброе слово и кошке приятно.

• Выяснить среднесрочные и долгосрочные цели, которые стоят перед командой. Это и самому знать полезно, и поможет выяснить, понимает ли команда свои цели.

• Выяснить список терминов и идиоматических выражений, принятых в команде (если есть специфические термины), это нужно для полноценного понимания технический обсуждений по логике реализации фич.

• Бизнес-процесс, в котором участвует разрабатываемый продукт и его описание. Нужно для понимания логики развития продукта.

• Уточнить статус по конфликтам в команде: есть ли такие, кто и почему конфликтует по мнению бизнес-лидера. Но возможно, ответ на этот вопрос будет «не знаю».

• Уточнить неформального лидера команды по мнению бизнес-лидера.

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

• Уточнить процесс постановки задач: кто и как доносит до разработчиков, что надо сделать. Если окажется, что в этом процессе есть какой-то человек-переводчик, который расписывает задачи разработчикам, и это не системный аналитик, — то это ещё один косвенный признак неформального лидера.

• Спросить о текущих проблемах и аккуратно их зафиксировать.

• Уточнить способ и график презентации результатов проекта высшему руководству. Заявить о своём желании участвовать в этом мероприятии.

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

• Согласовать определённую техническую квоту рабочего времени разработчиков на рефакторинг проекта и его техническое усовершенствование. Тут можно сослаться на определенные «общепринятых» практик надёжности сервисов, которые можно и нужно внедрить в проекте. Даже если вы сейчас не знаете, что конкретно нужно улучшить (не было встречи с предыдущим руководителем ИТ) поверьте, в ближайшее время такие задачи появятся.

Чего не стоит делать:

• Не давать никаких обещаний по срокам. Обычно на таких встречах представители бизнес-команды сразу обозначают определённый перечень проблем (с укомплектованностью, производительностью команды, архитектурой сервисов, надёжностью и прочим), и просят сообщить, когда же они будут устранены. Сошлитесь на то, что погружаетесь в проект и сможете показать план решения проблем позднее.

• Критиковать или явно соглашаться с критикой вашего предшественника. Если ход разговора требует от вас озвучить субъективное суждение, то лучше уходить от ответа: «Я пока не составил чёткого представления о состоянии проекта, и как раз занимаюсь этим».

Основная цель этого разговора — получить информацию о состоянии команды и проекта «глазами бизнеса», а также заявить о себе как о «главном ИТ в команде».

Следующий шаг — личные встречи тет-а-тет с членами команды.

Личные встречи тет-а-тет

Если команда разработки не превышает 20 человек, то лучше всего встретиться с каждым разработчиком лично. Если больше — вероятно, в команде есть технические лидеры, можно ограничится встречей только с ними.

Основная задача таких встреч — получить напрямую субъективное мнение каждого члена команды о состоянии и проблемах проекта (вполне возможно, что их не озвучили на общей встрече, потому что «постеснялись») и дать ощущение персональной заинтересованности вас как руководителя в каждом из сотрудников. Еще одна цель — получить примерное представление о психотипе каждого разработчика и возможностях его развития.

К серии таких встреч нужно подготовиться:

• Просмотреть код проекта и самому оценить его состояние.

• Выявить достаточность покрытия проекта тестами.

• Выявить состояние систем мониторинга доступности сервиса и оповещения (как проверяете доступность, как работает уведомление о недоступности).

• Изучить CodeStyle.

• Изучить и представлять архитектуру проекта и схему основных инфопотоков.

• Изучить динамику количества багов в проекте.

• Ознакомиться с техническим и архитектурным долгом.

• Изучить (если есть такая возможность) личные профили ребят на GitHUB/GitLab.

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

Непосредственно на встрече рекомендую сделать следующее:

• Какие среднесрочные и долгосрочные цели стоят перед проектом (сравнить ответ с пониманием от бизнеса)?

• Какие метрики говорят об успешности проекта (сравнить ответ с пониманием от бизнеса)?

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

• Есть ли у инженера какие-то сторонние пет-проекты?

• Какие языки программирования знает инженер?

• С какими технологиями он работал (или хотел бы работать)? Тут речь идёт не столько о языках, сколько о технологиях DevOps, поисковых движков, PWA, специфике баз данных.

• Как инженер характеризует свою команду? Есть ли в ней какие-то проблемы, на его взгляд?

• Как инженер характеризует состояние проекта, над которым работает?

• Каким образом мониторится доступность и надёжность проекта? Какая процедура реагирования на критическую проблему в проде?

• Какие планы у инженера на ближайший год — в каком ключе хотел развиваться, смотрит ли рынок, и т.д.?

Чего не надо делать:

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

• Критиковать технические решения, принятые командой в рамках развития проекта.

По итогам этих встреч вы сможете мысленно разделить членов команды на «волатильных» и «стабильных».

• «Волатильные» — это ребята, которые легко относятся к изменениям и готовы с головой бросится в разработку нового проекта (даже без ТЗ и чёткого понимания финального результата). Они могут за ночь на коленке собрать прототип новой бизнес-фичи. Их мотивирует движуха, новые задачи, новые технологии и процессы. Часто у них много пет-проектов (обычно незаконченных), они пробовали и поверхностно разбирались в большом количестве технологий и инструментов.

• «Стабильные» — это инженеры, которые привыкли делать всё основательно. Они до песка разбирают каждую новую задачу и делают её «на века». Обычно стек технологий, которыми владеют такие ребята, гораздо уже, но знают они его досконально. Им комфортнее работать с чётким ТЗ и понятными сроками, и они более ревностно относятся к результатам своего труда (если сделал фичу, но она не поехала в прод, то это обычно сильно демотивирует).

Для себя я считаю комфортной команду, в которой 30 % «волатильных» и 70% «стабильных» разработчиков. «Волатильным» инженерам лучше поручать разработку MVP и прототипов для проверки бизнес-гипотез, а «стабильные» нужны для создания уже проверенной функциональности, рассчитанной на большие нагрузки, и для проектирования сложных core-сервисов.

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

Гриндинг авторитета

После проведения вышеупомянутых встреч можно остановиться, перевести дух и сформулировать промежуточные итоги:

• Вы формально познакомились со всеми ключевыми стейкхолдерами и с командой.

• Вы сформировали для себя объективный (из нескольких источников) перечень потенциальных проблем в команде и в проекте, с которыми можно начать работать.

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

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

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

Авторитет = Уважение + Доверие

А что такое уважение?

Для себя я этот термин сформулировал как «признание совершенства субъекта уважения в той сфере, которая для меня важна».

К примеру, я уважаю Юрия Гагарина, потому что он первым совершил полёт в космос, а эту сферу я считаю важной. Уважаю Михайло Ломоносова за развитие науки в стране, в которой я живу и которую я люблю. Уважаю коллег-инженеров, потому что они гораздо лучше меня разбираются и развивают проекты, которые я считаю важными.

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

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

— «Я сходил к такому-то сотруднику с твоей проблемой, и получил такой-то ответ».

— «Я подготовил такие-то материалы и отправил их на согласование тому-то».

— «Я переговорил с такой-то смежной командой и договорился, что они сделают нужную функциональность к такой-то дате».

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

Гриндинг уважения в техническом плане сложнее и дольше. Тут нет серебряной пули. Вам нужно на основании своего опыта (не зря же вас назначили руководителем) в рамках технического обсуждения новых задач в команде предлагать простые и элегантные технические решения, которые позволяли бы быстро и надёжно реализовать новую функциональность или улучшить старую. Если ваши решения действительно хороши, то постепенно в глазах команды вы будете приобретать не только административное уважение, но и профессиональное.

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

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

А что такое доверие?

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

Доверия можно добиваться постепенно, решая административные «боли» сотрудника (как уже описывалось выше), либо, если подвернётся случай, применить приём «мальчик для битья» — это сразу значительно повысит доверие всей команды по отношению к вам.

Суть приема следующая. Возникает ситуация, когда один из членов команды допускает серьёзную ошибку, которая приводит к более-менее значимым последствиям (падение сервиса, серьёзное нарушение внутреннего регламента компании и т.д.). При разборе ситуации и поиске виноватых вы публично берёте вину на себя, с комментарием: «Это мои люди, я за них отвечаю, и их косяк — это мой косяк. Мы разработаем комплекс мероприятий по предотвращению таких ситуаций в будущем и внутри разберёмся, что надо сделать или внедрить, чтобы такого больше не было».  Идеально будет, если часть наказания даже коснётся вас, но в смягченном варианте (можно это заранее проговорить уже с вашим руководителем).

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

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

Сбор обратной связи

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

• Поменялась ли ситуация с командой и проектом в лучшую сторону? Если да, то в чём состоят эти улучшения? Этот вопрос нужен для того, чтобы сотрудник сам сформулировал социально ожидаемый ответ о том, ситуация стала лучше.

• Наблюдал ли сотрудник какие-то ваши поступки или действия, которые не понимает или осуждает? Это возможность объяснить ваши решения и действия, если кто-то не до конца понимает их смысл (например, не владеет полной картиной).

• Что нужно исправить вам как руководителю в вашем поведении и работе, чтобы соответствовать ожиданиям сотрудника? Это вопрос для понимания правильности вашего курса. Если ответ «всё нормально», то вы на верном пути. Если будут приведены примеры вашего некорректного (с точки зрения сотрудника) поведения, то это повод поразмышлять и, возможно, его скорректировать.

Чего не стоит делать на такой встрече:

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

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

• Не преувеличивайте вашу роль в успехе команды. Дайте возможность сотруднику её преувеличить.

Если встреча в целом даёт вам понимание, что вас воспринимают позитивно, то пора переходить к тимбилдингу.

Тимбилдинг

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

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

• лазертаг;

• баскетбол/футбол/волейбол;

• игра «Шляпа».

Средние варианты:

• совместное прохождение квестов, желательно хорроров и с актёрами;

• попить пива в баре;

• квиз.

Если команда удалённая и доступны только онлайн-варианты, то рекомендую онлайн-игры (CS:GO, Dota2 и т.д). Важно: команды должны состоять только из «своих», не должно быть посторонних «случайных» игроков.

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

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

Пуд соли и общественное признание

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

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

• Падение прода и судорожное его поднятие с выяснением причин. Хорошо комбинируется с приёмом «мальчик для битья».

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

В любой из этих историй вы должны играть ключевую роль. Более того, после окончания «пожара» важно публично рассказать о произошедшей ситуации и похвалить команду за её работу и оперативные и грамотные действия. К тому же активное участие в «пожарах» даст вам отличную возможность наблюдать за действиями всех членов команды в сложные моменты. Если лидерство на себя (помимо вас, конечно) будет брать и «неформальный лидер» — это хорошо, значит, по сути, ваш преемник уже сформирован и готов.

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

Выбор правой руки

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

«Правая рука» — это ваш преемник. Человек, который возглавит команду и будет выполнять функции руководителя в случае вашего отсутствия. Выбор и подготовка «правой руки» — важный и необходимый шаг, поскольку без него вас как руководителя не повысят (не подготовил замену).

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

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

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

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

Важно для себя понять простое правило: сила руководителя — в его команде и его людях.

Если вы построили команду, которая может прекрасно функционировать без вас, то вы молодец. Не стоит бояться того, что в этом случае вас уволят — скорее всего, вас попросят возглавить ещё одну команду (с соответствующим ростом должности).