Технический Директор ( CIO / CTO )

В самом начале я хотел бы внести ясность в возникшие путаницы о роли Технического Директор ( CIO / CTO ).

Во-первых, Технический Директор ( CIO / CTO ) в стартапах почти всегда имеет отношение к разработке и развитию Продуктов. При этом в некоторых уже существующих компаниях под Техническим Директором ( CTO ) понимают главного Системного Администратора ( System Administrator ), который может поддерживать инфраструктуру и заниматься внедрением и настройкой сторонних программ под требования бизнеса ( интегратор ). Я рассматриваю Технического Директора ( CIO / CTO ) именно как роль, которая непосредственно влияет на разработку и развития собственных Продуктов.

Во-вторых, та роль, о которой я говорил и буду описывать, корректнее называть Информационный Директор ( Chief Information Officer, CIO ), а Главного Инженера ( VP of Engineering ) правильнее называть Chief Technology Officer ( CTO ). Однако исторически сложилось так, что в мире стартапов Технического Директор называют Chief Technology Officer ( CTO ), а Главного инженера — VP of Engineering. Я ранее придерживался и продолжу придерживаться общепринятых определений, хотя считаю, что они вносят путаницу в и без того сложный мир IT.

Ранее я писал, что Главный Инженер ( VP of Engineering ) — это верхняя ступень развития специалиста в инженерном направлении. Тогда кто же такой Технический Директор ( CIO / CTO )?

Это третья путаница и она возникла из-за того, что на должности Технического Директора ( CIO / CTO ) можно встретить людей с разным опытом и жизненным путём: в каких-то компаниях это может быть технический сооснователь, который создал первоначальную версию Продукта и продолжил развивать Отдел Разработки ( Development Division ); в каких-то — один из первых разработчиков или Руководитель Команды ( Team Lead ) или Руководителя Разработки ( Development Lead ), причастный с созданию продукта с самого начала; где-то это человек, который является только представителем компании во внешнем мире и никак не связан с технологиями внутри компании.

Итак, кто же такой Технический Директор ( CIO / CTO ), чем он должен заниматься, а чем не должен? Для лучшего понимания роли Технический Директор ( CIO / CTO ) я постараюсь описать её с разных сторон и разными словами.

Есть очень короткое и ёмкое определение:

Технический Директор ( CIO / CTO ) — это исполнительное руководящее лицо компании, отвечающее за ее стратегическое развитие, в котором компания нуждается на данной конкретной стадии существования.

Камиль Фурнье / От разработчика до руководителя. Менеджмент для IT-специалистов / Москва: Издательство «МИФ», 2018 / ISBN 978-5-00117-319-9 / С. 223

В этом определение слово «стратегическое» означает, что Технический Директор ( CIO / CTO ) должен думать на перспективу, помогать планировать будущее бизнеса компании и продумывать то, что поможет сделать эти планы возможными. А «исполнительное» означает, что Технический Директор ( CIO / CTO ) отвечает за то, чтобы сделать стратегические планы компании реальностью, путём разбивки их на продукты, проекты и задачи и направления людей для их реализации.

Короткое определение описывает роль очень высокоуровнево и не раскрывает все грани роли Технический Директор ( CIO / CTO ). Если описывать подробнее, то получаются следующие грани:

• Результаты бизнеса — основной приоритет
• Быть лидером и не только для IT Отдела ( IT Division )
• Оценка, управление и принятие ответственности за риски
• Выстраивание процесса таким образом, чтобы Бизнес знал когда он получит нужный ему функционал
• Инкапсуляция IT Отдела ( IT Division ) от внешних раздражителей и псевдо-ASAP задача
• Объединение IT Отдела ( IT Division ) в единую команду, нацеленную на результат, её мотивация для достижения наилучшей скорости движения вперёд
• Разработка IT стратегии и бюджета
• Взаимодействие IT Отдела ( IT Division ) с остальными отделами
• Взаимодействие с партнёрами, инвесторами, государственными органами и внешним миром

Результаты бизнеса — основной приоритет

Прежде всего Технический Директор ( CIO / CTO ) должен интересоваться бизнесом компании, заботиться о его развитии и достижении наилучших результатов. Он должен уметь формировать бизнес-стратегию компании через призму технологий. Он должен определять области, в которых технологии смогут открыть новые возможности для бизнеса компании, и гармонично соединять их с общей стратегией развития компании. Технический Директор ( CIO / CTO ) должен понимать, где лежат наибольшие возможности и риски для бизнеса компании, и заниматься ими.

