Первый раз, когда мне пришлось уволить человека, я репетировал речь в лифте. Три фразы, согласованные с HR. Четкие, человеческие, финальные. Слова были. А вот что делать с руками, куда смотреть, когда лицо собеседника изменится, и как потом пройти через опенспейс мимо тех, у кого работа осталась, — этому инструкция не прилагалась.
Я отсидел остаток дня, уткнувшись в монитор, и ушел пораньше. Эта история сидела во мне месяцами. Но именно она сделала меня гораздо более жестким и внимательным нанимающим менеджером. Не вдохновляющая метафора, а голая конкретика: в следующий раз, когда пятеро коллег уговаривали себя взять «вроде бы нормального» кандидата, я говорил «нет». Потому что телом знал, во что обходится это «вроде бы» через двенадцать месяцев.
Тема этого текста — не боль. Тема — дистанция до последствий.
Боль — это прокси, а не действующее вещество
Есть популярная версия этого аргумента, и она опасна своей половинчатостью. Звучит она так: чтобы учиться, нужно страдать. Компании стали слишком мягкими, а настоящий рост происходит, когда ты ощущаешь всю тяжесть своих ошибок. No pain, no gain.
Я понимаю, откуда это берется. Но «нужна боль» — неряшливый заменитель более точного механизма. И эта неряшливость дает прикрытие руководителям, которые ломают людей под соусом «закалки».
Меня научило не страдание. Страдание было побочным эффектом. Научило меня короткое расстояние между моим решением и его результатом. Я нанял небрежно — мне же пришлось это расхлебывать. Петля замкнулась быстро и близко, так что отвернуться не получилось.
Уйма боли не учит вообще ничему. Публичное унижение учит прятаться. Шестидесятичасовая гонка учит ненавидеть тех, кто ее устроил. Тревога учит избеганию. Это не обучение. Это издержки без приложенного урока.
Точная формулировка такая: люди учатся через близость к последствиям своих решений. Боль иногда — побочный эффект этой близости. Она не действующее вещество, и оптимизировать систему под боль — ошибка.
Вина и дистанция — два разных рычага
Почти любой разговор в индустрии об ошибках скатывается в одну плоскость: blame vs blameless. Мы спорим, называть ли имя инженера в постмортеме, увольнять ли за аварию, не сделала ли психологическая безопасность всех бесхребетными.
Неверный спор. Рычагов здесь два, а не один.
Первый рычаг — вина: сколько персональной ответственности и наказания мы привязываем к провалу. Второй — дистанция: как далеко человек сидит от последствий того, что сделал. Мы сварили их в голове, будто снижение вины требует увеличения дистанции. Это не так.
Можно провести абсолютно blameless-разбор, где инженер, выкативший баг, сидит в комнате, слышит, что именно случилось с живым клиентом, проговаривает вслух свою логику и забирает follow-up. Вины — ноль. Близости — максимум. Это рабочий квадрант, доступный любому, кто захочет.
Что происходит в реальности во многих «зрелых» организациях — другое. Мы выкручиваем вину в ноль и одновременно отодвигаем дистанцию на максимум, а потом хвалим себя за первое и не упоминаем второе. Баг становится «инцидентом». Инцидент — «уроком». Урок — тикетом. К моменту оформления он имеет эмоциональную текстуру сводки погоды. Никого не обвинили. Никто и не изменился.
Исходная blameless-идея, версия Etsy и Google SRE, никогда не утверждала обратного. Она говорила: не наказывайте за честные ошибки, потому что наказание заставляет прятать информацию. Это верно. Но она ничего не говорила про изоляцию от последствий. Эту часть мы добавили сами, потому что она удобная.
Держите людей близко к последствиям
Если близость — действующее вещество, то задача руководителя не причинять боль и не убирать её. Задача — защищать сигнал. Держать людей рядом с тем, что делают их решения, и убирать шум, который заставляет прятаться.
Тяжелый разговор проводите лично
Когда нужно сказать сотруднику, что его результаты не работают, что поведение на стендапе неприемлемо или что его роль сокращена, — будьте тем, кто в комнате. Соблазн отдать это на аутсорс огромен и растет. Есть HR-партнер, который «проведет беседу». Есть скрипт. Все чаще — видеозвонок.
Говорить в веб-камеру — значит вырезать ровно ту часть, которая учит. Дискомфорт личного разговора — не дефект, который надо устранить. Это и есть обратная связь. Это то, что заставит вас нанимать тщательнее и давать обратную связь раньше в следующий раз. Уберите это — получите менеджера, который раз за разом делает одну и ту же ошибку найма и ничего не чувствует в финале.
Цель — не сделать эти разговоры травматичными. Не набить руку до онемения. Лучшие руководители, которых я знаю, со временем чувствуют их легче не потому, что зачерствели, а потому, что сделали всю работу на входе. Наняли правильно. Дали жесткую обратную связь рано, когда она еще могла что-то изменить. Не дали ситуации гнить год. Близость сделала их лучше, а мастерство снизило боль. Онемение от избегания и спокойствие от компетентности выглядят одинаково снаружи, но это не одно и то же.
Код и живой клиент
Лучшее, что я видел для качества кода, — не процесс. Это клиент на звонке, своими словами и со своей злостью описывающий выходные, потраченные на чистку данных из-за бага, который выкатил кто-то из команды. Это ощущение не получить из алерта в Sentry. Фраза «пострадала часть клиентов» спроектирована почти идеально, чтобы защитить вас от любого обучения. Настоящие имена, живые голоса, реальные последствия. Вот что заставляет команду держать планку качества дольше, чем это удобно.
Дежурства без подстраховки
On-call — чистейшая версия этой логики. Ты пишешь — ты носишь пейджер. Когда те, кто пишет код, — те же люди, кого этот код будит в три часа ночи, петля замыкается сама. Никаких плакатов с ценностями не нужно. Разделите эти две группы — одна команда поставляет, другая держит пейджер, — и вы построили машину по производству того, с чем никому не придется жить.
Не «спасайте» проект собой
Последнее — про вас, не про команду. Когда проект начинает шататься, соблазн влететь и починить всё самому огромен. Ощущается как лидерство. На деле — верный способ навсегда отдалить команду от её собственных последствий. Они не чувствуют вибрации, поэтому не учатся рулить. Я делал так не раз. В моменте это всегда выглядит как щедрость, а через год — как команда, неспособная работать без меня в комнате.
Машина дистанции почти невидима
Вот что делает задачу по-настоящему сложной. Почти никакая дистанция в современной организации не добавлена специально, и почти вся она добавлена по хорошей причине.
Фича-флаги — это хорошо. А еще это слой между вами и радиусом поражения от плохого изменения. Поэтапные выкатки — отлично. А еще это значит, что сломанное вами ловит система, а не яростное письмо с вашим именем в строке «Кому». Blameless-культура — правильно. Сделанная лениво, она становится ритуалом, чья реальная функция — убедиться, что никто ничего не чувствует. Удаленка хороша по сотне причин. Она же превращает самые трудные человеческие моменты работы в то, что делается через экран — то есть плохо.
Я не призываю всё это отменить. Это был бы свой собственный театр жесткости. Смысл в том, чтобы заметить: дистанция накапливается по умолчанию, тихо, одно разумное решение за другим, и замечать это — ничья работа. Значит, она становится вашей.
Когда вы находите место, где команда полностью изолирована от результатов своей работы, — это не признак здоровой системы. Это утечка в петле обратной связи. Вы должны как минимум знать, что утечка есть. Эксперты оценки персонала часто сталкиваются с тем, что руководители искренне не замечают, как выстроенные ими процессы экранируют сотрудников от реальности.
Открытый вопрос про ИИ
Оставлю это как вопрос, потому что не думаю, что у меня есть ответ.
Самая большая машина дистанцирования, которую я когда-либо видел, устанавливается прямо сейчас всеми нами. Когда инженер пишет функцию, он владеет ею, и когда она ломается, он чувствует натяжение этого владения. Когда он принимает функцию, написанную ИИ, что-то смещается, чему мы пока не придумали названия. Код прошел ревью. Скомпилировался. Он никогда не был по-настоящему «его».
Если близость к последствиям — это то, что превращает опыт в суждение на протяжении карьеры, что произойдет с поколением, чье отношение к большей части кода — «приемка», а не «авторство»? Возможно, ничего. Возможно, суждение найдет обходной путь. Но я бы хотел, чтобы каждый лидер, внедряющий это на скорости, хотя бы посидел с этим вопросом. Потому что дистанция добавляется так же, как всегда: по хорошим причинам, по умолчанию, без ответственного за наблюдение.
Практические рекомендации
- Проведите аудит «петель обратной связи». Возьмите три ключевых процесса в команде (найм, поставка, инциденты) и честно запишите, через сколько рук и систем проходит информация о последствиях, прежде чем дойти до того, кто принял решение. Если цепочка длиннее двух звеньев — вы нашли утечку.
- Откалибруйте разбор инцидентов. На ближайшем постмортеме задайте два вопроса отдельно: «Есть ли здесь чья-то вина?» и «Находится ли автор решения в этой комнате и слышит ли он последствия?». Ответ «нет» на второй вопрос при ответе «нет» на первый — тревожный звоночек.
- Верните голос клиента. Раз в квартал приводите на командную встречу живого пользователя (или включайте запись его разговора со службой поддержки), который столкнулся с результатом работы команды. Не дашборд, не метрику, а голос.
- Срастите разработку и сопровождение. Если команда разработки не несет ответственности за эксплуатацию своего продукта, запустите пилот по совмещению: хотя бы одну неделю в месяц разработчики держат пейджер. Эффект от корпоративного обучения закрепляется именно в таких практиках, а не в теории.
- Тренируйте «мышцу присутствия». В сложных разговорах (увольнение, отказ в повышении, жесткая обратная связь) не делегируйте их HR-у полностью. Ваше личное присутствие — не наказание сотруднику, а ваш собственный тренажер ответственности за предыдущие решения.
- Легализуйте «владение последствиями». Внедрите в командные ритуалы простой вопрос: «Кто что почувствовал/понял из того, что случилось на прошлой неделе?». Это смещает фокус с формального отчета на проживание результата.
Заключение
Настоящий рост запускает не страдание, а невозможность отвернуться. Руководитель, который прячется за скрипты, системы и чужие плечи, лишает себя единственного, что делает его решения лучше со временем, — короткой петли обратной связи.
Найдите места, где ваши люди защищены от того, что они делают. Часть этой защиты — милосердие, и его стоит сохранить. Но часть — просто дистанция, надевшая маску заботы. Научитесь отличать одно от другого. И оставайтесь в комнате.
Часто задаваемые вопросы
Чем «близость к последствиям» отличается от наказания?
Наказание — это искусственно добавленная боль за ошибку (штраф, выговор, увольнение). Близость к последствиям — это организация процесса так, чтобы человек сам увидел, услышал и прожил результат своего решения. Первое вызывает страх и сокрытие, второе — обучение и ответственность.
Как совмещать психологическую безопасность и близость к последствиям?
Психологическая безопасность — это право на ошибку без уничтожения карьеры. Близость к последствиям — это обязанность увидеть результат ошибки. Они не противоречат друг другу: вы можете не наказывать инженера за баг, но обязаны посадить его на звонок с пострадавшим клиентом.
Не приведет ли это к выгоранию сотрудников?
Выгорание вызывает хронический стресс от неопределенности, несправедливости и отсутствия контроля. Четкая, предсказуемая петля обратной связи, наоборот, дает чувство контроля и осмысленности. Проблемы возникают, когда близость к последствиям подменяют токсичной культурой «страдания».
Что делать, если сотрудник после близкого контакта с последствиями демотивирован?
Это нормальная первая реакция. Задача руководителя — не обесценивать её («соберись, тряпка»), а помочь отрефлексировать: «Что именно ты понял? Что в процессе привело к этому? Что ты сделаешь иначе завтра?». Демотивация без рефлексии — потеря, демотивация с рефлексией — точка роста.
Как быть с удаленными командами, где личное присутствие невозможно?
Видеозвонок — худший из доступных вариантов, но иногда единственный. Компенсируйте отсутствие физического присутствия максимальной детализацией последствий: включайте записи звонков клиентов, показывайте скриншоты реальных убытков, давайте голые цифры ущерба. Не заменяйте живой разговор безликим тикетом.
Применима ли эта концепция за пределами IT и разработки?
Абсолютно. В продажах — это совместный выезд к клиенту, который уходит к конкуренту. В HR — присутствие нанимающего менеджера при увольнении. В финансах — защита бюджета перед теми, чей проект урезали. Везде, где решение и его последствия разнесены по разным людям или отделам, работает один и тот же принцип.
