Где у CTO больше свободы: стартап и корпорация

Кирилл пришёл в технологии через системное администрирование и не работал профессиональным разработчиком. Его путь к CTO складывался из постепенного расширения задач. В медицинском стартапе он сначала руководил поддержкой, наладил работу своей службы и предложил взять на себя разработку. В START пришёл проектным менеджером; когда часть команды, включая прежнего технического руководителя, ушла, получил возможность занять освободившуюся роль. За шесть лет команда выросла примерно с 12 до 150 человек. Это не история заранее рассчитанной карьерной лестницы: гость отдельно отмечает случайности, готовность брать новые задачи и совпадение момента с накопленным опытом. Для инженера такой переход означает смену способа влияния: сначала хорошие решения находишь сам, затем помогаешь находить их команде, а дальше отвечаешь за способность всей организации работать с технологиями. Проверить интерес к менеджменту можно небольшими дополнительными обязанностями и обратной связью, прежде чем менять роль целиком.

Масштабирование потребовало пересматривать процессы, а не только нанимать людей. Книги дали Кириллу набор подходов, но особенно помогли разговоры с CTO, уже прошедшими похожий путь. Он договаривался о встречах, описывал конкретную проблему, узнавал об ошибках коллег и адаптировал решения к своему контексту. В стартапе роли оставались широкими: проектный менеджер мог одновременно писать подробные требования, выполнять работу системного аналитика и вести несколько команд. Первый собственный кодировщик контента написал разработчик Python. По мере роста менялась и экономика платформы. На старте использовались внешние CDN, биллинг и кодировщик; позднее стоимость и ограничения поставщиков создавали основания разрабатывать отдельные компоненты самостоятельно. Новые направления команды возникали из потребностей бизнеса и технологий. Это важное ограничение истории роста: увеличение штата само по себе не цель, а сильный специалист или отдельная команда нужны там, где появилась работа, которую прежняя структура уже не решает.

Переход в «Звук» был связан и с накопленной усталостью, и с интересом к большему масштабу. Вместо знакомой среды Кирилл оказался среди вертикалей, горизонтальных связей и обязательных требований, назначение которых сначала было неочевидно. По его оценке, на полноценное понимание правил игры ушло около полугода. Главная перестройка заключалась в отказе от привычки самому быстро исправить техническую проблему и сразу увидеть результат. В большой организации CTO строит систему, способную выполнять эту работу через других людей. Для этого нужно разобраться в ожиданиях генерального директора и директора по продукту, услышать проблемы команды и наладить взаимодействие с руководителями первого и второго уровня. Авторитет появляется через действия и полезные изменения. Кирилл предлагал команде обсуждать его решения и проверять аргументы, хотя признаёт: часть привычек из предыдущей компании сегодня перенёс бы иначе.

Одним из изменений стали платформенные команды и распределение знаний, прежде сосредоточенных у отдельных специалистов. В маленькой компании зависимость от одного человека может быть осознанным риском при ограниченных ресурсах; на большом масштабе она угрожает работе системы. Другой задачей стало развитие инженерной карьеры. Если после уровня senior доступны только руководящие должности, компания либо теряет сильного инженера, либо превращает его в менеджера ради повышения дохода. В «Звуке» развивали техническую вертикаль, где можно влиять через экспертизу без обязательного управления людьми. Однако такую роль нельзя создавать только ради названия: нужны сложные задачи, понятная область применения и польза для бизнеса. Сильные инженеры развивают коллег и самого CTO; руководителю полезно нанимать людей, которые лучше него разбираются в отдельных областях. Александр отдельно описывает опыт staff-инженеров: технологических экспертов и участников сложных межкомандных проектов, чья ответственность отличается от заботы о повышениях и регулярных встречах с подчинёнными.

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

Отдельная трудность корпорации — прекращать работу над тем, что перестало приносить пользу. Команды заинтересованы в продолжении своих проектов, а ресурсов иногда достаточно, чтобы долго поддерживать лишние функции. Кирилл связывает способность отказываться от них с культурой и готовностью принять трудное решение, обосновать его и довести до конца. Александр добавляет объяснение через стимулы: за успешную инициативу руководитель может получить небольшое признание, тогда как неудача делает его персонально виноватым. В такой среде ожидание указаний становится рациональной стратегией. Обмен полезными практиками поэтому не сводится к копированию процессов. Стартапу пригодятся умеренная формализация, наблюдаемость и управление рисками: например, понятный порядок действий при инциденте и распределение ответственности. Корпорации — автономия команд, короткий путь проверки гипотез и персональная ответственность за результат. Финальный карьерный совет Кирилла возвращает разговор к началу: двигаться к большему масштабу ответственности, развивать кругозор и понимать интересы других людей, а не стремиться исключительно к титулу CTO.