Почему управление начинается с проектирования системы
Управление часто представляют как деятельность руководителя внутри уже существующей системы.
Поставить задачу.
Распределить ответственность.
Провести встречу.
Проверить результат.
Скорректировать отклонение.
Поддержать сотрудника.
Усилить контроль.
Принять решение.
На операционном уровне всё это действительно необходимо.
Но есть более фундаментальный уровень.
До того как руководитель начинает управлять людьми и задачами, уже существует среда, которая во многом определяет их поведение.
Кто имеет право принимать решения.
Как распределяются ресурсы.
Какие показатели считаются важными.
Что происходит при ошибке.
Как формируются приоритеты.
Где проходит граница ответственности.
Как быстро движется информация.
Что требуется согласовывать.
За какое поведение человек получает признание, деньги или карьерные возможности.
Именно эта архитектура часто влияет на результат сильнее, чем отдельные управленческие действия.
Поэтому зрелое управление начинается не с вопроса:
«Как заставить систему работать лучше?»
А с другого:
«Как должна быть устроена система, чтобы нужное поведение возникало в ней естественным образом?»
Большая часть поведения сотрудников рациональна внутри существующей системы
Руководители часто говорят:
«Люди не берут ответственность».
Но прежде чем работать с ответственностью, полезно посмотреть на условия.
Что произойдёт, если сотрудник самостоятельно примет решение?
Если оно окажется успешным — это будет считаться нормой.
Если ошибочным — может начаться разбор:
почему не согласовал?
На каком основании решил?
Почему не предупредил руководителя?
Через несколько таких ситуаций человек делает вполне рациональный вывод:
самостоятельность опасна.
Безопаснее согласовывать.
Теперь руководство наблюдает большое количество эскалаций и говорит:
«Команда недостаточно самостоятельная».
Но система сама обучила людей именно такому поведению.
Проблема здесь не только в людях.
Она находится в архитектуре полномочий и ответственности.
Поведение часто является следствием условий, а не личных качеств
Представим другую ситуацию.
Компания хочет усилить сотрудничество между функциями.
Но KPI устроены так:
продажи отвечают за объём;
операции — за себестоимость;
финансы — за снижение запасов;
клиентский сервис — за скорость решения обращения.
Каждая функция действует рационально внутри собственной цели.
Продажи хотят больше индивидуальных условий.
Операции сопротивляются вариативности.
Финансы ограничивают запас.
Сервис требует резервной мощности.
Возникают конфликты.
Можно провести командный тренинг.
Поговорить о сотрудничестве.
Организовать стратегическую сессию.
Это иногда помогает.
Но пока архитектура целей создаёт противоречие, система продолжит воспроизводить конфликт.
Именно поэтому системное мышление предлагает рассматривать результат как следствие взаимодействия элементов, а не только качества каждого участника отдельно.
Сильная система делает правильное поведение проще
Представим два процесса.
В первом сотрудник должен помнить о важном действии.
Зайти в таблицу.
Проверить дату.
Написать коллеге.
Получить ответ.
Обновить статус.
Поставить напоминание.
Во втором система автоматически показывает срок, отправляет уведомление, фиксирует статус и эскалирует отклонение.
В первом случае организация зависит от дисциплины человека.
Во втором — от архитектуры процесса.
Это не означает, что ответственность сотрудника больше не нужна.
Но зрелое управление старается уменьшать количество ситуаций, где хороший результат зависит исключительно от памяти, героизма и постоянного ручного контроля.
Управление системой сильнее управления отдельным действием
Руководитель может ежедневно напоминать:
«Пожалуйста, поднимайте риски раньше».
Но если ранний сигнал приводит к критике, риски всё равно будут появляться поздно.
Можно говорить:
«Не берите слишком много задач».
Но если каждый новый запрос руководства объявляется приоритетным, незавершённая работа будет расти.
Можно требовать:
«Принимайте решения быстрее».
Но если полномочия размыты, сотрудники продолжат согласовывать.
Можно призывать:
«Думайте о клиенте».
Но если KPI вознаграждает только внутреннюю эффективность, поведение будет соответствовать KPI.
Управленческое воздействие на человека ограничено, если сама система толкает его в противоположную сторону.
Именно поэтому хороший руководитель постепенно становится архитектором
На ранних этапах управленческой карьеры результат часто создаётся через непосредственное вмешательство.
Проверить.
Помочь.
Скоординировать.
Решить конфликт.
Уточнить.
Подтолкнуть.
Но по мере роста масштаба эта модель перестаёт работать.
Если руководитель управляет десятками людей и множеством процессов, он уже не может лично присутствовать в каждой точке.
Ему нужна система, которая продолжает работать без постоянного участия.
Здесь меняется сама единица управления.
Не отдельная задача.
Не отдельный сотрудник.
А условия, в которых множество людей регулярно принимают решения.
Проектирование системы начинается с результата
Очень легко начать проектировать с процесса.
Как должна выглядеть структура?
Какие встречи проводить?
Какой регламент написать?
Какие роли создать?
Но сначала нужен другой вопрос:
какой результат система должна устойчиво производить?
Например:
быстро выводить продукт;
сохранять качество при росте;
снижать время принятия решений;
обеспечивать предсказуемость проектов;
быстро адаптироваться к изменениям спроса.
После этого можно проектировать механизмы.
Если результат не определён, организация рискует создать красивую систему без ясной функции.
Структура должна соответствовать потоку ценности
Это особенно важно в компаниях с сильными функциональными подразделениями.
Оргструктура может выглядеть логично:
маркетинг;
продажи;
операции;
ИТ;
финансы;
HR.
Но клиентский результат проходит через несколько функций.
В одной появляется запрос.
В другой — решение.
В третьей — исполнение.
В четвёртой — поддержка.
Если управление построено только вертикально, на границах начинают возникать потери.
Ожидание.
Передача ответственности.
Разные приоритеты.
Повторное объяснение.
Согласования.
Конфликты KPI.
Каждый отдел может работать хорошо, а общий поток — плохо.
Поэтому проектирование системы должно учитывать не только структуру подразделений, но и сквозное движение результата.
Границы ответственности должны совпадать с правом действия
Одна из наиболее разрушительных конструкций выглядит так:
человек отвечает за результат, но не может принимать ключевые решения.
Например, руководитель проекта отвечает за срок.
Но не контролирует ресурс.
Не способен остановить менее важную инициативу.
Не определяет приоритет.
Не может изменить объём.
Не управляет внешними зависимостями.
Формально ответственность есть.
Практически система не даёт человеку достаточных рычагов.
После срыва срока начинается вопрос:
«Почему не обеспечили результат?»
Такая архитектура постепенно разрушает и ответственность, и доверие.
Поэтому проектирование управления требует постоянно сопоставлять:
за что человек отвечает;
какими полномочиями обладает;
какую информацию получает;
какими ресурсами управляет.
Решение должно приниматься на минимально необходимом уровне
Централизация кажется безопасной.
Чем важнее решение, тем выше хочется его поднять.
Но если слишком много решений поднимается вверх, появляется очередь.
Руководитель становится ограничением системы.
Сотрудники ждут.
Клиенты ждут.
Проекты ждут.
Потом руководство жалуется:
«Организация медленно принимает решения».
Самое сильное изменение может заключаться не в том, чтобы требовать большей скорости.
А в перепроектировании прав решений.
Какие вопросы действительно должны доходить до директора?
Какие можно принимать ниже?
При каких условиях?
Какой риск допустим?
Когда нужна эскалация?
Так скорость появляется не из давления.
Она появляется из архитектуры.
Хорошая система делает эскалацию исключением, а не основным способом работы
Если почти любой спор доходит до руководителя, это не обязательно означает высокую вовлечённость лидера.
Возможно, в системе не хватает правил принятия решения.
Например, две функции конфликтуют за ресурс.
Каждый раз вопрос решает директор.
Вместо этого можно определить:
по каким критериям распределяется ресурс;
кто имеет финальное слово;
какие инициативы выше по приоритету;
как обрабатывается исключение.
Тогда руководитель больше не обязан каждый раз быть ручным интегратором.
Приоритетизация — это элемент архитектуры
Многие проблемы с исполнением начинаются не внутри команды.
Они появляются выше.
Организация запускает слишком много проектов.
Каждый имеет спонсора.
Каждый важен.
Ресурсы пересекаются.
Даты рассчитаны так, будто все инициативы существуют изолированно.
Дальше начинается операционный хаос.
Руководители требуют:
лучше планировать;
быстрее работать;
точнее оценивать.
Но проблема создана на уровне портфеля.
Если организация принимает больше обязательств, чем физически способна выполнить, никакая локальная эффективность не устранит конфликт.
В роли Head of HR PMO пользователь как раз формулирует важность портфельной приоритизации, прозрачности ресурсов, зависимостей и рисков как отдельного управленческого контура.
Реальные приоритеты определяются не словами, а ресурсами
Можно объявить инициативу стратегической.
Но если ключевые специалисты заняты другими проектами, реальный приоритет находится там.
Можно сказать:
«Качество для нас главное».
Но если сроки всегда важнее, сотрудники быстро понимают настоящую систему.
Можно заявить:
«Развитие людей — приоритет».
Но если обучение первым отменяется в период нагрузки, культура считывает другой сигнал.
Архитектура управления проявляется прежде всего в том:
куда уходят деньги;
время;
люди;
внимание руководства.
Именно поэтому проектирование системы невозможно отделить от распределения ресурсов.
Метрики тоже являются частью дизайна
Показатель не просто измеряет систему.
Он изменяет её.
Если команда оценивается по количеству закрытых задач, появится стимул закрывать больше небольших задач.
Если подбор оценивается только по скорости, качество может стать вторичным.
Если продажи мотивируются только на выручку, маржинальность может пострадать.
Если руководитель получает бонус исключительно за результат функции, межфункциональное сотрудничество легко превращается в издержку.
Поэтому сильный вопрос:
какое поведение станет рациональным, если мы введём этот KPI?
Не только:
«Что он будет измерять?»
Метрика — это элемент архитектуры стимулов.
Информационные потоки проектируются так же, как процессы
Руководитель может принимать качественные решения только на основании доступной информации.
Если данные приходят поздно, решение будет поздним.
Если информация проходит через множество уровней, она искажается.
Если плохие новости фильтруются, руководство получает чрезмерно оптимистичную картину.
Если разные функции используют разные версии данных, появляются бесконечные споры о фактах.
Поэтому проектирование управленческой системы включает вопрос:
кто, что, когда и в каком виде должен видеть?
Прозрачность — это не количество отчётов.
Это способность системы доставлять нужную информацию к точке решения до того, как окно возможностей закроется.
Хороший дашборд — тоже элемент архитектуры
Он не должен просто показывать много цифр.
Он должен помогать управлять.
Что изменилось?
Где отклонение?
Какой тренд?
Какая зависимость под угрозой?
Какой ресурс перегружен?
Какое решение требуется?
Кто его должен принять?
В таком виде аналитика становится частью управленческого контура.
Она соединяет наблюдение и действие.
Проектирование системы требует учитывать обратные связи
Допустим, руководство усиливает контроль после нескольких ошибок.
Ошибок становится меньше.
Хорошо.
Но появляется вторичный эффект.
Решения замедляются.
Сотрудники меньше рискуют.
Больше вопросов поднимается вверх.
Руководители перегружаются.
Система становится менее адаптивной.
Теперь очередная задержка вызывает ещё больше контроля.
Получается самоподдерживающийся цикл.
Системное мышление необходимо именно потому, что изменение одного элемента может запускать последствия в других частях системы. Это один из базовых принципов PMBOK 7, где проект рассматривается как часть взаимосвязанной системы, изменяющейся под воздействием внутренних и внешних факторов.
Любая система создаёт побочные эффекты
Невозможно спроектировать идеальную организацию.
Каждый выбор имеет цену.
Централизация повышает единообразие, но может снизить скорость.
Децентрализация повышает автономию, но усложняет координацию.
Высокая специализация увеличивает экспертизу, но создаёт больше передач между функциями.
Универсальные команды уменьшают зависимости, но могут быть дороже.
Строгие стандарты повышают предсказуемость, но уменьшают пространство адаптации.
Поэтому проектирование системы — это не поиск правильной модели.
Это управление компромиссами.
Хорошая архитектура делает компромиссы явными
Например:
где важнее скорость, а где контроль;
где допустима автономия, а где требуется стандарт;
где нужен резерв мощности;
где можно принимать риск;
какая ошибка обратима;
какое решение требует высокого уровня согласования.
Если эти компромиссы не определены заранее, они всё равно будут существовать.
Но принимать их начнут ситуативно.
И тогда организация становится зависимой от личности руководителя.
Сильная система должна нормально работать не только при идеальных людях
Это один из лучших критериев архитектуры.
Если процесс работает только потому, что его ведёт исключительно сильный специалист, это слабая система.
Если проект успешен только потому, что PM лично контролирует все зависимости, система слабая.
Если функция держится на руководителе, который постоянно решает всё вручную, система слабая.
Сильная архитектура должна снижать зависимость от исключительного героизма.
Она помогает нормальному профессионалу получать хороший результат.
А сильному — заниматься задачами более высокого уровня.
Это не означает борьбу с сильными людьми
Наоборот.
Сильный человек особенно ценен, когда перестаёт быть постоянным компенсатором системных дефектов.
Если опытный руководитель каждый день тушит однотипные пожары, компания использует его компетенцию плохо.
После очередной проблемы полезно спросить:
что нужно изменить в системе, чтобы такая ситуация больше не требовала моего личного вмешательства?
Этот вопрос постепенно превращает руководителя из пожарного в архитектора.
Процессы должны быть спроектированы вокруг нормального сценария и исключений
Очень распространённая ошибка — создать идеальный процесс для стандартной ситуации.
А потом выясняется, что реальные кейсы постоянно выходят за его рамки.
Возникают исключения.
Ручные обходы.
Неофициальные договорённости.
Дополнительные таблицы.
Специальные чаты.
Это сильный сигнал.
Если исключение стало регулярным, оно уже часть системы.
Нужно не требовать лучше соблюдать первоначальную схему.
Нужно перепроектировать её с учётом реального поведения.
Архитектура должна уменьшать количество незавершённой работы
Организации часто пытаются ускориться через увеличение активности.
Запустить больше проектов.
Дать людям больше задач.
Открыть больше направлений.
Но каждая единица незавершённой работы создаёт стоимость.
Её нужно отслеживать.
Координировать.
Обновлять.
Держать в памяти.
Управлять зависимостями.
Если незавершённой работы становится слишком много, система замедляется.
Поэтому ограничение WIP — не просто практика команды.
Это принцип проектирования потока.
Иногда лучший способ повысить скорость системы — начать меньше.
Архитектура должна учитывать ограничение
Не все части системы одинаково определяют результат.
Есть участок, где образуется очередь.
Редкая компетенция.
Один уровень согласования.
Одна технология.
Один поставщик.
Если ограничение работает на пределе, оптимизация других участков может почти ничего не дать.
Более того, она способна увеличить очередь перед bottleneck.
В материалах по системному мышлению отдельно подчёркивается необходимость анализировать процесс целиком и искать ограничение, определяющее результат всей системы.
Поэтому проектирование начинается не с идеи:
«Сделаем все функции максимально эффективными».
А с вопроса:
«Что сегодня ограничивает способность всей системы создавать результат?»
Культура тоже является частью архитектуры
Культуру часто воспринимают как что-то мягкое.
Ценности.
Коммуникация.
Отношения.
Но на практике культура отвечает на очень конкретные вопросы.
Что здесь безопасно говорить?
Что происходит после ошибки?
Можно ли спорить с руководителем?
Что важнее — результат или демонстрация лояльности?
Вознаграждается ли самостоятельность?
Можно ли остановить плохую инициативу?
Насколько обязательны обещания?
Эти правила формируются через повторяющиеся действия системы.
Поэтому культура не отделена от управления.
Она является результатом того, как спроектированы и применяются управленческие механизмы.
Нельзя создать культуру ответственности в системе без полномочий
Нельзя создать культуру открытости, наказывая за плохие новости.
Нельзя создать культуру сотрудничества при конфликтующих KPI.
Нельзя создать культуру экспериментов, если каждая неудача требует поиска виновника.
Нельзя создать культуру фокуса, если руководство постоянно добавляет новые приоритеты.
Именно поэтому ценности без архитектурной поддержки постепенно превращаются в декларации.
Проектирование начинается с понимания реального поведения, а не идеальной модели
Организационные схемы часто описывают то, как система должна работать.
Но настоящий анализ начинается с наблюдения.
Как на самом деле принимается решение?
К кому идут за неформальным разрешением?
Где работа ждёт?
Какие процессы обходят?
Какие правила нарушаются регулярно?
Кто фактически определяет приоритет?
Где возникают ручные компенсации?
Как люди защищаются от системы?
Это и есть реальная архитектура.
Она может сильно отличаться от регламента.
Обходные пути — один из лучших источников информации
Если сотрудники создают Excel рядом с корпоративной системой, не обязательно сразу запрещать Excel.
Нужно понять:
какую потребность официальная система не закрывает?
Если руководители создают неформальный чат для быстрых решений, возможно, официальный процесс слишком медленный.
Если команда создаёт параллельный backlog, вероятно, единый backlog не отражает реальный способ работы.
Обходной путь часто является не нарушением.
Это адаптация системы.
А значит — диагностический сигнал для архитектора.
Хорошая система умеет различать стандарт и исключение
Полная стандартизация невозможна.
Полная свобода — тоже.
Зрелая архитектура определяет:
что должно быть одинаково всегда;
где допустима вариативность;
кто имеет право отступить от стандарта;
как исключение фиксируется;
когда регулярное исключение становится основанием изменить сам стандарт.
Так организация одновременно сохраняет управляемость и способность адаптироваться.
Архитектура управления должна развиваться вместе с масштабом
То, что хорошо работает в компании из пятидесяти человек, может разрушиться при пятистах.
На раннем этапе собственник может знать все ключевые вопросы.
Решения принимаются быстро.
Информация распространяется неформально.
Люди понимают контекст.
Компания растёт.
Количество решений увеличивается.
Появляются уровни управления.
Функции.
Регламенты.
Но если архитектура не меняется, собственник остаётся центральной точкой.
Тогда появляется bottleneck.
Рост организации требует роста системы управления.
Масштабирование — это не умножение старой модели
Если команда из десяти человек успешно работает неформально, десять таких команд не обязательно смогут работать так же.
Появляются межкомандные зависимости.
Общие ресурсы.
Архитектурные ограничения.
Портфельные конфликты.
Нужен новый уровень координации.
Проектирование системы поэтому всегда зависит от масштаба.
То, что раньше было избыточной бюрократией, позже может стать необходимым управленческим контуром.
И наоборот.
Механизм, который раньше помогал, со временем способен стать ограничением.
Сильная архитектура должна предусматривать изменение самой себя
Это особенно важный принцип.
Нельзя один раз спроектировать организацию и считать работу завершённой.
Среда меняется.
Компания растёт.
Технологии развиваются.
Появляются новые продукты.
Меняется рынок труда.
Возникают новые риски.
Поэтому управленческая система должна иметь механизмы собственного пересмотра.
Ретроспективы.
Операционные обзоры.
Портфельные циклы.
Пересмотр KPI.
Анализ процессов.
Организационные диагностики.
То есть в саму архитектуру должна быть встроена способность адаптироваться.
ИИ делает вопрос архитектуры ещё важнее
Когда инструмент усиливает скорость выполнения отдельных задач, ограничение всё чаще перемещается в устройство самой системы.
Сотрудник способен быстрее создать анализ.
Документ.
Код.
Презентацию.
Отчёт.
Но если после этого результат ждёт три согласования, общий поток почти не ускоряется.
Если решение всё равно принимает один перегруженный руководитель, скорость генерации информации только увеличивает очередь перед ним.
Это важный управленческий эффект.
Чем мощнее становятся отдельные инструменты, тем заметнее слабость архитектуры вокруг них.
Автоматизация плохого процесса делает плохой процесс быстрее
Поэтому цифровая трансформация тоже должна начинаться с архитектуры.
Что мы пытаемся улучшить?
Нужен ли этот этап?
Почему существует согласование?
Кто использует эти данные?
Можно ли убрать действие?
Как изменится поток после автоматизации?
Если просто оцифровать существующую сложность, организация получает более технологичную сложность.
Но не обязательно более сильную систему.
Проектирование системы требует отказаться от иллюзии полного контроля
Система, в которой руководство пытается предусмотреть все ситуации, становится слишком тяжёлой.
Регламенты разрастаются.
Согласования увеличиваются.
Исключения множатся.
При этом среда всё равно остаётся неопределённой.
Поэтому зрелая архитектура проектирует не полный контроль.
Она проектирует способность справляться с отклонением.
Как быстро мы обнаруживаем изменение?
Кто способен принять решение?
Как получает информацию?
Какой риск допустим?
Как система обучается после события?
Это значительно устойчивее попытки заранее описать каждый возможный случай.
Управление не должно стремиться устранить неопределённость
Оно должно делать её управляемой.
В проектах это особенно очевидно.
PMBOK 7 рассматривает проекты как системы, работающие внутри более широкого контекста и постоянно меняющиеся под воздействием внешних и внутренних факторов.
Нельзя создать план, который гарантированно останется правильным.
Но можно создать систему, которая быстро обнаруживает отклонение и своевременно корректирует решение.
Это и есть архитектурная задача.
Хорошая архитектура освобождает внимание руководителя
Это один из наиболее практичных результатов.
В слабой системе руководитель постоянно работает с исключениями.
Кто-то не договорился.
Что-то потерялось.
Ресурс конфликтует.
Приоритет непонятен.
Решение зависло.
Информация не дошла.
В сильной системе большая часть типовых ситуаций разрешается без него.
Тогда внимание руководителя можно направить туда, где оно действительно необходимо.
Стратегия.
Сложные компромиссы.
Новые риски.
Развитие системы.
Будущие ограничения.
Именно это является одним из главных результатов зрелого управления.
Чем выше уровень руководителя, тем меньше его ценность должна зависеть от количества личных решений
Если директор гордится тем, что без него ничего не происходит, система находится в опасной зависимости.
Сильный директор должен стремиться к противоположному.
Чтобы большая часть правильных решений принималась без него.
В понятных границах.
С нужной информацией.
С ясной ответственностью.
С механизмом эскалации действительно сложных случаев.
Тогда руководитель перестаёт быть центром управления каждой операцией.
Он становится автором среды, в которой управление распределено.
Это и есть переход от руководства людьми к проектированию условий
Поставить задачу можно быстро.
Создать систему, в которой человеку понятно, какую задачу выбирать самому, значительно сложнее.
Проверить работу можно лично.
Создать прозрачность, при которой отклонения становятся видимыми без постоянной проверки, сложнее.
Разрешить конфликт можно административно.
Спроектировать правила, которые уменьшают вероятность повторения конфликта, сложнее.
Именно поэтому архитектурное управление требует более высокого уровня мышления.
Оно работает не только с текущим событием.
Оно работает с механизмом воспроизводства событий.
Сильная управленческая система отвечает на несколько фундаментальных вопросов
Как создаётся ценность?
Кто отвечает за конечный результат?
Где принимаются решения?
Какие полномочия нужны для этой ответственности?
Как устанавливаются приоритеты?
Как распределяются ограниченные ресурсы?
Как информация достигает точки решения?
Как обнаруживаются риски?
Что происходит при отклонении?
Как система учится?
Какие стимулы формируют поведение?
Как мы понимаем, что сама архитектура перестала работать?
Если эти вопросы не решены осознанно, ответы всё равно появятся.
Но стихийно.
Через привычки.
Личные договорённости.
Политику.
Исторические правила.
И именно эта неформальная система начнёт реально управлять организацией.
Проектирование системы не отменяет лидерство
Даже идеальная архитектура не заменит руководителя.
Всегда будут ситуации, которые невозможно заранее описать.
Конфликты интересов.
Кризисы.
Этические вопросы.
Стратегическая неопределённость.
Сложные кадровые решения.
Но хорошая архитектура позволяет не тратить лидерство на то, что должно решаться системой.
Это принципиальная разница.
Лидер нужен там, где требуется суждение.
А не там, где процесс просто не был нормально спроектирован.
Управленческая зрелость проявляется в вопросе после каждой повторяющейся проблемы
Можно спросить:
«Кто должен исправить?»
А можно:
«Что в системе позволяет этой проблеме возникать снова?»
Первый вопрос помогает решить сегодняшний случай.
Второй — уменьшить вероятность завтрашнего.
Именно поэтому управление начинается с проектирования системы.
Потому что любой руководитель физически ограничен.
Он не может проверить всё.
Решить всё.
Проконтролировать всё.
Знать всё.
Но он способен создать условия, в которых множество людей принимают значительно больше правильных решений без его участия.
В этом и заключается один из главных переходов от операционного управления к настоящему лидерству.
Слабая система требует сильного руководителя каждый день.
Сильная система позволяет сильному руководителю заниматься будущим.
И, возможно, главный вопрос управленца поэтому звучит не так:
«Как мне добиться нужного результата от людей?»
А так:
«Какую систему нужно создать, чтобы нужный результат становился естественным следствием того, как здесь устроена работа?»
Данный материал носит исключительно ознакомительный и дискуссионный характер и отражает личное мнение автора.
