Адаптивные организации

Культура компании: неуловимое, которое можно определить

Про культуру любят говорить, что это нечто неосязаемое: атмосфера, которую чувствуешь, но не можешь объяснить. Из-за этого её часто оставляют «на потом» или сводят к пуфикам в офисе и корпоративам. Но у культуры есть вполне точное определение.

Организационная культура - это то, как компания превращает свою миссию в действия и выполняет обещание, данное клиентам. Если совсем просто: «как у нас принято делать».

Из чего она состоит
Культура складывается из наблюдаемых элементов: стиль лидерства и коммуникации, ценности и ритуалы, практики работы с людьми (найм, онбординг), устройство команд и подходы к управлению эффективностью. Она влияет на то, как люди принимают решения, какое поведение получает признание и кого продвигают. Раз всё это можно увидеть, значит, это можно описать, измерить и изменить.
Три слоя культуры
1️⃣ Миссия. Она отвечает на вопрос, зачем компания существует и куда идёт. Это компас.
2️⃣ Бренд. Это обещание клиентам: уровень качества и сервиса, который отличает вас от конкурентов.
3️⃣ Повседневные действия. Именно здесь миссия и бренд либо оживают, либо остаются красивыми словами.

Что даёт сильная культура
Сотрудники, которые сильно чувствуют связь с культурой компании:
• в 4,3 раза чаще вовлечены в работу;
• в 5,3 раза чаще готовы рекомендовать компанию как отличное место работы;
• на 62% реже часто испытывают выгорание;
• на 47% реже ищут другую работу.

Есть и эффект выравнивания: когда все движутся в одну сторону, и сотрудники, и клиенты, и инвесторы говорят о компании одинаково. Культура подсказывает, на что тратить время, силы и ресурсы.

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

Как понять, что с культурой проблемы
Начните со сравнения: как руководители описывают культуру и как её проживают сотрудники. Почти везде между этим есть разрыв. Тревожные сигналы:
• размывается идентичность внутри компании и на рынке;
• падает обратная связь от клиентов;
• сложно привлекать сильных людей;
• органический рост замедляется из-за невыразительного клиентского опыта;
• инициативы руководства стартуют бодро, но теряют импульс.
Бывает и тоньше: нет одного события, но растёт ощущение «мы уже не те, что раньше».

Почему шаблонные опросники не работают
Многие инструменты подгоняют компанию под готовые «типы культуры» (инновационная, клиентоцентричная, инклюзивная) и сравнивают с внешними бенчмарками. Это ошибка: так теряется то, что делает вас уникальными. Возьмите «клиентоцентричность»: в каждой отрасли и у каждого продукта она выглядит по-своему. Универсальный список вопросов покажет общие тенденции, но не покажет прогресс в выполнении именно вашего обещания клиенту. Вопросы должны отражать специфику компании, быть связаны с реальными бизнес-процессами и опираться на серьёзные исследования.

Четыре шага к изменениям
🔜 Понять текущее состояние. Сначала выстроить у руководителей единое видение желаемой культуры. Без него менять нечего.
🔜 Определить разрыв. Сопоставить, где желаемая культура совпадает с реальным опытом сотрудников, а где нет.
🔜 Согласовать системы. Для одних это пересмотр метрик под миссию и бренд, для других - улучшение коммуникации. Нужна реальная вовлечённость руководства.
🔜 Закрепить ответственность. Отслеживать, как миссия, бренд и культура согласуются по локациям, подразделениям и ролям, и видеть, где выше риск текучки, низкой продуктивности или проблем с сервисом.
Про сроки. Улучшение вовлечённости часто даёт результат в течение года. Изменения культуры дают сильнейший эффект за три-пять лет. Это не спринт.

Главное
Хорошая культура не возникает случайно. Её проектируют осознанно и поддерживают последовательными действиями. Определить, какой она должна быть, обычно самое простое. Труднее всего ежедневно выстраивать то, что вы заявили.

Адаптивные организации pinned a photo

Всем привет!

У нас большое обновление: наш закрытый клуб получил свое отдельное пространство practices.club. Теперь все материалы, записи и анонсы событий живут в одном месте. Заходите посмотреть, больше 30 материалов уже доступно в записи.

Каждый месяц мы проводим минимум 4 воркшопа для наших участников, которые выкладываем в записи. В октябре их будет 5:

📅 1 октября, 19:00–21:00 МСК
Модель зрелости AI в организации от scrum.org
Роман Дорошенко про whitepaper о зрелости AI в организации от Scrum.org, который недавно вышел. Будем разбираться, что в нем полезного, а что можно смело игнорировать.

📅 8 октября, 19:00–21:00 МСК
Разбор кейсов
Роман Дорошенко разбирает ваши вопросы и кейсы. Если кейсов от вас не будет – будем работать с моими!

