Часто в командах появляется человек, который умеет вытаскивать релизы в последний момент, быстро закрывать инциденты и держать весь контекст в голове. Это удобно: кажется, что проблема решена. Но стоит этому человеку уйти в отпуск или выгореть, как система даёт трещину: процессы останавливаются, сроки сдвигаются, и все удивляются, почему всё сломалось.
Почему так происходит
- Людей поощряют за быстрые и заметные результаты.
- В спешке документация и процессы остаются «на совести» эксперта.
- Остальные члены команды привыкли не вмешиваться в «важную» область. Пусть делает профи.
Чем это плохо — три основных эффекта
- Уязвимость: если герой недоступен, возникает кризис.
- Потеря роста у коллег: никто не учится, потому что «важное» всегда решает герой.
- Иллюзия контроля: менеджер думает всё под контролем, но не видит скрытые риски.
Как выглядят ответственность и еёпередача
Ответственность, это не просто набор задач. Это зона влияния: за что человек отвечает, какие результаты ожидаются и в каких пределах он может принимать решения.
Передача ответственности , это процесс обучения, тестирования и подтверждения результатов. Ниже - практические шаги.
Пошаговый план передачи ответственности
Шаг 1. Карта знаний и обязанностей
• Составьте простую карту: кто умеет что, кто решает какие проблемы.
• Оцените «bus-factor»: сколько людей должны уйти, чтобы область перестала работать?
Шаг 2. Малые передачи, сначала простые кейсы
• Выберите несложный, но значимый компонент для передачи.
• Организуйте парное сопровождение: герой + новый владелец на 1–2 спринта.
• Согласуйте критерии успеха: что будет означать «успешная передача».
Шаг 3. Контроль и обратная связь, не как статус-чек, а как поддержка
• Статус берите из инструментов: CI, мониторинг, тикеты.
• Встречи используйте для обсуждения блокеров и знаний, а не для перечисления статуса.
• Оценивайте процесс: как человек справляется с новой зоной ответственности, какие методы применяет.
Шаг 4. Делегирование как рост, дайте право на ошибку
• Люди боятся ошибиться , это естественно.
• Пропишите условия безопасной ошибки: малые эксперименты, откатные планы, быстрый разбор ошибок без штрафов.
• Обязательно разбирайте ошибки с фокусом на уроки, а не на поиск виновных.
Какие метрики помогают понять прогресс
• Доля задач в критических областях, закрытых не-героем.
• Время восстановления системы при отсутствии основного владельца.
• Количество уникальных людей, способных выполнить критические операции.
Эмоции и управление изменением
Герои боятся потерять влияние; коллеги боятся ответственности; менеджеры боятся потери контроля.
Решение: говорить об этих страхах открыто и объяснять, что передача ответственности, это не понижение ценности, а трансформация роли: из пожарного в наставника/стратега.
Вознаграждайте тех, кто учит других: признание и карьерные стимулы важнее, чем просто похвала.
Частые ошибки и как их избежать
- Начать сразу с больших фрагментов. Правильно: маленькими шагами.
- Не дать поддержки после делегирования. Правильно: pairing, код-ревью, доступ к документации.
- Игнорировать эмоциональную сторону. Правильно: обсуждать страхи и ожидания.
Как понять, что вы добились результата
• Команда решает критические задачи без постоянных запросов к одному человеку.
• Новые инженеры быстрее вовлекаются и получают опыт.
• Менеджер видит прогнозируемую стабильность, а не кризисы каждую неделю.
Бороться с героизмом — значит строить систему: процессы, документацию, зоны ответственности и культуру, где люди развиваются. Это дорога от случая и удачи к предсказуемому росту и устойчивости продукта. Результат: команда, которая не ломается при отсутствии отдельных людей, а растёт вместе с продуктом.
Если вы хотите продолжить тему и получать короткие практические заметки — подпишитесь на мой Telegram-канал: https://t.me/pavelsengineeringstuff — там я делюсь кейсами и шаблонами по управлению инженерными командами.