Оценивать CTO сложно именно потому, что большая часть хорошей работы технологического руководителя не выглядит как отдельный результат. Предотвращённая проблема не случилась. Правильный архитектурный выбор может стать заметен через год. Сильный руководитель может вообще реже участвовать в операционных решениях, потому что команда научилась принимать их сама.
Поэтому вопрос «сколько фич выпустило IT?» почти ничего не говорит о качестве CTO.
Начните с того, за что CTO отвечает
Нельзя оценивать человека по роли, которую компания сама не определила. В одной компании CTO отвечает за продуктовую технологию и архитектуру, в другой — ещё и за всю инженерную организацию, инфраструктуру, безопасность и внутренние системы.
Сначала нужно договориться о нескольких зонах ответственности. Какие решения принадлежат CTO? Какие риски он должен контролировать? Какие изменения компания ждёт от технологической функции?
Без этого оценка быстро превращается в набор субъективных впечатлений. Если сама граница роли неочевидна, полезно сначала разобраться, чем CTO отличается от VP of Engineering и что именно компания ожидает от каждой роли.
Смотрите на качество решений, а не на их количество
Слабый CTO может быть очень занят. Он присутствует на каждом совещании, согласует архитектуру, смотрит pull request и лично решает десятки вопросов. Это создаёт ощущение контроля, но часто означает только одно: без него система не работает.
Сильный CTO строит механизм принятия решений. Понятно, какие вопросы решаются в командах, какие поднимаются выше и какие требуют его личного участия.
Полезный вопрос CEO: становится ли технологическая организация со временем более самостоятельной или всё сильнее зависит от одного человека?
Проверяйте предсказуемость
Технологии невозможно сделать полностью предсказуемыми. Но постоянные сюрпризы — плохой сигнал.
Если CEO узнаёт о критическом техническом долге только перед запуском, о проблемах с масштабированием — после падения системы, а о нехватке людей — после срыва квартального плана, CTO не управляет рисками, а сообщает о последствиях.
Хороший CTO не обещает отсутствие проблем. Он делает так, чтобы важные проблемы становились видимыми заранее.
Смотрите, как технология связана с бизнесом
CTO не должен отвечать на любой бизнес-запрос словом «нет» только потому, что решение технически некрасивое. Но он также не должен превращать инженерную организацию в фабрику срочных хотелок.
Сильная работа видна в качестве компромиссов: где компания сознательно ускорилась, где инвестировала в фундамент, где приняла риск, а где отказалась от него.
CEO должен понимать не все технические детали, а логику технологического выбора и его последствия для бизнеса.
Посмотрите на команду под CTO
Очень полезный индикатор — качество руководителей и экспертов, которых CTO выращивает вокруг себя.
Есть ли сильные Engineering Managers, архитекторы и технические лидеры? Могут ли они спорить с CTO? Понятно ли им, за что они отвечают? Или вся организация ждёт решения одного человека?
Если спустя несколько лет любой серьёзный вопрос всё ещё должен дойти до CTO, это не признак незаменимости. Это организационный долг.
Оценивайте не отсутствие технического долга, а управление им
Компания без технического долга, скорее всего, либо ничего не делает, либо называет его другим словом. Задача CTO — не уничтожить долг, а сделать его осознанным.
Какие ограничения уже тормозят бизнес? Какие могут подождать? Что станет критичным при росте? Где дешевле жить с несовершенством, чем исправлять его сейчас?
Если эти разговоры ведутся понятным бизнесу языком, CTO управляет технологическим риском. Если технический долг появляется только как аргумент «нам нужен ещё квартал на рефакторинг», диалог устроен плохо. Для грубой количественной оценки можно использовать мой калькулятор технического долга, но сам по себе балл не заменяет разговор о бизнес-последствиях.
И главный вопрос: что стало лучше без участия CTO?
Парадокс сильного технологического руководителя в том, что часть его успеха делает его самого менее заметным.
Команды быстрее принимают решения. Риски поднимаются раньше. Бизнес лучше понимает цену выбора. Архитектура развивается не только в голове одного человека. Инженерные руководители становятся сильнее.
Эти же признаки полезно проверять ещё на этапе найма: вопросы кандидату должны показывать не только техническую глубину, но и то, как будущий CTO принимает решения, строит команду и работает с бизнесом.
Хороший CTO не должен быть главным героем технологической организации. Его результат — организация, которой всё реже нужен герой.