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

Revolut пересадил инженеров на GLM, и счёт за AI упал в 10 раз. Повторим? Новость недели: Revolut сделал GLM-5.3 от Z.ai моделью по умолчанию для ~2000 инженеров. Claude Code и Codex теперь запасной вариант для сложных задач. Модель работает на собственных ~56 NVIDIA B200, миллион токенов обходится примерно в $0,30, а счёт составляет около десятой части того, что раньше уходило Anthropic и OpenAI. По внутренним данным, время на кодинг сократилось на 60%, lead time на 70%. Подробности Дэвид Абитболь, руководитель AI-операций Revolut, рассказал на AI Engineer NYC — доклад целиком (12 минут). Звучит как «все бегом на GLM». Но давайте разберемся. Что в новости раздуто -«Revolut перешёл на GLM». Не весь. По данным Revelio Labs, в Revolut ~21 тыс. сотрудников, из них ~11,5 тыс. в инженерной группе. Даже если учесть, что эта категория шире, чем «разработчики», 2000 человек — явно не все. -«В 10 раз дешевле». Это сравнение счетов, а не полной стоимости владения. Сколько стоят сами GPU, электричество и люди, которые всё это обслуживают, не раскрыли. С какими моделями и объёмами сравнивали, тоже. -«−60% и −70%». Целиком записать это на GLM нельзя. Одновременно сняли бюджетные лимиты, поменяли правила использования, инженеры просто набили руку. Ещё на Gemini у них было −20% и −10%. Контрольной группы нет. Но кейс от этого не становится менее интересным. Наоборот: самое ценное в нём не модель, а объём работы, который пришлось сделать вокруг неё. Чтобы использовать GLM так же, как Revolut, мало взять его из коробки. Придётся решить вот такие проблемы: 1. Скорость ответа. На старте первый токен приходил через 10+ секунд. Целевой порог Revolut — меньше 3 секунд, после пяти начинаются жалобы в Slack. За четыре месяца довели до 1,68 с, не добавив ни одной GPU. Это потребовало много работы с подбором ограничения контекста и оптимизации использования памяти GPU. 2. Другая экономика. Со своей моделью вы платите не за токены, а за железо. Значит, его надо загружать и считать утилизацию, а не просто оплачивать счёт по факту. 3. Маршрутизация. Одной модели не хватает. Картинки через роутер уходят в Gemini, тяжёлые задачи — в Claude Code и Codex. Кто-то должен решить, какая задача в какую модель идёт, и сделать это незаметным для инженера. 4. Безопасность и регулятор. Агенты работают в специально спроектированной песочнице. Человек всегда в контуре, ответы не хранятся. Отдельная работа большая работа проделана против prompt injection. И всё это нужно уметь объяснить регулятору. 5. Измерение эффекта. Revolut год измерял coding time и lead time по всем 2000 инженерам. Без этого «AI нас ускорил» остаётся ощущением, а не фактом. 6. Процессы. Самое интересное. Когда лимиты сняли, инженеры перестали копить токены «на конец квартала» и понесли AI в Jira, Confluence и поиск по документации. Lead time улучшился сильнее, чем coding time. Узкое место было не в написании кода, а во всём, что вокруг него: ожидания, согласования, поиск контекста. Получается, модель — меньшая часть истории. Остальное — инфраструктура, правила игры и перестройка процессов. Подключить модель можно за вечер. Научить организацию ею пользоваться — нет. Мы умеем решать именно такие задачи: выбрать модели и выстроить маршрутизацию, задать правила безопасного использования, договориться о метриках и перестроить процессы так, чтобы эффект от AI был виден в поставке, а не только в ощущениях. 👉 Учиться: курс «AI для Agile-практиков» — https://scrum.ru/agentic-engineering 👉 Разобрать вашу ситуацию: консультация — info@scrum.ru

Кого ждёт успех в эпоху AI Дэвид Брукс в The Atlantic написал про тип людей, которых ждёт успех в эпоху AI. Ключевым качеством станет не знание инструментов, а потребность в познании: насколько человеку вообще нравится думать. Он делит людей на три типа по тому, как они относятся к умственным усилиям. 1️⃣ Productive Passengers. Потребность в познании низкая. AI нужен, чтобы думать меньше. Продуктивность на бумаге растёт, а собственные интеллектуальные способности постепенно атрофируются. 2️⃣ Reluctant Optimizers. Потребность средняя. Риски они понимают, но то и дело поддаются соблазну упростить себе интеллектуальную жизнь. Со временем падают любознательность и мотивация. 3️⃣ Mental Marathoners. Потребность высокая. AI они используют, чтобы расти: ищут оригинальность, глубоко работают с информацией и воспринимают AI в первую очередь как партнёра для дискуссий. Для меня здесь главное то, что один и тот же инструмент даёт противоположный результат. 🔜 Разница не в AI, а в том, что человек с ним делает: отдаёт ему мышление или использует его, чтобы мыслить лучше. А для руководителя это ещё и вопрос про команду. Снаружи Passenger и Marathoner могут выглядеть одинаково продуктивными. Разница проявится через год: один перестанет задавать вопросы, а второй станет сильнее. Смотрите не на то, сколько человек использует AI, а на то, как. Спорит ли он с ответом? Проверяет ли? Приходит ли с собственной гипотезой? А вы к какому типу ближе себя ощущаете? Только честно 🙂

