Тихий саботаж в команде
Я хочу поговорить о своеобразном тихом саботаже – о том, о чем руководитель проекта, скорее всего, не скажет вслух, обсуждая свою команду. А именно – о манипуляциях на работе.
Я работаю в сфере IT около пяти лет и за это время успела поработать в нескольких командах разработки и нескольких корпоративных культурах.
Представим, что я выступаю перед вами с докладом. Cледующие 30 минут – это ресурс, который я заберу, но не скажу об этом прямо. Как я это сделаю? Я скажу: «Коллеги, этот доклад – результат большой работы и моих профессиональных наблюдений. Конечно же, чтобы поддержать меня и чтобы эти 30 минут прошли максимально эффективно и продуктивно, пожалуйста, будьте внимательны».
Скорее всего, если после этого человек захочет посмотреть в телефон или поговорить с соседом, он почувствует легкую вину. Совсем капельку. Хотя я совершенно ничего не сделала. Никто ведь не хочет показаться невовлеченным, некомандным или неактивным. А то я, скорее всего, расстроюсь.
За 30 секунд я привязала ценность своего выступления к социальной репутации человека. А теперь представим, как такие невидимые нити забирают не 30 секунд времени, а дни, недели и месяцы продуктивности команды. Важно учиться не попадаться на такие крючки.
Разберемся, что такое манипуляции, как с ними жить и как с ними работать.
Что такое манипуляция
Манипуляция – это скрытое воздействие на человека с целью получения от него какой-либо выгоды. Из этого определения следуют два принципа.
Во-первых, это скрытое воздействие. Манипулятор не говорит о своих желаниях напрямую, а пытается получить желаемое косвенным путем. Он не скажет: «Петя, я хочу от тебя это, это и это». Манипуляция работает иначе.
Во-вторых, это получение выгоды. Манипулятор хочет получить какой-либо ресурс. Выгода может быть абсолютно разной: материальный или психологический ресурс либо определенное, выгодное манипулятору поведение.
Причем манипуляции совершенно спокойно встречаются даже в ламповых командах. На самом деле они могут появиться где угодно. Определим, почему это происходит в IT-сфере?
Я выделила несколько основных причин.
Первая причина – разрыв между бизнесом и разработкой, то есть разные языки, на которых мы говорим. В командах работают совершенно разные люди. Среднестатистическая команда – это аналитики, разработчики, дизайнеры, тестировщики. Все они говорят на разных языках: аналитики – на языке бизнеса, разработчики – на языке платформы.
Это создает идеальные условия для манипуляций, потому что человек не всегда может проверить то, что говорит ему коллега. На этом можно играть, в том числе перекидывая ответственность.
Следующая причина – культура «геройства» и авралов. До сих пор ценится подход, при котором нужно перерабатывать и ночами спасать проект. Манипуляции в такой среде обращаются именно к культу геройства и переработок: «Помоги, сделай. Ты что, не командный, что ли?»
Еще одна причина – полизависимость и сильные компетенции. В сфере 1С это довольно яркая история: каждый человек становится гуру в своей определенной области. Кто-то является экспертом по расчету заработной платы, кто-то – мастером сложных запросов. В этом случае манипуляции обращаются к экспертизе как к ресурсу.
Цена манипуляций для команды и бизнеса
Манипуляции наносят прямой ущерб и бизнесу, и команде, и каждому человеку в отдельности.
Первое последствие – выгорание ключевых специалистов, потому что под удар попадают самые трудолюбивые сотрудники. Те, кто денно и нощно работает и берет на себя нагрузку за двоих, десятерых или двадцатерых.
К чему это приводит? Такие люди либо уходят в скрытую, тихую оборону и начинают выполнять только свои задачи, либо вообще покидают компанию.
Следующее последствие – падение качества и рост долгов. Задачи, выполненные на коленке человеком, которому их изначально не поручали, неизбежно превращаются в будущий технический долг. Манипуляции порождают плохо задокументированный хаос в проекте.
Последнее по порядку, но не по важности последствие – разрушение психологической среды. Манипуляции неизбежно приводят к фрагментации коллектива и блокировке честной обратной связи. Люди просто перестают доверять друг другу.
По своей структуре манипуляции можно разделить на два основных типа: лингвистические и психологические.
Лингвистические манипуляции – это определенные речевые паттерны, обороты и правила построения предложений.
Психологические манипуляции – более сильные техники воздействия. Они не всегда имеют определенную речевую основу. Как правило, они создают конкретную психологическую ситуацию и цепляются за наши потребности.
Начнем с лингвистических крючков. Они более понятны и не обладают настолько сильным эффектом.
Лингвистический прием №1. Разговорный постулат
Первый лингвистический прием я называю разговорным постулатом. По сути, это вопросы, на которые нельзя ответить «нет», не почувствовав себя некомандным.
Например, спринт заканчивается, а не все задачи выполнены. Тимлид говорит: «Ребята, спринт заканчивается, надо поднажать. Вась, давай останешься после работы. Давайте уже наконец все выполним. Мы же все здесь профессионалы».
Если человек отвечает «нет», возникает вопрос уже не о том, есть ли у него силы или другие планы. Возникает вопрос о его лояльности. Отказ как будто объявляет его некомандным игроком: «Как я могу не закрыть спринт? Как я могу подвести команду?»
Антидотом здесь будет разделение эмоциональной составляющей и самого запроса. Вообще любая манипуляция строится на том, что она целится в эмоции. Сначала человек реагирует на эмоциональную обертку и совершенно не обращает внимания на суть запроса.
Задача – отделить эмоции от запроса и сказать тимлиду: «Вань, помощь – это важно. Опиши, какие задачи у нас сейчас есть. Давайте определим сроки и проведем оценку по времени. Если мы где-то ошиблись, давайте подумаем, почему это произошло».
Мы не говорим «нет». Мы соглашаемся с красивой оберткой: помощь важна, мы делимся экспертизой. Но при этом возвращаем запрос в рабочее русло.
Лингвистический прием №2. Иллюзия выбора
Еще один лингвистический прием – иллюзия выбора. Многие родители используют его со своими детьми.
Манипулятор предлагает человеку два варианта. Наш мозг довольно легко обмануть: когда нам дают варианты, мы думаем, что получили возможность выбирать. Но на самом деле манипулятор предлагает только те варианты, которые выгодны ему и, возможно, совершенно невыгодны нам.
Например, руководитель проекта возвращается со встречи с заказчиком и говорит команде: «Клиент ждет эту функцию послезавтра. Либо берем два дня, перерабатываем, но все делаем и радуем клиента, либо берем эту задачу в спринт и выпускаем только через две недели».
Предлагаются два крайне нежелательных варианта: либо геройство с переработками, либо позорно долгий срок.
Антидотом в случае с иллюзией выбора будет реалистичный вариант. Мы снова отделяем эмоции от запроса и говорим руководителю проекта: «Иван Петрович, давайте рассмотрим альтернативные варианты. Мы проведем с ребятами технический анализ этой функции. Дайте нам два-три часа, после чего мы предложим клиенту реалистичный сценарий. Возможно, результат будет готов не через два дня, но мы сможем решить задачу другим способом».
Лингвистические приемы – это определенные речевые конструкции. Человек, который ничего не знает о лингвистических крючках, может вообще не понять, что его обманывают и пытаются косвенным путем чего-то от него добиться.
Поэтому важно слушать собеседника, анализировать его слова и опираться на командные процессы. Когда границы основаны не на личном «я не хочу» или «я не буду», а на том, что процесс не позволяет или план не сойдется, манипулятору будет не за что зацепиться. Ему придется идти вразрез с командными договоренностями и процессами, а там он заведомо проигрывает.
Психологический кейс №1. Игра в беспомощность
Перейдем к психологическим воздействиям. Здесь я приведу конкретные случаи из своей практики. Это живые люди, живые ситуации и то, как мы с ними работали.
Первый психологический случай я назвала «Игра в беспомощность».
К нам на проект пришел коллега. Он был очень коммуникабельным, настоящей душой компании. Ребята его любили, все с ним общались. Под предлогом того, что он еще не до конца понимает свой функциональный блок, коллега довольно часто обращался с простым запросом: «Маш, ты тут разбираешься? Давай посмотрим, где я ошибаюсь и чего не понимаю».
Вроде бы это звучит как нормальный запрос. Но вся суть заключалась в том, что ребята тратили колоссальное количество времени на помощь коллеге. Более того, это происходило систематически и занимало не 15 и не 30 минут. Порой они сидели по полтора часа.
Потом сотрудники приходили ко мне на встречи один на один и спрашивали: «Ир, что происходит?» Они сами злились на то, что помогали коллеге.
Почему они на это велись? Как я уже говорила, мы все хотим быть экспертами в какой-либо области. Манипулятор дарит человеку эту возможность: «Держи. Ты гуру в этой области. Раз ты умный, ты и делай». В результате человек начинает работать за двоих или троих.
Чем это опасно? Сотрудник тратит уйму времени на помощь коллеге, расходует свой экспертный ресурс и совершенно не развивается.
Чтобы с этим справиться, мы перевели помощь через своеобразный процессный фильтр и ввели в команде правило. Если запрос занимает от 15 до 30 минут, можно созвониться и обсудить его. Если требуется больше времени, запрос нужно оформить в виде задачи.
Когда мы структурируем запрос в виде задачи, это отсеивает лень у того, кто просит помощи. Он должен написать, что уже сделал, с какими блокерами столкнулся, с кем поговорил и что предпринял для решения задачи.
Кроме того, запрос становится видимым для руководителя проекта, потому что появляется в системе учета в виде отдельной задачи. Сам проситель начинает расти, поскольку перестает паразитировать на команде и ресурсах коллег.
Психологический кейс №2. Игра в судью
Следующий психологический случай я назвала «Игра в судью».
Я работала на проекте с очень серьезным Legacy. Это было около четырех лет назад, и тогда нанять сеньор-разработчика было непросто. Наконец мы нашли такого человека, обрадовались и привели его на проект.
На Code Review опытный сотрудник, который стоял практически у истоков проекта, использовал уничижительные и немного пассивно-агрессивные комментарии: «Слушай, а ты точно сеньор? Мы вообще-то здесь код пишем вот так».
Такие фразы критиковали не код, а личность. Здесь звучали чистый газлайтинг и профессиональный снобизм. Подобные высказывания ставят под сомнение само право человека находиться в команде. Новичок, который еще не проработал и месяца, начинает думать: «А точно ли я сеньор? Может быть, я обманываю сам себя?»
Такие сотрудники либо сами уходят в токсичность, после чего начинается открытый или скрытый конфликт, либо увольняются. Результат для нашей команды был довольно плачевным: примерно через два месяца сотрудник просто ушел, потому что не смог так работать. Это был настоящий провал.
Мы начали работать над проблемой поздно, но все-таки провели работу над ошибками.
Мы обратились к регламентам и стали составлять чек-листы того, что принято на проекте и что считается для нас нормой: как устроена культура кода, как мы пишем код, что считаем хорошим, а что – неприемлемым. Благодаря этому мы избегаем оценки личности и ссылаемся на конкретный стандарт из регламента.
Кроме того, мы ввели для сотрудников шаблоны обратной связи. В них прямо было написано: «Чтобы донести свою мысль, используй этот шаблон и подставь необходимые ключевые слова».
Многим людям это помогает, потому что не все умеют давать обратную связь и не у всех развит эмоциональный интеллект. Это нормально. Шаблоны и регламенты действительно могут помочь. Критика благодаря им переходит в профессиональное русло.
Психологический кейс №3. Инициация молчанием
Последний случай я назвала «Инициация молчанием». Он произошел на том же проекте. Вообще практически все свои примеры я собрала именно там.
К нам пришел новый системный аналитик. На встречах по проекту он пытался рассказать о подходе, который уже где-то внедрял. Я не помню, что именно это был за подход, но в данном случае это не так важно.
Более опытный аналитик, давно работавший на проекте, говорил ему: «Ты только пришел. Посиди пока, послушай. Исторически так сложилось, что тут поделать?»
Это очень разрушительно для новичка. Во-первых, происходит уничижение его опыта и квалификации. Во-вторых, команда продолжает вариться в собственном болоте и не может рассматривать новые подходы, потому что их просто никто не слушает: «Сначала поработай на проекте, освойся, а потом уже выступай с предложениями». Кроме того, такое поведение закрепляет неявную иерархию в команде, в которой новичок заведомо ничего не знает, а опытного специалиста обязан слушать.
В результате новичок либо просто перестает разговаривать с командой и делиться своим опытом, либо уходит. Инновации замирают.
С точки зрения индивидуальной защиты это довольно интересный пример. Безусловно, во время подобных манипуляций на встречах большую роль должен играть модератор. Модератор – это человек, который возвращает команду к цели встречи и к процессам.
Но наш новичок поступил очень интересно. Он использовал технику вопроса «А что, если?».
На многих тренингах и в материалах в интернете говорят, что в подобной манипулятивной ситуации нужно перевести внимание с доминирующего члена команды, который подавляет новичка, на остальных участников. Но на самом деле это не очень рабочая схема, потому что мы сами начинаем манипулировать другими людьми: «Поддержите меня, скажите что-нибудь».
Наш новичок использовал другую схему. Он сказал: «Вань, а что, если у меня уже был опыт в этой сфере и я могу им поделиться? Я могу рассказать, чем у нас это закончилось».
Это сработало как волшебная палочка. Доминирующий человек получил новые вводные и ответил: «Ладно, раз опыт есть, расскажи. Послушаем тебя».
Новичок получил право голоса, но при этом не нарушил иерархию, потому что доминирующему члену команды дали новые вводные. Наш страж порядка остался при своей позиции в иерархии.
Когда новый системный аналитик предложил свою идею, мы ее внедрили и адаптировали под реалии проекта. Идея оказалась здравой. Зря мы не слушали его раньше.
Личной защиты недостаточно
Все приведенные примеры красной нитью объединяет одна мысль: личные тактики защиты – это хорошо. Хорошо, когда человек умеет, словно в карате, отбивать манипулятивные приемы.
Но этот вопрос необходимо решать и системно. Если в командных процессах есть дыры, сотрудники, какими бы мастерами защиты от манипуляций они ни были, просто устанут. Подобная борьба съедает очень много эмоционального ресурса.
Как выстроить в команде систему, при которой манипуляции если не исчезнут, то по крайней мере начнут сходить на нет?
Я предлагаю три принципа перепрошивки:
-
Видимость нагрузки: мы делаем нагрузку понятной для команды и прозрачной для руководителя проекта.
-
Четкие шаблоны и протоколы.
-
Регулярные ретроспективы.
Видимость нагрузки
В первом случае я уже рассказывала о правиле, которое мы ввели в команде: если запрос занимает больше 15–30 минут, его нужно оформить в виде задачи.
Помощь становится видимой, а проситель учится структурировать запрос. Бывает, что, пока человек структурирует запрос, он сам находит решение.
Этот подход работает не только с просьбами о помощи, но и с любыми задачами в рамках проекта.
На изображениях приведен пример того, как мы оформляем задачи. У нас есть четкое структурированное содержание, которое мы обновляем по мере того, как разговариваем с разными людьми и получаем новые вводные. Есть человек, ответственный за задачу, и человек, который в настоящий момент над ней работает. Есть оценка по времени. Если мы выходим за ее рамки, становится понятно, что в команде что-то сломалось.
Возможно, это выглядит как большое количество административной работы. Возможно, так и есть. Но такая система очень помогает управлять командой. Для сотрудников, которые любят тихо пользоваться помощью коллег, она практически сводит такую возможность на нет.
Четкие шаблоны и протоколы
В нашей команде есть документ, который называется «Общие вопросы разработки». Над ним мы работали совместно с командой разработчиков.
По сути, мы зафиксировали, что принято в рамках конкретной команды и проекта: как мы пишем код, какой код пройдет ревью, а какой – нет.
Разработчикам больше не нужно изобретать велосипед. У них есть конкретные правила, на которые они могут опираться.
Кроме того, документ очень помогает при онбординге новичков. Мы сразу предлагаем им его прочитать. Они понимают, что принято в команде, и могут задавать предметные вопросы. Споры благодаря этому становятся конструктивными.
На изображении приведен пример того, как выглядит этот документ. Он может находиться где угодно: в Google Таблицах, Confluence или другой удобной для команды системе. Главное, чтобы команда работала над ним совместно.
Это живой документ. Он обновляется по мере того, как команда находит новые подходы и развивается.
Регулярные ретроспективы
Последний инструмент – ретроспективы. Причем не просто провели и забыли, а регулярные.
Мы привыкли воспринимать ретроспективу как анализ того, что было хорошо и что было плохо: наметили план и побежали дальше. Но при правильной организации ретроспектива может стать иммунитетом, в том числе от манипуляций.
Инструментов проведения ретроспектив бесчисленное множество. Но если мы хотим защищаться от манипуляций, нужно помнить, где они процветают. Они прекрасно работают там, где нет четких правил и все размыто.
Один из подходящих инструментов называется «Устав команды». Он хорошо работает в командах, которые только начинают собираться, например на старте проекта. Но его можно использовать и в командах, существующих уже давно. Более того, такой команде, как мне кажется, будет даже легче его сформулировать.
Устав команды – это договоренности о том, кто мы, куда идем, какие у нас ценности и роли. Это своеобразная командная хартия.
Когда мы формируем такой устав, у нас появляются четкие критерии взаимодействия в команде. Новый человек уже не сможет диктовать свои правила игры: «Петя, посмотри. Мы живем так. То, как работаешь ты, у нас не принято».
Устав команды может выглядеть совершенно по-разному и иметь разные форматы. Например, это может быть обычный ватман с нарисованными картинками, висящий в офисе.
Но при формировании устава важны регулярные ретроспективы. Регулярность зависит от команды: раз в спринт, раз в квартал или раз в полгода. Но такие встречи должны проводиться, потому что команде необходимо сверяться.
Команда меняется, она не статична. Поэтому устав должен дополняться. Это такой же живой документ, который формируется в зависимости от того, как команда движется по проекту.
Заключение
Манипуляции – это не всегда история о том, что кто-то является плохим человеком. Конечно, встречаются и такие люди, без этого никуда. Но по большей части манипуляции говорят о дырах в командных процессах.
Когда я говорю о манипуляциях, я не призываю отказаться от критики, перестать предлагать решения и помогать друг другу или закрыться в своей скорлупе. Я призываю делать все это в прозрачной системе. В системе, где помощь имеет цену и ценность, критика – стандарты, а идея – право голоса.
Культура без манипуляций – это не культура подозрений. Это культура ясности. Культура, в которой коллега может сказать «нет», и это не будет считаться проявлением некомандности или неправильного отношения. Отказ будет опираться на принятые в команде правила и договоренности.
Начать можно с малого – внедрить одно небольшое правило. Главное – начать.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
