Почему хороший CTO должен стать "бесполезным человеком"

От CTO, VP of Engineering или тимлида обычно ожидается, что он будет руководить командой разработчиков и отвечать за код. Но это слишком узкое понимание роли. Код не существует отдельно от продукта. Если забыть об этом, можно утонуть в рутине и погубить проект. Чтобы этого не случилось, необходимо разобраться с истинной ролью CTO.

Код — не главное

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

Самой компании нужно, чтобы продукт развивался, чтобы было больше пользователей и engagement-метрики росли. Когда есть рост и архитектура не справляется с нагрузкой, вот тогда есть смысл думать о переписывании части кода.

Следить за тем, чтобы продукт решал проблему пользователя и помогал компании достигать бизнес-целей — вот что требуется от CTO. Если лидер не выполняет эту роль, если он поддерживает позицию "наше дело — писать код" и противопоставляет программистов бизнес-девелоперам, компания будет развиваться медленнее, чем могла бы. Это в лучшем случае.

Что на самом деле делает CTO

CTO на определенном этапе перестает писать код. Главной задачей становится поиск и развитие специалистов. Есть известная фраза "engineering is easy, people are hard", она идеально описывает ситуацию, с которой сталкивается технический директор, когда начинает растить команду.

Задача СТО или тимлида — быть бесполезным человеком. Все процессы должны быть настроены, а сотрудники обучены так, чтобы команда работала автономно, без участия руководителя. Тогда можно сконцентрироваться на стратегических задачах и планировании. Скажем, можно вовремя заметить, что команде нужны новые специалисты.

Для этого СТО с ранних этапов должен растить в команде новых лидеров. Нужно забыть о четких инструкциях и позволить людям решать проблемы самостоятельно. Я обычно прошу провести рисерч и предложить решение. Важно при этом поддерживать, давать обратную связь: исправлять ошибки, хвалить за достижения. Это лучше делать тет-а-тет.

У меня было несколько сотрудников в Google, развитием которых я очень горжусь, сейчас есть такой человек в Mate academy. Со временем уровень доверия вырастает так, что вы можете поставить новому лидеру любую задачу — и забыть о ней. Он выполнит все на 100% или своевременно обратится за помощью. 

Взаимодействие между командами

Эффективно коммуницировать нужно не только со своей командой, но и с другими департаментами. К примеру, в Google строят атмосферу, при которой в принятии решений, касающихся продукта, участвуют все. По крайней мере, у каждого есть возможность высказаться. Это отличная практика, которую мы сейчас внедряем и в Mate academy.

Чтобы координировать кросс-командную работу, стоит ежедневно проводить короткие стендапы, где сотрудники рассказывают о выполненных задачах, делятся планами и сообщают о проблемах. Часто оказывается, что кто-то из коллег уже сталкивался с похожей проблемой, и решить вопрос можно за 15 минут.

Умение вовремя решать текущие проблемы — жизненно важно. Особенно сейчас, когда никто не работает по модели waterfall. Раньше архитектор рисовал прототип, дизайнер оформлял компоненты, инженеры их отдельно программировали. Затем пытались собрать все в кучу — и ничего не работало. При нынешней популярности Scrum и других Agile-методологий есть возможность вовремя заметить ошибку. И ваши конкуренты это делают. 

Планирование и контроль качества

Чтобы мотивировать людей высказываться, нужно делать процессы максимально прозрачными. Если мы определяем OKR (objectives and key results) на следующий месяц, квартал или год, участвовать в обсуждении должны все желающие. Запрашиваем предложения у команды, назначаем дедлайн, до которого можно внести идеи на рассмотрение. Затем обсуждаем и выбираем, какие реализовать, приоритезируем.

Для каждого процесса определяем оунера. Если нет оунера, процесс не движется, проверено. Ответственность может взять на себя кто угодно: инженер, дизайнер, продакт-менеджер. Логично, когда это тот же человек, который придумал идею.

Когда 20 человек высказывают идеи и 3-5 компания принимает, у всех появляется чувство ownership. Люди ощущают, что влияют на продукт. Не только авторы одобренных идей относятся к задачам намного ответственнее, но и вся команда. И на следующих встречах сотрудники смелее делятся предложениями.

Конечно, все, что делает команда, нужно измерять. Определять метрики, отслеживать их, анализировать показатели в динамике. Это тоже должен быть прозрачный процесс, о котором осведомлены сотрудники, решающие ежедневные задачи. Хороший лидер не станет оценивать команду по "засекреченным" критериям. Метрики необходимо обсуждать с коллегами. Тогда они и сами смогут контролировать эффективность своей работы, вовремя замечать ошибки и исправлять их.

Какие навыки стоит развивать CTO

Для технического директора, как и для любого лидера, важны развитые коммуникативные навыки. Нужно уметь четко доносить свою мысль, корректно давать фидбек и принимать обратную связь по поводу собственной работы.

В этом плане руководствуюсь двумя принципами. Первый — нужно оперировать данными. С данными спорить сложно. Второй принцип — отделять человека от его идей и действий. Бывает, что в процессе код-ревью программист идентифицирует себя со своим кодом. Критикуешь работу, а он принимает замечания на свой счет. Чтобы этого не случалось, CTO должен правильно доносить мысли, акцентируя внимание на работе, а не на личности.

Для развития коммуникационных навыков советую книгу "Getting More" Стюарта Даймонда, а для развития продуктового мышления — работы Дэна Ариэли ("Predictably Irrational: The Hidden Forces That Shape Our Decisions", "The Upside of Irrationality: The Unexpected Benefits of Defying Logic at Work and at Home", "The Honest Truth about Dishonesty. How We Lie to Everyone — Especially Ourselves"). Еще можно опираться на опыт коллег: 19 мая в рамках Kyiv CTO Meetup #4 мы будем обсуждать роль CTO в продакт-менеджменте.

Опыт показывает, что спускать инструкции сверху и требовать бездумного исполнения — плохая стратегия. Когда CTO начинает строить полноценную двустороннюю коммуникацию с собственной командой и с другими департаментами, от этого выигрывают все.