Сила не только в людях. Сила - в связях. (#пролюдей)
По итогам приличного количества услышанных историй про трансформацию команд, сложности и последствия, вот вам моя точка зрения, почему стабильные IT-команды работают лучше, и почему им иногда не нужно мешать.
В айтишечке, где технологии меняются быстрее, чем листья календаря, забывается одна простая истина: самое ценное в продукте — не код или эксплуатация систем, а команда, которая его пишет и поддерживает.
Имеем парадокс: команды из сильных инженеров, архитекторов и продактов не могут выйти на стабильный ритм и давать прогресс, в то же время другие команды без «звезд» стабильно выпускают качественные фичи, быстро реагируют на инциденты и даже радуются новым вызовам.
В чём разница? Не в технологическом стеке и не в уровне скиллов (хотя и в них конечно же тоже). Разница в качестве взаимодействия внутри команды. И это далеко не всегда про качественный менеджмент.
Тезис 1: Психологическая безопасность — основа высокой эффективности. Создать ее по распоряжению нельзя.
Google проектом Aristotle показал: ключевой фактор успеха IT-команд - психологическая безопасность. То есть среда, в которой разработчик может сказать: «Я не понял архитектуру», SRE - признать, что инцидент вызван его правкой, или продакт предложить откат фичи без риска быть низложенным.
Такая культура не создаётся за один ретро-дейли-груминг. Она выстраивается месяцами через доверие, открытость и тысячи незаметных сигналов: кто-то кому-то помог, где-то поддержал, где-то признал свою неправоту. Такие штуки формируют в некотором смысле социальный капитал команды, и его нельзя измерить или посчитать, но это ахрененно важный актив.
Тезис 2: Команды в IT не собираются. Они созревают. И делают это не со скоростью сахарной браги.
Г-н Койл в своем «Кульурном коде» выдал, что эффективные команды - это не временные проектные группы, а устойчивые социальные системы. В IT это особенно заметно: лучшие результаты показывают долгоживущие и стабильные команды, которые прошли вместе через кучу релизов, инцидентов, кризисов в конце концов.
Именно в таких коллективах складываются:
- единый язык общения (не только Python или Go),
- неформальные каналы координации («Я уже спрашивал у Тани — она в курсе»),
- высокая скорость принятия решений («Да, делай, мы доверяем»).
Эти патерны поведения нельзя просто так создать или взять и перенести в новую команду. Их можно только вырастить со временем и только совместной работой.
Тезис 3: Цена реорганизации - долгий спад после «оптимизации»
Частые перестановки разработчиков между командами, «перебалансировка нагрузки», смена тимлидов «для развития» - всё это выглядит логично на организационной схеме. На практике это практически всегда сброс прогресса на ноль.
Команда возвращается на стадию forming и storming (Такман не одобрил бы):
- снова учится доверять,
- восстанавливает коммуникацию,
- теряет скорость и предсказуемость,
- теряет участников.
Результат:
- Прогресса не видать, сплошные продолбы,
- Рост времени на вливание новых людей,
- Повышение количества ошибок,
- Снижение вовлечённости,
- Выгорание.
Скорость и надёжность зависят от слаженности, и такие решения могут стоить компании недель задержек и десятков инцидентов, особенно, если их не планировать как следует с учетом максимального количества рисков.
Итогом.
Лучшая стратегия для руководителя такого актива - не вмешиваться без острой необходимости. Трансформируй вокруг и встраивай то, что есть в то, что будет.
Если команда стабильно дает, что должна, быстро реагирует на инциденты и демонстрирует инициативу, пусть даже и не удовлетворяет отдельным требованиям - это не повод для реорганизации. Это повод для гордости.
Стабильность команды - это не инерция и признак застоя. Это конкурентное преимущество. Тот же г-н Койл выдал - "Лучшее, что вы можете сделать для своей команды, - это не вмешиваться, когда она уже нашла свой ритм". Что-то в этом есть, не так ли?
А на деле имеем, что имеем.
По итогам приличного количества услышанных историй про трансформацию команд, сложности и последствия, вот вам моя точка зрения, почему стабильные IT-команды работают лучше, и почему им иногда не нужно мешать.
В айтишечке, где технологии меняются быстрее, чем листья календаря, забывается одна простая истина: самое ценное в продукте — не код или эксплуатация систем, а команда, которая его пишет и поддерживает.
Имеем парадокс: команды из сильных инженеров, архитекторов и продактов не могут выйти на стабильный ритм и давать прогресс, в то же время другие команды без «звезд» стабильно выпускают качественные фичи, быстро реагируют на инциденты и даже радуются новым вызовам.
В чём разница? Не в технологическом стеке и не в уровне скиллов (хотя и в них конечно же тоже). Разница в качестве взаимодействия внутри команды. И это далеко не всегда про качественный менеджмент.
Тезис 1: Психологическая безопасность — основа высокой эффективности. Создать ее по распоряжению нельзя.
Google проектом Aristotle показал: ключевой фактор успеха IT-команд - психологическая безопасность. То есть среда, в которой разработчик может сказать: «Я не понял архитектуру», SRE - признать, что инцидент вызван его правкой, или продакт предложить откат фичи без риска быть низложенным.
Такая культура не создаётся за один ретро-дейли-груминг. Она выстраивается месяцами через доверие, открытость и тысячи незаметных сигналов: кто-то кому-то помог, где-то поддержал, где-то признал свою неправоту. Такие штуки формируют в некотором смысле социальный капитал команды, и его нельзя измерить или посчитать, но это ахрененно важный актив.
Тезис 2: Команды в IT не собираются. Они созревают. И делают это не со скоростью сахарной браги.
Г-н Койл в своем «Кульурном коде» выдал, что эффективные команды - это не временные проектные группы, а устойчивые социальные системы. В IT это особенно заметно: лучшие результаты показывают долгоживущие и стабильные команды, которые прошли вместе через кучу релизов, инцидентов, кризисов в конце концов.
Именно в таких коллективах складываются:
- единый язык общения (не только Python или Go),
- неформальные каналы координации («Я уже спрашивал у Тани — она в курсе»),
- высокая скорость принятия решений («Да, делай, мы доверяем»).
Эти патерны поведения нельзя просто так создать или взять и перенести в новую команду. Их можно только вырастить со временем и только совместной работой.
Тезис 3: Цена реорганизации - долгий спад после «оптимизации»
Частые перестановки разработчиков между командами, «перебалансировка нагрузки», смена тимлидов «для развития» - всё это выглядит логично на организационной схеме. На практике это практически всегда сброс прогресса на ноль.
Команда возвращается на стадию forming и storming (Такман не одобрил бы):
- снова учится доверять,
- восстанавливает коммуникацию,
- теряет скорость и предсказуемость,
- теряет участников.
Результат:
- Прогресса не видать, сплошные продолбы,
- Рост времени на вливание новых людей,
- Повышение количества ошибок,
- Снижение вовлечённости,
- Выгорание.
Скорость и надёжность зависят от слаженности, и такие решения могут стоить компании недель задержек и десятков инцидентов, особенно, если их не планировать как следует с учетом максимального количества рисков.
Итогом.
Лучшая стратегия для руководителя такого актива - не вмешиваться без острой необходимости. Трансформируй вокруг и встраивай то, что есть в то, что будет.
Если команда стабильно дает, что должна, быстро реагирует на инциденты и демонстрирует инициативу, пусть даже и не удовлетворяет отдельным требованиям - это не повод для реорганизации. Это повод для гордости.
Стабильность команды - это не инерция и признак застоя. Это конкурентное преимущество. Тот же г-н Койл выдал - "Лучшее, что вы можете сделать для своей команды, - это не вмешиваться, когда она уже нашла свой ритм". Что-то в этом есть, не так ли?
А на деле имеем, что имеем.