Полная версия
Настоящий CTO: думай как технический директор
1.1. Суть работы технического директора
На самом верхнем уровне CTO прежде всего отвечает за техническое руководство и реализацию основного продукта компании, то есть решение задач бизнеса в интересах клиента. CTO обычно подчиняется генеральному директору, но нередко и финансовому директору, главному операционному директору (Chief Operating Officer, COO) или даже ИТ-директору (Chief Information Officer, CIO), в зависимости от размера компании и количества прямых подчиненных, которым генеральному директору комфортно управлять.
И наоборот, в компетенцию CTO обычно не входит ИТ-инфраструктура, или бэк-офис. Хотя серверы и программное обеспечение, из которых состоит ваш продукт, относятся к ведению технического директора, но настольные компьютеры, почтовые серверы, телефоны, принтеры и т. д. – нет. Обычно это зона ответственности ИТ-директора или отдельного менеджера, который чаще всего подчиняется финансовому директору. Технический директор же сфокусирован на разработке, поддержке и эксплуатации основной платформы, технологии или линейки продуктов, которые обслуживают клиентов (заказчиков), – иногда это называют фронт-офисом.
Тем не менее в небольших компаниях эта граница нередко бывает размытой, и в зависимости от своих навыков вы можете заниматься тем, что потенциально не входит в вашу зону ответственности. В стартапах и небольших компаниях CTO обычно делает все – от заказа ноутбуков и заключения договоров с интернет-провайдером до замены чернил в принтере, написания кода и выкладывания его на серверы.
С другой стороны, в устоявшемся (малом или среднем) бизнесе обычно нет формальной должности CTO. В нем может быть команда разработчиков, группа поддержки и команда системных инженеров, но никто не следит за технологической стратегией и не управляет ею как единым целым. В подобную ситуацию легко попасть, если компания долгое время развивается, не осознавая, что ее связь с данными/технологиями теснее, чем может показаться.
В этом нет ничьей вины, поскольку большинство не понимает, как воспользоваться преимуществами роли CTO, чтобы получить максимальную отдачу от своей деятельности. Опять же, эта книга поможет вам убедить руководство в необходимости введения должности технического директора.
Подобно тому, как финансовый директор организует финансы и бухгалтерию таким образом, что работа с ними становится удобной и беспроблемной, так и хороший технический директор разгружает генерального директора и совет директоров, чтобы они могли сосредоточиться на вопросе что, в то время как он сам занимается вопросом как. Хороший технический директор обеспечивает для своей компании:
• Стабильную, масштабируемую и управляемую платформу, которая обеспечит развитие компании.
• Компетентное лидерство для поддержания актуальности платформы.
• Возможность использовать потенциал платформы для исследования новых областей бизнеса.
• Операционную устойчивость для надежного и предсказуемого обслуживания клиентов.
• Гибкое использование технологий на благо компании и клиентов.
• Создание и сохранение высокоэффективной команды, а также управление ею.
Переход финансового директора на должность генерального – это обычная и естественная практика, а вот разработчики и ИТ-менеджеры часто плохо подготовлены к роли технического директора. Большинство из них считает, что это просто расширение их текущих повседневных задач. Такое отношение, хотя и часто встречающееся, ведет к провалу.
СТО – это гораздо больше, чем просто управление командой и написание кода, особенно когда компания начинает расти и, тем более, когда ее приобретает другая компания или инвестиционная группа. Как уже отмечалось, у хорошего специалиста все выглядит просто, но за этой простотой скрываются многолетний опыт и серьезные испытания.
В зону ответственности технического директора входит широкий круг вопросов, от проектирования архитектуры и дизайна продукта до приема на работу новых сотрудников, вопросов внедрения, соответствия нормативным требованиям, безопасности, отчетности/взаимодействия, стратегии/видения, а также планирования бюджета. По мере развития компании CTO может начать заниматься и другими вопросами, включая подготовку к презентациям генерального директора и/или совета директоров, работу с поставщиками, подготовку для внешних инвесторов, получение и обработку запросов на due diligence и даже оценку других команд / технологических стеков, если планируется их интеграция с потенциальным партнерством или поглощением.
Хорошего CTO отличает способность адаптироваться к потребностям компании или, по крайней мере, вовремя признать, что он больше не может выполнять свои обязанности и должен уступить место тому, кто может.
Вице-президент по разработке
Стоит отметить, что грань между вице-президентом по разработке и техническим директором иногда довольно размыта и часто является предметом дискуссий. Разница может существовать только в названиях должностей в штатном расписании, а может быть четкое разделение, когда вице-президент по разработке подчиняется техническому директору, отвечая за обеспечение работы команды инженеров и оставляя все остальное техническому директору. Для целей этой книги многое, о чем я говорю, применимо к обоим вариантам, и я считаю, что вице-президент по разработке – это промежуточная ступень на пути к должности CTO.
1.2. Различные типы CTO
Определение CTO во многом зависит от среды, в которой он работает, поэтому рассмотрим немного подробнее распространенные типы компаний, в которых может быть позиция технического директора. Вопросы в конце каждого раздела помогут вам определить, к какому типу вы ближе всего:
• Предстартап, номинальная должность.
• Стартап, эксперт в области технологий.
• Устоявшаяся/зрелая компания:
• Технический директор, должность учреждена впервые;
• Технический директор, пришедший на смену прежнему СТО.
1.2.1. Предстартап, номинальная должность
Типичный стартап на начальном этапе может состоять всего из двух человек – визионера и технаря. Скорее всего, они оба в начале своего профессионального пути, возможно, только что закончили учебу и не имеют реального опыта работы в отрасли. Тем не менее их привлекают перспективы, которых может достичь только мечтатель с железной волей.
Здесь технарь каждый день пишет код, пытаясь не отставать от видения основателя в том, как они представляют компанию. Продукт ожидает множество крутых поворотов и редизайнов, поскольку творение начинает попадать в руки пользователей. Для солидности основатель печатает технарю визитки с названием должности «технический директор» (в основном чтобы компенсировать низкую зарплату, если она вообще есть).
Они идут на всевозможные ухищрения, чтобы добиться результата; но, когда клиенты начинают платить, необходимо сместить фокус внимания с разработки на рост продукта. Это подразумевает вопросы поддержания работоспособности систем, защиты данных в соответствии с нормативными требованиями и роста команды – все это вдобавок к написанию кода.
Хотя такой технический директор и не находится в одной лиге с лучшими представителями отрасли (возможный претендент на такое звание – Вернер Фогельс (Werner Vogels) из Amazon), забот и тревоги у него ничуть не меньше. Он, как правило, не желает отказываться от контроля и чувствует угрозу, когда кто-то из новичков в команде кажется более опытным. Тому, кто тащил проект ночами, кровью и потом, трудно признавать, что может появиться кто-то более подходящий, чем он.
Когда к проекту подключаются крупные инвесторы, такие как венчурные фонды, – они могут попытаться привлечь к управлению специалиста с бо́льшим опытом, поскольку технология является ключевым компонентом успеха. Однако существующий технический директор вполне может справиться с новыми обязанностями, если получит небольшую помощь и наставничество. Этим техническим директором можете быть вы, если ответите «да» на один или несколько из следующих вопросов:
• Когда вы принимаете технические решения, никто их не оспаривает и не проверяет.
• Вы единственный человек, который занимается разработкой.
• Это ваша первая настоящая работа, даже если она не очень щедро оплачивается.
• В компании очень мало процессов или структур.
• Только вы знаете, как управлять системой (системами) и обслуживать ее.
1.2.2. Финансируемый стартап: технологический эксперт с деньгами
На следующем этапе развития стартап, описанный в предыдущем разделе, убеждает одного или нескольких инвесторов (членов семьи, бизнес-ангелов или венчурный фонд) вложиться в развитие бизнеса. На кону серьезные деньги, а размер бюджета заставляет поверить, будто успех уже в кармане. Однако большинство не понимает, что живет в кредит, который рано или поздно придется возвращать.
Техническому директору поручено быстро сформировать команду для поддержки архитектуры, которая еще не приобрела окончательную форму. Необходимо выдавать продукт, чтобы бизнес мог двигаться вперед, но команда разработчиков еще не определилась с тем, что конкретно они делают, поэтому трудно понять, что создавать.
В конце концов продукт поставлен, и заплатившие за него клиенты ожидают определенного уровня обслуживания. CTO теперь должен сместить акцент с исследований и разработки на поддержку и развитие. Удовлетворение потребностей клиентов и масштабирование при одновременном управлении созданием следующего поколения продукта – это искусство, требующее строгой дисциплины.
Со временем вопросы экономии начинают выходить на первый план. CTO должен выбрать подходящую технологию, не слишком затратную, но при этом с возможностью масштабировать расходы по мере роста клиентской базы. В прошлом большая часть инвестиций стартапа тратилась на дорогостоящие серверы и хостинг. Теперь же при грамотном ведении дел и стратегическом использовании облачных сервисов расходы на эксплуатацию могут составлять лишь малую часть общих инвестиций. Тем не менее неверное решение может повлечь рост затрат.
Многие технические директора в подобном положении не желают следовать принятым правилам и начинают испытывать трудности (в основном потому, что не знают правил, ведь это их первая подобная должность). Иногда в их действиях наблюдается полное отсутствие какой-либо системы, потому что полная свобода им кажется современной и модной. Тем не менее структуры и процессы существуют не просто так: они необходимы для предоставления клиентам стабильного и предсказуемого сервиса.
С другой стороны, некоторые CTO отчаянно стремятся придерживаться однажды заданной философии и испытывают параноидальный страх принять неверное решение. В итоге они доводят себя до состояния, в котором не могут двигаться вперед, потому что цена ошибки слишком велика. Это явление – паралич принятия решений, когда страх перед неверным решением препятствует принятию вообще любого решения.
Компании этого типа уже участвуют в финансовой гонке, пытаясь получить прибыль до того, как у них закончатся деньги, и превратиться из стартапа в устоявшийся, прибыльный бизнес, и это вызывает стресс у всех участников. Вы работаете в подобной компании, если ответили «да» на один или несколько из следующих вопросов:
• Компания моложе трех лет.
• Никто в вашем отделе еще не проработал больше 18 месяцев.
• Ваша платформа переживает вторую (или третью) итерацию.
• Компания тратит больше денег, чем зарабатывает.
• Вам кажется, что параметры продукта меняются каждую неделю/месяц.
1.2.3. Устоявшаяся компания: первый технический директор
Успешная и зарекомендовавшая себя компания, обычно возглавляемая основателем, развивается до этапа, когда ее глава решает, что необходимо более твердо управлять платформой. В его распоряжении есть несколько разработчиков и вспомогательный персонал, возможно, подчиняющийся финансовому директору. Системы играют ключевую роль в поддержании бизнеса, но со временем они начинают устаревать, что затрудняет либо исправление ошибок, либо расширение (такие платформы, как PowerBuilder, Microsoft Access и Visual Basic, используются гораздо шире, чем многие готовы признать).
Главная проблема подобных компаний, которую они еще не осознали, заключается в том, что никто не занимается обеспечением беспроблемной работы и жизнеспособности технологической платформы в долгосрочной перспективе. Это все равно что жить в доме много лет, забывая, насколько важны такие вещи, как кондиционер и горячая вода, не понимая, что с каждым годом коммуникации постепенно ветшают и в конце концов откажут, оставив дом без самого необходимого.
Иногда компании везет – руководство понимает, что необходимо заменить критически важные системы, но просто не знает, как это сделать. Может быть, настойчивый торговый представитель убедил всех, что проблемы будут решены, если компания перейдет на дорогое готовое решение, но цена таких вложений заставляет задуматься. Отрасль знает много примеров неудачного внедрения Salesforce/Microsoft/Oracle, случившихся по вине некомпетентных решений. Платформа ни при чем, дело в том, что в большинстве случаев достаточно не полного пакета услуг, а лишь его небольшой части. На другой стороне диапазона находится руководство, которое не понимает, что их время давно вышло и при следующей перезагрузке все сломается, и считает, что ничего не нужно менять – работает сегодня, будет работать и завтра.
После обсуждения ситуации, возможно, выслушав советников или инвесторов, руководство решает нанять первого технического директора. У успешного кандидата впереди много возможностей, но также ему придется доказать свою полезность, потому что некоторые до сих пор считают, что можно прекрасно обойтись без него.
Такой технический директор должен уделять больше внимания стратегии и учитывать, что внедрение изменений или новых систем может вызвать нервозность в команде. Одна из его первоочередных задач будет заключаться в замене устаревших систем без нарушения текущих операций. Ему предстоит столкнуться со множеством возражений из разряда «У нас так не принято», и, хотя задача может быть трудной, ее решение приведет к значительной трансформации и принесет пользу компании. Эта роль идеально подходит для технического директора с опытом или для тех, кто хочет перейти на следующий уровень профессионального развития. У таких компаний следующие особенности:
• Это устоявшаяся компания с платежеспособными клиентами и зрелой линейкой продуктов.
• Большинству платформ более 10 лет.
• Лишь немногие в курсе, как поддерживать все в работоспособном состоянии; они не знают, почему делают те или иные вещи, но знают, что если они их делают, то все работает как надо.
• Большинство людей в компании не осознают, насколько сильно они полагаются на технологии или данные.
• Отсутствуют стандартные политики или практики, в том числе реальное внимание к безопасности или соответствию требованиям.
1.2.4. Устоявшаяся компания с техническим директором
Наконец, солидная компания осознает ценность технического директора. Возможно, он уже был в компании с самого начала и получил все необходимые знания в процессе работы без подсказок и указаний, что и как делать или не делать. Кажется, у него все работает, потому что компания оправдывает ожидания клиентов. Но пришло время двигаться дальше, поэтому он оставляет хорошо работающую машину.
Смена руководства может означать как глоток свежего воздуха и новые задачи, так и просто поддержание существующего порядка вещей. Частные инвестиционные компании, как правило, меняют топ-менеджеров, если считают, что у нынешних менеджеров недостаточно опыта или знаний, чтобы привести компанию к желаемой цели. Им некогда ждать и наблюдать, потому что период владения компанией обычно составляет от трех до пяти лет. Подобную компанию легко узнать:
• Позиция технического директора в ней есть не менее трех лет.
• Организован технический отдел, определены роли и иерархия.
• Установлены процедуры и стандартные методы работы, и в основном они соблюдаются.
• Существуют общие планы, стратегическое видение и планы проектов.
• Технология стабильна и понятна большинству сотрудников компании.
Конечно, существуют и смешанные типы компаний, но в каждой из них CTO в какой-то момент проходит один из описанных этапов развития карьеры.
1.3. Определение потребности в техническом директоре
Руководство часто задается вопросом, нужен ли им CTO. Или – если он уже есть – нужно ли заменить его кем-то, кто обладает другим набором навыков и драйвом? Это решение может быть вызвано наблюдениями за другими похожими компаниями аналогичного размера, в которых эта позиция уже имеется. Еще одним триггером может быть стойкое убеждение, что технологии приносят меньше пользы, чем могли бы – вера в то, что все должно быть намного проще (и, возможно, дешевле), чем сейчас.
Если в компании, помимо ИТ-систем бэк-офиса (электронная почта, файлы, календари, чат и т. д.), есть технологии, с которыми взаимодействуют клиенты или которые имеют решающее значение для получения прибыли, – крайне важно, чтобы кто-то контролировал их эксплуатацию, постоянное совершенствование и развитие. Еще один простой тест: есть ли у вас специально разработанный программный продукт, без которого клиенты не смогут использовать то, за что они платят компании?
Так как же доказать руководству, что эта должность необходима? Это может быть непросто, особенно если вы сами на нее претендуете. Самая успешная аргументация всегда та, которая основывается на данных, а не на эмоциях. Это не значит, что интуиция не играет роли в принятии решений, но она никогда не должна быть единственным фактором.
Рассмотрите следующие вопросы. Если ответ на них утвердительный, значит, должность технического директора вам необходима:
• Разрабатывается ли в компании специальное ПО для клиентов или для поддержки клиентов?
• Проводилась ли значительная доработка сторонней платформы (например, Salesforce или Microsoft Dynamics) для поддержки клиентов?
• У вас отсутствуют данные о взаимодействии клиентов с вашими системами?
• В вашей отрасли существуют требования или законы, которые необходимо соблюдать (например, вы храните медицинскую или финансовую информацию о своих клиентах или для них)?
• Относятся ли в компании к вопросам безопасности как к досадной помехе и часто оставляют пароли в открытом доступе?
• Вы используете и поддерживаете свои собственные серверы, с которыми работают клиенты?
• У вас отсутствует песочница или безопасная среда для тестирования и проверки нового ПО или конфигураций?
• У вас маленькая команда начинающих или совсем неопытных технических специалистов без технического руководства?
• Слова «исправление» или «обновление» программного обеспечения звучат для вас в новинку и вы годами этим не занимались?
• У вас отсутствует документация или управление ресурсами/версиями для систем, используемых клиентами?
• У вас нет политики резервного копирования или аварийного восстановления без прерывания сервиса?
• Принципы работы системы известны лишь немногим ключевым сотрудникам, а это значит, что без них компания окажется в беде в случае критического сбоя?
• Решает ли служба поддержки проблемы, связанные с некачественным или устаревшим программным обеспечением?
• Текущие системы начинают устаревать и не в состоянии обеспечить функционал, который требуется клиентам?
Ресторан не может работать без шеф-повара, который следит за кухней и за тем, чтобы каждый выполнял свою работу, а посетители получали вкусную еду. Технический директор – это шеф-повар компании, следящий за всем, что необходимо, чтобы блюда подавались.
1.4. Эволюция от инженера
Подавляющее большинство технических директоров, с которыми мне посчастливилось работать, быть наставником или просто иметь знакомство, имели богатое техническое прошлое, что довольно важно. Многие из них обладали хорошим практическим опытом и тягой ко всему новому – это отличные качества для
надежного и грамотного старшего инженера, даже архитектора. Но делают ли они своего обладателя хорошим техническим директором?
К сожалению, не всегда. Хотя роль CTO выглядит привлекательной, она подразумевает множество обязанностей, неочевидных на первый взгляд (в этом вы убедитесь, прочитав эту книгу), и для большинства инженеров эти обязанности представляют сложность. Не каждый технический директор с легкостью несет бремя офисной работы, потому что оно не соответствует его природным инженерным склонностям. Почему так происходит?
Одна из главных причин – неготовность мыслить более масштабными и долгосрочными категориями. Масштабность – это не создание более крупных платформ или управление ими, а умение рассматривать эти системы в контексте компании и конечного пользователя. Долгосрочное мышление основано на пятилетних блоках – естественном цикле бизнеса. Как платформа будет выглядеть через пять лет? Будет ли она удовлетворять потребности бизнеса и останется ли при этом актуальной?
На первый взгляд это кажется логичным и простым, но стоит копнуть немного глубже – и проблема становится сложной и запутанной и никогда не решается до конца, но требует гибкого и адаптируемого подхода.
Помимо социальных навыков, которые необходимо освоить, – умения общаться с коллегами, не имеющими инженерного образования, готовить бюджет для проекта, который еще непонятно что собой представляет, набирать и поддерживать команду талантливых специалистов, – при всем этом чтобы еще и клиент остался доволен, – существует мир неопределенных решений и неизвестных результатов, такой непохожий на бинарный мир, где все определено, из которого пришел новоиспеченный СТО и в котором ему комфортно.
С этим можно справиться. Самые успешные технические директора – это те, кто знает, как применить свои технические знания на пользу компании. Самый эффективный инструмент в арсенале инженера на должности CTO – это понимание, чего ожидать: вы знаете, что будет работать, а что нет, и сколько времени что-то потребует или будет продолжаться. Этот инструмент поможет стать эффективным и результативным техническим директором.
Мудрые слова
Вам не скажут спасибо
Я вспоминаю один из лучших советов, который дал мой давний наставник и друг Джим Милбери, партнер-основатель ParkerGale Capital. В то время я был архитектором, переделывал проект платформы для портфельной компании и совершил ошибку новичка, думая о сегодняшнем дне и забывая о завтрашнем. Моим оружием было то, что благодаря новой архитектуре я экономил компании 10 000 долларов в год. По тем временам это были большие деньги. Однако существовал риск (небольшой) сбоя компонента. Джим сказал, что экономия – это хорошо, но попробуй объясни совету директоров, что ты сэкономил компании 10 000 долларов, когда они потеряют репутацию у клиентов из-за сбоя. Это был урок, который показал мне, что у моих решений более далеко идущие последствия, чем просто наличие работающего функционала.
1.4.1. Первые 100 дней
Типичный вопрос, который задают на собеседованиях на руководящие должности, чтобы понять, насколько кандидат думающий и мыслит ли он стратегически: «Что вы сделаете в первые 100 дней работы?» «100 дней» – отличный инструмент для начинающих технических директоров, дающий важные идеи о том, что им делать и как справляться с новой ролью. Опытные технические директора с приходом в новую компанию тоже будут делать все это, прежде чем приступать к работе.
В следующем разделе мы узнаем, как начать приносить пользу еще до наступления 100-го дня, не принимая при этом необдуманных/реакционных решений. Как инженер, не поддавайтесь искушению выносить суждения (по крайней мере, вслух) и засучив рукава все менять. Инженеры любят брать быка за рога – они видят проблему и хотят ее решить. Боритесь с этим желанием.
0–7 ДНЕЙПервую неделю необходимо посвятить знакомству с компанией с позиции клиента. Узнайте точно, чем занимается компания, какая терминология в ней используется, какая модель ценообразования применяется и какие клиенты наиболее важны. Не погружайтесь в детали – разберитесь, как работает компания, чем занимается каждый отдел и кто ключевые лица.
7–30 ДНЕЙСледующие несколько недель уделите знакомству с техническим отделом, а также подробному изучению работы каждого отдела компании. Технический отдел будет (или, по крайней мере, должен) работать на автопилоте, пока вы набираете скорость. Вас могут привлекать к участию во встречах, но пока просто слушайте и наблюдайте, обращая внимание на то, как другие сотрудники воспринимают технический отдел и с какими типами людей вам предстоит взаимодействовать.