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

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

Почему так происходит? Это не глупость и не слабость. Исследования показывают: туннельное зрение — естественная реакция на стресс. В работе Staw, Sandelands & Dutton (1981). “Threat rigidity effects in organizational behavior” описано, что под давлением люди начинают действовать привычнее, меньше обсуждать альтернативы, больше слушать лидера. Команда становится сплочённее, но теряет гибкость.

Эллен Лангер в книге “Осознанность” (1989) тоже говорит об этом. Она провела эксперимент: участникам показывали одно и то же видео. Половине сказали, что на видео — пациент. Другим — что врач. Первые видели неуверенного человека, вторые — уверенного и профессионального. Хотя на видео была та же сцена. Просто одна фраза задала рамку. Люди начинали замечать детали, которые «подтверждали» их рамку, и игнорировали остальные. Это и есть эффект туннельного зрения: мы видим не реальность, а то, что влезает в рамку.

Даниэль Канеман в “Думай медленно… решай быстро” называет это узким кадрированием. Люди оценивают каждое решение изолированно, не видя общей картины. Например, инвесторы смотрят на каждую сделку отдельно, а не как часть портфеля. Из-за этого либо перестраховываются, либо рискуют без нужды.

Туннельное зрение возникает в нескольких ситуациях:
— когда есть давление или угроза. Например, падают продажи, и все силы уходят на пожарное тушение, а про долгосрочные планы забывают;  
— когда руководитель централизует все решения. Люди перестают предлагать новые идеи — все ждут указаний сверху; 
— когда задачи формулируются слишком узко. Например, KPI про «увеличить лиды на 30%» превращается в навязчивую цель, и никто не думает, а какие лиды нужны и куда они потом денутся.

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

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

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

В такие моменты хочется махнуть рукой и взять задачу на себя. Сделать быстро, сделать как надо. Но именно здесь начинается ловушка: если делать за младших, они не учатся работать сами. Они привыкают, что их спасут.

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

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

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

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

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

Разберём на примере, что если руководитель отдела будет уволен за ошибку (скажем увод бюджета отдела в минус). Как это в итоге отразиться на команде, и почему со временем лучшие сотрудники команды разбегутся. Даже если руководитель этого не хотел.

Для объяснения как это работает буду использовать «Теорию ожиданий Врума» (1964) и метаанализ по «Теории ожидания» от Эрде и Тьерри (1996).

Попробую не душнить, но начнём с теории. Мотивация по Вруму зависит от трёх фактров:

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

Допустим, руководителю сказали сделать ×5 выручки за год, с определенной маржой.

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

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

А если премия не ценна для этого руководителя, то он откажется от этих рисков и не пойдет в эту историю (валентность).

То есть если что-то ломается в цепочке «усилия → результат → вознаграждение», то результата не будет.

Метаанализ, который провели Эрде и Тьерри, показывает как это работает на практике. Они провели метаанализ по 77 исследований и 12 000 участников. Вот что откопали:

1) Ожидание сильнее всего влияет на производительность.
2) Инструментальность лучше предсказывает удовлетворенность и текучесть кадров.
3) Валентность слабо влияет на поведение, но сильно влияет на выбор работы. То есть люди идут туда, где вознаграждение для них ценно.

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

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

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

Будет выдерживать максимальную возможную маржу по проектам, с минимальными человеческими ресурсами. Грубо говоря это приведёт к перегрузу команды.

А перегруз команды приведёт к снижению мотивации и текучке кадров. Сотрудники видят, что:

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

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

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

Во времена СССР, когда ставили жесткие условия по выполнению KPI, красные директора начали дословно выполнять поставленные задачи. Надо сделать больше м² стали, то её начинали делать более тонкой, и таким образом материала хватало на больше количество м². Это тот же принцип.

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

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

К сожалению, одной теории все действия не объяснить.

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

Есть «Теория агентских издержек», когда ТОПы хотят идеальных результатов, а руководители начинают «играть в отчётность».

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

Если интересно, могу по каждому рассказать. :)

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

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

Допустим, у нас есть джун, которому поставили задачу подобрать семантическое ядро по процедуре УЗИ. Ставить такую задачу будет либо старший, либо мидл. В момент постановки задачи, они опишут понимание (для джуна понимание сформировать сложно, не хватает насмотренности), и отдают его на джуна. Если джун говорит: «Я всё понял, пошёл делать», значит ответственность за задачу делегирована, теперь это ответственность на джуне.

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

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