📅 15 октября, 19:00–21:00 МСК
Карты Wardley
Роман Дорошенко об одном из самых мощных инструментов работы со стратегией.

📅 22 октября, 19:00–21:00 МСК
Опыт создания мульти-агентной системы, поднятой на OpenClaw
Илья Павличенко расскажет о мультиагентных системах и поделится своим практическим опытом.

📅 29 октября, 19:00–21:00 МСК
Воркшоп по функциональной связанности. Решаем задачки
Илья Павличенко разбирает с вами тему функциональной связанности. Не только теория, но и решение практический кейсов. Заберете себе в коллекцию мощный инструмент работы с организационным дизайном.

👉 Ждем вас в practices.club

⚡️ 13 инструментов диагностики организации

За последние год собралось много инструментов организационной диагностики. Они помогают увидеть, где организация теряет скорость и адаптивность и что именно можно менять.

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

Такой формат пробую впервые — не знаю, зайдёт вам или нет. Посмотрите и напишите, какой инструмент вам понравился больше всего.

00:00 — Введение: кому и зачем нужны 13 инструментов диагностики
00:50 — Интервью (1)
02:03 — Тепловая карта (2)
05:23 — DSM-матрица (3)
08:29 — Функциональный анализ (4)
09:20 — Матрица критичности и неопределённости (5)
10:52 — Матрица зависимости (6)
12:32 — Value Stream Mapping (7)
14:31 — Feature-Team Adoption Map (8)
16:17 — Org Topology, организационная топология (9)
18:14 — Сетевая диаграмма оргдизайна (10)
19:54 — Причинно-следственные связи, CLD (11)
20:34 — PST: Professional System Thinker
20:55 — Айсберг системного мышления (12)
21:38 — Причинно-следственная карта (13)
23:19 — DAO Практикум
24:03 — DAO: Designing Adaptive Organizations

Фича ради фичи или ради результата?

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

1. Активность — что мы делаем.
«Переделываем онбординг»

2. Выход (output) — что появится в результате работы.
«Онбординг из 3 шагов вместо 7»

3. Результат (outcome) — как изменится поведение пользователей.
«На 5% больше новичков доходят до первой оплаты в первую неделю»

4. Влияние (impact) — что это даст бизнесу.
«На 30% растёт выручка с новых когорт, окупается привлечение»

Как читать результат:

— Не получается заполнить ступени 3–4? Перед вами не результат, а фича ради фичи. Или чья-то непроверенная гипотеза.

— На 3-й ступени нет цифры и срока? Тогда вы никогда не узнаете, сработало ли.

— Команда отчитывается только ступенями 1–2 («выкатили!»)? Значит, вы управляете загрузкой, а не продуктом.

— Самый рискованный переход — между 2-й и 3-й ступенью. Именно здесь нужен дешёвый эксперимент до разработки, а не после.

Вопрос, который меняет любое планирование:
«Какое поведение пользователей должно измениться, чтобы мы признали это успехом?»

Перешлите тому, у кого роадмап на квартал уже расписан 🙂

Эта лестница — один из 25+ инструментов тренинга Professional Scrum Product Owner Advanced (PSPO-A). Три дня мы разбираем, какие «шапки» надевает сильный владелец продукта:

- Визионер — видение, стратегия, метрики, ценообразование
- Представитель клиента — Jobs-to-be-Done, типы конкуренции, пирамиды ценности B2B и B2C
- Экспериментатор — как дёшево проверять гипотезы даже в сложных продуктах
- Инфлюенсер — карта стейкхолдеров и 5 шагов эффективного «нет»
- Принимающий решения — неделегируемые решения и масштабирование роли

Работаем на сквозном кейсе в мини-группах. После тренинга вы будете готовы к экзамену PSPO II от Scrum.org. Две попытки сдачи экзамена включены в стоимость. Тренинг подойдет, даже если вы не были на первой ступени.

📅 28 – 30 октября, онлайн, 10:00–16:00 МСК

👉 scrum.ru/pspo-a

Pioneers, Settlers & Town Planners: три типа продактов, которые нужны компании

Идея разделять продактов на три типа из предыдущего поста, пришла в голову Саймону Уордли.

Идею он позаимствовал из книги Роберта Кринджли 1992 года Accidental Empires — там были описаны типы людей, покорявших ранний рынок ПК: те, кто расчищает дикую территорию; те, кто следом обустраивает её для жизни; и те, кто строит городскую инфраструктуру для тысяч жителей. Уордли перенёс эту метафору на продуктовые команды: любая технология проходит путь от экспериментальной новинки до товара повседневного спроса, и на каждом этапе этого пути нужен человек с принципиально другим складом мышления.