От чего зависит успех внедрения AI В BCG посчитали, куда уходят усилия в компаниях, у которых AI реально работает. Получилось правило 10-20-70 🔜 10% усилий идёт на алгоритмы, 🔜 20% на технологии и данные. 🔜 Остальные 70% на людей, процессы и культуру. Неудивительно, что большинство компаний распределяет внимание ровно наоборот. Выбирают модель, обсуждают платформу, считают лицензии. А вопрос «как изменится работа команды в понедельник утром» остаётся на потом. Что входит в эти 70%: 🟡 кто теперь принимает решение, человек или AI, и где проходит граница; 🟡 как меняются роли, если часть задач ушла в автоматизацию; 🟡 по каким критериям оценивать результат, если способ работы стал другим; 🟡 есть ли время и право пробовать и ошибаться. Это уже орг дизайн, а не проект. Купить инструмент можно за неделю. Перестроить вокруг него работу команды получается только за месяцы. Именно там остаётся основная часть результата. А как у вас распределены усилия: больше на инструменты или на то, как с ними работают люди?

Кто отвечает за ошибку AI-агента в организации? Представьте ситуацию: AI-агент проанализировал обратную связь пользователей, сформулировал гипотезу, подготовил изменения в продукте, написал код и создал pull request. Другой AI-агент проверил код, запустил тесты и одобрил изменения. Обновление попало в production. Через несколько часов выяснилось, что новая функциональность некорректно работает для части пользователей. Компания теряет деньги. Кто виноват? Разработчик, который не писал этот код? Product Manager, который не формулировал конкретную гипотезу? Руководитель, разрешивший использовать AI-агентов? Или сам AI? Последний вариант особенно удобен, но AI не несёт организационной ответственности. Он не может отвечать за последствия своих решений так, как это делает человек. При этом привычные механизмы распределения ответственности начинают давать сбой. Раньше мы могли относительно чётко связать действие с человеком, который его выполнил. Теперь между намерением человека и результатом может находиться целая цепочка автономных действий AI. Проблема не в том, что AI ошибается. Проблема в том, что мы делегируем ему действия быстрее, чем переосмысливаем ответственность. Здесь полезно различать несколько уровней автономности AI: 🔘 AI рекомендует. Анализирует данные и предлагает решение. Человек принимает решение и выполняет действие. 🔘AI выполняет. Человек ставит задачу, AI самостоятельно выполняет её, но результат требует проверки и подтверждения. 🔘AI принимает ограниченные решения. Агент самостоятельно действует в заранее определённых границах: например, исправляет некритичные ошибки или обрабатывает типовые запросы. 🔘AI управляет процессом. Агент самостоятельно планирует последовательность действий, взаимодействует с другими агентами и достигает поставленной цели с минимальным участием человека. С каждым уровнем растёт не только потенциальная производительность, но и сложность управления рисками. Поэтому недостаточно просто назначить человека, который «отвечает за AI». Нужно определить: ▶️Границы полномочий. Какие решения агент может принимать самостоятельно, а какие требуют подтверждения? ▶️Допустимую цену ошибки. Какой ущерб может возникнуть из-за одного неправильного действия? ▶️ Наблюдаемость. Можем ли мы восстановить, какие действия выполнил агент и на основании каких данных? ▶️Механизм остановки. Кто и при каких условиях может прервать работу агента или откатить результат? ▶️Владельца результата. Кто отвечает за качество результата и изменение правил работы AI? При этом важно не превратить человека в формального утверждающего, который нажимает Approve десятки раз в день, не имея возможности разобраться в происходящем. Человеческий контроль имеет смысл только тогда, когда человек способен реально повлиять на результат. На практике это означает, что степень автономности AI должна зависеть от риска, обратимости действий и возможности обнаружить ошибку. Например, агент может самостоятельно классифицировать обращения пользователей, но изменение тарифов, удаление данных или публикация новой функциональности могут требовать дополнительных проверок. И здесь возникает интересный организационный парадокс. Мы внедряем AI-агентов, чтобы уменьшить необходимость человеческого участия в операционной работе, но чем больше решений им делегируем, тем важнее становятся архитектура полномочий, механизмы контроля и ясность ответственности. Автономность без ответственности — это не самоорганизация. Это управленческий вакуум. Поэтому перед внедрением очередного AI-агента стоит задать себе один вопрос: «Если завтра этот агент совершит ошибку с серьёзными последствиями, сможем ли мы точно объяснить, кто разрешил ему действовать, почему это было допустимо и как мы предотвратим повторение?» Если ответ неочевиден, возможно, начинать нужно не с выбора AI-модели, а с организационного дизайна.

