Когнитивная нагрузка как метрика здоровья команды

Любой менеджер создаёт вокруг себя деятельность: agile-ритуалы, встречи, статусы, чаты, задачи в трекере и даже банально «быстрые вопросы на минутку».

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

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

Когнитивная нагрузка / mental workload — это объём ментальных усилий, которые люди тратят на процессы и коммуникации поверх самой работы. И это то, за чем менеджер обязан следить.

Что создаёт лишнюю нагрузку? Несколько ситуаций, где это не очевидно с ходу.

1️⃣ Бюрократия на входе

Вы хотите упорядочить задачи — и вводите форму из 10 полей перед созданием тикета. И внезапно задача из «перекрасить кнопку, вот макет» превращается в А4: описание, обоснование, риски, критерии, ссылки, согласования…

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

2️⃣ Большие общие встречи «чтобы все были в курсе»

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

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

3️⃣ Коммуникация расползлась в сотню чатов

Раньше чатов было 5–10, все друг друга знали, важное легко находилось. Потом чатов стало 100+, часть заброшена, часть живёт своей жизнью — но вы всё равно утром скроллите, чтобы не пропустить важное.

Это постоянная тревога «а вдруг я что-то пропустил». По ощущениям — мелочь. По факту — ежедневный налог.

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

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

Что обязан делать менеджер?

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

Иначе это просто шум!

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

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


А какие у вас есть советы на этот счёт, интересно послушать.

Кейс «Затягивание сроков?» — разбор

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

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

Я бы разложил кейс на два вопроса:
— что делать с новичком?
— что делать со «старичком»

1️⃣ Что делать с новичком

Новичок делает задачи примерно в 2 раза быстрее человека того же грейда. Это факт.

Тут легко сделать неправильный вывод «старичок слабее». Надо проверить гипотезы.

Гипотеза А: мы недооценили новичка на входе

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

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


Гипотеза Б: сравнение «нечестное»

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

Тут надо честно взглянуть на наборы задач и постараться выровнять их. То есть догрузить новичка и снять задачи со старичка.


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

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


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

И это ваша работа.


2️⃣ Что делать со «старичком»?

Допустим что все же вы склонны к варианту, что «старичок» заскучал, расслабился, привык. Увольнять? Почти никогда такие увольнения не бывают верным решением — особенно если роль уникальная и человек носит критичный контекст.

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

Важно: «мы планировали повысить» ≠ «обязаны повысить».
Повышение — это подтверждение соответствия ожиданиям следующего уровня, а не награда за стаж или уникальность.


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



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

Тимлид не тимлид? Разбор

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

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

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

К сожалению, в этой ситуации есть два быстрых выхода и один медленный.

И да, «медленный» — это тот, про который многие написали, и его любят, потому что он выглядит гуманно.

1️⃣Медленный путь: учим, растим, наблюдаем

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

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

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


Прежде чем обсуждать быстрые пути давайте поймем какую проблему мы решаем и какие у нас цели (Саша, привет 😉):
— не потерять delivery (пока вы всё чините)
— не потерять людей (у вас уже один на грани ухода)
Где у нас болит больше и что приоритетнее в моменте?

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

Если KPI/метрик нет — ок, берёте суррогаты типа: план/факт, переносы, время в ожидании, дефекты/переделки, количество «срочно» и «пожаров».

И далее будет понятно каким путём идти.

2️⃣. Быстрый путь №1: убираем лида

Этот путь не про вышвырнуть человека на улицу, а про то чтобы развести роли. Главное у вас ведь был и есть сильный инженер / дизайнер / ктоонувастам, А проблемы лидства и процессов вы вполне можете на время закрыть сами.

Этот путь почти всегда правильнее, если:
— команда буксует по факту, а не «по ощущениям»
— нет прозрачности, делегирования тоже нет, bus factor = 1
— человек защищает монополию («без меня вы все утонете») и не готов менять модель управления и себя
— есть высокий риск ухода людей (и он уже проявился)

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


3️⃣. Быстрый путь №2: верим лиду и перестраиваем команду под него

Да, это тоже рабочий вариант. Но только если есть основание верить не харизме человека, а фактам. В чём отличие от пути 1️⃣? В том что окончательность решения вы сразу же проговариваете команде.

Когда это разумно:
— есть цифры и по ним команда хорошо идет
— стейкхолдеры довольны

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

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


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