Три архетипа
⭐️ Пионеры
Кайфуют от неопределённости и риска, строят с нуля. По сути ведут себя как основатели — не случайно первый продакт в стартапе почти всегда и есть его фаундер. Нужны на самой ранней стадии — в поисках product-market fit.
Как распознать: ищите предпринимательский опыт — но не любой. Важно отличать того, кто «строил», от того, кто «поддерживал» уже построенное.

🪴 Поселенцы
Приходят, когда PMF уже нащупан. Их зона интереса — не создание нового, а масштабирование: охват, метрики, оптимизация, A/B-тесты. Часто плотно работают с data science.
Как распознать: ищите тех, кто видит творческую задачу в тестировании гипотез и может чётко объяснить, как измерить эффект новой фичи.

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

Почему это не линейная смена стадий
Архетипы не вытесняют друг друга. Даже в зрелой компании нужны все три типа одновременно — просто в разных пропорциях и на разных направлениях: часть ресурсов идёт в core-продукт (поселенцы), часть — в новые точки роста (пионеры), часть — в платформенную инфраструктуру (градостроители). А готовая платформа сама создаёт почву для нового витка пионерства — цикл замкнутый, а не линейный.

Если нанимать «под фичи», а не «под стадию роста бизнеса», рано или поздно упрётесь в несоответствие между тем, что умеет команда, и тем, что реально нужно продукту сейчас.

Эластичная продуктовая команда: как Airbnb строит гибкие команды под цели, а не под фичи

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

5 принципов, которые стоят за этой идеей:
1️⃣ Начинайте с видения, а не с фич
Структурируйте продуктовые команды вокруг результатов (outcomes), а не вокруг конкретных фич — иначе компания будет цепляться за функции, даже если те уже не приносят пользы. У видения должен быть горизонт в 5+ лет, а у команд — понятная миссия, которая из этого видения следует. Пример: миссия команды Payments в Airbnb — сделать так, чтобы платежи между гостями и хозяевами были максимально бесшовными и «человечными», а не просто транзакционными.

2️⃣Команды должны быть модульными
В Airbnb продакты не сидят отдельно от инженеров и дизайнеров — все объединены в мультидисциплинарные группы без иерархии. Если нужно что-то презентовать остальной компании, выступает тот, кому это логичнее — например, дата-сайентист, если речь про результаты A/B-теста.

3️⃣Нанимайте три типа продактов:
🔵Пионеры — любят строить с нуля, рисковать, создавать прототипы. Нужны на этапе поиска product-market fit.
🔵Поселенцы (Settlers) — фокусируются на масштабировании, метриках, A/B-тестах и оптимизации уже работающего продукта.
🔵Градостроители (Town Planners) — строят платформенную инфраструктуру, которая выдержит будущий рост и непредвиденные сценарии использования.
Все три типа нужны компании одновременно, просто в разных пропорциях в зависимости от стадии.

4️⃣ Ресурсы распределяйте через понятный процесс
Каждый квартал в Airbnb пересматривают команды: достигли ли цели, почему нет, соответствует ли проект видению продукта. Хороший пример — фича Wish List, изначально задуманная как персональный список избранного. Оказалось, что путешествия чаще планируют группой, и после переосмысления продукт превратили в инструмент совместного планирования поездок — что заметно подняло вовлечённость.

5️⃣ Собирайте и распускайте команды без драмы
Реорганизация — это нормально, если у компании есть культура итераций. Так же было при первом выходе Airbnb на международные рынки в 2012 году: под перевод, локальные способы оплаты и адаптацию интерфейса собрали отдельную команду, а когда системы заработали — распределили задачи по постоянным командам.

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

Как вам такая идея?

По мотивам интервью с первым PM Airbnb для First Round.

Норма управляемости: концепция, которая пережила своё время

«Один руководитель — не больше семи подчинённых».

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

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

В XX веке эту логику перенесли в теорию управления: число возможных связей между руководителем и подчинёнными растёт не линейно, а по экспоненте. Добавляешь одного подчинённого — количество потенциальных взаимодействий взлетает в разы.
Из этой формулы и работ британского теоретика Линдалла Урвика родилось практическое правило: оптимум — 5–8 прямых подчинённых, реже до 10–12. Это легло в основу организационных пирамид XX века — заводов, министерств, индустриальных корпораций вроде General Motors и IBM.

Что это такое по сути
Норма управляемости (span of control) — количество сотрудников, которые могут непосредственно и эффективно подчиняться одному руководителю.
🔜 Чем меньше норма — тем выше и «этажнее» организация, тем длиннее путь решения от верха до низа.
🔜 Чем норма шире — тем организация площе и самостоятельнее на местах.

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

