09:12.
Инженер замечает проблему.
Она пока небольшая. Ничего критического не произошло. Но есть риск: если предположение подтвердится, срок проекта может сдвинуться.
Он не сообщает руководству.
Сначала нужно проверить.
11:40.
Проблема подтверждается.
Инженер пишет руководителю отдела.
Тот отвечает:
— Давайте пока не эскалировать. Возможно, решим сами.
Это звучит разумно.
15:25.
Решить не получилось.
Подключают ещё двух коллег. Появляется новый вариант. Нужно несколько часов, чтобы его проверить.
Клиенту пока ничего не говорят.
18:10.
Вариант тоже не работает.
Кто-то предлагает сообщить директору.
— Уже конец рабочего дня. Давайте утром. Возможно, за ночь поставщик ответит.
На этом этапе компания потеряла не деньги.
Она потеряла кое-что потенциально более ценное:
время, в течение которого ещё можно было выбирать.
День второй. 10:15
Поставщик отвечает.
Хороших новостей нет.
Теперь становится понятно: проблема серьёзнее, чем предполагалось вчера.
Информация поднимается ещё на один уровень управления.
Начинаются вопросы:
— Кто уже знает?
— Клиенту сообщили?
— Насколько это критично?
— Есть альтернативный вариант?
— Когда мы точно поймём последствия?
Команда снова решает сначала собрать все факты.
Никто не хочет идти к CEO с половиной информации.
Это тоже кажется профессиональным.
16:30
CEO наконец узнаёт о проблеме.
И задаёт всего один вопрос:
«Когда мы впервые поняли, что это может произойти?»
Ответ:
«Вчера утром».
И вот теперь перед нами уже совсем другая проблема.
Не техническая.
Не проблема поставщика.
Не проблема проекта.
Это проблема скорости движения плохих новостей внутри компании.
Мы измеряем почти всё. Кроме того, как быстро до нас доходит правда
Современные компании измеряют огромное количество показателей.
Revenue.
Margin.
Conversion.
SLA.
Uptime.
Lead time.
Customer satisfaction.
Project completion.
Количество инцидентов.
Время реакции технической поддержки.
Но есть показатель, который редко можно увидеть на корпоративном dashboard:
Time to Bad News.
Назовём его TBN.
Это время между моментом, когда кто-то внутри организации впервые понял, что существует существенная проблема, и моментом, когда об этом узнал человек, способный принять необходимое решение.
Если инженер обнаружил риск в 09:12, а CEO узнал о нём на следующий день в 16:30, TBN составляет больше суток.
И иногда именно эти часы обходятся компании дороже первоначальной ошибки.
Потому что сама проблема могла ещё иметь несколько решений.
Но каждое потерянное окно времени закрывало одно из них.
Почему умные сотрудники скрывают плохие новости?
Обычно не потому, что хотят навредить компании.
Наоборот.
Чаще всего человек думает:
«Сначала попробую решить сам».
Это естественная профессиональная реакция.
Никому не хочется приходить к руководителю только с проблемой.
Нас учат:
Не приноси проблему — принеси решение.
Звучит прекрасно.
Но у этой управленческой философии есть опасная сторона.
Если сотрудник считает, что он имеет право сообщить о проблеме только тогда, когда уже нашёл решение, руководство может узнавать о критических рисках слишком поздно.
Иногда руководителю нужен не готовый ответ.
Ему нужна ранняя информация.
Потому что на другом уровне организации могут существовать варианты, которых сотрудник просто не видит.
Можно изменить приоритет.
Позвонить заказчику.
Подключить вендора.
Изменить архитектуру.
Зарезервировать другой товар.
Перенаправить бюджет.
Привлечь другого специалиста.
Эскалировать вопрос на уровень, недоступный сотруднику.
Но всё это имеет одну общую зависимость:
время.
Плохая новость имеет срок годности
Представим простой случай.
Сегодня вы узнаёте, что оборудование может не приехать вовремя.
У вас есть четыре альтернативы.
Через три дня — три.
Через неделю — одна.
За день до contractual deadline у вас уже может не быть ни одной.
Сама информация не изменилась.
Изменилась её ценность.
В понедельник она была инструментом для принятия решения.
В пятницу она стала объяснением того, почему решение уже невозможно принять.
И это фундаментальное различие.
Хорошая система управления должна доставлять проблему руководству тогда, когда информация ещё позволяет что-то изменить.
Не тогда, когда остаётся только объяснять последствия.
Но почему информация застревает?
Потому что в организациях существуют невидимые фильтры.
Сотрудник фильтрует информацию перед руководителем.
Руководитель — перед директором.
Директор — перед CEO.
Каждый уровень хочет сначала разобраться.
Каждый хочет показать контроль.
Каждый надеется, что проблема исчезнет до следующей эскалации.
И происходит странная вещь.
Чем выше человек находится в организации, тем более «обработанную» реальность он получает.
Инженер видит:
«У нас проблема».
Менеджер:
«У нас есть проблема, но команда работает над ней».
Директор:
«Есть определённый риск, ситуация контролируется».
До CEO иногда доходит:
«Есть небольшой вопрос, который сейчас решается».
Проблема одна.
Но после прохождения четырёх организационных уровней её температура изменилась.
Красный постепенно превращается в жёлтый
Это один из самых опасных эффектов корпоративной коммуникации.
Не обязательно кто-то врёт.
Каждый человек просто немного смягчает сообщение.
«Проблема» становится «сложностью».
«Задержка» — «возможным изменением срока».
«Критический риск» — «моментом, требующим внимания».
А «мы не знаем, как это решить» превращается в:
«Команда рассматривает несколько вариантов».
По отдельности каждое изменение кажется безобидным.
Но в результате человек, принимающий решение, получает совсем другую картину реальности.
Поэтому проблема не в том, открыта ли дверь CEO
Многие руководители говорят:
«Моя дверь всегда открыта».
Но это ещё не означает, что плохие новости действительно доходят быстро.
Вопрос не в двери.
Вопрос в том, что происходит с человеком после того, как он через неё вошёл.
Представьте два сценария.
В первом сотрудник сообщает о проблеме, а первая реакция руководителя:
— Как это вообще произошло?
— Кто виноват?
— Почему вы допустили это?
— Почему раньше не подумали?
В следующий раз сотрудник будет думать не о скорости эскалации.
Он будет думать о собственной защите.
Во втором сценарии первый вопрос руководителя звучит иначе:
«Что мы ещё можем изменить, если начнём действовать прямо сейчас?»
Разница огромна.
Первый вопрос ищет прошлое.
Второй защищает будущее.
Разбор ответственности тоже нужен.
Но после того, как компания остановила ущерб.
Психологическая безопасность — это не корпоративная мягкость
Термин psychological safety иногда понимают неправильно.
Будто речь идёт о среде, где никого нельзя критиковать и все должны чувствовать себя комфортно.
Нет.
В операционном смысле психологическая безопасность — это способность сотрудника сказать:
«У нас проблема».
«Я ошибся».
«Я не уверен».
«Этот срок нереалистичен».
«Я не согласен».
«Я думаю, что проект движется в неправильном направлении».
— до того, как доказать это становится слишком дорого.
Это не вопрос комфорта.
Это инфраструктура управления риском.
Есть ещё одна опасная фраза: «Не беспокойте руководство мелочами»
Разумеется, CEO не должен получать уведомление о каждом техническом инциденте.
Если всё эскалировать наверх, организация перестанет работать.
Поэтому задача — не создать культуру постоянной тревоги.
Задача — определить условия эскалации.
Например:
если под угрозой contractual deadline;
если возможны финансовые потери выше установленного порога;
если затронут ключевой клиент;
если существует cybersecurity или compliance risk;
если проблема может повлиять на репутацию;
если решение требует полномочий, которых нет у текущего владельца задачи;
если каждый час уменьшает количество доступных вариантов.
Последний критерий особенно важен.
Иногда проблема ещё маленькая, но скорость её развития уже требует эскалации.
Попробуйте провести один эксперимент
На следующем management meeting не спрашивайте:
«Какие у нас проблемы?»
Спросите:
«Какие проблемы мы сейчас пытаемся решить самостоятельно, но через неделю пожалеем, что не подняли их сегодня?»
Пауза после этого вопроса может оказаться гораздо полезнее очередного dashboard.
А потом задайте второй:
«О какой плохой новости вам сегодня сложнее всего мне сказать?»
Если руководитель способен спокойно выслушать ответ, он может узнать о своей компании больше за десять минут, чем из двадцати KPI.
AI сделает эту проблему ещё интереснее
Мы входим в эпоху, когда информация внутри компании будет двигаться технически быстрее.
AI сможет анализировать тысячи сообщений.
Обнаруживать отклонения.
Предсказывать задержки.
Выделять риски.
Находить аномалии.
Создавать executive summaries практически мгновенно.
Но есть парадокс.
Компания может иметь AI, который обнаруживает проблему за 30 секунд, и культуру, которая сообщает о ней руководству через три дня.
Технология ускорит обнаружение.
Но она не исправит организационное поведение автоматически.
Поэтому следующим конкурентным преимуществом может стать не только скорость получения данных.
А скорость, с которой организация готова принять неприятную правду из этих данных.
Возможно, компаниям нужен ещё один KPI
Не обязательно помещать его на официальный dashboard.
Но руководителям стоит иногда задавать себе вопрос:
Каков наш Time to Bad News?
Минуты?
Часы?
Дни?
И ещё важнее:
что происходит с этим временем по мере роста компании?
Потому что организация из 20 человек может передавать плохие новости почти мгновенно.
При 200 сотрудниках появляются уровни.
При 2 000 — процессы.
При 20 000 — комитеты, отчёты, governance и escalation paths.
Каждый новый уровень управления способен добавить не только контроль.
Он способен добавить задержку правды.
Самая опасная компания — не та, в которой происходят ошибки
Ошибки происходят везде.
Проекты задерживаются.
Системы ломаются.
Люди ошибаются.
Прогнозы оказываются неверными.
Поставщики подводят.
Рынок меняется.
Ни одна технология и ни один management framework не создадут компанию, в которой никогда не возникает плохих новостей.
Поэтому зрелость организации определяется не отсутствием проблем.
Она определяется тем, что происходит после первых признаков проблемы.
Кто узнаёт?
Насколько быстро?
Насколько точно передаётся информация?
Можно ли сказать «мы не знаем»?
Есть ли у человека право эскалировать риск?
И остаётся ли к моменту принятия решения достаточно времени, чтобы действительно что-то изменить?
Вернёмся к нашему инженеру.
09:12.
Он увидел проблему.
В этот момент компания ещё ничего не потеряла.
У неё были варианты.
Настоящий таймер запустился именно тогда.
Не до устранения технической неисправности.
Не до ответа поставщика.
Не до совещания.
А до момента, когда информация попадёт к человеку, способному принять решение.
И поэтому, возможно, руководителю стоит измерять не только то, как быстро его компания решает проблемы.
Но и то, как быстро она осмеливается признать, что проблема существует.