Кто такой технический директор (CTO)
Кто такой технический директор (CTO) в IT-компании
Именно такое определение дает нам википедия и остальной интернет. Но ведь это лишь очень поверхностное определение, которое не раскрывает настоящие должностные обязанности. Давайте посмотрим на этого специалиста с точки зрения IT-индустрии.
Это не программист или любитель хардкорно программировать днями и ночами. Это руководитель который может хорошо делегировать свои обязанности на других.
Это не самый лучший / умный / классный технический специалист в отделе. Нет, он, может быть, даже хуже MIDDLE-разработчиков понимает некоторые аспекты в программировании (но это крайне редко).
Чтобы окончательно понять суть работы CTO, давайте взглянем на его обязанности.
Обязанности и роль технического директора в компании
Технический директор будет иметь ровно такие обязанности, какие возложит на его плечи сама компания и генеральный директор на данном (абстрактно) этапе развития компании. Расплывчато? Но это так! За ним можно закрепить кучу разных задач, в которых нужна техническая подкованность.
По моему личному и опыту коллег по цеху, чаще всего, технический директор будет решать каких специалистов закрепить за тем или иным проектом, а также какие стеки технологий использовать при разработке приложения или же продумывать стратегию развития определенного продукта.
Давайте на простом примере. Возьмем нишу разработки веб-сайтов. Технический директор получает задачу на разработку простого сайта для малого бизнеса. Далее, он выбирает CMS (систему управления контентом) исходя из общения с клиентом, решает какие фреймворки (bootstrap, vue.js, uikit, laravel) и инструменты использовать, распределяет задачи по специалистами (seo, дизайнер, программист), а может вообще делегировать данную задачу проект-менеджеру или тимлиду (старшему разработчику).
Как видите, роль технического стратега отлично подходит техническому директору. Обязанности из этого вытекают следующие: постановка целей и задач, разделение большой задачи на мелкие кусочки, распределение задач по персоналу, контроль выполнения задач, найм сотрудников, поддержка и мотивирование коллектива разработчиков. Ну а далее все зависит от места работы. Где-то CTO может составлять отчеты, иногда общаться с клиентами, считать рабочие часы сотрудников и даже обучать.
Кто такой CIO и в чём разница между CIO, CDO и CTO
Кто такой CIO
Роль CIO в компании состоит в разработке информационной стратегии по управлению бизнесом на основе передовых цифровых технологий, а также в обеспечении ее ИТ-составляющих. Также CIO руководит сотрудниками ИТ-департамента, поддерживает рабочие связи с другими службами компании (единым проектным офисом,отделом бизнес-аналитики, подразделением информационной безопасности) и руководством. CIO:
учитывает материалы и оборудование;
контролирует подготовку автоматизированных рабочих мест;
сотрудничает с партнерами по вопросам заключения договоров, поставкам компьютерной техники, программного обеспечения, комплектующих, расходных материалов, различных услуг;
принимает технику, оборудование, материалы и контролирует их количество, качество и использование;
принимает технику, оборудование, материалы и контролирует их количество, качество и использование;
контролирует документооборот, оформляет техдокументацию и составляет отчетность по IT-подразделению;
занимается сопровождением разработанных и внедренных программ, созданием рабочих инструкций по ним;
контролирует своевременное устранение неисправностей работы компьютерной техники и программного обеспечения.
CIO собирает сведения о выборе технологий, партнеров и оборудовании и предоставляет их генеральному директору (CEO) с обоснованием своих решений по выгодам и стоимости того или иного варианта (например, использования аутсорсинга вместо труда собственных сотрудников).
Чем отличаются должности CIO, CDO, CTO и другие Chief
Помимо CIO в компаниях существуют различные связанные с ИТ руководящие должности. В их перечень входят:
директор по цифровым технологиям (CDO, Сhief Digital Officer). В задачи CDO входят: переориентация «аналоговых» компаний в цифровые с полным использованием потенциала современных технологий, мониторинг операций в различных цифровых продуктах и сферах (мобильных приложениях, социальных сетях и связанных с ними приложениях, виртуальных товарах), а также управление информацией и маркетингом на основе веб-технологий. CDO четко формулируют цифровые стратегии предприятия и определяют, как компания сможет экспериментировать в цифровой сфере;
В отличие от CIO, которые фокусируются на организацию внутренней ИТ-инфраструктуры, CTO и CDO ориентируются на клиентскую базу вне компании, а также на развитие бизнеса.
Получить все необходимые для работы по специальностям CIO, CTO и CDO знания и компетенции можно в рамках курсов по программам MBA IT, которые проводит ЦРК БИ (ЦЕНТР РАЗВИТИЯ КОМПЕТЕНЦИЙ В БИЗНЕС-ИНФОРМАТИКЕ) НИУ ВШЭ. Записаться на курсы можно здесь.
Выживут только СТО-экстраверты: кодить уже недостаточно
Долгое время роль CTO была ролью исключительно технической компетенцией, а руководителями IT становились главные инженеры компании.
Сейчас, когда почти каждый бизнес нацелен на цифровую трансформацию, требования к CTO изменились. Кто он — эффективный CTO нового поколения? И как не ошибиться в найме такого человека?
Привет, меня зовут Лена, я — сооснователь стартапа Performetry, data science платформы анализа продуктивности команд.
Два года назад, когда мы только стартовали, то долго искали CTO. Пересмотрели сотни кандидатов, но не было уверенности, что среди них есть подходящий человек. Решение подсказала управляющий директор акселератора TechStars Lesa Mitchell: на одном из наших one-to-one она убедила меня, что стать CTO должна я. Тогда мне вспомнилась фраза Стива Джобса:
“Лучшими менеджерами становятся не те, кто хочет стать менеджерами, а те, кто готов взять на себя ответственность, потому что никто не выполнит эту роль лучше”.
Да, я инженер по образованию, но последние 10 лет работала на стороне бизнеса. Сегодня я хочу рассказать, почему CTO нового поколения больше не может оставаться исключительно техническим специалистом и почему старший инженер в компании не всегда подходит на эту роль.
С самого детства меня интересовали технологии. В начале 2000-х был тренд на экономическое образование и, казалось бы, женщинам в IT тогда не было места. Но меня это не остановило. В секрете от родителей я поступила в ГУУ, где и стала разработчиком. Работать начала еще на втором курсе университета и в общем проработала в этой сфере около 5 лет, запустив несколько успешных проектов национального уровня.
Осознав собственную потребность в поиске лидеров, у которых можно учиться, я начала больше обращать внимания на происходящее вокруг меня. Помню, как одним пятничным вечером смотрела “Бизнес секреты с Олегом Тиньковым” — в гостях у него был Артём Агабеков. Всё, что он говорил, буквально каждая фраза, резонировала со мной.
Так я решила найти возможность поработать с Артемом. Его агентство Adventum предлагало роль стажера. Уйти с руководящей должности в разработке на роль стажера в агентстве было очень непростым решением, не говоря уже о потере в зарплате в десятикратном размере. Но желание развиваться превалировало. Артем стал для меня идейным вдохновителем. И этот принцип — работать напрямую с вдохновляющим лидером — остался со мной навсегда.
Новый путь я начала с погружения в незнакомую для себя web-аналитику в команде Adventum.ru. Разрабатывала и запускала digital-стратегии больших компаний, в том числе стратегию для первого на тот момент онлайн-банка — Tinkoff Bank. Огромное преимущество перед другими специалистами мне давал опыт в разработке. Фактически я стала первопроходцем во внедрении маркетинговых IT-инструментов в стратегии развития российского бизнеса.
Можно сказать, что я ушла из разработки, чтобы вернуться, но уже с бизнес-мышлением. Именно смена мышления позволила мне из классического разработчика вырасти в бизнес-оунера. Да, технический бэкграунд важен, но он не менее важен, чем понимание бизнес-составляющей.
За последние несколько лет отрасль IT трансформировалась до неузнаваемости — как и роль технического директора. Еще в конце 1990-х инженерное образование и опыт разработки “руками” для этой позиции были основными требованиями, а руководителем IT по умолчанию становился главный инженер компании.
Бизнес-мышление и умение вдохновлять сегодня выходят на первый план. Когда почти каждая компания стремится к цифровой трансформации, СТО превращается в главного стратега, совмещающего разные роли — операционного директора, новатора, лидера, драйвера бизнеса, ускоряющего внедрение новых технологий.
Одним из главных качеств является умение привлекать инженеров высокого к себе в команду.
Деньги больше не являются ключевым фактором принятия решения для специалистов: люди должны хотеть с вами работать, должны верить в вас как в лидера.
Именно поэтому успешные технические директора, особенно в американских компаниях, инвестируют свое время и ресурсы в развитие эмпатии, в умение “заряжать” и выступать на публике. Всё это приобретает особенную важность с распространением работы из дома, так как конкуренция за хороших технических специалистов достигла критического максимума.
Вторым незаменимым качеством технического директора стало планирование. CTO — правая рука генерального директора. Хороший CTO должен общаться с клиентами, знать требования инвесторов, понимать, к какой цели стремится компания через 5 лет. На этой роли нужно уметь расставлять приоритеты и оценивать риски, чтобы обеспечить всю инфраструктуру, необходимую для достижения бизнес-целей.
Де факто СТО нового порядка — это главврач в технологической компании, который может определить, что не так в бизнес-модели: в технологиях, продажах, маркетинге.
Образ скромного инженера, гика, который прячется за мониторами и не показывается на свет, устарел безвозвратно.
СТО должен быть экстравертом, взаимодействовать с клиентами, понимать, какие вопросы им задавать и как трансформировать их ответы в язык инженеров. Это, пожалуй, главный барьер, который заставляет буксовать компании старой ментальности, в отличие от более продвинутых Google или Facebook.
СТО в Google — в первую очередь не технарь в самом дальнем кабинете, которого все обходят стороной. Это управленец, который беспокоится, чем сотрудники живут и интересуются, какие у них страхи и как развивать и мотивировать их. Он прекрасно знает своих клиентов, часто выступает на конференциях и является технологическим вдохновителем глобального масштаба. Эмпатия, управление людьми, знание бизнеса и искренняя забота о людях — это теперь главные инструменты СТО, без которых не построить эффективную систему.
Полагаясь на тренды в индустрии, которые вижу я в технологических компаниях — от IT-гигантов до стартапов, составила собственный чек-лист для найма правильного CTO.
Согласны ли вы с пунктами в чек-листе? Что добавили бы? Как лично для себя проектируете ролевую модель сильного СTO-лидера, нужного менеджменту и собственным сотрудниками?
CTO от стартапа до корпорации и обратно
Гость нового выпуска подкаста «Сушите вёсла» — Android-разработчик, технический директор, автор Telegram-канала «Android в лицах» и создатель стартапа PapaJobs Саша Смирнов. В этот раз обсуждаем сразу несколько тем: чем полезны стартапы специалисту, кто такой CTO, а также ищем разницу между Developer и Software Engineer.
Железные разработчики Redmadrobot Артём Кулаков и Рома Чорыев регулярно находят интересных гостей и приглашают их в студию. На месте ребята обсуждают всевозможные стороны создания ИТ-продуктов, делятся опытом и шутят шутки разной степени сложности.
Гость седьмого выпуска — разносторонний специалист, имеющий опыт работы как в больших компаниях, так и в стартапах. Поэтому этот подкаст получился обо всём важном: о развитии разработчика в стартапе, о том, как стать CTO, что нужно качать в процессе и как нащупать разницу между «разработчиком» и «инженером».
Прикрепляем подкаст и ответы на несколько волнующих вопросов:
03:25 — Зачем люди идут работать в стартап?
10:04 — Какие есть плюсы и минусы?
20:42 — Карьерный рост в стартапе возможен ли?
22:38 — Как выглядит senior разработчик из стартапа на рынке?
28:50 — Не прошло ли время стартапов и стоит сейчас их запускать?
33:35 — CTO — что скрывается за этими буквами?
34:16 — Кто такой технический директор и чем он занимается?
39:20 — А CTO настоящий директор или так для красоты назвали?
41:22 — Нужно ли хотеть стать техническим директором обычному разработчику и как это сделать?
52:31 — Developer vs Software Engineer: большие компании любят говорить, что у них работают не разработчики, а инженеры. Это понты или что-то за этим все-таки стоит?
54:26 — В чем принципиальное различие между этими видами специалистов?
1:08:00 — Не кажется ли, что это просто «приличное» название fullstack-разработчиков?
Саша рассказал, что ему нравится делать продукт с нуля: придумывать, как и что будет работать, улучшать жизнь людей. Он считает, что в продуктовой компании сложнее повлиять на какие-то решения, а в стартапе в этом плане свобода, ведь ты не ограничен своей «песочницей».
Если говорить про крупные компании, то там ты сильно завязан на той «песочнице», которую тебе выделили, и идти куда-то дальше сложно. Когда ты находишься в стартапе, то ты создаешь продукт с нуля, и в этом случае impact может быть больше, чем при выпуске еще одной фичи в готовом продукте.
Минусы тоже есть, один из главных — вопрос денег. Если стартап «выстрелит», то заработать можно много. Но до этого момента высок шанс получать ниже рынка, а по опыту нашего гостя, даже быть без зарплаты какое-то время. Тут уже вступает в силу выбор каждого отдельного специалиста — что ему важнее в конкретный момент времени.
Саша объяснил, что карьерный рост в стартапе очень быстрый. Ты понимаешь, как всё устроено в проекте, поэтому, если появляется новая интересная позиция, скорее возьмут человека «изнутри». Но с другой стороны, в стартапе достаточно легко взять столько ответственности, что тебя может буквально «разорвать».
Психологический фон, наверное, это один из минусов. Особенно в нашей культуре. Допустим, чем хороша культура Сан-Франциско и почему Кремниевая долина случилась там? Там ты берёшь деньги у инвесторов, пробуешь сделать стартап, и он, например, сгорает.
Ты идёшь и пишешь другую идею, и получаешь деньги на снова. Ну, потому что ты можешь иметь право на ошибку — это нормально. Более того, тогда, когда ты ошибся, это более ценно, так как тогда ты больше не совершишь такой промах.
А у нас как считается? Ты не имеешь права на ошибку, то есть у нас мало денег, у нас мало возможностей, у нас нет права на ошибку — работайте. И вот когда у тебя нет права оступиться, то делать инновации сложно, потому что инновации — это про ошибки. Я сделаю их 100 штук, а 101 «взлетит» и даст мне х100.
CTO, или технический директор, или главный инженер — человек, отвечающий за технологическую часть производства: за развитие и разработку новых продуктов. Так говорит «Википедия», но в разговоре в студии выяснили, что конкретного объяснения этой позиции нет. Слово Саше Смирнову:
Это хороший вопрос, чёткого ответа не даст никто, а всё, что дают, это просто какой-то набор мнений. CTO — достаточно запутанная позиция, которая может за много чего быть в ответе. Чаще всего и лучше её понимать как должность человека, ответственного за технологии.
Опираясь на свой опыт, Саша поделился представлением о том, как должен выглядеть технический директор в идеальном мире:
В идеальной ситуации это специалист, который «оунит» все направления технологий. Он понимает «боли» бизнеса и задачи, которые ему предстоит решать, и понимает, как технологии будут этому помогать. Он может сказать, каких людей нужно нанимать, какие инструменты важно использовать, он может подсказать, сколько времени придётся потратить на принятие или изменение, и прочее.
Кроме того, по мнению гостя, идеальный CTO должен следить за стеком технологий: вовремя его обновлять. Человек на этой позиции принимает решения, отвечает за ресурсы и постоянно находится в контексте бизнес-стратегии компании.
Саша, Артём и Рома обсудили, что изначально такой специалист должен быть хорошим разработчиком. Второе по важности — умение управлять командой и понимание, какие технологии стоит использовать прямо сейчас.
Нужно понимать, что это обширный вопрос, когда мы говорим о CTO. В самом начале ты должен быть классным разработчиком либо просто уметь разрабатывать. Если мы говорим дальше, то ты должен уметь управлять командой: уметь попадать в сроки, понимать, как решать задачи, не зная абсолютно, как и что работает, и уметь коммуницировать.
Идем дальше, ты должен уметь нанимать, выбирать технологии — то есть, у тебя, получается, еще какое-то видение должно появляться, и, по сути, у тебя должна быть стратегия. То есть важно качать leadership, стратегическое мышление и подобные вещи.
В студии случилась настоящая дискуссия на этот счёт. У каждого участника свой опыт и взгляд на эти понятия и то, что на самом деле за ними стоит. Мнения — разные, но одинаково интересные. Поэтому лучше один раз услышать с 52:31, чем сто раз прочитать.
Слушайте подкаст на удобной платформе: Soundcloud, Apple, Google Podcasts.
QA для начинающих: как протестировать ракету или самолёт
Архитектор ПО: зачем он нужен и в чём его проклятие
Приходите обсуждать выпуск в Telegram-чат.
А если все три разработчика на разных направлениях: бек, мобайл и фронт?
50 %. Либо будет, либо не будет. Как и всегда
Далеко не все небольшие и средние компании используют должности вроде CTO просто от желания казаться круче. Есть сферы, где подобную должность в обязательном порядке требует (и согласовывает кандидата) центробанк страны (я сейчас говорю о ЕС). В частности, речь идёт о сфере финансов.
Зовите меня фаундером! 🙂
В своем CV на должность техдира (CTO/Team Leader/Software Engineer в отдел iOS&Android разработки) одним из пунктов своих способностей я указывал:
— На всех этапах разработки замещать любого из членов своей команды и мотивировать ее своим примером;
Часто вижу вакансии, в которых фаундеры пытаются самостоятельно (без СТО): выбрать стек технологий для своего стартапа, найти бэкендщика, фронтендщика, дизайнера и т.д. – т.е. самостоятельно «собрать» команду на проект. Потом удивляются, почему ничего не получается…
Собирать команду, выбирать стек технологий, устанавливать сроки, соблюдать сроки, самостоятельно писать качественный, чистый, читаемый код, рефакторить его, взаимодействовать с менеджерами, дизайнерами, девелоперами, тестировщиками – это все должен уметь делать СТО + решать какую часть работы можно делегировать команде.
Вам будет понятней, если я напишу, что кто-то из команды «заболеет и сдохнет» или решит сменить место работы?
Насколько мелкой должна быть компания, чтобы CTO в ней мог заменить любую другую позицию? Три с половиной человека? CTO — это уже давно не про разработку — это лидер лидеров. Никакому CTO в более или менее крупной компании не стоит лезть в какой-нибудь UI/UX, а оттуда прыгать в DevOps просто потому, что кто-то из членов команды заболел. У хорошего CTO вообще не должно существовать в команде bus factor’а, при котором в случае болезни одного из сотрудников случается остановка проекта. Решаются такие вопросы не нырянием CTO в отладку приложений. Когда вы из lead/head/architect позиции переходите в C-level, то стоит забыть уже о том, чтобы быть самым главным экспертом по технологиям, потому что заниматься вы будете не тем, чем привыкли заниматься, будучи технарём. На вас будут и бюджеты, и общение с бизнесом, и регулярные встречи с руководителями других отделов, и работа с другими лидами/хедами. В таких условиях вам будет банально не до чтения технических ресурсов, а опыт разработки будет постепенно утрачиваться. Именно поэтому многие не решаются идти в руководители, предпочитая продолжать оттачивать экспертизу на позиции архитектора.
Роли в маленьких стартапах очень перепутаны и нужно уметь заменять как можно больше функциональных областей. А если назначить себя — СТО всея стартапа, то боюсь на выходе получится ГОВНО ВСЕЯ РУСИ.
А как вам 8 директоров на 40 человек? 🙂
CTO — достаточно запутанная позиция, которая может за много чего быть в ответе.
Нужно понимать, что это обширный вопрос, когда мы говорим о CTO.
CTO от стартапа до корпорации и обратно
Каждый раз триггерюсь на СТО
Задние диски поменять почём? 🙂
Он понимает «боли» бизнеса и задачи, которые ему предстоит решать
Хоть кто-то это понимает! )) Сам бизнес обычно слишком туп, чтобы адекватно сформулировать свои хотелки.
В компании отказались комментировать сообщение.
Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании
May 18 · 11 min read
В этот вторник я выступал на конференции Highload++. Ниже видео выступления, а дальше его текстовая версия.
Интересно, что доклад прошел долгий путь — впервые идея о нем появилась около 2х лет и звучала изначально так
После недавнего посещения митапа для руководителей разработки, я осознал, что хотел бы еще раз сходить на #highload на CTO-трек. И там поговорить со сцены про управление сложностью в разработке ПО, важность абстракций и правильного уровня детализации для каждого уровня специалиста от линейного разработчика до ИТ-директора.
Хотелось бы обсудить как при росте компании от стартапа из 2х друзей до корпорации из тысяч сотрудников технический директор должен отходить от знания деталей реализации (например, описания полей в табличках) к концептуальным вопросам относящимся к архитектуре, атрибутам качества, ограниченным контекстам, в рамках которых работают части его системы. Интересно, что на этом пути роль технического директора меняется зачастую с изменением человека, который ее исполняет, т.к. редко кто может одинаково эффективно исполнять эту роль на всех этапах развития компании:)
За два года воды утекло много и кажется надо правильно ответить на базовые вопросы: зачем это доклад аудитории и зачем этот доклад мне. И начнем с читателей, которым этот доклад будет полезным, если вы задумывались о вопросах
Ну а мне будет интересно под е литься своим опытом, рассказать про путь “моего друга” и дать рекомендации как вам можно по нему пройти, собрав поменьше граблей. Про свой путь к позиции руководителя разработки я рассказывал года 3 назад на митапе в Яндексе. С тех пор моя должность поменялась и сейчас я CTO управления разработки цифровых экосистем в Tinkoff, которое отвечает за 2 платформы: онлайн привлечение и мобильный банк для физлиц.
План нашего общения
Жизненный цикл организации
Позиция CTO сильно отличается от компании к компании. Сильно влияют несколько факторов:
По первому пункту можно заметить, что сейчас разве что ларьки с шаурмой не называют себя it-компанией, а не общепит заведением, да и то не все. Но нас сегодня будут интересовать it’шные компании, т.к. в неайтишных компаниях роль it и его руководителя достаточно утилитарная и поддерживающая. Также мы будем смотреть на продуктовые компании, т.к. аутсорс в основном сконцентрирован на продаже голов и роль CTO там сильно отличается. А вот про фазы жизненного цикла стоит поговорить подробнее. На картинке ниже представлены этапы развития организации.
По горизонтали представлено развитие организации во времени, когда она последовательно развивается и переходит от одного этапа к другому. По вертикали мы видим некоторые абстрактные количественные показатели (выручка, прибыль, штат организации). Основная мысль моего доклада в том, что переходы между этапами являются некоторыми переломными моментами как для самой организации, так и для топ менеджмента, одним из представителей которых является CTO. Давайте пройдемся по этапам и посмотрим на специфику каждого этапа и посмотрим на роль CTO в рамках него
Startup
На этом этапе компания только зарождается. Основателем выступает предприниматель, который в одиночку или с несколькими соратниками выполняет все работы. В it-компаниях часто требуется как минимум два человека, которые исполняют роли главного за бизнес часть и главного по технической реализации задуманного. Первый является зародышем CEO и CPO, а второй начинающий CTO.
Цели на этой стадии ещё нечёткие, творческий процесс протекает свободно. Контроль за работой основан на личном участии руководителей во всех рабочих процессах. Организация не формализована и не бюрократизирована, для неё характерна простая структура управления. Основное внимание уделяется созданию нового продукта или услуги и завоеванию места на рынке.
Обычно у основателей есть идея, в которую они поверили и решили ее реализовать. Дальше они делают MVP своими силами или с небольшой командой, а потом пытаются получить финансирование на доработку продукта и выход на рынок.
Роль CTO этом этапе в том, чтобы обеспечить реализацию MVP. Зачастую он это делает один или если позволяют финансы с небольшой командой. По-факту, CTO в стартапе исполняет роль самого компетентного разработчика или тимлида небольшой команды. Поэтому и скилы тут должны быть соответствующие этой роли. На этом уровне CTO как раз много думает про технические детали реализации продукта, вплоть до уровня конкретных таблиц в базе данных или конкретной схемы развертывания в дата центре.
Кстати, я сам напрямую в создании отдельной компании сам не участвовал, но помогал с запуском подобных активностей внутри большой компании. Похожим образом создавался Тинькофф Журнал, технические подробности эволюции мои коллеги рассказывали в своем докладе на Python Conf. Если подытожить, то это интересный этап, но потенциально опасный — много стартапов его не проходят, но если проходят, то наступает следующий этап.
Growth
В начале этого этапа у нас есть продукт, который выведен на рынок, есть деньги для его развития и масштабирования команды.Основная цель — формирование стратегии развития и быстрый рост организации и захват доли рынка. На этом этапе критически важно, чтобы новый сотрудники организации понимали и разделяли идеи основателей и была выстроена эффективная коллективная работа.
Именно на этой стадии от основателей требуется навыки профессиональных менеджеров. В итоге, требуется изменение стиля управления, которое можно обеспечить поменявшись самому или пригласив профессиональных менеджеров со стороны, которые забирают на себя часть функций.
Данный этап характеризуется ростом количества сотрудников, их специализации, формализацией общения и стандартизацией процессов работы. Главными задачами организации являются: создание условий для экономического роста и обеспечение высокого качества товаров и услуг.
Конкретно для позиции CTO это значит, что уровень погружения в технические детали уменьшается и наступает время активного найма сотрудников и выстраивания их эффективной работы над частями продукта. Да он все еще много думает про технику, но также про найм и процессы.
Например, можно подумать, что масштабирование будет выглядеть как простое увеличение количества разработчиков под растущий бэклог. Но это так не работает.
На самом деле современная кросс-функциональная команда разработки устроена достаточно сложным образом, часто в ее состав входят аналитики, разработчики, тестировщики, системные инженеры, иногда дата сатанисты и кибер безопасники. Обычно вокруг всего этого навернут достаточно нетривиальный процесс разработки, который проходит стадии от идеи какой-то фичи до деплоя приложения с реализованной фичей и дальнейшей эксплуатацией приложения. Подробнее про современные процессы разработки я рассказывал на Devfest 2020.
В итоге, правильно рассматривать как единицу масштабирования команду вместе с тимлидом, который выступает входящей точкой для продакта и позволяет CTO не погружаться в операционную работу команды, если все идет хорошо и нет факапов или сложных и/или срочных проектов.
В итоге, масштабирование выглядит так:
Maturity — формализации структуры и управления
После ударного роста наступает стадия зрелости организации. В которой можно выделить 2 части формализации структуры и управления, а также усложнения сложности.
Во время формализации деятельности важно стабилизировать рост организации, например
Именно на этом этапе CTO становится достаточно сложно совмещать работу над техническим развитием, развитием процессов и людей, участвующих в них. Давайте рассмотрим эту трансформацию на графике, где по вертикали — ориентация на процессы, а по горизонтали — ориентация на технические возможности. По диагонали мы отображаем масштабирование компании.
На первом этапе у нас был CTO типа Startup Coder, в команде которого было до 10 человек. Он отлично справлялся с техническим развитием продукта + лично управлял небольшой командой.
На втором этапе количество сотрудников у нас подросло до
50 человек. На этом этапе Engineering Manager переключается на агрессивный найм и сетап команд. Он меньше думает про технику и больше про сбалансированность команд и обеспечение их работы.
На этапе “Maturity — формализации структуры и управления” у CTO команда уже порядка 150 человек и ему достаточно сложно совмещать техническую и процессную историю. Он занимается причесыванием оргструктуры после бурного роста, формализует роли и грейды сотрудников, внедряет performance review и т.д. В итоге, к нему на помощь могут прийти delivery manager для помощи по части процессов и/или Architect для помощи по технической части. Ну и потенциально наш CTO может быть уникальным единорожкой “All-in-One CTO”, который справляется со всем этим самостоятельно:)
Maturity — усложнение сложности
На этом этапе рост компании в рамках изначального рынка замедляется и компания решает диверсифицировать свою деятельность и запускает продукты в смежных областях. Это приводит к усложнению структуры компании и некоторой децентрализации процесса принятия решений.
Интересно посмотреть на пример из банковской индустрии (по книге “Bank 4.0”), где банкинг прошел 4 стадии:
Теперь посмотрим на то, как развивалась группа компаний Tinkoff
Можно заметить, что уже значительное время происходит диверсификация рынков, появляются новые продукты и значительная доля прибыли приходит с некредитных продуктов. Ну и стадия вездесущего банкинга из книги Банк 4.0 на этом графике наступает после появления в 2019 году Super App, объединяющему финансовые продукты в одном приложении.
Для такого развития компания работает в рамках отдельных бизнес-вертикалей, у каждой из которых есть отдельное IT управление, которое входит в департамент IT. Также есть отдельные истории с платформенными и сервисными линиями, которые предоставляют централизованные сервисы, которые нужны всем. И у этих платформенных и сервисных линий есть свое отражение в соответствующих IT управлениях.
Теперь взглянем на то, как меняется роль CTO в таких крупных организациях, которые проходят этап усложнения сложности.
По-факту, наш All-in-One CTO морфирует в трехголового Змея-Горыныча, который состоит из 3х ролей: CIO, CTO, VP of Engineering. Конкретные обязанности этих ролей сильно зависят от конкретной организации, также как наличие отдельных людей под эти роли или совмещение части из них в одном человеке. Давайте приведем одну из конфигураций зон ответственности (кстати, в Tinkoff конфигурация отличается):
В Tinkoff конфигурация отличается. По-факту, руководит всем департаментом IT наш CIO, который входит в правление компании. Ему репортят руководители управлений, которые эффективно являются CTO конкретных бизнес-вертикалей, платформ или сервисных линий.
Decline
В результате конкуренции, сокращающегося рынка организация сталкивается с уменьшением спроса на свою продукцию или услуги. Руководители ищут пути удержания рынков и использования новых возможностей. Увеличивается потребность в работниках, особенно тех, кто обладает наиболее ценными специальностями. Количество конфликтов нередко увеличивается. К руководству приходят новые люди, предпринимающие попытки задержать упадок. Механизм выработки и принятия решений централизован.
Подводим итоги
Если отобразить все этапы развития компания на одном рисунке, то получится такая картина.
Но нас интересует не просто она, а маппинг CTO разных уровней на эти этап
На этом доклад подходит к концу, а ниже список рекомендованной литературы, на которую я ссылался чуть выше по тексту.