Почему эта логика больше не работает
1️⃣ Изменилась природа работы. Формула моделировала физический, повторяющийся труд, где каждый шаг нужно было согласовывать. Сегодняшняя работа знаниевая — люди сами ставят себе задачи и принимают решения, а роль руководителя сместилась от контроля к устранению препятствий и коучингу.
2️⃣ Технологии снизили издержки координации. Формула строилась на том, что взаимодействие требует личного присутствия руководителя. Сейчас статус задач виден в Jira, обсуждения идут асинхронно в Slack, а данные о работе команды — в дашборде в реальном времени.
3️⃣ Практика опровергла теорию числами. Реальные компании давно живут вне «правила семи». В Google у инженерных директоров бывало по 20–60 прямых подчинённых. В компаниях с плоской структурой формальных менеджеров с классической нормой нет вообще — есть автономные кросс-функциональные команды.
4️⃣ Норма зависит от контекста, а не от числа. Реальный предел определяют однородность задач, опыт сотрудников, качество инструментов и то, распределена ли команда территориально. Один менеджер может эффективно вести 5 человек со сложными разнородными задачами — или 40 человек с похожими, хорошо описанными процессами. Единого «правильного числа» не существует.
5️⃣ Изменилась модель лидерства. Классическая норма исходила из модели «руководитель как контролёр». Современный менеджмент всё чаще строится вокруг модели «руководитель как опора» — где ценность не в надзоре, а в развитии людей и снятии барьеров. Здесь узкое место — не «сколько человек можно контролировать», а «скольким я могу реально помочь расти».

Что приходит на смену

Вместо жёсткой нормы сегодня чаще говорят о span of support (скольким людям менеджер может реально помочь) и span of accountability (за какой результат, а не за сколько голов, он отвечает).

Плоские структуры и самоуправляемые команды показали: формула управляемости — не универсальный закон, а артефакт индустриальной эпохи, которая уже закончилась.
Как исторический ориентир норма управляемости не бесполезна — она напоминает, что координация не бесплатна.
⚡️ Но воспринимать её как точное число для любой команды в 2026 году — всё равно что проектировать смартфон по чертежам печатной машинки.

⚡️ Системное мышление подорожало

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

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

Элизабет Стоун, директор по продукту и технологиям Netflix, рассказывала об этом у Ленни Рачицкого: при найме она теперь смотрит в первую очередь на системных мыслителей, а глубокая узкая экспертиза отходит на второй план. Логика простая — экспертиза устаревает вместе с инструментом, а понимание взаимосвязей переносится в любой домен.

Заодно я выложил в открытый доступ свой скилл для Claude. Он собирает историю, вытаскивает переменные, определяет архетип, строит диаграмму циклов (CLD) и ищет точки приложения усилий. Внутри 11 системных архетипов, 12 рычагов Медоуз, разбор по айсбергу и девять эталонных кейсов.

Системное мышление становится мощной практикой для лидеров, и для этого есть программа Professional Systems Thinker. Следующий поток собирается на 3 ноября: восемь модулей, от основ до сложных многоконтурных историй. К середине вы берёте свою настоящую хроническую проблему из организации и ведете ее через всю программу как сквозной кейс — с разбором каждую неделю, пока не появится работающее решение. Группы я держу небольшими и стартую от восьми человек: наберётся раньше — начнём раньше, так что заглянуть на страницу лучше сейчас.

В какой системе вам нужно детально разобраться?

⚡️ Кейс: три AI-ассистента для встреч

На связи снова Илья Павличенко.
Недавно я помогал кластеру из трех Scrum-команд выстроить их процессы. Для кодинга и индивидуальных задач они AI уже активно используют. А вот на командных встречах — практически нет. Хотя именно там проходит заметная часть совместной работы. Поэтому мы решили встроить AI прямо в Scrum-события.

На PBR появился ассистент по декомпозиции элементов бэклога. Команды расходятся по группам, работают с ним, потом возвращаются и обсуждают результат вместе.

Для Sprint Planning — ассистент по формулированию Цели Спринта. Для ретроспективы — ассистент для системного исследования проблем и построения системных диаграмм (CLD).

В итоге мы сразу встроили трех специализированных AI-ассистентов в регулярную работу команд. И обратная связь оказалась очень сильной.

А потом я наткнулся на исследование HBR. Оказалось, исследователи предлагают очень похожий подход: использовать AI непосредственно во время совместной работы команды, а не только один на один.

Если захотите попробовать такой подход у себя, в AI-практикум как раз можно собирать таких специализированных ассистентов под свои встречи и рабочие сценарии.

Для какой встречи вы бы первым сделали AI-ассистента?

Вероятностное мышление в бизнесе: как перестать гадать и начать взвешивать

Это вторая часть — если вы ещё не читали про дилемму с зонтиком и формулу «вероятность × последствия», начните c предыдущего поста.

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

