Как давать фидбэк команде

Первое, что стоит сделать, — забыть про бутерброды и прочие странные техники, которым до сих пор кто‑то учит. Там в основе идеи замаскировать проблему чем угодно, чтобы запутать того, кому вы фидбэк даете, кажется, что не то, что нам нужно. Начнём с понимания: зачем вообще нужен фидбэк?

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

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

Какие варианты действий
1. Сказать Пете, что он туповат и игнорирует базовые инструменты. Максимум, чего мы добьемся, — оборонительной реакции. В худшем случае Петя решит, что туповат его руководитель, и просто уйдёт.
2. Можно ставить задачи Пете. Но тут проблема: у вас же ещё Никита, Кирилл, Максим и Вова, которые, кстати, справляются с тем, чтобы свои задачи по своим проектам не терять. Замыкать систему на себе и создавать боттлнек тоже кажется неразумным, да и с ответственностью за задачу тут явно что‑то не то.
3. Можно дать фидбэк сразу после факапа. Без ярлыков объяснить, к чему приводят потерянные задачи, показать, что «думать и помнить» одновременно тяжело, и предложить решение — вести календарь. Затем помочь разобраться с инструментом, если понадобится.

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

Что такое HHIPP
1. Helpful (полезно). Фидбэк должен помочь, а не унизить.
2. Humble (без высокомерия). Иногда легко скатиться в позицию учителя и показывать, какой вы опытный и умный. Тут важно, что вы не демонстрируете своё превосходство, а искренне хотите помочь именно Пете.
3. Immediate (сразу). Обратная связь даётся как можно ближе к моменту совершения ошибки. Не нужно откладывать обратные связи в папочку и ждать one-to-one, который вы раз в месяц проводите, пользы будет мало.
4. In‑Person (лично). Лично, говорят, что лучше очно, но можно приватном видеозвонке.
5. Not Personal (основываемся на фактах). Разбираем конкретное действие и его последствия, не присваиваем характеристики Пете, даже, если сильно хочется.

Что делаем, если видим, что у Пети появляется проблема?
1. Двухминутный разговор. После встречи с клиентом приглашаете Петю на короткий колл: «Есть минутка обсудить задачу?» Дальше — факт, последствие, вопрос, договор.
2. Действие и последствия. «Задача потерялась, из‑за этого клиент сдвигает релиз. Думать и помнить одновременно сложно: либо теряешь фокус на текущей работе, либо забываешь то, что вне поля зрения».
3. Договоренности и ресурсы. Петя сам исправляет ошибку: до завтра переносит все задачи в календарь. Вы при необходимости даёте инструмент, гайд или оплачиваете курс по тайм‑менеджменту :)

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

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