По инженерным командам заметил определенные patterns. Например, по размеру команды и поведению. Я могу разделить команды на две большие группы. 1) маленькая команда 1-3 человека, где все делают все достаточно быстро, помогают друг другу. Это не обязательно стартап, это может быть большая компания, но команды там маленькие и автономные. Инженеры чувствуют свободу и занимаются тем, что нравится. 2) большая команда до 10 человек и выше. Тут уже полная неразбериха, каждые пилит что-то свое, старенькие инженеры не хотят помогать новеньким. Решения принимаются либо очень долго, либо очень быстро и непрозрачно, часто кулуарно. Эксперты становятся bottle neck и могут быть токсичными для всей команды. Особенно их бесит, когда берут новых инженеров с зарплатой на 30% выше, чем у них. Если с маленькими командами все понятно и проблем обычно не бывает, за исключением отсутствия документации и риска потерять человека и вместе с ним всю экспертизу, то с большими командами вечные проблемы. ->Согласно закону Брукса, каждая “добавленная голова” повышает стоимость координации (n(n-1)/2). ->Согласно эффекту Рингельмана, с ростом группы падает индивидуальный вклад. ->Согласно закону Конуэя, система копирует структуру коммуникаций. Если оргуструктура запутана, продукт тоже будет фрагментирован. Так же появляется проблемы связанные с “психологической безопасностью”, команда перестает учиться и делиться знаниями. Как диагностировать проблему? - Время принятия решения и кол-во решения принятых без обсуждений с командой. Иначе говоря, отсутствия технических документов - tech spec, RAPID, etc - Задержка с Code Review и очередь к “экспертам” - Низкие оценки в опросах про эффективность команды (опросы важный элемент для больших команд) - Четкие сигналы о проблемах на встречать 1:1 - Отсутствие ownership и инициативы от команды А как у вас обстоят дела с инженерными командами? Вы эксперт bottle neck? Страдаете от закрытости коллег? Не знаете как расшевелить ваши команды?