Чтобы всем было понятно, о чём речь, сразу дам определение.

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

По сути, эта модель делит происходящее в компании или команде на уровни — от видимых симптомов (события) до глубоких причин (структура и ментальная модель), как айсберг, большая часть которого скрыта под водой.

Вот недавно у меня произошло событие. Пришёл разработчик и сказал, что хочет увольняться. Без предпосылок. Всё было ОК. И тут — как гром среди ясного неба.

Что чаще всего происходит после этого? Идём искать нового! Но, как по мне, этого недостаточно. В 99% случаев все просто «тушат пожар», крайне редко проводя какой-то анализ: А почему он уволился? Что стало причиной? Можно ли было избежать этого увольнения? Не уволится ли за ним ещё кто-то? И так далее.

В моём кейсе я просто не отследил выгорание. Человек давно не был в отпуске и просто заебался до такой степени, что даже задумывается на неопределённый срок уйти из ИТ.

Таких примеров можно привести массу: Массовые жалобы на баги в проде; Провал по retention (или подставь любую другую метрику); Сорвали сроки в третий раз подряд; 10 последних гипотез не подтвердились после их тестирования.

Как с этим быть? Как работать на опережение? Об этом ниже.

Нижний уровень. Ментальная модель.

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

Если фаундер или топ-менеджеры верят, что жёсткая иерархия — это классно, то в компании будут уровни, замы, менеджеры -1 и так далее.

Вот ещё частые установки, которые я вижу: Скорость важнее качества → релизы без тестов; «Менеджер так сказал — я так и сделал» → разработчики молчат о проблемах; Ошибки — это плохо → затягивание сроков, излишний перфекционизм, низкая скорость команды; Микроменеджмент → выгорание и текучка.

Как по мне, менять ментальную модель фаундера или топ-менеджмента — это как пытаться вытащить фуру из песка в одиночку. Смысла мало, сил потратишь кучу, вероятность на успех стремится к нулю.

Поэтому, если я хочу что-то поменять, то спускаюсь на уровень структуры, паттернов — и ковыряю уже там.

Средний уровень. Структура компании.

Этот уровень отвечает на вопрос: какие процессы, роли, правила создают паттерны?

Именно на этом уровне можно найти «системные баги», которые приводят к провалам.

Моё видение такое: именно структура компании формирует её культуру. А культура — это и есть те самые паттерны поведения сотрудников и то, как они реагируют на события.

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

Что входит в структуру: Процессы (планирование, приоритизация, разработка, тестирование, поддержка и так далее); Роли, ответственности (кто за что отвечает и принимает решения); Коммуникационные паттерны (кто, когда и как общается в команде); Метрики, способы принятия решений (что замеряем, как, какие выводы делаем, как используем эти выводы); Корпоративная культура, правила внутри компании и команды (тот самый вайб).

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

Примеры, которые многим знакомы: Не налажен процесс в QA → баги попадают на прод; Нет системного ревью → код нестабилен, нечитабелен, не масштабируется; Roadmap продукта просто спускают сверху → низкая мотивация у команды; Оценка задач «пальцем в небо» → частые срывы сроков.