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

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

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

А на вопрос, зачем было доводить до этого, иногда отвечают: «Не нравится — уволим. За забором очередь».

Очередь из резюме — не очередь из готовых замен

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

Часть этого должна быть записана. Если не записана — процесс действительно плохой. Но увольнение не чинит процесс. Оно просто убирает из компании человека, который пока ещё помнит ответы.

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

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

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

Я не против увольнений. Я против магического мышления

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

Вопрос в другом: мы увольняем человека за его результат или пытаемся увольнением исправить криво собранную работу?

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

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

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

Пока команда молчит, руководителю кажется, что всё нормально

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

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

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

Хронический рабочий стресс не остаётся только личной проблемой сотрудника. ВОЗ описывает выгорание через истощение, дистанцирование от работы и снижение профессиональной эффективности. Для прода важен практический результат: уставший человек позже сообщает о риске, избегает лишнего спора и чаще работает самым знакомым, а не самым разумным способом.

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

Что я бы проверил до решения об увольнении

Мне нравится старая модель GRPI Ричарда Бекхарда: цели, роли, процессы и отношения. Её удобно использовать не как красивую схему для презентации, а как порядок вопросов. Краткое описание модели есть в материале INSEAD.

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

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

Дальше — процесс. Где хранятся доступы, как передают сервис, кто разбирает ошибки, куда эскалировать риск? История с паролями на личных ноутбуках провалилась именно здесь.

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

После этих вопросов решение вполне может остаться прежним. Зато оно будет принято не из раздражения и не из веры в бесконечный рынок кандидатов.

Уволить можно быстро. Заменить — не всегда

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

Но пока такой системы нет, зависимость уже существует — даже если её не видно в штатном расписании.

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

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