Мы запускаем курс по агентной разработке. Почти каждая команда разработки уже пробует ИИ. У кого-то купленные подписки на Cursor и Claude, у кого-то пилоты, у кого-то задача от руководства «внедрить AI в разработку». И почти везде одна картина: отдельные инженеры стали быстрее, а продукт быстрее не стал. Задачи просто копятся в новых очередях: на ревью, на тестировании, на согласованиях. ✔️Мы считаем, что дело не в модели и не в инструменте. Когда агенты пишут код, меняется весь процесс разработки: как ставятся задачи, кто и как проверяет результат, где нужны тесты, что остаётся на человеке. Если процесс остаётся прежним, ИИ просто ускоряет отдельные куски старого конвейера. ✔️Последний год мы строили такой процесс на своих проектах и проектах клиентов: агенты ведут задачу от постановки до работающего результата: сами пишут спеку и код, гоняют регрессию по всему проекту, проходят путь пользователя и сдают работу с видео и скриншотами. Человек ставит задачу и принимает результат. ▶️На курсе разберём, как выстроить такой SDLC у себя: — каким должен быть процесс, чтобы ИИ ускорял продукт, а не просто плодил код; — какие инженерные практики нужны, чтобы качество не деградировало; — как встроить это в существующую компанию с легаси, инфобезом, политиками и SAP или 1С где-то рядом; — как меняются роли и что такое AI-Native команда. Это не курс про промпты. За 4 недели вы сделаете 3 проекта, один из них на своей рабочей задаче, и попробуете новый процесс руками. ▶️Старт 1 декабря, занятия онлайн по вторникам и пятницам с 10:00 до 14:00 МСК. $100 на токены и инструменты входят в стоимость. Подробности и запись: scrum.ru/agentic-engineering

Stop Doing List: почему перестать делать иногда важнее, чем правильно расставить приоритеты? ▶️Представьте типичную ситуацию: компания определила стратегические приоритеты на квартал. Команды согласовали цели, составили планы, распределили ресурсы. А через месяц выясняется, что люди перегружены, сроки сдвигаются, а стратегические инициативы почти не продвигаются. Что произошло? Ничего необычного. Компания добавила новые приоритеты, но не отказалась от старых обязательств. Продолжаются проекты, актуальность которых уже сомнительна. Готовятся отчёты, которые никто не читает. Проводятся встречи, решения с которых ни на что не влияют. Поддерживаются процессы, смысл которых давно забыт. ▶️Организации гораздо лучше умеют начинать, чем заканчивать. И дело не только в плохом управлении приоритетами. Начало новой инициативы обычно воспринимается позитивно: развитие, амбиции, движение вперёд. А остановка существующей — как признание ошибки, потеря вложенных ресурсов или отказ от обещаний. Здесь срабатывает в том числе эффект невозвратных затрат (sunk cost fallacy): чем больше мы уже инвестировали в проект, тем труднее отказаться от него, даже если дальнейшие инвестиции не имеют смысла. В результате портфель инициатив только растёт. Но приоритеты имеют смысл, только если что-то действительно перестаёт быть приоритетом. Поэтому полезно дополнить привычный список задач ещё одним инструментом — Stop Doing List, списком того, что мы сознательно прекращаем делать. Попробуйте провести с командой небольшой эксперимент: раз в месяц выделяйте 30 минут и пересматривайте текущие инициативы, регулярные активности и обязательства. Для каждой задайте три вопроса: 🔘Какую ценность эта деятельность создаёт сейчас? 🔘Что произойдёт, если мы перестанем это делать на месяц? 🔘Если бы мы ещё не занимались этим, начали бы сегодня? Особенно интересен третий вопрос. Он помогает отделить реальную необходимость от инерции и прошлых решений. По результатам пересмотра возможны три решения: ▶️ Продолжить, если ценность понятна. ▶️Приостановить, если ценность сомнительна и её нужно проверить. ▶️Прекратить, если затраты больше не оправданы ожидаемым результатом. И ещё важный момент: освободившееся время не нужно немедленно заполнять новыми задачами. Часто именно уменьшение количества параллельной работы позволяет системе работать быстрее. Стратегия — это не только выбор того, что мы будем делать. Это ещё и осознанный отказ от того, чего делать не будем. В следующий раз, когда в вашей компании появится новый стратегический приоритет, попробуйте задать руководству простой вопрос: «А что мы теперь перестанем делать, чтобы у нас появились ресурсы на этот приоритет?» Иногда ответ на него говорит о реальной стратегии компании больше, чем вся презентация с целями на квартал.