Никаких компромиссов. Беспроигрышные переговоры с экстремально высокими ставками. От топ-переговорщика ФБР

⭐️ О чём книга?

Это книга Криса Восса — бывшего переговорщика ФБР по кризисным ситуациям. В биографиях его часто описывают как человека, который вел переговоры с похитителями, грабителями банков и террористами

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


⭐ Мысли из книги

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

▫. «Как я могу это сделать?» и «Всё правильно»

Пожалуй, две ключевые фразы, которые я вынес из книги.

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

Например: вы хотите купить автомобиль за 4 млн, но у вас есть только 3.8 и кредит вы не хотите. Вместо «Я готов заплатить 3.8, по рукам?» или «Может дадите скидочку?». Вы говорите: «Цена чуть выше, чем я рассчитывал…» — и дальше ключевое: «Как я могу купить этот автомобиль?»
Вместо позиционной войны вы приглашаете человека искать решение.

«Всё правильно» — важный маркер. В оригинале это That’s right, и Восс противопоставляет его You’re right (“вы правы”), потому что “you’re right” нередко означает «да-да, ты прав, только отстань», а “that’s right” — «да, ты меня правильно понял». Поэтому цель переговоров — не «да», не кивки и не «вы правы», а ощущение у человека, что его действительно услышали.

Здесь я привожу английские варианты, потому что не уверен что «всё правильно» верный перевод, моё личное ощущение что в быту мы чаще говорим «всё верно»


▫. К переговорам нужно всегда готовиться

Мысль не новая, но когда её говорит человек с таким опытом — она звучит убедительнее.
— соберите факты
— поймите, что важно другой стороне
— накиньте сценарий (план А → Б)
— и только потом идите в разговор


▫. Ярлыки, зеркалирование, молчание

Ярлык (labeling) — словами назвать эмоцию/состояние оппонента:
«Похоже, для вас это важно», «Похоже, вас раздражает срок», «Кажется, вы переживаете за риски».
Если попали — получите «всё правильно». Если нет — человек часто сам уточнит, что на самом деле происходит.

Зеркалирование (mirroring) это про то, чтобы повторять последние 1–3 слова собеседника с любопытствующей интонацией, чтобы он продолжал говорить и раскрывал детали (тут грех не вспомнить ситуацию про активное слушание из ТБВ)

И да: лучшее, что вы можете делать в переговорах, — молчать и слушать. Этот навык полезен всем руководителям.


▫ . Чем сложнее переговоры, тем медленнее вы идёте к результату

Иногда переговоры выигрываются не аргументом, а тем, что вы выдержали темп.

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


⭐ Мои впечатления

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


Оценка книги: 9.5/10

Остальные обзоры книг доступны по тегу #книгобзор@teamleading

Три типа когнитивной нагрузки

Продолжаю копать тему когнитивной нагрузки (CLT — Cognitive Load Theory) и наткнулся на статью Альтеа Камински на Learning Scientists. Она кратко пересказывает модель Свеллера о том какая бывает когнитивная нагрузка, а именно встроенная / внешняя / полезная.

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

1️⃣ Встроенная (intrinsic)

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

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

Пример из разработки:
— переименовать поле — почти всегда низкая встроенная нагрузка.
— спроектировать миграцию + обратную совместимость + несколько интеграций — высокая.


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

2️⃣ Внешняя (extraneous)

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

Пример из статьи:
готовить ужин на своей кухне и на чужой — разные по когнитивной нагрузке задачи при схожей формулировке.

Примеры из разработки:
— требования к задаче размазаны по 5 чатам, нет единого источника правды;
— CI иногда падает;
— смена контекста каждые 10 минут,
— митинги ради митингов.

Это всё не добавляет ценности — только ест мозг. Поэтому с этой нагрузкой всегда надо искать пути уменьшения.

3️⃣ Полезная (germane)

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

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

Ещё примеры:
— написать краткую доку «как это работает»,
— сделать чек-лист,
— вынести решение в ADR,
— покрыть тестами то, что постоянно ломается,
— разобрать инцидент так, чтобы он не повторился,
— купить ёмкости для круп и подписать их с помощью эмбоссера (а то что мы всё про работу)


Зачем всё это знать?

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

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

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

В конце я вернусь к книге Барбары Оакли и дам то что у меня хорошо работает в пункте 3️⃣: выходите иногда проветриться без наушников и просто гуляйте.