Всем привет, меня зовут Семён, я руковожу разработкой витрины объектов недвижимости в Домклик. Занимал должности от разработчика до директора в разных компаниях и разных странах, проходил этот путь несколько раз и не понаслышке знаю, каково это — выходить из зоны комфорта и в корне менять род занятий. Так, например, происходит при переходе с роли разработчика на роль тимлида. Но сегодня я хочу обсудить следующий возможный шаг в карьере тимлида — переход на директорскую (executive) должность. Он таит в себе много вызовов и неожиданностей. Статья будет интересна тем, кто собирается сделать такой карьерный шаг, а также новоиспечённым СТО, viceCTO, техдирам и прочим Е-level технарям. Прошу под кат.

Сабж

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

Руководство вновь отмечает Петины успехи и предлагает ему возглавить всю инженерную часть компании, стать техническим директором. Такое решение вполне логично: человек хорошо себя зарекомендовал и в роли специалиста, и в роли супервайзера, и поэтому он наверняка справится и с директорской должностью. В свою очередь, Петя руководствуется той же логикой: он смог перейти из разработчиков в лиды, что может пойти не так с ролью техдира? Но проходит время, и в один прекрасный день все разработчики в компании получают скромный анонс, что Петя решил «продолжить развитие за рамками компании». Что произошло? Почему человек, отлично показавший себя в разных ролях, вдруг «не справился» на должности технического директора? Вероятно, Петины ожидания от роли не совпали с реальностью; в то же время, руководство компании тоже не увидело того, что ожидало при назначении Пети на должность. Ниже я рассмотрю, с какими сложностями обычно сталкивается человек при переходе из лидов в директора, и как подготовиться к такого рода переменам.

Бесконечная неопределённость

Первая и не всегда самая очевидная проблема, с которой сталкивается «директор-новичок» — большая степень неопределённости. В бытность разработчиком к Пете попадали хорошо проработанные задачи, с описанным DoD, макетами, критериями приёмки и пр. Работа с такой задачей была конечна во времени и почти всегда имела ощутимый результат (работающий в production код, улучшение ключевых метрик продукта). Когда Петя был тимлидом, он, полагаясь на свои знания доменной модели и архитектуры системы, мог спроектировать фичу от начала до конца, декомпозировать большой эпик на задачи, оценить и передать исполнителям. Степень неопределённости в сравнении с работой разработчика была выше, но Петя успешно с ней справлялся, так как у него был опыт решения подобных задач, пускай и в меньшем масштабе.

В работе же директора нет зоны ответственности, итераций, четких задач, указаний, понимания конечного результата — нет ничего, к чему привык специалист за годы работы. Зачастую, есть только идеи руководства или собственника из разряда «сделать как Гугл, но лучше». Поэтому конечный результат и направление, в котором стоит двигаться, выбирает сам технический директор, сам каскадирует это на своих -1, сам ставит сроки и контролирует выполнение. И конечно же, сам принимает ответственность за всё это. Груз этой ответственности вкупе с отсутствием быстрого результата (а некоторые проекты могут идти месяцами) может негативно сказаться на эмоциональном состоянии и мотивации человека.

«Проблема не на нашей стороне»

Второй отличительной особенностью работы техдиром является то, что не существует «не твоих» проблем. В бытность разработчиком и тимлидом Петя с лёгкостью мог диагностировать проблему и перенаправить её в смежную команду: не грузятся фотки — проблема в CDN, не открывается сайт — это к службе кибербезопасности (они отвечают за WAF), истёк SSL-сертификат — это в инфраструктуру, и т.д. СТО же обязан реагировать на все сигналы и несёт ответственность за весь ИТ-ландшафт. Плохой отзыв в AppStore — твоё, медленно грузится сайт — твоё, не ходит корпоративная почта — твоё, бухгалтер не может создать проводку в 1С — тоже твоё, не работает Wi-Fi в офисе, команда не успевает к дедлайну, большая текучка в подразделении, ввели санкции — ну ты понял… На первых порах такой поток разнородных задач/проблем/поручений вызывает стресс, особенно с учётом того, что вопросы могут возникать на выходных или в нерабочее время. Ах да, для директора нет понятия «нерабочее время».

“Everybody has a plan until they get punched in the face”, Mike Tyson

