Как стать СТО: рассказывают технические директоры IТ-компаний

СТО (технический директор) — один из руководителей компании, отвечающий за разработку новых сервисов или продуктов, а также за оптимизацию работы производства. СТО различных компаний рассказали DOU о том, как занять эту должность, что нужно знать и уметь, что в ней самого сложного и как развиваться дальше.

Дмитрий Абрамов, Delivery Director, Deputy Head of Kiev R&D Center в DataArt

Стоит помнить, что «T» в аббревиатуре CTO значит «technical». Технический лидер должен хорошо понимать, как именно работают все инженерные и девелоперские процессы в компании. В небольших стартапах CTO чаще всего участвует и в написании кода, и в выпуске релизов, и в настройке сред, и в разработке технической архитектуры. В средних и крупных бизнесах часть этих функций делегируется другим людям, но разбираться во всех деталях производства CTO просто обязан. В силу этого чаще всего в CTO вырастают инженеры. Стать сильным разработчиком, побыть архитектором, запустить пару сложных продуктов в прод — типичный путь для хороших CTO.

Станет сложно, когда окажется, что Chief — это не просто «главный». Это босс, это лидер большой команды, это глава части компании, это ответственный за бесперебойную работу всех технических инструментов: от приложений пользователей до серверов в облаке и подписок на внешние SaaS и платёжные системы. Придётся работать с людьми, и когда от CTO-новичка начинает зависеть их найм, зарплаты и увольнение, не все справляются одинаково хорошо. Более того, придётся заниматься также бюджетами, контрактами, переговорами с бизнесом, защитой перед финансовым директором или владельцем компании своих идей и людей. Как ни крути, но C-levelобязывает быть не просто инженером, но и уметь управлять компанией в команде других топов. Не для всех начинающих очевидно, что топ-босс должен уметь делать очень многое, иначе ему не выжить.

Чтобы иметь возможность стать CTO, нужно в первую очередь понять, как работает бизнес. Откуда он берёт деньги, кто его клиенты, что компания для них делает, какими инструментами для этого пользуется и какие средства вкладывает в поддержку своей инфраструктуры? Понимание базовой экономики бизнеса, умение составлять и исполнять бюджет is a must. Дальше следует озаботиться умением общаться с внутренним заказчиком и совместно работать над созданием новых сервисов. Ну и, естественно, нужно быть сильным технически, чтобы уметь планировать и создавать то, что необходимо компании для жизни.

Для получения опыта, необходимого для CTO, я советовал бы поработать в нескольких проектах, которые привели к выходу продукта на рынок. Причём делать это в роли тимлида, архитектора или PM. Желательно иметь частое общение с бизнесом, для которого делается продукт, чтобы научиться понимать его ожидания и ограничения.

Павел Никиточкин, CTO & Management 3.0 Practitioner в JetThoughts

CTO горят идеей, имея достаточно организационных и технических навыков для создания и управления компанией. CTO зачастую являются ветеранами отрасли с многолетним опытом управления и ведения бизнеса. С другой стороны, часто это могут быть неопытные, но талантливые программисты, которые превратили свою страсть программировать в бизнес.

Вы не научитесь быть СТО в школе. Ресурсов, которые помогут именно научиться быть CTO не так много, как хотелось бы, но все же я постараюсь указать пути вашего развития и получения навыков для того, чтобы стать опытнее в этом деле:

• банальная, но все же самая эффективная стратегия — найти наставников, которые лучше вас, и учиться у них, опирайтесь на опыт успешных СЕО/СТО;
• если в вашем окружении таковых нет, напишите холодные письма или свяжитесь с опытными СТО или техлидами посредством Twitter (или других соцсетей) и попросите у них совет/наставничество за чашечкой кофе;
• познавательной будет книга Джоела Бисли «Современный СТО»;
• из подкастов рекомендую обратить внимание на: CTO Think, Modern CTO;
• посещайте встречи и собрания CTO в различных крупных городах. Это могут быть конференции и саммиты. Можно найти в Календаре;
• черпайте знания в профильных сообществах и каналах. Как пример — популярный @rands.

Самая главная трудность — это принять трансформацию. Надо искать мотивацию для решения нового рода проблем. Будет тяжелее выделить время на отдых и семью. Теперь это не четко сформулированные технические задачи, а часто меняющие и не тривиальные проблемы бизнеса.

Программистам, которые начинали с увлечения технологиями, придется перестроиться и перейти на «скучную» для них сторону. Technical Frameworks заменяются на Management Frameworks. Programming Language превратятся в Official/Corporate Language! Clean Code на Team Culture!

Как развиваться дальше? Наставлять других — помогать начинающим и тем самым давать оценку своим методам и улучшать их. Конкуренты не дадут засохнуть, надо всегда повышать производительность. Для этого надо иметь среду, позволяющую проводить постоянные эксперименты и делать выводы.