Одно из важнейших положений, которое всегда должен помнить человек в роли Технического Директора ( CIO / CTO ) — это то, что в первую очередь эта роль руководителя, а только потом инженера.

Быть лидером и не только для IT Отдела ( IT Division )

Технический Директор ( CIO / CTO ) должен воспринимать свою роль не как источник власти, а как источник сервиса. Он должен понимать, что его задача как лидера — помогать сотрудникам выполнять свою работу наилучшим образом. Другими словами, он должен снимать барьеры на пути своих сотрудников, давая им работать на полную, а не возводить преграды и вмешиваться в их работу.

Мнение Технического Директора ( CIO / CTO ) в стратегических и тактических вопросах должно быть важно для других директоров так же, как и бизнес-потребности или технические идеи других директоров для Технического Директора ( CIO / CTO ). Технический Директор ( CIO / CTO ) должен понимать общую картину состояния бизнеса и видеть его потенциальное будущее. Он должен уметь выстраивать планы в стартапах на месяцы, а в компаниях на годы вперед так, чтобы было легче реализовывать имеющийся потенциал и в максимальной степени задействовать перспективные возможности на пути движения вперед. Технический Директор ( CIO / CTO ) хорошо понимаете воздействие организационных структур компании на IT команды, осознаёт ценность руководства, позволяющего достигать результатов, а не скатываться в бесконечный процесс.

Новые IT специалисты будут приходить в компанию, особенно если это стартап, если верят в Технического Директора ( CIO / CTO ), членов его команд, пришедших ранее, и в цели компании.

Оценка, управление и принятие ответственности за риски

Технический Директор ( CIO / CTO ) должен уметь принимать решения даже в отсутствии полной информации и быть готовым брать на себя ответственность за принятые решения.

В современном бизнесе очень часто то, что сегодня было правильным уже завтра требует изменений. Это абсолютно нормальный процесс. Особенно для стартапов, которые в поисках истинной потребности с устойчивой и прибыльной бизнес-моделью совершают резкие изменения целей ( pivot ).

Выстраивание процесса таким образом, чтобы Бизнес знал когда он получит нужный ему функционал

Чем выше слой, тем больше ожидается самостоятельного решения проблем от роли за него отвечающей. Технический Директор ( CIO / CTO ) должен хорошо знать состояние дел в отрасли и понимать как работает бизнес с юридической, финансовой и бухгалтерской точек зрения. Разобравшись во всех этих вопросах, Технический Директор ( CIO / CTO ) сможет сконцентрироваться на первоочередной задаче стартапа — нахождении правильной ниши для продукта ( product/market fit ).

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

Достигнуть это можно путём организации нужной на данный момент развития компании структуры IT Отдела ( IT Division ), определения технологического вектора и распространения ценностей компании внутри своего отдела.

Инкапсуляция IT Отдела ( IT Division ) от внешних раздражителей и псевдо-ASAP задача

Как я уже писал в заметке об устройстве IT Отдела ( IT Division ), я придерживаюсь Принципа Инкапсуляции. То есть Технический Директор ( CIO / CTO ) должен создать такие условия для работы IT-специалистов, которые позволят им работать максимально эффективно. Одно из важнейших условий — оберегать IT специалистов от внешних источников раздражения и отвлечения. Создание программных систем требует спокойствия и Состояния Потока, в которое долго и сложно «погружаться», но можно мгновенно разрушить, отвлекая человека, и тогда придётся проделывать «погружение» заново. Это очень раздражает и поэтому нужно приложить максимум усилий, чтобы обеспечить IT специалистам спокойные условия работы, которые помогут «погрузиться» в Состояние Потока.

Иногда у бизнес подразделений ( Бизнес ) возникает желание закинуть в разработку вот прямо сейчас новую «срочную и важную» задачу, которая появилась вот только что. Почти всегда люди с этой задачей искренне верят, что она «срочная и важная». Как показывает мой опыт, почти всегда это не так!

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

Как гласит подслушанная мной народная мудрость, с которой я полностью согласен:

Геройство одних — это распиздяйство других.