Ещё один вызов для техдира-новичка — это необходимость принятия решений «здесь и сейчас». Когда Петя был разработчиком, он мог ответить за срок выполнения конкретной задачи; когда он был тимлидом, он мог взять паузу, чтобы детально проработать план реализации фичи, декомпозировать, прикинуть с командой технический дизайн, и только потом вернуться с оценкой. А у директора зачастую нет такой возможности. Собственник/CEO хочет услышать сроки и стоимость выполнения проекта «здесь и сейчас», прямо на совещании, на котором этот вопрос прозвучал. Можно, конечно, на каждый подробный вопрос руководства обещать «поисследовать и вернуться», но такая стратегия не будет работать вечно, да и, честно говоря, заставляет выглядеть директора некомпетентным и боящимся ответственности. Ещё более странно в ответ на подобные вопросы руководства начинать рассказывать про agile vs waterfall, итеративную разработку, MVP, быстрый цикл обратной связи и прочее. Классический ответ на такие рассуждения: «Бизнес так не работает. Мне нужно подписать контракт сегодня и на всю сумму. Я не могу оформить контракт на часть услуг или на MVP». Я не говорю, что техдир обязан всегда «брать под козырёк» и коммититься на нереальные сроки, я лишь хочу сказать, что человек должен быть готов к такого рода давлению, чтобы в нужный момент критически посмотреть на вызов/проблему/предложение и почелленджить его. К сожалению, навык этот вырабатывается со временем, а пока он не сформирован, новичок будет находиться в состоянии стресса.

Синдром самозванца, 80 lvl

Уже не раз было сказано, что становясь из разработчика тимлидом человек как бы меняет профессию, выходит из зоны комфорта. Так вот, в случае дальнейшего роста в СТО этот эффект усиливается в разы в силу нескольких причин:

• Невозможность использовать привычные паттерны решения задач. Опыт разработчика зачастую никак не поможет решать задачи уровня директора в силу разницы масштабов и разнородности задач. К примеру, вполне нормальная задача для СТО — открытие нового регионального офиса или выход на новый рынок.

• «Свой среди чужих, чужой среди своих». С одной стороны, становясь директором, человек окончательно теряет связь с командой разработки, из которой он «вырос»: не участвует в ежедневных церемониях и не в курсе проблем и настроений, отчего он чувствует себя «отчуждённым». С другой стороны, у него новый круг общения и peers, для которых он новичок и пока ещё не до конца свой.

• Из предыдущего пункта вытекает ещё один, не очень очевидный: неизбежная и так нелюбимая всеми технарями «политика», в которой новичок, конечно, будет «отгребать по щам» первое время. Сюда можно отнести конкуренцию за бюджеты/численность/проекты, перебрасывание ответственности, постоянно меняющиеся договорённости и правила игры — всё это, к сожалению, неизбежно в кресле директора.

• При этом всём, как бы тяжело ни было и какое бы давление на него не оказывалось, СТО обязан демонстрировать спокойствие, уверенность и лидерские качества.

Всё это, вкупе с трудностями, перечисленными выше, оказывает неимоверную нагрузку на новоиспечённого директора в первые месяцы его работы.

Расписание

Отдельно стоит упомянуть изменения в ежедневном расписании. Помимо уже упомянутой доступности 24/7 и шквала поручений стоит подготовиться к ранним встречам, длинным стратегическим сессиям, срочным инициативам, критическим инцидентам и выступлениям на Town Hall. Особенно остро вопрос со срочными задачами может встать в кризисные времена, которые мы переживаем сейчас. 

Привилегированный «завхоз»

Еще один неприятный факт состоит в том, что в должности технического директора иногда бывает много на первый взгляд «непрофильных» активностей:

• Бюджетирование. Как минимум, придётся планировать ФОТ подразделения и закупки оборудования (как серверного, так и используемого сотрудниками для разработки). Закупки — это отдельное приключение, если компания работает по 44-ФЗ или 223-ФЗ.

• Работа с HR-брендом и сообществом. Казалось бы, при чём здесь СТО? При том, что каждый СТО желает видеть хороший поток кандидатов на свои вакансии, а для этого необходимо популяризировать компанию в сообществе: выступать на конференциях, организовывать митапы, качать open source, улучшать процесс подбора; в общем, быть «на виду».

• Сбор всевозможных списков-экселей: от доли прошедших очередной опрос на вовлечённость до количества привитых от ковида в подразделении.

• Если вдруг новичка-техдира ещё угораздило стать CEO (или генеральным директором) по совместительству, то нора становится бесконечно глубокой. Мне в такой роли приходилось вести работу со всеми поставщиками — от снеков на кухне до офисной мебели, — отвечать за условия труда, бюджетировать и отвечать за PnL не только ИТ, но и всей компании, отвечать за своевременную выплату ЗП и бонусов, и бог ещё знает что.

Вместо заключения

Я попытался описать, с какими вызовами может столкнуться новичок в роли технического директора. Попадись такая статья на глаза нашему Пете перед его назначением, кто знает, возможно, он остался бы хорошим тимлидом. Надо сказать, описание получилось мрачноватым, но, конечно же, не всё так плохо. В работе технического директора есть много прекрасного: от компенсации до возможности положительно влиять на бизнес и, не побоюсь этого слова, мир. Главное, не бояться брать ответственность за свои решения, освоить джедайские техники, укреплять горизонтальные связи, побольше доверять людям и делегировать, и всё обязательно получится.