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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А потом я понял одну важную штуку: пока не написал — не понял.

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

Я начал замечать это на работе. Когда готовишься к 1-to-1, пишешь ТЗ, готовишь КП — вдруг видишь: «О, тут дырка». Пока крутил идею в голове, всё казалось логичным. А когда перенёс на бумагу — стало ясно, что чего-то не хватает. Или наоборот: связал две вещи, которые раньше казались отдельными.

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

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

Есть пара правил, которые мне помогают:

— Пиши своими словами. Не копировать чужое, а объяснить, как понял сам.  
— Задавай вопросы прямо в тексте. «Почему я считаю так?», «А если наоборот?», «Что меня тут смущает?»  
— Не пытайся сделать идеально. Это черновик. Это процесс. Не публикация.

Я раньше думал, что письмо — это «последняя стадия». Что сначала идея, потом текст. А оказалось наоборот: письмо — это часть пути.

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

В IT-Agency мы стараемся работать по принципам «Джедайских техник» Максима Дорофеева. Одна из практик, которая хорошо прижилась в моём личном планировании, — это список задач «Когда-нибудь».

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

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

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

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

Почему я продолжаю вести «Когда-нибудь»
Для меня «Когда-нибудь» — это способ не перегружать оперативную память и в то же время уважительно относиться к своим идеям. Я не обязан всё сделать. Но я даю себе шанс к ним вернуться, когда придёт время.

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

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

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

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

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

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

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

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