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

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

Позиция тимлида вообще предполагает relationship management, который может быть направлен как и на команду, так и наверх, в сторону стейкхолдеров. Но в этой статье я хочу поговорить именно про связку TL + Dev Team. Руководителю важно выстроить и поддерживать доверительные отношения с сотрудниками. Это поможет эффективно управлять командой и добиваться слаженной и продуктивной работы.

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

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

Не бойтесь признаться, что чего-то не знаете

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

«Как я могу руководить людьми, которые в чем-то компетентнее меня?»‎, ―  думал я. «А что я буду делать, если ко мне придут с вопросом, а я не буду знать ответ? Саша опытнее меня как разработчик, он лучше подходит на роль руководителя команды». Так я считал раньше, когда я задумывался о роли тимлида. Но потом я переосмыслил задачи и зону ответственности руководителя. 

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

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

А вот если тимлид все замыкает на себе и вдобавок занимается микроменеджментом — эффект обратный. Люди будут меньше заинтересованы в качественной работе. 

Осознанная некомпетентность предполагает, что члены команды постоянно делятся экспертизой друг с другом и с руководителем, и таким образом они прокачивают друг друга. Но при этом тимлиду всё-таки важно не отстранятся от этого процесса, а периодически делать подробный zoom in на определенные задачи. Это сохраняет авторитет и доверие ― люди видят, что ими управляет не бюрократ, который понятия не имеет, как все работает, а человек, готовый погрузиться в задачи и  спроектировать решение. Ну и к тому же продукт IT-компании ―  это сервисы и системы, и трудно управлять тем, что ты понимаешь поверхностно.

Помните об интересах команды

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

Часто руководители применяют стили управления, которые позволяют им выглядеть хорошо перед начальством и клиентами, но плохо влияют на эффективность работы. Я для себя выделил три модели поведения, которые точно нельзя использовать, если хочешь показывать хорошие результаты.

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

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

Технарь. Обычно это бывший разработчик, которого повысили за выслугу лет или за то, что он самый опытный в команде. Хороший программист, но плохой менеджер. Может за два дня закрыть задачи на весь спринт. Все сложные задачи делает сам, потому что все остальные не справятся ― или ему так только кажется. Он не стесняется критиковать коллег и не любит ходить в отпуск, потому что без него все развалится. Беда такого тимлида в том, что он не умеет делегировать ответственность и задачи, не дает своей команде расти, не заботиться о сотрудниках и не признает свои ошибки. Это демотивирует ― люди быстро начинают скучать и работать, спустя рукава. А потом тимлиду приходит оффер, и проект встает насмерть.

Объясняйте, что вы делаете и зачем 

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

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

Любые изменения необходимо обсудить с командой: обозначить проблему,  предложить решение, выслушать мнения и рассмотреть альтернативы. Если не получается убедить команду в правильности ваших действий, можно предложить попробовать и посмотреть на результат через некоторое время. Но не настаивать, что решение ― окончательное и бесповоротное. Это поможет замотивировать людей не принимать перемены в штыки, а еще увидеть слабые места нововведений и починить их.

Соблюдайте договоренности

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

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

Для этого необходимо ответить на три вопроса:

• Кто будет делать?

• Что будет делать?

• Когда будет делать?

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

Правильная договоренность звучала бы так: «Каждый разработчик с сегодняшнего дня пишет тесты на все новые методы API». Соблюдение такой договоренности уже можно проверить.

Комбинируйте виды общения с командой

Существует три вида коммуникации внутри команды. И каждый из них подходит или не подходит для конкретных ситуаций. 

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

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

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

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

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

Практикуйте фасилитацию

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

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

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

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

Учитесь решать конфликты

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

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

• Дайте человеку время успокоиться. Эмоции мешают слышать оппонента и объективно оценивать ситуацию.

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

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

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

Не манипулируйте

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

Легкие: 

• Попытка взять на слабо: «Я бы хотел вот это сделать, но ты наверное не справишься»

• Газлайтинг: «Я этого не говорил», «Ты все истолковываешь неправильно» 

• Навязывание чувства вины: «Вы не протестировали и зарелизили, а мне теперь из-за вас придется выслушивать от руководства».

Тяжелые:

Это, как правило, попытки застыдить, полностью переложить ответственность и даже унизить:

• «Я от тебя такого не ожидал»

• «Почему я должен это объяснять человеку с таким опытом работы» 

• «Как мидл разработчик может допускать такие ошибки»

• «Ты меня очень сильно подвел»

Активные: когда мы вслух выражаем свое недовольство и упрекаем людей в расчете, что они сделают то, что нам нужно. 

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

Негативные: все, о чем я сказал  выше: обвинения, навязывание чувства вины, разочарование, обида. 

Позитивные: «Ну мы же с вами умные люди», «Саш, ну ты же опытный разработчик, кроме тебя никто не справится, спасай».

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

Будьте честны

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

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

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

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

В итоге я все равно ушел и не пожалел.

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

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

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