Когда команда обходит оргструктуру В любой команде есть человек, к которому идут с вопросами, хотя по схеме он не отвечает ни за что. «Спроси у Ани, она знает», «это к Диме, он уже делал». Может восприниматься, как лёгкий беспорядок, но это самая честная карта того, как работает компания. Профессор Университета Вирджинии Роб Кросс много лет изучает такие неформальные связи, и делает это просто: спрашивает тысячи сотрудников, куда они идут за информацией, нужной для работы. В одной нефтяной компании он нашёл человека, который по схеме стоял довольно низко, но был центром сети, связывающей разведку, бурение и добычу. ⚡️ Таких людей Кросс называет брокерами: они соединяют разные группы и видят связи, которые другие не замечают. А на краях таких карт часто оказываются эксперты, которых компания почти не использует. Поэтому, когда команда обходит схему, задайте три вопроса: 🔜 К кому на самом деле ходят за ответом и почему не к назначенным? 🔜 Не перегружен ли этот человек? Если всё держится на одном «неформальном лидере», это риск. 🔜 Кого мы не слышим, потому что в схеме для него нет точки входа? Проверить это можно за 15 минут. Попросите каждого написать на листочке два-три имени: к кому он идёт, когда нужно разобраться в задаче или получить решение. Нарисуйте стрелки. Вы увидите то, чего нет ни на одном слайде. А к кому в вашей команде идут за ответами, хотя в схеме его роль про другое?

Как сказать «нет» стейкхолдеру и не испортить отношения Самая частая боль продакта: приходит топ-менеджер или ключевой заказчик с горящими глазами и словами «Нам срочно нужна эта фича, конкуренты уже сделали!». Если сразу отказать — получите репутацию человека, который вечно всё блокирует. Если молча забрать в бэклог — превратите команду в фича-фабрику. Вот 4 рабочих приёма, которые помогают перевести разговор с языка требований на язык ценности: ​🟡Переход от решения к проблеме. Вместо «У нас нет на это ресурсов» спросите: «Какую именно проблему пользователя или бизнеса мы хотим этим решить? Что изменится в поведении клиента, когда мы это выкатим?» Часто уже на этом этапе выясняется, что задачу можно закрыть в 10 раз проще и без разработки. ​🟡Разговор через метрики и гипотезы. Сформулируйте запрос как эксперимент: «Давай зафиксируем: если мы делаем X, то ожидаем рост метрики Y на Z%. Как мы поймём через неделю после релиза, что фича реально сработала?» ​🟡Прозрачная цена выбора. Никогда не спорьте о важности новой задачи в вакууме — покажите то, чем придётся пожертвовать: «Мы можем взять это в ближайший спринт. Для этого нужно сдвинуть вправо задачу А (которая принесёт N выручки) или задачу Б (которая снизит отток). Что из этого мы готовы отложить?» ​🟡Дешёвая проверка до разработки. Предложите промежуточный шаг: «Прежде чем тратить месяц работы команды, давай за 2 дня соберём прототип и проверим, нужно ли это реальным пользователям». Управлять ожиданиями стейкхолдеров и выстраивать продуктовую стратегию на основе экспериментов — главная разница между джуном и зрелым лидером продукта. Если вы уже переросли базовые механики работы с бэклогом и хотите выйти на уровень стратегического управления продуктом, приходите на продвинутый тренинг Professional Scrum Product Owner — Advanced. Три дня плотной практики, разбора антипаттернов и инструментов для владельцев продукта и продакт-менеджеров. 🔜 Занять место в группе и посмотреть расписание: https://scrum.ru/pspo-a