🔘Детерминированное мышление звучит так: «Исследование показывает 70% вероятность, что фичу оценят — значит, катим на всех сразу, чего тянуть». Оставшиеся 30% молча выпадают из плана: никто не закладывает откат, мониторинг метрик в первую неделю или сценарий «а что если юзеры её просто не заметят». Когда фича проседает по вовлечённости, команда искренне удивляется — хотя цифры предупреждали с самого начала.
🔘Мышление «всё или ничего» звучит так: «Есть шанс, что конкурент скопирует нашу фичу за месяц — значит, откладываем публичный анонс, урезаем демо на конференции и заставляем всех подписывать NDA даже на созвон с потенциальным партнёром». Малая вероятность превращается в непропорционально большую реакцию, потому что проще заблокировать саму возможность риска, чем спокойно жить с калиброванной вероятностью 10-15%.

Где это проявляется
Инвестиции и бюджет. Маркетинговый канал с 70% шансом окупиться и 30% шансом слить бюджет в ноль — это не повод вкладывать в него весь квартальный бюджет или вообще игнорировать. Вопрос в размере теста: 50 тысяч на пилот, а не 5 миллионов сразу и не ноль.
Запуск продуктов. Новый продукт с 40% шансом на провал — не обязательно плохая идея, если провал стоит вам три месяца работы одной небольшой команды, а успех — это новая линейка выручки на годы вперёд. Именно так на бумаге выглядели многие продукты, которые сегодня приносят компаниям основную прибыль.
Найм. Кандидат с сильным портфолио, но без опыта работы в команде больше 5 человек — это не решение «беру / не беру» по ощущению на собеседовании, а вопрос: что дешевле — три месяца испытательного срока с риском расстаться, или упустить сильного специалиста, потому что где-то в резюме не хватает одной строчки.
Риски и комплаенс. Вероятность утечки данных клиентов может быть невелика — скажем, 2-3% в год, — но её цена (штрафы, суд, отток клиентов) настолько высока, что серьёзные вложения в защиту оправданы даже при такой низкой вероятности. А вот вероятность, что раз в год упадёт внутренний дашборд на 20 минут, — это тот риск, ради которого не стоит останавливать разработку на две недели.
Прогнозирование. План продаж, построенный на одной цифре «мы ожидаем рост на 15%», ломается при первом же отклонении от плана. Модель с тремя сценариями — пессимистичный (+5%), базовый (+15%), оптимистичный (+30%) — и понятными триггерами перехода между ними держит удар куда лучше.

Как встроить это в управленческие привычки
✔️ Заменяйте вопрос «сработает ли это?» вопросом «насколько это вероятно и насколько я уверен?» — даже грубая оценка вроде «я процентов на 70 уверен» на созвоне делает разговор в команде честнее, чем уверенное «да, точно сработает».
✔️ Всегда спрашивайте цену ошибки в обе стороны: что дороже — потратить две недели на дополнительное тестирование фичи, которая скорее всего и так сработает, или выкатить её сырой и потом тушить пожар с недовольными пользователями.
✔️ Обновляйте оценку по мере поступления новых данных. Если после первого дня A/B-теста метрики просели сильнее прогноза — прогноз из питча трёхнедельной давности больше не главный ориентир.
✔️ Заложите в культуру, что часть решений «не сработает» — и это нормально. Если у команды каждый запуск оказывается удачным, скорее всего, она слишком осторожничает и упускает более рискованные, но более прибыльные ставки.

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

Вероятностное мышление: почему 60% — это не «да» и не «нет»

Дилемма с зонтиком
Представьте: утром вы смотрите прогноз погоды и видите — 60% вероятность дождя, 15% вероятность грозы (и оставшиеся 25% — что будет солнечно).
Возьмете зонт?

Большинство людей реагируют одним из двух способов:
🔘Детерминированное мышление: «60% — это много, рисковать не буду, беру зонт».
🔘Мышление «всё или ничего»: «Есть хоть какой-то шанс дождя? На всякий случай беру зонт!»

🔜Ни один из этих подходов не оптимален. Вероятностный мыслитель рассуждает иначе: важна не сама вероятность дождя, а то, сколько стоит ошибиться в каждую сторону.
Если ничего не стоит взять с собой зонт (например, кинуть его в машину), а промокнуть перед важной встречей стоит дорого, то даже умеренная вероятность дождя оправдывает зонт.
Если же зонт — реальная обуза (например, у вас только зонт-трость и вы на метро со 100 пакетами), а промокнуть — не проблема, то даже 60% может быть недостаточно, чтобы его брать.

Формула, которая работает
Хорошее решение — не то, которое гарантированно сработает. Это то, которое правильно взвешивает вероятность каждого исхода против цены ошибки в обе стороны. Практически это три вопроса:
1️⃣ Какие исходы возможны и с какой примерно вероятностью?
2️⃣Сколько стоит быть неготовым, если случится плохой сценарий?
3️⃣Сколько стоит подготовка к плохому сценарию, если он не случится?

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

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

