БИЗНЕС И ЦИФРОВИЗАЦИЯ

InfoQ: быстрый рост ломает социальную систему IT-команд

14 мая 2026 года InfoQ описал, как масштабирование команд повышает риск сбоев в коммуникации, решений и психологической безопасности.

✍️ Редакция iTech News | 15.05.2026 | ⏱ 5 мин | 👁 2 | Источник: InfoQ
InfoQ: быстрый рост ломает социальную систему IT-команд

Быстрое масштабирование команд бьет не только по процессам, но и по доверию между людьми. 14 мая 2026 года InfoQ пересказал выступление Charlotte de Jong Schouwenburg с Dev Summit Munich и напомнил неприятную для многих компаний вещь: если команда резко растет, старые связи перестают работать, а психологическую безопасность приходится собирать заново почти как инфраструктуру после неудачного релиза.

По данным InfoQ, de Jong Schouwenburg называет это проблемой human scalability: чем больше становится организация, тем шире поверхность взаимодействий и тем выше риск, что информация, решения и ответственность застрянут в людях, а не в системе. Для русскоязычного IT-рынка тезис более чем прикладной. Любая компания, которая за год разрослась из нескольких продуктовых команд в сеть из функций, локаций и подрядчиков, уже видела этот эффект: релизы идут, Jira заполнена, а между командами начинается тихий дрейф контекста.

Ключевая мысль выступления проста и неприятна своей приземленностью. Когда социальная система заметно меняется, запас доверия и безопасности обнуляется частично или полностью. Людям нужны новые рабочие привычки, новые маршруты коммуникации и новые способы быстро понимать, кто за что отвечает. И это требует времени. Проблему нельзя закрыть одной презентацией про values и созвоном all hands. De Jong Schouwenburg предлагает закладывать в коммуникацию осознанную избыточность: повторять ключевые сообщения в разное время, в разных форматах и через разные каналы, чтобы контекст не зависел от одного письма, одного менеджера или одной встречи, на которую половина людей пришла с выключенной камерой и включенным Slack.

В этом месте статья InfoQ особенно полезна тем, что уходит от красивых слов к механике. Повторение, по сути, объявляется не бюрократией, а рабочим инструментом. Одни люди лучше считывают контекст в письменном виде, другим нужен разговор, третьим понятнее демо, а не стратегический документ на восемь страниц. Если компания не дублирует важные сообщения, она почти гарантированно создает зоны, где люди выпадают из общего понимания целей. Снаружи это выглядит как «что-то много недопонимания», внутри превращается в переработки, лишние согласования и вечную охоту на того самого человека, который «в курсе, как тут на самом деле».

Отдельный акцент сделан на том, как снижать риск изоляции команд. De Jong Schouwenburg советует строить мосты между группами до того, как начнется давление сроков и инцидентов. В набор таких мостов она включает многокомандные офсайты, виртуальные кофе, общие ритуалы, buddy-схемы между площадками, совместные демо, обучающие сессии и ротацию фасилитаторов. Последний пункт особенно важен: если вся межкомандная координация держится на одном «хабе» или неформальном связующем, компания получает не менеджерский талант, а single point of failure в человеческом виде. Пока такой человек на месте, система кажется устойчивой. Стоит ему заболеть, выгореть или уйти, и внезапно выясняется, что половина решений передавалась устно, а вторая половина просто жила у него в голове.

В интервью InfoQ de Jong Schouwenburg отдельно разбирает признаки того, что узкие места уже появились. Среди индикаторов она называет задержки в принятии решений, зависимость работы от согласования у одного человека, культурный дрейф между офисами или функциями, а также перегруженных connectors — людей, которые становятся клеем между слоями организации. Когда таких людей слишком мало, а зависимость от них слишком велика, начинаются знакомые симптомы: команды ждут контекст, решения тормозят, переоткрываются уже закрытые вопросы, а кросс-функциональная работа превращается в цепочку уточнений. Для инженерной культуры здесь есть неудобный, но полезный вывод: bottleneck может жить не только в монолите, базе данных или CI, но и в привычке всей компании ходить за ответом к одному «герою».

Еще один сильный тезис касается метрик. Докладчица предлагает наблюдать за состоянием человеческой системы так же внимательно, как за технической. Не в стиле «раз в полгода спросим, счастливы ли сотрудники», а через ранние сигналы устойчивости: насколько открыто команды поднимают риски, как часто межкомандное рассогласование приводит к переделкам, насколько люди участвуют в ретро, насколько сильно различаются командные культуры между площадками. Это, по сути, попытка перевести разговор о доверии из абстрактной HR-плоскости в управляемую операционную практику. Для CTO, VP Engineering и product-руководителей подход удобен тем, что он не требует веры в модные слова: если under stress здоровая система ведет себя предсказуемо, то нездоровая начинает трещать по швам задолго до громкого срыва сроков.

Наконец, de Jong Schouwenburg довольно жестко формулирует роль лидеров. Они ускоряют или тормозят масштабирование команд не лозунгами, а личным поведением. Если руководитель может публично признать неопределенность, сказать «я ошибся» или реально пригласить несогласие, он нормализует уязвимость и снижает стоимость честного разговора. Если же сверху декларируют openness, а на практике вознаграждают только удобное молчание и героическое тушение пожаров, люди быстро считывают настоящий протокол. В этом смысле культура действительно копирует не то, что лидер говорит, а то, что он демонстрирует и терпит.

Для бизнеса из этого следует довольно трезвый вывод. При росте компании проблема редко выглядит как «нам не хватает еще пары синьоров и одного EM». Чаще речь о том, что организационная архитектура не поспевает за числом связей, зависимостей и точек принятия решений. Инженерные команды привыкли думать о надежности систем, но теперь все чаще придется так же холодно думать и о надежности человеческих контуров: где у нас дублирование, где хрупкие мосты, где люди еще спорят по существу, а где уже просто экономят силы. На следующем витке роста выиграют не те, кто громче говорит про культуру, а те, кто научится проектировать ее с той же дисциплиной, с какой проектирует платформу или delivery-процесс.

Поделиться: Telegram X LinkedIn