Как измерить лояльность команды: eNPS за пять минут Если настроение в команде вы оцениваете по тону на планёрках, картина может оказаться далека от реальной. ⚡️ Для этого есть простая метрика, eNPS (индекс лояльности сотрудников). Как это работает Сотрудникам задают два вопроса: «Порекомендуете ли вы компанию друзьям по шкале от 0 до 10?» и «Почему вы поставили такую оценку?». По ответам всех делят на три группы: 9–10 сторонники, 7–8 нейтральные, 0–6 критики. Как считать eNPS = % сторонников − % критиков. Пример: в команде 50 человек, 40% сторонников и 30% критиков, значит eNPS = 10%. ниже 0: критиков больше, чем сторонников, это проблема Как читать результат 0–30%: средний уровень, команда работает стабильно 30–50%: отличный результат от 50%: высокая вовлечённость и устойчивая команда Что важно учесть 1️⃣ Опрос должен быть коротким и понятным, иначе люди начнут ставить галочки наугад. 2️⃣ Заранее объясните, зачем он нужен, и покажите команде итоги. 3️⃣ Проводите регулярно, но не слишком часто: раз в квартал для недавно собранной команды, раз в полгода или год для давно работающей. Анонимность сама по себе не главное. Важнее выстроить среду, где открытая обратная связь, даже негативная, не становится проблемой. Если у менеджера среднего звена есть KPI на рост eNPS, честных оценок ждать не стоит. Если показатель низкий, командообразующие мероприятия не помогут: скорее всего проблема на уровне структуры, например, работа командная, а цели у людей индивидуальные. Работать в этом случае нужно со структурой организации, целыми и системой вознаграждений. А сама метрика не заменяет управленческий диалог. А вы замеряете лояльность в своей команде? Подробный разбор в статье: https://mts-link.ru/blog/enps-kak-izmerit-loyalnost-komandy/

Как внедрение AI сказывается на культуре компании? Ответ ищем в исследовании Gallup. Опрашивали сотрудников американских компаниях, где уже внедрили AI. Ответы разделились почти поровну: 24% говорят, что стало лучше, 25% что хуже. Остальные ничего не заметили. Для меня напрашивается следующий вывод: AI сам по себе культуру не улучшает. Он скорее усилитель: где в команде было доверие и ясность, станет сильнее, а где не было, станет заметнее. Еще из интересного. ❓ Что отличает команды, где стало лучше? Не инструменты и не бюджет. Руководитель. Если менеджер сам продвигает AI и поддерживает команду, то о реальных изменениях в работе говорят 33% сотрудников. Если нет, то только 4%. Разница почти в восемь раз. ❗️И последнее: половина HR-директоров из крупнейших компаний признались, что не уверены в своих менеджерах в этом вопросе. При этом обучают их уже больше половины. Но обучения мало: у менеджеров и так хватает задач, и «ещё одно важное направление» без времени и поддержки превращается просто в нагрузку. ⚡️ Запустить AI легко, а вот дать людям, которые ведут команды, время, ясность и право ошибаться уже задача руководства. Именно там решается, куда качнётся культура. А у вас как? Руководитель в вашей команде двигает AI или пока просто «спускает» задачу?

Подходы меняются. Вопросы остаются. Если посмотреть на продуктовую разработку за последние 10-15 лет, кажется, что изменилось всё. Waterfall сменился Agile, потом пришли Lean Startup и Design Thinking, затем OKR, Continuous Discovery, продуктовая аналитика в реальном времени, а теперь ещё и AI, который пишет код, делает прототипы и разбирает интервью с клиентами. Меняется скорость, с которой мы можем что-то сделать и получить обратную связь. Меняются инструменты и словарь. Но попробуйте вспомнить самые продуктивные продуктовые встречи в вашей практике. Скорее всего, на них звучали одни и те же вопросы: 🟡Для кого мы это делаем? 🟡Какую проблему решаем? 🟡Как поймём, что получилось? 🟡Что самое дешёвое можем сделать, чтобы проверить? Если ответов нет, не спасёт ни один фреймворк. Если ответы есть, заработает почти любой подход, хоть Scrum, хоть Kanban, хоть ваш собственный гибрид. Парадокс в том, что чем быстрее мы можем строить, тем дальше мы можем уйти не в том направлении. Раньше один шаг в неверную сторону занимал месяц. Теперь мы можем успеть сделать и выкатить пятьдесят бесполезных фичей за квартал. Попробуйте сегодня (15 минут): Откройте бэклог, возьмите три верхние задачи и для каждой заполните одну строку: клиент 🔜 проблема 🔜 метрика успеха 🔜 самый дешёвый способ проверить Там, где строка не складывается, и находится ваш следующий важный разговор с командой или стейкхолдерами. Не «нам нужны лучшие инструменты», а «мы пока не понимаем, зачем это делаем». Инструменты будут появляться и устаревать. Умение задавать эти вопросы и честно отвечать на них остаётся. ⚡️ Если хочется системно прокачать этот навык, у нас есть углублённый тренинг для Product Owner, где как раз разбирают, как принимать продуктовые решения в условиях неопределённости: https://scrum.ru/pspo-a