Как же определить насколько задача действительно является важной и срочной ( ASAP )? Как уже указывалось, задача Технического Директора ( CIO / CTO ) развернуть стратегию, исходя из текущего положения компании. Поэтому я всегда стараюсь задать к задаче следующие вопросы.

Как она соотносится со стратегическими целями?

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

Если задача никак не соотносится со стратегическим планом, то переходим к следующему вопросу.

Сколько мы заработаем, выполнив эту задачу?

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

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

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

Поэтому нужно очень крепко думать насколько задача нужна и нужна прямо сейчас.

Сколько мы не потерям, выполнив задачу?

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

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

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

Но и данный случай весьма редкий.

Соответственно, все задачи, которые не прошли фильтр из этих вопросов с моей точки зрения не могут называться «важными и срочными» и подлежат в лучшем случае включению в общий продуктовый список задач ( Product Backlog ).

Объединение IT Отдела ( IT Division ) в единую команду, нацеленную на результат, её мотивация для достижения наилучшей скорости движения вперёд

Чтобы объединение стало возможно у всех в команде должны быть одинаковые ценности и задача Технического Директор ( CIO / CTO ) донести их до всех в своей команде. Я выделяю следующие ценности, которые транслирую команде:

• Доверие.
• Партнерство.
• Уважение коллеги как личности.
• Честность и открытость процессов.
• Развитие, когда это возможно.
• Получение удовольствия от того, что делаешь.
• Получение признания за то, что делаешь.
• Важен результат, а не процесс.

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

Если собрана команда профессионалов, есть интересные задачи, а результатами труда IT Отдела ( IT Division ) пользуются, а не кладут в стол, то проблем с самомотивацией и энтузиазмом в такой команде быть не должно. Да, в любом деле есть интересная творческая часть, а есть рутинная часть, которая важна не менее чем творческая, но не приносит такого удовольствия от её выполнения как творческая. Технический Директор ( CIO / CTO ) и руководители в IT Отделе ( IT Division ) должны понимать важность того, что ощущение радости должно быть тесно связано с достижениями и культивировать это в сотрудниках. Если сотрудник реализовал скучную, но нужную бизнесу компании задачу, то это тоже повод для радости и похвалы. При этом нужно обязательно следить за ситуациями, когда сотрудник уже продолжительное время занимается рутинными задачами, то нужно при первой же возможности переключить его на интересную задачу, чтобы вновь увидеть всепожирающее пламя любопытства в его глазах.

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

Технический Директор ( CIO / CTO ) должен формировать дискуссии вокруг технологических вопросов и следить, чтобы в них присутствовало видение стратегии всей компании, а в принятых решениях содержались и нетехнические соображения.

Ещё важными особенностями работы с командой я бы выделил:

• Управлять, в том числе ставить задачи и напоминать об обязательствах, нужно с помощью вопросов, а не приказов.
• Нужно вовлекать сотрудников в диалог, а не принуждать с помощью приказов.
• При возникновении аварии нужно, как говорил Генри Форд, найти ответы на вопросы как устранить сложившуюся ситуацию и как не допустить её повторение в будущем, а не искать виноватого.
• Нужно использовать практику регулярных личных встреч с сотрудниками. Если в отделе или команде их слишком много, чтобы организовать регулярную личную встречу с каждым, то регулярные личные встречи нужно проводить с ключевыми сотрудниками, а с остальными использовать общие встречи, например, во время обеда, но они обязательно должны быть. В этом вопросе главное, чтобы встречи были действительно регулярные и переносились как можно реже, а также чтобы инициатором встреч был руководитель.

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

Также в задачи Технического Директор ( CIO / CTO ) входит доносить и разъяснять людям ценности компании, демонстрировать своим примером приверженность обязательствам и самое сложное и важное — подавать пример и единство всех директоров даже тогда, когда не хочется или он лично не согласен с принятым решением.

Разработка IT стратегии и бюджета

Как уже отмечалось ранее, Технический Директор ( CIO / CTO ) должен думать стратегически, то есть на перспективу, исходя из той точки, в которой сейчас находится компания, а также делать эти план реальностью. В конечном итоге это воплощается в двух документах: технологическая стратегия и её финансовое отображение в виде бюджета IT Отдела ( IT Division ).