Об этом — в следующем посте.

⚡️ Как убрать рутину и стать продуктивнее: 7 сценариев с AI

Привет! На связи Илья Павличенко👨

На днях сел и подумал, где AI уже реально помогает мне в работе. Получилось семь сценариев. Может быть, что-то из этого пригодится и вам.

1. Монтаж видео. Раньше у меня было два монтажера и уходило 30–40 тысяч рублей в месяц. Теперь Codex помогает мне локально монтировать записи тренингов.
2. Создание софта. Для DAO Practice я сам вайбкодил в Claude инструмент для организационной диагностики и автоматизировал часть работы.
3. Презентации и документы. Презентации в Gamma собираю за 20–30 минут. PRD, коммерческие предложения и другие документы делаю через Codex за несколько прогонов.
4. Исследования и discovery. Для исследования рынка использую Deep Research в GPT, Claude и Perplexity, потом свожу результаты в NotebookLM. Zoom AI Companion транскрибирует discovery-интервью, а Codex помогает искать паттерны и гипотезы.
5. Организационная диагностика. Десятки интервью, воркшопы и документы обрабатываю через Claude и Codex: ищу паттерны и причинно-следственные связи.
6. AI-ассистенты и skills. В ChatGPT у меня есть Custom GPT для повторяющихся задач: посты, ретроспективы, встречи. В Claude делаю разные skills под конкретные задачи, например по системному мышлению и работе с CLD.
7. Обучение и автоматизация новостей. В NotebookLM загружаю видео, статьи, исследования и другие источники и быстро собираю выжимки, mind map или подкасты. Feedly + Zapier + Codex автоматически собирают и фильтруют новые материалы, а готовая подборка приходит мне на почту.

Если что-то из этого полезно, могу отдельно раскрыть конкретный сценарий. И поделитесь в комментариях, чем сами уже пользуетесь.

Что раскрыть подробнее?

Чем "группки" опасны для организации?

Вчера смотрела очередную серию нового сезона «Теда Лассо» — в ней женская футбольная команда «Ричмонда» выигрывает матчи, но внутри давно не команда. Защитницы держатся защитниц, полузащитницы — полузащитниц, нападающие — нападающих. Все в одной форме, в одной раздевалке — а по факту три лагеря, которые скорее защищают своих, чем работают на общий результат.
Доктор Шэрон Филдстоун формулирует это в подкасте у Трента Крима почти как диагноз: клики (или группировки)— способ найти безопасность в стрессовой среде. Люди инстинктивно группируются с похожими на себя — не со зла, а потому что так спокойнее. Проблема в том, что чем безопаснее внутри группы, тем выше стена между группами.
Тед решает это не тренировками, а квиз-вечером в пабе со случайно перемешанными командами. Вечер заканчивается дракой и ночью в участке — но пережитое сообща сближает игроков сильнее любых установок сверху.

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

Что такое клики в организациях

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

Формируются они чаще всего по функции («разработка» против «бизнеса»), стажу (старожилы против новичков), локации (офис против удалёнки), иерархии или просто личной симпатии.

⚡️ Само по себе объединение по интересам — не патология, а нормальная потребность в принадлежности. Проблема начинается там, где принадлежность к группе становится важнее принадлежности к команде.

Почему это плохо
🟡Информация перестаёт течь свободно. Важные данные первыми узнают свои, до чужих доходят с задержкой или в искажённом виде — отсюда вечное «а нам никто не сказал».
🟡Решения принимаются в пользу группы, а не результата. Отдел прикрывает отдел, даже когда стоило бы признать ошибку и исправить процесс.
🟡«Чужаки» выключаются из процесса. Человек, не вписавшийся ни в одну клику, годами остаётся на периферии, даже если хорошо работает — прямой путь к выгоранию и уходу лучших.
🟡Конфликты становятся межгрупповыми. Спор о том, как сделать фичу, превращается в спор «разработка против продукта» и решается не аргументами, а тем, у чьей клики больше влияния.
🟡Общая цель размывается. Каждая клика начинает считать приоритетом свои метрики, а не результат компании целиком.

Что с этим делать
🔜 Называть проблему вслух. Тед прямо говорит команде о том, что видит раскол — без обвинений в адрес конкретных людей.
🔜 Создавать общую цель. Квиз-вечер сработал не потому, что все захотели дружить, а потому что появилась задача, где важен результат команды, а не позиции. В компании эту роль играет ясная, измеримая цель, за которую отвечают все вместе.
🔜 Перемешивать состав искусственно. Случайные команды на квизе разрушили привычные группировки. В работе это ротация в проектах, кросс-функциональные команды, парная работа людей из разных отделов.
🔜 Создавать совместный опыт. Ночь в участке сблизила игроков сильнее тимбилдинга именно потому, что последствия были общими. В компании это совместная ответственность за результат — когда оценка зависит от общего исхода, а не только показателей отдела.
🔜 Держать руку на пульсе. Клики формируются заново — при росте команды, смене руководства, переходе на удалёнку. Регулярные ретро и внимательные разговоры с людьми помогают заметить раскол до того, как он станет нормой.

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