Дэйв Уэст уходит с поста CEO Scrum.org После 11 лет во главе Scrum.org Дэйв Уэст объявил, что уходит. Для мира Scrum это заметное событие. Уэст возглавлял организацию больше десяти лет и за это время вырастил продукт, бизнес и сообщество. Судя по его посту, дальше организацию поведёт Алекс Армстронг. Человек он не новый: сооснователь Scrum.org вместе с Кеном Шваабером. Что будет со Scrum.org? Наши тренеры от Scrum.org Рома и Илья новостями не делятся 🙂 Но что точно понятно: рынок сейчас нелёгкий. Бум и вера в адаптивные фреймворки, остались в прошлом. Компании сокращают коучей и Scrum Master'ов, спрос на обучение просел, а конкуренты не стоят на месте: Scrum Alliance, SAFe, Scrum Inc. Плюс огромное влияние ИИ: он меняет и спрос на обучение, и саму роль Scrum Master'а, и работу по разработке продукта в организациях. Следим за новостями. А как вы думаете, что ждёт Scrum.org?

Это все фантастика! Наверняка вы слышали такое, работая с практически любыми изменениями в организации. Люди склонны отвергать новое. Тем временем фантастика: 📌«Но как сильна инертность мысли! Как и все новое, новый принцип межпланетного транспорта с первых же минут обрел немало противников — тех, кто возлежал на старых лаврах и не хотел идти дальше, кто всю жизнь свою посвятил доказательству невозможности практического осуществления фотонного привода, кто сначала, с маху, охаял нововведение, а потом не нашел в себе смелости признать свою неправоту, и просто тех, кто искренне не хотел рисковать людьми и государственными средствами…» А. и Б. Стругацкие, «Страна багровых туч» (1959) Фотонного привода у нас до сих пор нет, а вот противники нововведений описаны документально точно. И, что полезнее, Стругацкие делят их на четыре разных типа: 🟡Те, кто на лаврах. Старый порядок им выгоден, новый ничего не обещает. 🟡Те, чья экспертиза построена на старом. Изменение для них обесценивает годы работы и профессиональную идентичность. 🟡Те, кто поспешил осудить. Возражение уже не про суть, а про то, как не потерять лицо. 🟡Те, кто честно не хочет рисковать. Людьми, деньгами, результатом. 🔜 С каждым типом нужно работать по-своему. Первым нужно показать, что они получат в новой системе. Вторым — как их опыт в ней пригодится. Третьим — дать возможность передумать без публичного поражения. А четвёртых стоит слушать внимательнее всех: их возражения часто и есть лучший список рисков. Сопротивление изменениям — не одна стена, а несколько разных дверей. И к каждой нужен свой ключ.

Налог на эмпатию: сколько стоит быть «эмоциональным стабилизатором» Когда вы последний раз закрывали рабочий день с мыслью «я сегодня почти ничего не сделал, но весь день слушал»? Экономика нестабильна. Вокруг ИИ много тревоги: «заменят ли меня?», «что будет с моей ролью?». И с этими вопросами люди идут не в HR-портал и не в корпоративную рассылку, а к своему менеджеру. Или к тому, кому доверяют: к коллеге за соседним столом, к наставнику, к тому самому человеку, с которым «можно поговорить по-человечески». Коллин Аммерман и Дипа Пурушотаман из Гарвардской школы бизнеса в статье для MIT Sloan Management Review назвали это «налогом на эмпатию»: невидимая работа по эмоциональной поддержке команды. Авторы пишут о руководителях, но на практике стабилизатором часто становится не тот, у кого в должностной инструкции написано «управляет командой», а тот, у кого есть доверие. Выслушать тревогу. Помочь справиться со стрессом. Объяснить, что реорганизация значит для конкретного человека. Всё это занимает часы, но нигде не фигурирует: ни в KPI, ни в должностной инструкции, ни в оценке эффективности. Почему это «налог»? 🔜 его платят постоянно и принудительно 🔜 он забирает ресурс, который можно потратить на другое 🔜 его редко замечают, пока не станет слишком поздно А поздно наступает так: накапливается истощение, потом выгорание, потом сильный человек уходит. Авторы отмечают, что тяжесть этой нагрузки может стать причиной ухода из компании. Что с этим делать? Вот три шага, которые подходят любой организации: 1️⃣ Признать, что эта часть работы существует. Назвать эту работу работой, а не «мягким навыком, который сам собой разумеется». 2️⃣ Нормализовать границы. Никто не обязан быть бездонным резервуаром поддержки, и сказать «мне нужна пауза» должно быть нормально. 3️⃣ Распределить нагрузку. Эмоциональная поддержка не должна держаться на нескольких «удобных» людях. Это общая культурная задача, и участвовать в ней должны все, включая тех, кто привык этого не замечать. И вопрос для самопроверки: кто в вашей организации эмоционально держит команду, и знает ли об этом кто-нибудь, кроме него самого? 💔 Если ответ «не знаю», налог, скорее всего, уже взимается. Источник

