Вопрос «должен ли CTO писать код?» часто превращается в спор двух лагерей. Одни считают, что технологический руководитель обязан оставаться hands-on. Другие — что настоящий CTO давно должен заниматься только стратегией и людьми.
Мне кажется, оба ответа слишком простые. Роль CTO меняется вместе с компанией.
На ранней стадии код может быть частью роли
Когда команда маленькая, границы должностей условны. CTO может проектировать архитектуру, писать критичные части системы, проводить code review и параллельно нанимать первых инженеров.
В этом нет проблемы, пока компания действительно получает максимальную пользу именно от такого распределения времени.
Проблема начинается, когда организация выросла, а CTO продолжает работать так, будто вокруг всё ещё пять разработчиков.
Самый дорогой разработчик компании — плохая цель
Если ключевой production-код регулярно может написать только CTO, компания получила не техническое лидерство, а новую критическую зависимость.
Каждый час, который CTO тратит на задачу, доступную сильному инженеру, стоит сравнить с тем, что в это время не происходит: не нанят руководитель, не решён конфликт между командами, не принята архитектурная развилка, не выстроен разговор с бизнесом.
Чем больше компания, тем выше альтернативная стоимость личного coding time CTO.
Перестать писать код — не значит перестать понимать технологии
Есть и противоположная крайность. CTO отдаляется от инженерной реальности настолько, что обсуждает технологию только презентациями и бюджетами.
Технический руководитель должен сохранять способность зайти достаточно глубоко: понять архитектурный компромисс, задать неприятный вопрос, проверить логику оценки или увидеть, что команда прячет организационную проблему за техническими словами.
Но «могу разобраться» и «должен сделать сам» — совершенно разные вещи.
Есть много способов оставаться hands-on без ownership production-задач
CTO может участвовать в design review, разбирать инциденты, читать ключевые технические документы, делать небольшие прототипы, обсуждать архитектуру с инженерами или иногда погружаться в код для проверки гипотезы.
Такая работа помогает не потерять контакт с реальностью, но не делает CTO частью ежедневного delivery-контура.
Признаки того, что CTO пишет слишком много кода
Решения ждут, пока CTO закончит текущую задачу. Инженеры несут сложные проблемы сразу ему, вместо того чтобы решать их на своём уровне. Руководители команд получают меньше внимания, чем pull request. CTO начинает обходить процессы, потому что «так быстрее».
Особенно опасный сигнал — когда команда считает, что критичную проблему в конце всё равно придёт и исправит CTO.
Так техническая сила руководителя постепенно делает организацию слабее.
Признаки того, что CTO оторвался слишком далеко
Он не может предметно обсудить ключевые технические риски. Не понимает, почему оценки команды отличаются в разы. Узнаёт о серьёзных архитектурных ограничениях только из эскалаций. Слишком легко принимает красивые технологические объяснения.
Тогда возникает обратная проблема: роль формально стратегическая, но стратегия строится на всё более слабом понимании реальности.
Хорошая точка баланса
Я бы формулировал её так: CTO должен быть способен погрузиться в технологию достаточно глубоко, но организация не должна нуждаться в его личном коде для нормальной работы.
По мере роста компании основным продуктом CTO становится не код, а технологическая организация: люди, решения, архитектурные принципы, инвестиции и способность бизнеса менять систему без героизма отдельных людей.
CTO стоит перестать регулярно писать production-код тогда, когда его личная скорость начинает ограничивать скорость всей организации.