Сила не только в людях. Сила — в связях. 

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

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

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

В чём разница? Не в технологическом стеке и не в уровне скиллов (хотя и в них конечно же тоже). Разница в качестве взаимодействия внутри команды. И это далеко не всегда про качественный менеджмент.

Тезис 1: Психологическая безопасность — основа высокой эффективности. Создать ее по распоряжению нельзя.

Google проектом Aristotle показал: ключевой фактор успеха IT-команд  — психологическая безопасность. То есть среда, в которой разработчик может сказать: «Я не понял архитектуру»,  SRE — признать, что инцидент вызван его правкой, или продакт предложить откат фичи без риска быть низложенным.

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

Тезис 2: Команды в IT не собираются. Они созревают. И делают это не со скоростью сахарной браги.

Г-н Койл в своем «Кульурном коде» выдал, что эффективные команды — это не временные проектные группы, а устойчивые социальные системы. В IT это особенно заметно: лучшие результаты показывают долгоживущие и стабильные команды, которые прошли вместе через кучу релизов, инцидентов, кризисов в конце концов.

Именно в таких коллективах складываются:

• единый язык общения (не только Python или Go),
• неформальные каналы координации («Я уже спрашивал у Тани — она в курсе»),
• высокая скорость принятия решений («Да, делай, мы доверяем»).

Эти патерны поведения нельзя просто так создать или взять и перенести в новую команду. Их можно только вырастить со временем и только совместной работой.

Тезис 3: Цена реорганизации — долгий спад после «оптимизации»

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

Команда возвращается на стадию forming и storming (Такман не одобрил бы): 

 — снова учится доверять,
 — восстанавливает коммуникацию,  
 — теряет скорость и предсказуемость, 
 — теряет участников. 

Результат:  

• Прогресса не видать, сплошные продолбы, 
• Рост времени на вливание новых людей,  
• Повышение количества ошибок,  
• Снижение вовлечённости,
• Выгорание. 

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

Итогом. 

Лучшая стратегия для руководителя такого актива — не вмешиваться без острой необходимости. Трансформируй вокруг и встраивай то, что есть в то, что будет. 

Если команда стабильно дает, что должна, быстро реагирует на инциденты и демонстрирует инициативу, пусть даже и не удовлетворяет отдельным требованиям — это не повод для реорганизации. Это повод для гордости.

Стабильность команды — это не инерция и признак застоя. Это конкурентное преимущество. Тот же г-н Койл выдал — «Лучшее, что вы можете сделать для своей команды, — это не вмешиваться, когда она уже нашла свой ритм».  Что-то в этом есть, не так ли?

А на деле имеем, что имеем.