⚡️ Как решить запутанную проблему так, чтобы она не вернулась Люди сопротивляются изменениям: «Мы 20 лет так работали». Каждый отдел оптимизирует свою работу — и создаёт проблемы следующему. Одни и те же пожары месяцами превращаются в хотфиксы. У вас 15 команд и десятки зависимостей — и непонятно, куда приложить усилия. 7 октября с 16:00 до 18:00 проведу открытый эфир о том, как решать проблемы с помощью системного мышления и AI. Прямо на эфире выберем одного участника с реальной проблемой. Я проведу короткое интервью, а затем передадим историю команде AI-агентов. Агенты построят разные системные гипотезы и будут спорить между собой. AI-критик сравнит их с исходной историей, после чего мы построим итоговую системную модель и найдём рычаги изменений. Реальная проблема → системная модель → рычаг → изменение. Участие бесплатное. Запись получат те, кто придёт на эфир. 📅 Добавьте эфир в свой календарь, чтобы не пропустить. Ссылку на Zoom пришлю за час до начала: https://calendar.app.google/aCqhcfzcxtVPSkFx6

Обратная связь: что делать, когда сложно слушать Попробуйте вспомнить, когда вы последний раз спокойно выслушали критику и не начали оправдываться хотя бы про себя. Авторы книги "Спасибо за обратную связь. Как стать неуязвимым для критики и открытым для похвалы", считают, что именно здесь всё и решается 🔜 Можно услышать идеально поданный отзыв и отмахнуться. А можно вытащить пользу из неуклюжей и обидной критики. Всё зависит не от того, кто говорит, а от того, кто слушает. Поэтому книга о том, как принимать обратную связь, даже когда она несправедлива, плохо подана или пришла в неподходящий момент. Три типа обратной связи 1️⃣ Признание: «вы важны, ваша работа замечена». 2️⃣ Коучинг: «вот как можно сделать лучше». 3️⃣ Оценка: «вот где вы относительно стандарта» (рейтинг, грейд, бонус). Многие конфликты возникают от несовпадения. Человек просит признания, а получает коучинг. Руководитель хочет дать совет, а сотрудник слышит оценку своего места в иерархии. Три триггера, которые мешают услышать 🟡 Триггер правды: «это неправда, это несправедливо». Отделяйте содержание от подачи и спросите себя, что здесь может быть верным. 🟡 Триггер отношений: «кто он такой, чтобы мне это говорить?». Отделяйте «кто» от «что»: информация может быть полезной, даже если источник вам не нравится. 🟡 Триггер идентичности: критика бьёт по самооценке. Относитесь к себе сложнее, чем «я хороший» или «я плохой»: ошибка в одном эпизоде не отменяет всего остального. Слепые пятна Мы судим себя по намерениям, а других по результатам. Нам кажется, что мы были мягкими, а собеседник услышал резкость. Обратная связь помогает увидеть разрыв между намерением и впечатлением. Что делать на практике 🔜 Вместо расплывчатого «дай обратную связь» просите об одном: «Что одно ты бы посоветовал мне изменить?» Ответ получится конкретнее, а направление зададите вы. 🔜 Сортируйте отзыв «в сторону коучинга»: ищите, что можно улучшить, даже если критика звучит как оценка. 🔜 Берите обратную связь небольшими порциями, не пытайтесь изменить всё сразу. 🔜 Ловите собственные реакции: заметили, что обороняетесь, спросите себя, какой именно триггер сработал.

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

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

