Think Like a CTO: базовая линия для небольших компаний

Саша выбрал книгу, когда у него сменилась зона ответственности и понадобилось расширить взгляд на её периметр: оглавление совпадало с тем, чем должен заниматься руководитель разработки. Оба сразу называют главное ограничение — автор пишет из опыта фонда, который покупает небольшие компании, чинит их и перепродаёт через два-три года, поэтому советы рассчитаны на кризис-менеджмент при десятке-тридцати разработчиках. Для таких компаний книга задаёт полезную базовую линию, потому что часть функций у них просто западает; в крупную технологическую компанию с ней не пойдёшь. Первая глава про то, кем бывает CTO, разложена по этапу жизненного цикла и по тому, первый ли ты директор или пришёл после кого-то. Саша отмечает честные наблюдения: должность вместо зарплаты как манипуляция на ранних стадиях и прямой совет уступить место, если не справляешься, — отсылка к принципу Питера, которую он предлагает читать мягче: зрелый CTO видит, где у него провисает зона, и укрепляет её людьми.

Александр вспоминает свой доклад 2021 года «CTO от стартапа до IPO»: на каждом этапе компании нужен разный руководитель, и человек, которому хорошо в стартапе, может заскучать на стадии тонкой настройки продукта или борьбы за издержки на зрелом рынке. Отсюда его главный тезис — честно понимать, что хочешь делать сам и что компании нужно прямо сейчас, иначе однажды не захочется идти на работу. Раздел про первые дни в роли Саша дополняет ловушками аудита: «дрейф в сторону известного», когда человек кидается чинить знакомый участок, не дойдя до полной картины; переговоры об ожиданиях, где бизнес-заказчик и команды пытаются повесить на новичка амбиции предшественника; и «эффект арбуза», когда по метрикам всё зелёное, а внутри красное. Александр добавляет к этому Швейка: проблема смягчается на каждой ступеньке доклада наверх.

Глава о взаимодействии с руководителями в оригинале называется managing up, и участники считают перевод неудачным: речь идёт именно о CEO, финансовом директоре и общих комитетах, а не о горизонтальных связях с коллегами, которые в книге почти не раскрыты. Саша раскладывает коммуникацию по векторам — вниз, к своим людям и через уровень; вбок, к пирам и к продуктовому директору; вверх — и добавляет ветку к бизнес-заказчику, которой у автора нет. Полезнее всего ему показалась часть про финансового директора: для инженера, пришедшего в роль, управление бюджетом — новая зона. Автор предлагает делить расходы на разработку, эксплуатацию и поддержку, что похоже на привычное деление на изменения и текущую работу, и советует держать финансовую модель, прикидывая рост расходов вместе с клиентской базой. Управление изменениями автор проходит вскользь, и Саша отправляет за глубиной к модели Коттера и его книге про айсберг; долину страданий в книге он читает как отсылку к циклу Гартнера, который Александр как раз разбирает в черновике.

Главу о долгосрочном видении оба называют простой: она сводится к тому, что технологическая стратегия должна поддерживать миссию и видение, но не говорит, как её каскадировать вглубь, а без этого написанная стратегия сама не заживёт. Александр противопоставляет ей Technology Strategy Patterns: говорить на языке бизнеса, понимать его паттерны — SWOT, матрицу BCG и прочие инструменты, которыми легко жонглируют финансовый и коммерческий директора, — и объяснять через них, почему техническое решение поможет деньгам. Саша замечает, что автор упоминает «опоры в технологиях», но не даёт способа их выбрать, и советует подходы из DDD для выделения доменов и степени влияния. Спор о «быстро, качественно, дёшево» они переводят в проектный треугольник и дальше в портфельное управление: стратегия исполняется набором связанных инициатив с общим бюджетом, и это инструмент, которым надо уметь пользоваться, — если в наборе один молоток, вокруг только гвозди.

Три главы про команду — создание, собеседования, управление — оба считают написанными на уровне тимлида: баланс компетенций, фактор автобуса, как составить вакансию. Саша заметил, что раздел о тексте вакансии длиннее раздела о лидерстве, где автор лишь обещает «ещё две книги», не называя их; ему не хватило и мышления уровнем команд, а не отдельных людей. Полезная нить одна — матрица компетенций, к которой автор возвращается при найме и оценке. Динамику команды Саша дополняет моделью Такмана, а Александр — своим подкастом с Настей Кобичевой, где Такман сравнивался с психодинамической моделью, и рассказом о том, как в Т-Банке оценка стала промо-запросом с пакетом артефактов от самого сотрудника. Глава о технологических решениях — купить или сделать, облако или свои серверы — сводится к критериям и сравнению опций; Александр, рассказывавший об архитектуре в масштабе и ведении RFC и ADR, не находит в ней процесса: журнала решений, пересмотра, экспертизы.

Сильнее всего его задела глава о разработке: водопад описан по байкам, без циклов обратной связи из оригинальных статей, гибкая разработка сведена к скраму, а про качество почти ничего. Взамен он советует Accelerate и книги про инженерные процессы, Саша — романы Де Марко и Голдратта и «Проект Феникс» как лёгкий вход. Главы о договорах, документации и безопасности участники проходят быстро: это гигиена, в большой компании за ней стоят юристы, отдельные команды и CISO, а автор описывает уровень «хотя бы что-то записать, пока Вася не ушёл». Поддержку они пересказывают как уровни от первой линии до команды, главы о росте компании — как due diligence и байку про три конверта. Последний совет книги — готовить преемника — Александр иллюстрирует опытом: при шестистах пятидесяти людях и нескольких доменах в какой-то момент нужно разделять зоны, и если не растил людей заранее, ступеньку не переступить. Саша поставил бы этот совет гораздо раньше. Итог общий: книга противоречивая, но провоцирует рефлексию, и это в ней главное.