21 августа в «Фармакоде» прошла закрытая встреча, посвящённая личной эффективности руководителя. Спикером стала Елена Куренная, executive coach, бизнес-тренер, фасилитатор и дизайнер обучения. В разговоре участвовали руководители из ИТ, поэтому довольно быстро обсуждение вышло за рамки классического тайм-менеджмента и перешло к вопросам, которые для CIO гораздо существеннее: как устроена зависимость команды от руководителя, что действительно имеет смысл делегировать, почему постоянные переключения незаметно съедают управленческий ресурс и где проходит граница между полезным применением ИИ и автоматизацией плохо устроенного процесса.
Личная эффективность CIO определяется не количеством задач, которые он способен закрыть самостоятельно, а тем, насколько хорошо работает ИТ-функция без его постоянного вмешательства. Если большинство решений, согласований и нестандартных ситуаций неизменно сходятся к одному человеку, увеличение личной продуктивности руководителя лишь откладывает решение системной проблемы.
Разговор начался с простого мысленного эксперимента. Участникам предложили представить, что руководитель на две недели полностью выпадает из рабочего процесса. Он не читает почту и сообщения, не участвует в совещаниях, не согласовывает документы и не может быстро подключиться к сложному вопросу.
Для ИТ-руководителя это довольно точный диагностический вопрос. Если без CIO начинают останавливаться проекты, руководители направлений откладывают решения, а значительная часть нетиповых ситуаций просто ждёт возвращения начальника, речь идёт уже не столько о личной загрузке, сколько об устройстве всей системы управления.
Один из вопросов, с которого началась встреча: что произойдёт с работой функции, если руководитель на две недели полностью выпадет из процессов?
Сильная экспертиза иногда начинает работать против руководителя
В ИТ эта проблема возникает вполне естественным образом. Многие руководители вырастают из технических или проектных ролей и хорошо знают предметную область. Они способны оценить архитектурное решение, подключиться к сложному проекту, поговорить с подрядчиком на языке его инженеров, быстро разобраться в инциденте или заметить риск, который менее опытный сотрудник пока не видит.
На определённом этапе такая вовлечённость помогает. В небольшой команде сильный эксперт действительно ускоряет принятие решений и снижает вероятность ошибок. Сложность появляется позже, когда ИТ-функция растёт, появляются руководители направлений, архитекторы и владельцы систем, увеличивается количество проектов и подрядчиков, а привычная модель принятия решений почти не меняется.
CIO продолжает участвовать в вопросах, которыми когда-то занимался лично, хотя организационно они уже находятся уровнем ниже. Руководители направлений привыкают приносить наверх сложные решения, сотрудники знают, что спорный вопрос всегда можно эскалировать, а бизнес постепенно начинает воспринимать ИТ-директора как универсальную точку входа практически по любой технологической теме.
В результате сильная профессиональная экспертиза неожиданно начинает создавать дополнительную зависимость. Чем быстрее руководитель способен самостоятельно решить проблему, тем проще команде обратиться именно к нему. Чем чаще он подключается, тем меньше у подчинённых необходимости накапливать собственный опыт принятия решений.
На встрече эффективность рассматривали как сочетание ресурса, управленческих компетенций и образа мышления. Для ИТ-руководителя особенно важна взаимосвязь этих трёх элементов: высокой профессиональной квалификации недостаточно, если значительная её часть расходуется на оперативные вопросы, которые организация уже должна уметь решать без постоянного участия CIO.
Как ИТ-руководителю анализировать собственную рабочую нагрузку
Один из участников встречи рассказал об опыте компании, где руководители в течение недели фиксировали, куда на самом деле уходит их рабочее время. После такого хронометража выяснилось, что значительную его часть занимают совещания, и компания в итоге даже ограничила дни, в которые разрешалось проводить внутренние встречи.
Сам по себе подсчёт часов мало что меняет. Его ценность появляется на следующем этапе, когда руководитель начинает разбирать содержание рабочего дня и задавать другой вопрос: почему именно он участвует в конкретной деятельности?
В презентации предложено каждое регулярное действие относить к одной из четырёх категорий: то, что руководитель действительно должен делать сам; то, что можно делегировать; то, что можно автоматизировать; и то, что можно перестать делать вообще.
После хронометража важно не просто увидеть, куда ушло время, а определить, какую работу действительно должен выполнять сам руководитель.
Для ИТ-директора такое упражнение нередко даёт довольно неприятную, но полезную картину. В календаре обнаруживаются регулярные встречи, на которых он исторически присутствовал ещё до появления руководителя соответствующего направления; согласования, которые когда-то требовали его решения, но давно стали типовыми; проектные статусы, где CIO выступает скорее наблюдателем; вопросы подрядчиков, которые вполне могли бы решаться на другом уровне.
Каждый такой эпизод по отдельности кажется несущественным. Двадцать минут здесь, полчаса там, ещё одно согласование между встречами. Но именно из этих небольших включений постепенно складывается режим, в котором у ИТ-директора почти не остаётся непрерывного времени на задачи, соответствующие его уровню ответственности: развитие архитектуры, работу с ключевыми сотрудниками, стратегию, инвестиционные решения и нормальный разговор с бизнесом о том, что компании понадобится через год или два.
Поэтому хронометраж имеет смысл не как способ ещё плотнее упаковать календарь. Он позволяет увидеть работу, которую руководитель продолжает выполнять главным образом потому, что организация привыкла к его участию.
Ранее в «Фармакоде» мы отдельно разбирали тему выгорания ИТ-руководителей и того, почему обычный отпуск далеко не всегда решает проблему накопленной управленческой нагрузки.
Почему постоянные переключения снижают эффективность CIO
Для ИТ-управления характерна ещё одна особенность: руководителю приходится в течение дня работать с очень разными типами контекста. Утром он может обсуждать бюджет проекта, затем отвечать на вопрос по информационной безопасности, согласовывать договор, разбирать кадровую ситуацию и после этого пытаться вернуться к архитектурной инициативе.
Внешне такой день выглядит насыщенным. Однако сложные управленческие задачи требуют другого режима работы, в котором человек способен некоторое время удерживать один контекст и не реагировать на каждый новый входящий сигнал.
На встрече эту проблему обсуждали через понятие ментальной энергии. Постоянные переключения, большой информационный поток, большое количество решений и работа в условиях неопределённости постепенно сокращают ресурс, который нужен для анализа и осмысленного принятия решений.
Для CIO здесь возникает уже не только личный, но и организационный вопрос. Если руководитель не может на час или два отключиться от текущей коммуникации, потому что за это время обязательно возникнет вопрос, который никто другой не вправе или не способен решить, проблема находится не в недостаточной дисциплине самого CIO.
Можно выключить уведомления и заблокировать время в календаре, но если большинство значимых решений по-прежнему сходится в одну точку, организация довольно быстро вернёт руководителя в привычный режим. Поэтому защита собственного времени требует не только личных правил, но и понятного распределения ответственности внутри ИТ-функции: какие решения принимаются без CIO, какие требуют его участия, а какие должны эскалироваться только при выполнении заранее определённых условий.
Именно здесь разговор о личной эффективности перестаёт быть разговором о ежедневнике и переходит к устройству команды.
Делегирование в ИТ-команде: задача, полномочия и контроль
Для ИТ-руководителей сама идея делегирования обычно не нова. На уровне CIO никто не пытается выполнять всю работу собственными руками. Тем не менее передача задачи ещё не означает передачу ответственности за её решение.
Характерная ситуация выглядит вполне безобидно. Руководитель направления получает задачу, начинает с ней работать, а затем приходит к CIO с вопросом: «Как лучше поступить?» Руководитель предлагает вариант. Через некоторое время появляется следующее уточнение, затем ещё одно. Формально задача по-прежнему находится у сотрудника, но интеллектуальная работа и принятие ключевых решений постепенно возвращаются наверх.
Поэтому на встрече делегирование рассматривали как передачу не только самой работы, но и пространства самостоятельности. В модели, которую разбирала Елена Куренная, для этого необходимо определить ожидаемый результат, полномочия исполнителя, границы самостоятельности, критерии качества и контрольные точки.
Полноценное делегирование включает не только задачу, но и полномочия, границы самостоятельности, критерии результата и точки контроля.
Для ИТ-функции особенно важны полномочия и границы. Руководителю инфраструктуры трудно отвечать за результат, если любое изменение требует согласования с CIO. Архитектор не может действительно владеть архитектурным решением, если его позиция считается предварительной до личного одобрения директора. Руководитель проекта остаётся скорее координатором, если существенные вопросы по срокам, ресурсам и подрядчикам неизменно возвращаются наверх.
При этом делегирование не освобождает CIO от ответственности за работу функции. Оно меняет сам способ контроля. Вместо постоянного участия в каждом шаге руководитель договаривается о результате, определяет ограничения и заранее устанавливает ситуации, в которых действительно необходимо его подключение.
Для технологических команд эта разница особенно заметна. Квалифицированные специалисты довольно быстро понимают, когда им формально передали ответственность, но фактически оставили только право выполнять уже принятые наверху решения. После нескольких таких эпизодов самостоятельность становится ритуальной: сотрудник заранее приходит согласовывать всё, что потенциально может вызвать спор, а руководитель постепенно получает именно ту зависимую команду, на которую затем жалуется.
Почему «я быстрее сделаю сам» работает только на короткой дистанции
У технически сильных руководителей есть ещё одна понятная привычка: самостоятельно включаться в задачу, когда очевидно, что они решат её быстрее сотрудника.
В конкретной ситуации это может быть вполне рационально. Если проблема требует немедленного решения, не всегда есть возможность превращать её в учебный кейс для команды. Но регулярное использование такой модели имеет накопительный эффект.
Сегодня CIO самостоятельно решает вопрос за двадцать минут вместо того, чтобы потратить час на объяснение. Завтра сотрудник снова приходит с похожей задачей, потому что вчера у него не появилось собственного опыта её решения. Через несколько месяцев руководитель всё ещё делает такую работу быстрее всех, что становится новым доказательством необходимости его личного участия.
На встрече среди типичных управленческих паттернов обсуждали установки «я быстрее сделаю сам», «я должен всё знать», «ко мне можно прийти в любой момент» и «если я не проконтролирую, не сделают». Каждая из них может быть оправдана в отдельной ситуации. Проблема начинается тогда, когда исключение превращается в обычный способ управления.
Управленческие установки, которые выглядят рациональными в отдельной ситуации, при постоянном повторении формируют зависимую от руководителя систему.
Для CIO здесь существует ещё один риск. Чем выше находится руководитель в организации, тем дороже обходится его время, потраченное на задачу, которую мог выполнить другой сотрудник. Причём речь не только о стоимости рабочего часа. Каждое такое включение вытесняет работу, которую вместо ИТ-директора, скорее всего, не выполнит никто: переговоры с бизнесом, развитие ключевых сотрудников, формирование технологической повестки, оценку долгосрочных рисков и подготовку решений, последствия которых компания будет ощущать несколько лет.
Поэтому вопрос «могу ли я сделать это быстрее?» на уровне руководителя далеко не всегда самый полезный. Важнее понять, действительно ли организация выигрывает от того, что именно CIO продолжает выполнять эту работу.
Как CIO использовать ИИ для делегирования интеллектуальной работы
Обсуждение искусственного интеллекта на встрече оказалось логичным продолжением темы делегирования. При передаче части интеллектуальной работы ИИ возникают практически те же вопросы, что и при работе с сотрудником: насколько хорошо описан процесс, понятен ли ожидаемый результат, существуют ли критерии качества и может ли человек проверить полученный результат.
В презентации для этого предложен довольно простой фильтр. Если задача выполняется регулярно, её можно описать, результат имеет понятные критерии и его возможно проверить человеком, часть работы имеет смысл попробовать передать ИИ. При этом ответственность, итоговое решение, оценка критических рисков и значимый бизнес-контекст остаются за человеком.
Передача задачи ИИ требует тех же базовых условий: понятного процесса, критериев результата и возможности проверить полученный ответ.
Для ИТ-руководителя область применения такой логики значительно шире подготовки писем или протоколов встреч. ИИ можно использовать для первичной структуризации большого массива информации, сравнения вариантов, подготовки материалов к совещанию, анализа документа, поиска противоречий или получения нескольких альтернативных подходов к задаче.
Один из участников встречи рассказал о практике подготовки ИТ-проекта к защите перед бизнесом. После создания презентации он предлагает ИИ посмотреть на неё с позиции генерального директора: какие вопросы возникнут, какие аргументы недостаточно убедительны, где автор опирается на знания, которых у аудитории нет, и почему руководству вообще следует инвестировать в этот проект.
Такой подход позволяет увидеть материал с позиции человека, который не жил внутри проекта несколько месяцев и не обязан понимать техническую ценность решения без дополнительных объяснений.
Однако в обсуждении прозвучало и важное ограничение. Если модели просто назначить роль генерального директора, но не дать фактического контекста о компании, её стратегии, текущих проблемах и критериях принятия решений, она неизбежно начинает заполнять отсутствующую информацию предположениями. Получается аккуратно сформулированная, но отчасти вымышленная оценка.
Этот пример хорошо показывает общий принцип: автоматизация приносит наибольшую пользу там, где руководитель уже понимает процесс и способен оценить качество результата. Если в самом процессе нет ясности, технология не создаёт её автоматически, а только позволяет быстрее воспроизводить существующую неопределённость.
Креативность как рабочий инструмент ИТ-руководителя
Тема креативного мышления на первый взгляд может показаться менее связанной с повседневной работой CIO, хотя именно ИТ-руководителям регулярно приходится искать решения внутри довольно жёстких ограничений.
Нельзя бесконечно увеличивать бюджет и штат, невозможно каждый раз переносить сроки, технологический ландшафт нельзя одномоментно заменить на новый, а требования бизнеса при этом редко становятся скромнее. Значительная часть работы ИТ-директора как раз и состоит в поиске приемлемого решения в ситуации, где очевидного варианта нет.
На встрече обсуждали рефрейминг, SCAMPER, метод шести шляп мышления, ТРИЗ и поиск аналогий в других индустриях. Практический смысл этих подходов для руководителя состоит не столько в необходимости запомнить очередной набор названий, сколько в способности сознательно изменить формулировку проблемы.
Иногда вместо вопроса о том, какие дополнительные ресурсы нужны для решения, полезнее разобраться, что можно убрать из процесса. Вместо попытки ускорить существующий порядок действий стоит проверить, почему этот порядок вообще возник и сохраняет ли он смысл. Вместо поиска стандартной отраслевой практики имеет смысл посмотреть, как аналогичная проблема решается там, где ограничения ещё жёстче.
ИИ и здесь может быть полезен как средство быстро проверить несколько рамок и вариантов, однако качество такой работы по-прежнему зависит от профессиональной подготовки человека. Если руководитель понимает предметную область и знает, каким способом хочет анализировать задачу, ИИ помогает быстрее пройти несколько итераций. Если такой основы нет, большое количество вариантов само по себе не делает решение лучше.
Почему известные инструменты так редко меняют поведение
К концу встречи возник вполне закономерный вопрос: если большинство обсуждавшихся принципов руководителям давно знакомы, почему проблемы с делегированием, приоритетами и постоянной перегрузкой продолжают повторяться?
В презентации этот переход описан через путь от знания к устойчивой компетенции. Сначала руководитель знает инструмент, затем умеет им пользоваться, начинает применять регулярно, и только после этого новое поведение постепенно становится привычным способом принимать решения.
Для ИТ эта логика вообще должна быть интуитивно понятна. Мы не считаем информационную систему внедрённой только потому, что установили программное обеспечение и провели обучение пользователей. Требуются изменение процессов, практика эксплуатации, исправление ошибок и время, пока новый способ работы действительно станет повседневным.
С управленческими навыками происходит примерно то же самое, хотя почему-то от них часто ожидают мгновенного эффекта после книги, тренинга или стратегической сессии.
Поэтому попытка одновременно перестроить календарь, внедрить несколько методов приоритизации, изменить все совещания, полностью переработать делегирование и начать иначе использовать ИИ вряд ли даст устойчивый результат. Гораздо реалистичнее выбрать одну наблюдаемую проблему и несколько недель работать именно с ней.
Например, можно посмотреть, какие решения руководители направлений регулярно возвращают CIO, и разобраться, чего им не хватает для самостоятельности: полномочий, информации, компетенции или уверенности в том, что руководитель действительно разрешает принять решение без него. Другой вариант — провести хронометраж двух рабочих недель и выяснить, какая доля времени ИТ-директора уходит на деятельность, соответствующую его роли, а какая остаётся наследием прежней структуры команды.
Такой подход намного ближе к нормальной практике управления изменениями: сначала формулируется проблема, затем меняется конкретный элемент системы, после чего можно оценить результат и решить, какой шаг должен быть следующим.
Эффективность ИТ-руководителя проявляется в работе системы
Если вернуться к вопросу, с которого начиналась встреча, две недели отсутствия руководителя становятся довольно хорошим тестом не на его личную незаменимость, а на зрелость всей функции.
В устойчивой ИТ-организации за это время наверняка появятся вопросы, которые потребуют решения CIO после возвращения. Но текущая работа не должна останавливаться только потому, что руководитель временно недоступен. У команды должны быть понятны зоны ответственности, руководители направлений должны иметь возможность принимать решения в своих областях, а правила эскалации должны отделять действительно значимые риски от вопросов, которые просто непривычно решать самостоятельно.
Именно в этой точке личная эффективность перестаёт быть историей о том, как уместить ещё несколько задач в рабочий день. Для ИТ-директора она всё больше связана с тем, какую систему он создаёт вокруг себя: сколько решений эта система способна принимать без его участия, насколько разумно распределены полномочия и остаётся ли у самого CIO время на работу, которую действительно нельзя делегировать вниз или автоматизировать.
В материалах встречи эта идея была собрана в понятие «архитектуры эффективности»: ресурс руководителя, его навыки, технологическое усиление, устойчивые модели поведения и то, как всё это складывается в ежедневную систему управления.
Поэтому для ИТ-руководителя полезнее периодически оценивать не количество закрытых за неделю задач, а другой показатель: насколько хорошо работает ИТ-функция в тот момент, когда её руководитель перестаёт лично поддерживать каждый процесс.
Если со временем команда становится способна принимать больше решений самостоятельно, число обязательных согласований сокращается, а у CIO появляется пространство для работы со стратегией, архитектурой, людьми и бизнесом, значит, личная эффективность действительно растёт. И происходит это не потому, что руководитель научился быстрее выполнять всё ту же работу, а потому, что система вокруг него стала работать взрослее.
Для самостоятельного изучения
В основной текст я бы методики больше не тащил. Внизу статьи достаточно сделать небольшой блок «Материалы по теме» и повесить ссылки непосредственно на названия:
- Матрица Эйзенхауэра — открытый материал Яндекс Практикума. Матрица Эйзенхауэра: как расставлять приоритеты
- GTD — Getting Things Done — обзор методологии и принципа выгрузки задач из головы во внешнюю систему. Методология GTD
- SMART — постановка и проверка целей. Как ставить цели и задачи по SMART
- RACI — распределение ролей и ответственности в командах и проектах. Матрица RACI
- Метод «Шесть шляп мышления» — русскоязычный обзор в материале о техниках мозгового штурма. Метод «Шесть шляп»
- SCAMPER — практический разбор метода генерации и изменения идей. Метод SCAMPER
- ТРИЗ — официальное издание Фонда Г. С. Альтшуллера «Введение в ТРИЗ. Основные понятия и подходы». Введение в ТРИЗ
- Квадрат Декарта — инструмент структурирования сложного выбора. Квадрат Декарта
«Фармакод» — закрытое профессиональное сообщество ИТ-, ИБ- и цифровых руководителей фармацевтических компаний. На закрытых встречах клуба мы обсуждаем управленческие и технологические задачи в профессиональном кругу, где можно говорить не только об успешных кейсах, но и о проблемах, которые обычно остаются за пределами публичных конференций.