Из чего она состоит Культура складывается из наблюдаемых элементов: стиль лидерства и коммуникации, ценности и ритуалы, практики работы с людьми (найм, онбординг), устройство команд и подходы к управлению эффективностью. Она влияет на то, как люди принимают решения, какое поведение получает признание и кого продвигают. Раз всё это можно увидеть, значит, это можно описать, измерить и изменить. Три слоя культуры 1️⃣ Миссия. Она отвечает на вопрос, зачем компания существует и куда идёт. Это компас. 2️⃣ Бренд. Это обещание клиентам: уровень качества и сервиса, который отличает вас от конкурентов. 3️⃣ Повседневные действия. Именно здесь миссия и бренд либо оживают, либо остаются красивыми словами. Что даёт сильная культура Сотрудники, которые сильно чувствуют связь с культурой компании: • в 4,3 раза чаще вовлечены в работу; • в 5,3 раза чаще готовы рекомендовать компанию как отличное место работы; • на 62% реже часто испытывают выгорание; • на 47% реже ищут другую работу. Есть и эффект выравнивания: когда все движутся в одну сторону, и сотрудники, и клиенты, и инвесторы говорят о компании одинаково. Культура подсказывает, на что тратить время, силы и ресурсы. Культура и вовлечённость - разные вещи Вовлечённость показывает, насколько люди готовы работать на пределе. Культура задаёт, куда направить эту энергию. Вовлечённые сотрудники - топливо, культура - направление. К тому же, если базовые потребности людей не закрыты, они сопротивляются изменениям, а вовлечённые охотнее принимают перемены. Как понять, что с культурой проблемы Начните со сравнения: как руководители описывают культуру и как её проживают сотрудники. Почти везде между этим есть разрыв. Тревожные сигналы: • размывается идентичность внутри компании и на рынке; • падает обратная связь от клиентов; • сложно привлекать сильных людей; • органический рост замедляется из-за невыразительного клиентского опыта; • инициативы руководства стартуют бодро, но теряют импульс. Бывает и тоньше: нет одного события, но растёт ощущение «мы уже не те, что раньше». Почему шаблонные опросники не работают Многие инструменты подгоняют компанию под готовые «типы культуры» (инновационная, клиентоцентричная, инклюзивная) и сравнивают с внешними бенчмарками. Это ошибка: так теряется то, что делает вас уникальными. Возьмите «клиентоцентричность»: в каждой отрасли и у каждого продукта она выглядит по-своему. Универсальный список вопросов покажет общие тенденции, но не покажет прогресс в выполнении именно вашего обещания клиенту. Вопросы должны отражать специфику компании, быть связаны с реальными бизнес-процессами и опираться на серьёзные исследования. Четыре шага к изменениям 🔜 Понять текущее состояние. Сначала выстроить у руководителей единое видение желаемой культуры. Без него менять нечего. 🔜 Определить разрыв. Сопоставить, где желаемая культура совпадает с реальным опытом сотрудников, а где нет. 🔜 Согласовать системы. Для одних это пересмотр метрик под миссию и бренд, для других - улучшение коммуникации. Нужна реальная вовлечённость руководства. 🔜 Закрепить ответственность. Отслеживать, как миссия, бренд и культура согласуются по локациям, подразделениям и ролям, и видеть, где выше риск текучки, низкой продуктивности или проблем с сервисом. Про сроки. Улучшение вовлечённости часто даёт результат в течение года. Изменения культуры дают сильнейший эффект за три-пять лет. Это не спринт. Главное Хорошая культура не возникает случайно. Её проектируют осознанно и поддерживают последовательными действиями. Определить, какой она должна быть, обычно самое простое. Труднее всего ежедневно выстраивать то, что вы заявили.

Персональный AI-ассистент за 3 дня ⚡️Приглашаем на вебинар Илья Павличенко. 7–9 октября Илья проведёт бесплатный трёхдневный интенсив. За два прямых эфира он с нуля соберёт своего персонального AI-ассистента, а на третий день разберёт ассистентов участников. 🔜 Илья будет собирать всё вживую. Ассистент будет знать его контекст и материалы, готовить его к рабочему дню и встречам, работать с календарём и почтой, следить за важными источниками и готовить обзоры новых публикаций. Управлять им Илья будет прямо из Telegram. И ему интересна не только техническая часть. Илья покажет, как делегировать работу AI примерно так же, как сотруднику: определить роль, дать нужный контекст и знания, установить правила и границы полномочий. Что он может делать сам, что — только после подтверждения, а что ему вообще нельзя поручать. После первого эфира участники соберут паспорт собственного ассистента и настроят утренний брифинг в ChatGPT, Claude или Gemini. А 9 октября Илья разберёт их идеи голосом в Telegram-группе. ✔️ Эфиры 7 и 8 октября: 14:00–16:00 и повтор в 19:00–21:00. Участие бесплатное, программировать не понадобится. Регистрация здесь.

Всем привет! У нас большое обновление: наш закрытый клуб получил свое отдельное пространство 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 МСК Воркшоп по функциональной связанности. Решаем задачки Илья Павличенко разбирает с вами тему функциональной связанности. Не только теория, но и решение практический кейсов. Заберете себе в коллекцию мощный инструмент работы с организационным дизайном.

⚡️ 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