«Если не научиться тайм-менеджменту, жизнь превратится в ад»: как стать хорошим СТО и не сойти с ума от стресса

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

Что значит быть хорошим СТО, рассказал технический директор и сооснователь и RetargetApp Владимир Воробей в продолжении интервью.

СТО без технического бэкграунда неэффективны

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

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

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

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

Надо понимать технологии, что будет дешевле в конкретной ситуации

Технический бэкграунд нужен, например, когда принимаются какие-то стратегические высокоуровневые решения, завязанные на технических возможностях. Например, сейчас мы используем Amazon Web Services (АWS) — это множество сервисов под разные задачи. Нужно ли использовать какой-то из них для наших новых задач и сколько это будет стоить? Если сервис не подходит, какую техническую альтернативу можно использовать? Надо понимать технологии и что будет дешевле в конкретной ситуации, взвесить все за и против с учетом перспектив роста и других факторов.

Наша специфика — это интеграция с рекламными площадками Facebook, Google, Instagram. Такие интеграции имеют сложную техническую составляющую, СТО нужно понимать их технические возможности. Потому что от того, с какими рекламными площадками мы интегрируемся, зависит рост и развитие бизнеса.

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

Все, чем я занимаюсь, это менеджмент

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

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

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

Если не можешь делегировать — ты не очень хороший менеджер

Сложным шагом было отдать то, что делал своими руками — кодовую базу, например, — другим людям, доверить им это. Я очень понимаю людей, которые занимаются микроменеджментом, но делегирование — это о доверии. Если ты не можешь делегировать, наверняка ты не очень хороший менеджер. Потому что не доверяешь человеку, которого ты поставил на эту позицию, не веришь, что он сможет без тебя все сделать. Тогда возникает вопрос: поставил ли ты того человека?

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

На ключевые позиции я нанимаю людей сильнее меня

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

У меня очень простая тактика: на ключевые позиции я нанимаю людей сильнее меня. Объяснение простое: переход в менеджмент занимает очень много ресурсов и времени, а технологии постоянно меняются. Конечно, я держу руку на пульсе — отслеживаю, какие технологии с какими проблемами могут помочь. Но глубокое понимание деталей важно. Поэтому на все позиции, которые сейчас есть — сеньор-инженера, девопса, фронтенд-инженера, техлида — я брал людей, которые сильнее меня по технической части.

Если не научиться тайм-менеджменту, жизнь превратится в ад

Технических задач на мне не осталось, но работы от этого не становится меньше. Как говорится, если вы основываете свой проект, у вас будет возможность работать в любое время суток, хоть 24/7. Со мной примерно такая ситуация. Менеджерской работы не становится меньше, она другая по своей сути.

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

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

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

Читайте также: Менеджер != несостоявшийся программист: почему разработчики переходят в управление и чем там занимаются

Я бы не смог быть снова просто инженером

Я бы не смог быть снова просто инженером, даже если бы меня гипотетически переместили на позицию, где я должен только писать код. Я бы все равно задавал вопросы: как этот продукт будет использоваться, как мы этот код доставим, какую проблему он решает и эффективно ли мы это делаем.

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

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

В разных компаниях обязанности СТО могут отличаться кардинально

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

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

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

Читайте также: «Любой разработчик должен стать менеджером»: что будет, если вы не пойдете на повышение?