Пока я вижу только такой путь, как избежать этой ситуации:

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

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

Бывало такое, что к тебе приходил руководитель и что-то ультимативно делал?

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

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

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

А еще такое происходит, потому что у руководителя эго бежит впереди него. Он принимает такое решение, потому что считает что он прав в этом вопросе. И с кем-то это обсуждать — это терять время.

Решать все вопросы самолично — это не командная работа. Доверие к такому руководителю падает. Не надо так делать.

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

Безусловно для руководителя такая роль удобная. Можно всегда говорить, что без него бы всё развалилось. Что он единственный кто всё контролирует.

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

Знаете какая самая большая боль, которую ты испытываешь, когда становишься руководителем направления?

Качели. Ты нашёл клиента (продал проект), и у тебя перегружена команда (а бывало, что я и сам в производстве всё разгребал). Что делать в таком случае?

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

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

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

Практически во всех компаниях не хватает людей, которые могут с 0 сделать 1. Мы таких людей растим внутри команды.

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

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

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

Суть в том, что делать все не руками, а силами команды. Если бы делал сам, то за неделю создал бы 1 КП. А с командой может сделать 5 КП,

К примеру, по сборке КП. Младшие собирают информацию, мидлы формируют само КП. Старшие или ведущий вносит комментарии и правки как заказчик.

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

Сегодня хочу рассказать про ответственность и как эта ответственность у нас делится по ролям.

У нас в компании есть линейка специалистов: младший (младший джедай) → мидл (джедай) → старший (старший джедай) → ведущий (ведущий джедай) → руководитель дивизиона.

У каждого ранга своя ответственность:
— Младший → отвечает за задачки на проекте. Его ответственность, чтоб задачи были сделаны хорошо и точно в срок.
— Мидл → отвечает за проект. Его ответственность, чтоб на проекте была позитивная динамика в показателях и чтоб проект продлялся. При этом мидл работает с задачами, но ему может помогать младший.
— Старший → отвечает за портфель проектов. Его ответственность — это портфель проектов.
— Ведущий → отвечает за портфель проектов, команду, процессы.
— Руководитель → отвечает за все портфели ведущих, команду, процессы, решает управленческие процессы, которые пока невозможно передать на ведущего.

Про ответственность старших

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

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

Так же старший начинает активно работать с пресейлами → проводить первые встречи, готовить презентации, расчёты и презентовать итоговые расчёты.

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

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

Про ответственность ведущих

Ведущие — это наставники (ведущий — от слова ведёт). Три важных задачи ведущего:

— Растить как можно больше мидлов, старших и ведущих → люди растут только тогда, когда берут большую ответственность и справляются с этой ответственность.
— Увеличивать портфели проектов старших → участвовать в продажах, помогать старшим в стратегиях.
— Улучшать продукты и процессы → продукт должен быть как можно дешевле и качественнее для клиентов. Мы должны зарабатывать для клиента больше, чем он тратит на нас.
— Участвовать в маркетинге и строить персональный бренд → Какие бы крутые мы ни были, как бы круто мы не работали, на определенном развитии компании сарафанного радио не хватает, поэтому компании для увеличения роста нужно помогать с маркетингом: выступать, вести блог, писать статьи и кейсы и т. д.

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

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

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

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

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

Если через 1-3 месяца становится понятно, что решение было ошибочным, то просто откатываю его и на основе новой полученной информации принимаю новое решение.

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

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

Поэтому кроме внешней обратной связи нужно формировать внутреннюю обратную связь.

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

Так формируется циклический подход:

Сделали сильную работу → посмотрели, как работа откликнулась на общей цели (есть ли положительная динамика?) и соответствовала ли ценности.

Сильная работой может быть разной по сложности:

— Для джуна — на уровне задачи.
— Для мидла — на уровне проекта.
— Для сеньора/лида — на уровне портфеля проектов и команды.

Каждое решение, которое мы принимаем ежедневно имеет последствия:

— Запустили новую гипотезу → эта гипотеза дала уменьшение CAC → выполнить KPI стало еще проще.
— Запустили новую гипотезу → потратили 26 000 ₽ и поняли что эта аудитория или креатив не дают отклика даже близко к среднему → выстроили еще несколько гипотез и записали в базу знаний проекта, почему по нашему мнению эта гипотеза не сработала.

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

Это как с лампочками Томаса Эдисона. Он провёл около тысячи опытов, чтоб найти одну единственную лампочку, которая имела идеальные для него характеристики.