Есть сухое и емкое определение – технический директор, которое не отвечает на главный вопрос, какими компетенциями должен обладать данная роль. На мой взгляд, это не более чем «кривое отражение» западных подходов к производственным процессам. На деле оказывается, что CTO обычно называют руководителей департаментов/управлений/отделов , где сосредоточены компетенции по разработке инженерных решений (software и/или hardware). Отсюда возникает один из важных вопросов, должен ли CTO обладать техническим бэкграундом и понимать процессы в компании или достаточно быть хорошим управленцем? На этот вопрос у меня есть два противоречивых ответа из личного опыта. Кейс первый: Предыстория. В компании сменился руководитель управления и пришел новый руководитель, который уверено назвал себя CTO. Первое, что сделал руководитель, призвал забрать support в центр компетенций разработки и развития систем. Причем инициировал процесс «снизу», поручив это руководителям отделов, а не поднял вопрос на уровне дирекции (что было обречено изначально, но кого это волнует). Почему так делать нельзя, очевидно: цели разные, если разработке важно быстро сделать, то support-у важно не сломать что есть и предотвратить вал инцидентов. Да, есть примеры, где все сосредоточено «в одних руках», но обычно это небольшие команды, с ограниченными бюджетами, где цена последствий выкатки кривого релиза не высока. В больших компаниях данный конфликт интересов разрешается разделением ответственности на разных руководителях и это правильно. Второе, что инициировал руководитель, забрать себе компетенции по discovery и опять, поручение пошло «снизу», а не на уровне коммуникаций с контрагентами/заказчиками. Да, такие конфигурации команд встречаются довольно часто (стримы, где сосредоточено, discovery, delivery), но они зависят от процессов, заложенных «сверху», зрелости и компетенций «бизнеса». Третье, что инициировал руководитель, построить систему оценки эффективности сотрудников. Без каких-либо вводных: вот задача, решайте. Что из этого вышло: Первый вопрос закрылся через 3 месяца, когда руководитель осознал, что support ему никто не отдаст. Потому что не читал согласованных регламентов и не знал, что технически подразделения развития не имеют доступ на в промышленный контур, в отличии от support. И инфобез никогда таких доступов не согласует, на что есть очевидные причины. Второй вопрос закрылся через 3 месяца, когда руководители отделов запросили бюджеты на бизнес аналитиков у бизнеса и были ожидаемо посланы. Почему не сделано было сразу, руководитель замкнул общение с контрагентами на себе и не допускал подчиненных к коммуникациям с заказчиком (не делился информацией, не звал на встречи). Третий вопрос был сильно сложнее. Руководитель просто «проксировал» требование вышестоящего руководства, не организовав процесс. При этом не допускал подчинённых к обсуждению рабочих вопросов (это нормально, иначе на встрече дирекции соберется over 50 человек). Выяснилось, однако, совершенно случайно, что есть рабочая группа с компетенциями под данному вопросу, у которой есть требования к процессу, методологии оценки, инструменты автоматизации и готовой работать с командами. На это все ушло несколько месяцев.

А теперь переведем это все в цифры: Порядка трех месяцев проходили бессмысленные встречи в управлении. Два раза в неделю по два часа, на которых собиралось порядка 10 сотрудников, не говоря уже о one-on-one. Если перевести все в деньги, то было потрачено порядка 2 млн. рублей. Это цена, которая заплатила компания, чтобы CTO осознал, как устроены некоторые процессы и смог поставить задачу подчиненным. И это только 3 кейса, а процессов и проектов в большой компании сильно больше.

По первому кейсу ответ очевидный: CTO должен понимать, как устроены процессы, как ставить задачи, а если нет понимания, то платить компания за это не должна. Про второй кейс расскажу в следующий раз.