Почему не стоит начинать с понедельника или 1 сентября

Есть момент, который выглядит как победа, а на самом деле — точка провала.

Приказ подписан. Презентация показана на общей встрече. Дорожная карта нарисована, ответственный назначен, в календаре появились встречи по статусу. Формально изменение началось. А потом наступает обычный вторник — и человек в компании делает ровно то же, что делал в прошлый вторник. Просто теперь он делает свою привычную работу привычным способом, а параллельно заполняет отчёт о трансформации.

Схема поменялась. Поведение — нет.

Дальше включается то, что можно назвать организационным иммунитетом. Компания опознаёт изменение как чужеродное тело и начинает его вытеснять — не саботажем, а вполне добросовестными действиями. Смежники просят «пока не ломать процесс, у нас квартал». Финансы не согласуют бюджет под непонятный новый результат. Руководитель среднего звена мягко возвращает команду к прежним метрикам, потому что спрашивают с него по ним. Никто не против изменений. Просто у каждого есть причина повременить.

И через полгода всё аккуратно откатывается назад. А в компании появляется новый факт: «мы особенные, у нас такое не приживается». В следующий раз антитела сработают быстрее. У одного из клиентов я слышала: «Вы уйдете, а я останусь. Я тут уже 10 трансформаций пересидел, а делаю все по-старому».

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

Отсюда типичные симптомы:
🔘 Есть «надо», нет «хочу». Логика перемен безупречна, а энергии ноль. Люди умеют исполнять то, во что не верят, — ровно на минимально допустимом уровне.
🔘Есть голова, нет сердца. Изменение объясняют цифрами, а решение о том, вкладываться или переждать, человек принимает совсем другой частью себя.
🔘 Есть менеджмент, нет лидерства. Планировать и контролировать компания умеет отлично. Задавать направление и вести за собой — сильно хуже.
🔘 Есть избранные, нет многих. Трансформацию тащат восемь человек из проектного офиса, а остальные три тысячи наблюдают со стороны, как за погодой.

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

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

21–22 сентября — тренинг «Основы управления изменениями», созданный Kotter Inc. и лично Доктором Коттером.

Что будет внутри:
🔜 восемь ускорителей: от формулировки Большой Возможности и создания срочности до быстрых побед и встраивания нового поведения в культуру;
🔜 четыре принципа Коттера — те самые «Надо + Хочу», «Голова + Сердце», «Менеджмент + Лидерство», «Избранные некоторые + Разнообразные многие»;
🔜 нейронаука изменений: что именно в устройстве мозга включает сопротивление и как это обходить;
🔜 как структура организации помогает или мешает адаптации.

10 часов онлайн, 15:00–19:00 МСК, Zoom и Miro, работа в группах. После — цифровой бейдж от Kotter Inc. и доступ в Kotter Community на 6 месяцев.

⚡️ Регистрация по ссылке

⚡️ Как раскрыть потенциал организации и ускориться в 2-3 раза

Последние 15 лет я помогаю организациям ускоряться — от стартапов до больших банков и телекомов.

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

Мой опыт подтверждает: у любой организации есть потенциал ускориться в 2–3 раза.

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

Переходите по ссылке.

А вы догадываетесь, где спрятан потенциал вашей организации?

В мае Anthropic выпустила The Founder's Playbook — гайд по созданию AI-native стартапа в 2026-м.

Ожидаешь манифест в духе «теперь код пишет агент, инженеры не нужны». А самая объёмная глава в нём — Idea Stage, и она целиком про то, как не начать строить раньше времени.

Что там по сути:

- 42% стартапов закрываются, потому что построили то, что никому не нужно. Авторы прямо пишут: с агентным кодингом эта доля будет расти, а не падать.

- Рабочий прототип — не доказательство гипотезы. Доказательство — реакция живых людей на него. Прототип это всего лишь реквизит для разговора.

- Confirmation bias получил исследовательский AI-движок. Попросите AI обосновать вашу идею — обоснует. Попросите посчитать TAM — посчитает ровно такой, какой нужен для привлечения инвестиций. Еще и с радостью скажет: «Да, вы правы!»

- Расширение скоупа фичей потеряло естественный ограничитель. Раньше фичу сдерживала стоимость инженерного времени. Теперь фича — это вечер работы, и каждое отдельное «давайте ещё вот это» не выглядит большой проблемой.

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

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