Зеник Матчишин, СТО в Altran Ukraine (Lohika)

Перед тим як почати навчання, найкраще визначити, якого типу СТО ви хочете стати. Якщо дуже все спростити, є 3 види СТО:

1. Технічний-технічний. Виключно програмує, з бізнесом не пересікається.
2. Технічний-бізнес. Трошки програмує, трошки пересікається з бізнесом.
3. Бізнес-бізнес. Не програмує, але використовує багаж знань, щоб допомагати бізнесу.

Також є суттєва різниця між СТО в сервісних компаніях та СТО в продуктах. Якщо дуже коротко, то СТО в продуктах — це повна відповідальність за технічний розвиток саме цього продукту, в той час як СТО в сервісних компаніях — це розвиток нових компетенцій та підтримка існуючих на хорошому рівні, щоб могли допомогти продуктам.

З цією ввідною можна краще дати відповідь, як вчити. Якщо коротко, то на СТО не вчаться, СТО стають. Найефективнішим методом є проходження всіх кроків кар’єрного розвитку, щоб набратись досвіду та зрозуміти, як воно працює, і дійти до рівня архітекта. Після рівня архітекта можна спеціалізуватися:

• взяти і зробити один продукт з нуля та побути з ним хоча б 3-6місяців після продакшена — шлях продуктового СТО;
• паралельно брати участь в максимальній кількості проектів у ролі людини, яка «вирішує технічні проблеми» — шлях сервісного СТО.

Паралельно треба обов’язково бути в ситуаціях, коли ви працюєте з іншими СТО для вироблення поведінкових моделей та пасивного менторства. Проекти бувають дуже різні, тому стартовою точкою є відповідь на питання «Що я маю робити, щоб все працювало, і я був не потрібний». Ця відповідь буде містити набір технологій, підходів та практик, включаючи й підходи до людей. Як тільки ви це зробили раз і несли за це відповідальність, ви вже майже там. Пропорційно до розміру компанії росте потреба в people/soft skills. Чим більше людей, тим більше ви маєте бути доступні. Типово це має бути виправлено на рівні архітекта, але бажано не зупинятись.

Головні труднощі:

1. Треба розуміти, що ви будете в команді, і найчастіше це буде компроміс: «Так, AWS — це добре, але тут хочуть Azure, тому якщо ми хочемо рухатись далі, треба змінити підхід».
2. Комунікувати технічні рішення треба буде часто нетехнічним людям, тому без високих навиків комунікації будуть постійні конфлікти.
3. Треба також нести відповідальність за чужі рішення. В галузі є багато людей, які не затримуються на роботі і бавляться в resume driven розробку, і з їхніми аргументами та рішеннями треба теж вміти працювати. СТО — це в першу чергу відповідальність, і різні відмовки не є хорошим розвитком подій.
4. Кількість дрібних задач буде дуже великою, тому якщо є труднощі з багатозадачністю, краще навіть не починати.
5. Деколи технології не вистрілюють, і треба вміти переходити на інші речі. Програмне забезпечення — це таки не будинок, і деякі речі міняти можна, але треба вміти і знати як.
6. Треба дружити з грошима, так як на рівні СТО вже треба працювати з бюджетами та фінансовим плануванням.
7. По суті, тиск для розвитку вже не зупиниться, ви можете вибрати тільки напрямок (мені це більше плюс, проте комусь і мінус).

В залежності від вашого позиціонування та типу є 3 можливих шляхи розвитку:

1. Покривати собою повний поточний технічний стек.
2. Постійно стрибати зі стеку на стек.
3. Вийти на мета-рівень та працювати в режимі make things happen.

Найоптимальніше буде стати СТО продукту і повністю пройти там всі стежки, щоб все було відоме та зрозуміле, і після того зробити декілька технологічних стрибків. Тоді в голові буде загальне розуміння базових речей, і якщо ви не перестарались, ви і далі мотивовані та матимете життєві сили, що дозволяє виходити на мета-рівень, де вам, по суті, вже буде все одно, з якою технологією працювати. Ви зможете досягати поставлені технічні цілі будь-якими доступними методами.

Тарас Мурашко, CTO в EVO

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

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

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

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

Самое сложное — соблюдать баланс между потребностями бизнеса и технологиями, не допускать перекосов. С одной стороны, внедрять нужные бизнесу вещи, с другой — жестко апеллировать к технологическим ограничениям и необходимости срочного рефакторинга или перехода на новые технологии.

Самое приятное в работе, — наверное, наблюдать, как проект развивается дальше, как команды делают лучшие продукты. Ну и как счастливы клиенты, которые пользуются теми продуктами, которые создает компания.

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

