Привет, Хабр! Меня зовут Игорь Десятников, я Chief Technical Officer в компании Neuro.net. Несколько раз встречал на Хабре статьи с попыткой рассказать о роли СТО, об эволюции этой должности при расширении компании и т.п. С некоторыми вещами согласен, с другими — нет.
Сегодня расскажу о своем видении позиции СТО. Если получится — было бы отлично поднять в комментариях дискуссию. Если вы с чем-то не согласны, просто хотите дополнить или поделиться собственным опытом — давайте обсудим.
Кто такой CTO?
Есть разное понимание позиции CTO, причем вполне закономерно, что в каждой компании это может быть совершенно своя история. Приведу несколько примеров.
В одной компании хотят, чтобы кандидат на этой позиции был, по сути, тимлидом команды: писал код, проектировал решения и архитектуру, проводил ревью кода и выполнял прочие обязанности руководителя команды. Выстраивать процессы нужно лишь в рамках своей небольшой выделенной команды и все, что от тебя ожидается – это работающий продукт. Чаще всего такая роль СТО отводится в компании, которая находится на стадии стартапа и создания MVP продукта. По факту, им нужно быстро стартовать, запустить минимальный продукт и проверить его жизнеспособность.
В другой компании хотят, чтобы CTO занимался процессами разработки, инфраструктурой, управлением технарями. Это некий руководитель разработки. В западных компаниях есть еще такая должность VP of Engineering. Мне наиболее близка эта роль, хотя по своим обязанностям сейчас приходится делать еще много всего сверху.
В третьей компании могут хотеть, чтобы CTO занимался пресейлом, продвижением компании и маркетингом.
И каждая компания по-своему права, спорить здесь смысла нет. Считаю, что уже хорошо, когда основатели и акционеры в принципе понимают, что должен делать СТО в компании. Понимание задачи – первая стадия успешного ее решения.
На мой взгляд, у СТО есть “программа — минимум”: человек на этой должности должен понимать, какие основные возможности и риски есть у бизнеса, концентрироваться на них и фокусироваться на вопросе роста бизнеса.
Если подытожить, то в моем понимании СТО отвечает за стратегию технологического развития компании и руководит всем техническим блоком. Менеджерские навыки в этом смысле важнее технических. CTO это не тот, кто знает все, а человек, окруживший себя специалистами, которые знают все, что необходимо для развития компании, а он этим всем может управлять.
Как стать CTO?
Здесь я коротко расскажу свой путь роста, понятно, что у других коллег он может быть совершенно иным.
Начало пути
Мой путь к CTO пролегал через разработку и менеджмент. Я начал свою карьеру на позиции инженера по тестированию, потом перешел в разработчики и, в конечном итоге, вырос в тимлида команды разработки. В какой-то момент осознал, что хочу расти в менеджмент и управление, поэтому перешел на позицию Engineering manager. Далее несколько лет руководил большим отделом разработки на Highload-проектах. Лично я считаю, что CTO должен знать все технические процессы изнутри, знать боли и потенциальные узкие места. Именно такой путь, от тестирования до разработки и руководства департаментом, прошел я, но еще раз подчеркиваю, что он может быть совершенно другим.
Меня время от времени спрашивают: “Как вообще вырасти до руководителя отдела разработки или до тимлида”. Конечно, я помогаю разобраться, но часто это уже совсем не лидерская история. Чаще всего те, кто задают подобные вопросы, растут в управлении хуже, чем, так сказать, прирожденные лидеры. На мой взгляд для того, чтобы достичь всего перечисленного, лидером уже нужно быть, это, своего рода, личностные характеристики, soft skills, если хотите. Этому очень сложно научить, ты либо знаешь и можешь, либо нет.
Работа в Neuro.net и круг задач, которые нужно было решить
Когда я пришел в компанию, это случилось в конце 2019 года, команда была небольшой — всего 10 человек. Neuro.net была самым настоящим стартапом в самом начале пути: без процессов и четкой организации, но зато с планами по захвату мира. К счастью, последнее понемногу реализуем. Так, за очень непростой для всех 2020 год мы сумели вырасти сразу в 10 раз, так что сейчас под моим руководством около 110 человек. При этом мы продолжаем агрессивно расти. Мир, конечно, мы
Теперь о круге задач. В самом начале передо мной ставились цели по найму людей и выстраиванию бизнес-процессов. Понятно, что с быстрым ростом компании приходится процессы менять буквально на лету, где-то напильником (или даже рашпилем) их подшлифовывать, где-то вводить что-то новое. Все это заставляет тебя быть устойчивым к стрессу и уметь быстро переключаться с одного контекста на другой. Работы было и остается много, даже слишком.
Возможно, читателям будет интересно услышать про нюансы собеседования на позицию СТО. Так вот, вопросы могут быть совершенно разные, включая блок про найм команды, выстраивание бизнес-процессов, решение сложных конфликтных кейсов, методологии разработки и т.п. В остальном, часто это довольно объемное техническое собеседование: базы данных, сети, архитектура и прочее.
Самый адекватный вопрос, который я встречал на интервью: «У нас есть такая-то задача по разработке продукта и построению команды, как бы ты помог в ее решении?»
Нюансы работы СТО
Обязанность руководителя, в первую очередь, — выстроить работающий механизм. Если требуется частое погружение в детали, делать что-то вместо специалистов, которые не справились или плохо выполнили задачу – у тебя проблемы с управлением или, возможно, работу выполняют не те люди.
Настоящий признак эффективного руководителя – ему практически ничего не приходится делать самому. Необходимость вовлекаться в детали должна стать для руководителя плохим сигналом. Есть классная цитата, не помню, где я ее слышал, возможно она с Хабра: «Если ваш CTO не знает, как писать код — у меня для вас плохие новости. Если CTO у вас пишет код — новости еще хуже.»
Личный опыт в Neuro.net
Обычно мы проводим еженедельные митинги с каждой командой разработки, начиная с эксплуатации и заканчивая разработкой и тестированием. Там, где процессы не идеальны или много новых людей, встречаемся чаще: 2 или 3 раза в неделю. На этих собраниях традиционно обсуждаем что сделали, что планируем сделать, какие есть проблемы. Такая структура встреч позволяет всегда оставаться up-to-date, понимать, что происходит в команде и при необходимости давать кому-то обратную связь.
Есть периодические встречи, когда сотрудники могут задать любой вопрос, спросить про их боли, попросить помощи. Конечно, практикуются и индивидуальные встречи. Стараемся проводить их как можно чаще, т.к. на удаленке люди быстрее теряют связь с командой и компанией.
Иногда приходится собирать рабочие группы по каким-то проектам в разработке, которые требуют оперативности или ломают наш стандартный процесс разработки. Также у меня настроены дашборды и уведомления в JIRA, которые позволяют не выпадать из рабочего процесса.
Что касается проблем, то самая большая головная боль — где найти разработчиков, какой выделить под них бюджет и где его взять. Вообще история с деньгами очень тесно связана с жизнью СТО. Учитывая не всегда адекватный рынок IT, эта задача сильно усложняет повседневную жизнь.
Рабочее и личное время
Считаю важным осветить этот вопрос, поскольку он затрагивается не так и часто. Что касается меня, то все сложно. Это не та история, когда ты в 17.00 уходишь с работы и полностью переключаешься на свои личные дела, это просто невозможно сделать. Нет такого состояния, когда у тебя нет проблем или нет зон для улучшений, ты постоянно над чем-то размышляешь.
Периодически случаются срочные звонки, какие-то проблемы и прочее. Все это нужно решать и принимать решения очень быстро. Учитывая сумасшедший рост нашей компании, решения нужно принимать молниеносно и таких решений даже за один день может быть много. Думаю, что среди топ-менеджеров очень немного тех, кто способен «обнулиться» сразу же после выхода из офиса. Почему? Да просто потому, что в большинстве случаев это просто невозможно.
Советы руководителям
Периодически сталкиваюсь с историями, когда в компанию приходит новый руководитель. У него горят глаза, он практически сразу хочет все переделать на свой лад. Это типичная ошибка — ни в коем случае не стоит, не разобравшись в том, что есть, ломать существующую структуру и процессы, строя на развалинах что-то свое. Не факт, что новое будет лучше, чем было старое. Ситуация ухудшается тем, что на перестройку и все эти революции компания тратит дофига времени, теряя по пути ценных сотрудников, которые не смогли или не захотели смириться с переменами.
Так что первый совет от меня: сначала внимательно изучите, как всё устроено. Меняйте только то, в чем объективно назрели скорейшие перемены, и обязательно объясняйте коллективу, почему и зачем вы это меняете. Поддерживайте и развивайте дальше то, что и так дает хорошие результаты. Не ломайте то, что работает хорошо, вы вызовете большой негатив у команды. Подробно можно почитать здесь.
Второй совет, который хочу дать и который актуален для меня вот прямо сейчас: оберегайте команду технарей от бизнеса и их хотелок, станьте буфером между техническим отделом и продавцами. Иначе вы просто превратитесь в инструмент для реализации желаний других отделов, никакого стратегического развития не будет.
Ну и совет номер три: регулярно «сверяйте часы» с каждым сотрудником, который важен для вас и компании. Разговаривайте с вашими ключевыми сотрудниками и обсуждайте с ними все, что их беспокоит. Возможно, вы и понятия не имеете об этих проблемах или человек, которого они волнуют, неправильно понимает ситуацию. В любом случае, важно открыто их обсудить.
Читайте профильную литературу. Меня в свое время очень впечатлила книга Рэя Далио «Принципы», до сих пор считаю ее лучшей бизнес-литературой по управлению, несколько раз перечитывал. Книги попроще можно найти по ссылке.
