Новый CTO почти всегда приходит с ожиданием изменений. У компании есть проблемы, иначе роль либо не открывали бы, либо не меняли человека. Поэтому желание быстро показать результат понятно.
Но первые месяцы полезнее воспринимать не как время немедленной перестройки, а как период построения точной модели компании. Быстро менять можно то, что уже понятно. Всё остальное сначала стоит понять.
Первый месяц: понять бизнес до технологий
Начинать я бы стал не с архитектурной схемы, а с вопросов к CEO, продукту, продажам, финансам и операционным командам. На чём компания зарабатывает? Где теряет скорость? Какие обещания клиентам особенно критичны? Какие риски руководство уже видит?
Одно и то же техническое ограничение может быть мелкой неприятностью или серьёзным бизнес-риском в зависимости от модели компании.
До понимания бизнеса невозможно правильно расставить технологические приоритеты.
Постройте карту решений
Официальная оргструктура показывает, кто кому подчиняется. Но она редко показывает, кто на самом деле принимает решения.
Кто решает, что попадёт в roadmap? Кто определяет архитектуру? Кто может остановить релиз? Кто распоряжается бюджетом? Какие вопросы месяцами ходят между подразделениями?
Иногда проблема компании не в плохой технологии, а в том, что решения не имеют владельца.
Познакомьтесь с сильными людьми до изменения структуры
Новый руководитель легко видит недостатки существующей команды и хуже видит неформальные механизмы, на которых всё держится.
Кто знает систему глубже остальных? К кому идут при аварии? Кто способен спорить конструктивно? Кто соединяет несколько команд? Кто давно перегружен, потому что без него слишком многое не работает?
Реорганизация до ответа на эти вопросы может убрать именно те связи, которые пока удерживают систему.
Отделите срочные риски от раздражающих несовершенств
Новый CTO почти гарантированно найдёт старый код, странные процессы, ручные операции и решения, которые сам сделал бы иначе. Это ещё не означает, что их нужно исправлять первыми.
Сначала полезно выделить риски, способные реально ударить по бизнесу: критические точки отказа, зависимость от одного человека, проблемы с данными, безопасность, отсутствие восстановления, ограничения роста.
Не всё некрасивое опасно. И не всё опасное выглядит некрасиво.
Во втором месяце сформулируйте несколько решений
К этому моменту должна появиться не огромная программа трансформации, а короткий список вещей, которые действительно нужно изменить.
Например: сделать ответственность за архитектуру явной, убрать один критический bottleneck, изменить процесс приоритизации, усилить инженерное руководство или договориться с бизнесом о правилах работы с техническим долгом.
Хороший план первых месяцев помещается в голову. Если для его объяснения нужен большой transformation deck, возможно, он слишком сложный.
К 90-му дню должно быть понятно не всё, а главное
Через три месяца CTO не обязан исправить технологическую функцию. Но CEO уже должен понимать, что новый руководитель видит систему целиком.
Какие главные технологические риски? Какие организационные ограничения? Какие решения требуют инвестиций? Где компания сознательно принимает компромисс? Кто будет владельцем изменений?
Первые 90 дней CTO нужны не для того, чтобы переделать компанию. Они нужны, чтобы перестать принимать важные решения вслепую.