Дмитро Волошин, СТО в Preply

У нас немає профільної освіти на роль СТО, тому вчитися краще на практиці. Варто розуміти, що це частково управлінська посада, оскільки СТО взаємодіє з менеджментом компанії, але не плутати її з VP-Engineering — роль якоготполягає більше в роботі з людьми. Для себе я визначаю роль СТО в тому, щоб перетворювати людський потенціал команди розробників в якісний технічний продукт. Тобто відповідати за технічний стек, мати візію його розвитку і підтримувати процеси.

Відповідно найкраще до цієї ролі готують ролі нижчого рівня — Head of Engineering, Technical Lead, Solution Architect. Наприклад, у час моєї відсутності роль СТО в компанії виконує хтось з technical leads. На практиці варто брати великі проекти з впровадження нових процесів, технологій чи просто об’ємного функціоналу і доводити їх від початку до продакшену. В ідеалі варто також розвивати базові компетенції роботи з людьми, софт-скіли.

Основні труднощі полягають в тому, що роль у різних компаніях має різний зміст. Наприклад, СТО Амазону — це візіонер, який думає над новими технологіями і продуктами. В той час як від СТО маленького українського стартапу очікується писати код, СТО в банку більше буде відповідати за безпеку тощо. Тому варто розуміти, який кар’єрний план, в якій компанії будувати. Інша стандартна проблема — це баланс бажань бізнесу і можливостей технічної команди. Варто розуміти, що робота СТО — це спектр. Не можна бездумно робити все, що хоче бізнес, тому що в якийсь момент все розвалиться під тягарем технічного боргу. З іншого боку, якщо робити лише те, що хоче технічна команда, то «космічні кораблі будуть бороздити простори всесвіту» і бізнес перестане заробляти.

З теоретичних речей для подальшого розвитку варто читати технічну літературу, розуміти, куди рухається індустрія. СТО повинен мати досить великий авторитет в команді, адже команди розробки дуже раціональні. Хороший варіант розвитку — мати ментора СТО більшої компанії, відвідувати тематичні конференції. Також зауважу, що в Києві раз в півроку проводяться СТО мітапи, і для цього є закрита группа.

Дмитрий Лапшин, СТО в Sigma Software

Если честно, слабо себе представляю, как можно специально «учиться на CTO». И даже не уверен, что существуют какие-то специализированные курсы по этой теме. Скорее, стоит говорить о том, на чём фокусироваться в процессе обучения:

— Расти не только «вглубь», но и «вширь». Кажется, широкий технический кругозор и понимание того, как работает высокотехнологичный бизнес — это обязательная программа-минимум.
— Системный подход и целостное видение решения проблем.
— Эффективная коммуникация. Даже самый опытный программист в принципе может позволить себе быть букой-затворником. Но CTO общается и с проектными командами, и с руководством компании, и с клиентами. Важно подбирать нужные слова и проявлять находчивость, иногда даже немного быть дипломатом.

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

Затем, думаю, что крайне важно избежать соблазна поддаться хайпу и начать думать в ключе: «Ага, вот теперь-то я точно сделаю всё стильно-модно-молодёжно!». Потому что в реальности нередко технологии, активно нахваливаемые в блогах и на конференциях, на самом деле имеют ограниченную область применения и/или существенные подводные камни.

Поначалу бывает сложно побороть в себе симпатии к одному технологическому стеку и антипатии к другому. Если ты разработчик, можно, условно говоря, любить Java и ненавидеть .NET. Но как CTO ты совершенно точно не можешь себе позволить такие оценочные суждения.

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

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

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

Не забывать навыки, как делать те или иные вещи «руками». Наверное, многие из вас слышали про понятие «архитектор-астронавт», обозначающее человека, который сам давно уже не программирует и в результате витает в облаках абстракций, не задумываясь о том, как его гениальные решения будут воплощаться в коде. Так вот — «не надо так» ©. Программируйте хотя бы немного для себя, чтобы не терять навык. А если вы будете это делать, пробуя новые языки программирования, архитектурные подходы и технологические стеки — это будет самым разумным способом прокачивать себя.

Как показывает опыт, нужно быть готовым даже к радикальной смене парадигм. Когда я сам был разработчиком, «рулили» ООП, скрупулезный контроль качества и подходы к разработке с тщательным планированием наперёд. Спустя 10-15лет «на коне» функционально-реактивный подход, Agile, Lean и Minimum Viable Products с качеством «бета-версии». А ещё через 10 лет, возможно, мы вообще будем писать очень мало классического кода, а вместо этого обучать нейросети. Так или иначе, почивать на лаврах совершенно точно не придётся, постоянное обучение и вовлеченность — неотъемлемая часть профессии.