С одной стороны, технологическая стратегия компании связана с разработкой новых и развитием существующих Продуктов. Технический Директор ( CIO / CTO ) должен понимать какие новые технологии и как могут помочь в развитии текущих направлений бизнеса и создании новых точек роста для бизнеса компании, причём использование новых технологий должно быть обусловлено экономически, то есть либо ускорять процессы, либо делать их дешевле. Для этого Техническому Директору ( CIO / CTO ) необходимо постоянно следить за новостями мира IT и изучать новые технологии.

С другой, технологическая стратегия тесно связана с развитием IT Отдела ( IT Division ) путём развития знаний и умений всех сотрудников и пополнение отдела новыми сотрудниками. Здесь главная задача Технического Директора ( CIO / CTO ) заключается в том, чтобы проекты компании надежно обеспечивались возможностями специалистов с необходимыми знаниями и умениями.

Технологическая стратегия обязана способствовать будущему росту и предугадывать его. Для того, чтобы получить такую технологическую стратегию нужно быть не одиноким пророком, а частью команды: нужно узнать у сотрудников IT Отдела ( IT Division ) ( как минимум у Руководителей разработки ( Development Lead ) и Руководителей Команды ( Team Lead ) ) какие узкие места они видят, какие боли испытывают, где технический долг уже начинает больно бить по производительности или качеству, после чего так же совместно составить план по решению этих вопросов с учётом бизнес-интересов и планов компании; нужно поговорить с остальными директорами и узнать их мнение о том какие точки роста они видят в будущем и проанализировать возможные варианте тестирования этих идей, а также понять какие ресурсы понадобятся для реализации при позитивном результате тестирования; в конце очень желательно обратиться к себе и постараться выявить истинные причины проблем роста бизнес-показателей, а также попытаться спрогнозировать с какими проблемами можно столкнуться в будущем. При таком подходе получится заложить очень крепкий фундамент технологической стратегии и подготовиться к раскрытию максимума потенциала бизнес-планов.

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

Взаимодействие IT Отдела ( IT Division ) с остальными отделами

Участие в митингах, совещаниях, переписка по электронной почте и в мессенджерах, общение с людьми один на один, сбор мнений. Технический Директор ( CIO / CTO ) должен быть способен быстро анализировать большие объемы информации, выделять важнейшие элементы и делиться информацией с заинтересованными сторонами в понятном для них виде.

Технический Директор ( CIO / CTO ) должен уметь использовать политику взаимоотношений в компании, чтобы она способствовала движению организации вперед и развитию бизнеса. Он должен уметь конструктивно работать с коллегами за пределами IT Отдела ( IT Division ) и внимательно прислушиваетесь к мнениям по широкому кругу вопросов. Технический Директор ( CIO / CTO ) должен понимать, как правильно не соглашаться с чьим-то решением, но нести обязательства по его претворению в жизнь, несмотря на своё несогласие. Он должен уметь делегировать руководство членам своей команды, оставляя за собой лидерство.

Взаимодействие с партнёрами, инвесторами, государственными органами и внешним миром

Помимо работы внутри компании Технический Директор ( CIO / CTO ) также является её представитель во внешних кругах: он должен контролировать взаимодействие с ключевыми партнёрами компании, представлять технологическое и стратегическое ( через призму технологий ) направления компании перед инвесторами, а также взаимодействовать с государственными органами в рамках законов, регулирующих вопросы, связанные с технологиями.

Кроме этого Технический Директор ( CIO / CTO ) должен распространять ценности и технические подходы компании во внешней профессиональной среде путём личного выступления на профильных мероприятиях, а также организации участия менеджерских слоёв своей команды в технических мероприятиях в качестве выступающих, а инженерных слоёв как участников мероприятий.

Завершить заметку про Технического Директора ( CIO / CTO ) хочется ещё одним описанием этой роли с другой точки зрения.

Очень часто в литературе о стартапах можно прочитать, что любой из сотрудников стартапа должен обладать какой-то суперсилой или суперспособностью. Какой же суперспособностью должен обладать Технический директор ( CIO / CTO )? На мой взгляд самое правильное описание получается, если перефразировать Аркадия Морейниса ( оригинал ).

Суперспособность Технического Директора ( CIO / CTO ) — быть мультипликатором для способностей каждого из своего отдела. А вовсе не в том, чтобы заставлять их выполнять то, что он придумал.