Первые 72 часа CTO, по версии практикующего interim-руководителя, важнее любого быстрого погружения в репозиторий. В материале для русскоязычной аудитории Habr / Карьера автор с опытом временного управления инженерными командами разбирает типичную ошибку нового техдиректора: в первый день лезть в код, хотя главный дефицит в этот момент не технический, а управленческий.
Повод для текста предельно прикладной. Автор работает fractional и interim CTO: приходит в компанию после ухода предыдущего техдиректора, в момент перегруза инженерной команды или перед важным этапом вроде подготовки к инвестиционному раунду. Сценарий, который он описывает, знаком многим: новый CTO получает доступы, открывает репозиторий, находит очевидные проблемы и пытается быстро доказать свою полезность делом. На короткой дистанции это выглядит как инициативность. На длинной, пишет автор, часто заканчивается одинаково: полгода спустя у руководителя нет ни реальных полномочий, ни доверия внутри компании, ни запаса сил.
Логика этой ошибки понятна любому разработчику, доросшему до управления. Код дает быстрый и понятный отклик: сломанное можно починить, тесты позеленеют, пайплайн пройдет, команда увидит результат. Но CTO нанимают не за способность первым найти баг в сервисе и не за самый быстрый рефакторинг. На верхнем уровне должности ставка делается на другое: понять, чего на самом деле ждет CEO, где в компании проходят реальные линии влияния, какие решения уже зависли в неформальных договоренностях и какие риски никто не называет вслух. Это куда менее комфортная зона, чем инженерный разбор, потому что там нет ни компилятора, ни логов, ни четкой проверки гипотез. Зато именно там обычно и лежит причина, по которой бизнес вообще ищет нового технического руководителя.
Главная мысль текста строится вокруг парадокса первой недели. Пока CTO ничего не знает о компании, это не слабость, а актив. В этот момент он еще замечает то, к чему внутренние сотрудники давно привыкли: ручные деплои, бессмысленные планерки, вечные миграции, странные ритуалы согласований. Через несколько месяцев глаз замыливается, и многие дефекты среды перестают восприниматься как дефекты. Поэтому первые 72 часа CTO автор предлагает тратить не на код-ревью, а на сбор необработанной картины реальности. Идея неприятная для инженера, зато очень понятная для бизнеса: если новый техдиректор слишком быстро начинает оценивать техническую часть, ему почти сразу перестают показывать реальную систему и начинают показывать витрину.
В качестве практики на первый день автор предлагает не раздавать оценки, а задавать руководителям три вопроса. Первый: что должно измениться через 90 дней, чтобы найм CTO признали удачным. Здесь часто вскрывается разрыв между формальной вакансией и настоящим ожиданием CEO. На бумаге может быть написано «выстроить процессы», а в голове у основателя сидит вполне конкретная боль: сорванный релиз, нестабильная команда, конфликт между разработкой и продуктом. Второй вопрос: что новый руководитель может упустить. Он помогает быстро вытащить реальные страхи бизнеса, а не фасадные формулировки. Третий: кому в команде доверяют и почему. Это уже не про офисную политику в бытовом смысле, а про карту опорных точек. У нового CTO своего доверия пока нет, значит, первое время придется работать на заемном капитале.
Второй день, по описанию автора, должен быть посвящен не оргструктуре на бумаге, а реальному устройству власти. Почти в любой компании есть человек, без неформального одобрения которого решение не поедет, даже если по должности он не выглядит центром влияния. Есть чат, где все решают до встречи. Есть сервис или участок инфраструктуры, который никто не трогает не потому, что он стабилен, а потому, что все его боятся. Именно здесь текст попадает в нерв зрелых IT-команд: громкая проблема и настоящий риск обычно не совпадают. На встречах люди охотно рассказывают о том, что давно обсуждается и уже имеет своих сторонников и противников. Но критическая уязвимость чаще тихая. Это может быть один инженер, который единственный понимает, как работает прод; старый биллинг, который не трогали годами; временная интеграция, внезапно ставшая базовой для крупнейшего клиента. Если новый CTO бросается тушить только то, о чем все шумят, он собирает быстрые аплодисменты и откладывает большой кризис на потом.
Не геройствовать, а выстраивать контур управления
На третий день автор рекомендует сделать один маленький, но завершенный ход. Не объявлять реформу, не обещать переписать архитектуру, не выкатывать новую модель процессов. Лучше устранить дефект, который все давно терпят и который почувствует команда: флакующий тест, ночной ложный алерт, бесполезную регулярную встречу. Смысл не в масштабе задачи, а в сигнале. Для организации это означает, что новый CTO сначала слушает, потом действует и выбирает не самые эффектные, а самые болезненные точки. В инженерной среде такая репутация, как ни странно, часто работает лучше публичных стратегических деклараций.
Отдельно автор настаивает на вещи, которую многие управленцы недооценивают: письменной фиксации ожиданий. После первых разговоров с CEO нужно коротко описать, на чем CTO сосредоточится в первую очередь, а что сознательно откладывает. Вторая часть, по сути, важнее первой. Невысказанные ожидания в управлении разработкой почти всегда превращаются в конфликт на втором или третьем месяце: «почему ты не занялся этим сразу», «я думал, это входит в приоритет», «мы нанимали тебя для другого». Письмо не решает все проблемы, но снимает самый дорогой тип хаоса, когда стороны уверены, что договорились, хотя на самом деле каждый имел в виду свое.
Из этого же подхода вытекает и следующая мысль, полезная не только CTO, но и VP Engineering, Head of Development и фаундерам технических компаний. Выживает не тот руководитель, который однажды героически вытащил релиз, а тот, кто создал скучный, предсказуемый ритм управления. Регулярная встреча с CEO, постоянная коммуникация с командой, понятные еженедельные апдейты без драматургии и саморекламы. На старте это может казаться бюрократией. Через полгода именно из этой «скучной инфраструктуры» обычно и вырастает влияние: решения не теряются, ожидания не расползаются, приоритеты не приходится заново доказывать на каждом круге.
Почему этот текст важен не только для CTO
Хотя материал адресован прежде всего техническим директорам, его полезно читать и тем, кто нанимает таких людей. Для CEO и HR здесь есть неприятный, но честный вывод: нельзя одновременно ждать от нового CTO мгновенного технического подвига и постепенного завоевания управленческого мандата. Если компания зовет человека «разобраться с инженеркой», а сама оценивает его по скорости входа в кодовую базу, она подталкивает к той самой ошибке, которую потом будет считать личным провалом руководителя. Для разработчиков и тимлидов текст тоже звучит узнаваемо: новый начальник, который в первые дни демонстративно чинит код, может казаться своим парнем, но это еще не значит, что он понимает, как устроена сама организация.
Самый сильный тезис автора в том, что первые 72 часа CTO не разогрев перед настоящей работой, а момент, когда закладывается право на будущие непопулярные решения. Бюджетные разговоры на третьем месяце, отказ от чужой инициативы на пятом, попытка поменять процесс без внутреннего саботажа на шестом опираются не на харизму и не на былые инженерные заслуги, а на то, что было собрано в самом начале: карта доверия, список повторяющихся болей, зафиксированные ожидания и несколько маленьких выполненных обещаний. На фоне культа «лидера-спасателя» это звучит почти контркультурно. Но именно такая тихая, дисциплинированная работа все чаще выглядит более реалистичной моделью для компаний, где инженерка уже слишком сложна, чтобы управлять ею в режиме героического дебага.