И у этого есть неочевидное следствие. Когда эксперимент стоил дорого, узким местом была реализация. Теперь узкое место — качество самой гипотезы. Плохо сформулированная гипотеза раньше умирала на этапе оценки: дорого проверять. Сейчас её проверят за два дня, получат мутный результат и поедут дальше. Скорость без правильного направления — это просто более быстрый способ построить не то.

Плейбук заканчивается мыслью, что ограничение теперь не в том, что вы можете построить, а в том, что вы выбираете строить.

Это, вообще-то, классическая работа владельца продукта.

16–18 сентября проводим Professional Scrum Product Owner. Три дня по шесть часов, онлайн, Zoom + Miro. Учим не скраму, а продуктовому подходу ради бизнес-результата.

Из программы — ровно про то, о чём выше:

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

👉 Регистрация по ссылке

⚡️ Кейс: 58% автономности, 0% поставки

Один мой коллега проджект-менеджер столкнулся с типичной проблемой. Четыре ключевых архитектурных компонента находились за пределами его команды. Из-за этого постоянно возникали зависимости и лишние согласования.

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

Он собрал с командой HeatMap в моем программном обеспечении для диагностики организации. И тут случился хороший aha-момент.

Оказалось, что команда самостоятельно выполняет 58% работы. Вроде немало. Но из 11 элементов беклога самостоятельно доводит до конца 0. То есть команда много чего могла делать сама, но закончить самостоятельно хотя бы один элемент не могла вообще.

Карта показала и причину: почти каждый элемент в какой-то момент упирался во внешний компонент или организационную функцию. И вот тут разговор про оргструктуру резко стал предметным.

«Мы за 2 недели на изи поменяли структуру департамента и втянули 3 компонента внутрь юнита, максимально легко и без сопротивления команд или менеджмента».

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

Мне нравятся такие инструменты потому, что они делают видимым то, что до этого существовало только кусками в головах людей.

HeatMap — один из модулей моего ПО для диагностики и проектирования организаций. Там есть и другие модули, матрицы и способы посмотреть на организацию с разных сторон.

Мы используем этот инструментарий в двух программах — DAO «Дизайн адаптивных организаций» (ссылка) и DAO Практикум «Проектирование вашей организации» (ссылка).

На Практикуме участники работают со своей реальной организацией: собирают данные, визуализируют устройство системы и проектируют изменения.

Бывало: работаем много, закончить не можем?

AI-инструменты для Agile-практиков

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

На днях Илья Павличенко, партнер scrum.ru, протестировал Kimi K3. Больше всего в нем зацепила боковая панель: в одном месте собраны сайты, слайды, исследования, документы, таблицы, дизайн, код, задачи по расписанию и группы AI-агентов.

Он сразу попробовал сделать небольшой сайт и слайд-деку — оба результата получил быстро, причем прямо в бесплатной версии. Настолько удобно упакованного набора AI-инструментов он раньше не встречал. Kimi — отличный пример того, как стремительно меняется ландшафт вокруг нас.

Поэтому Илья собрал 5 бесплатных видео про AI-инструменты для Agile-практиков, где показывает ровно то, чем пользуется сам. Эту серию он планирует регулярно обновлять по мере появления действительно стоящих решений.

Внутри:

🔘 Как AI меняет нашу работу.
🔘 Как его используют продакты, коучи и менеджеры.
🔘 Какие инструменты стоит попробовать в первую очередь.
🔘 Чем отличаются ассистенты, навыки, агенты и вайб-кодинг.
🔘 Как за пять дней собрать своего первого AI-помощника.

🔜 Забрать 5 бесплатных видео можно здесь:
https://ai-praktika.online

Перформанс-хакинг

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

Джим Хайсмит называет это «перформанс-хакингом» — имитацией эффективного управления через красивые метрики без реального результата. Термин он позаимствовал из статьи «Cashing out Excellence» (MIT Sloan Management Review, 2023).

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

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

⚡️ Почти любая система измерения эффективности рано или поздно даёт сбой: начинает мотивировать ровно противоположное тому, ради чего её вводили.
Особенно ярко это проявляется в интеллектуальном и творческом труде — там, где по-настоящему важные вещи (качество мышления, инновационность, вовлечённость команды) плохо поддаются подсчёту, и любая попытка измерить их одной цифрой создаёт соблазн подогнать цифру, а не улучшить суть.

Логика перформанс-хакеров пронизывает разные уровни компании.
🔜 На уровне топ-менеджмента это выражается в одержимости квартальными финансовыми результатами.
🔜 А на уровне разработки та же логика превращается в одержимость «продуктивностью» вместо «ценности» — и в использование метрик вроде velocity для оценки конкретных команд и людей, хотя изначально они задумывались совсем для других целей.

Так что помним про Закон Гудхарта и используем метрики как источник эмпирической информации, а не как инструмент контроля.