Задачи CTO в Цельсе

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

Сегодня я хочу рассказать о том, чем занимаюсь я на позиции CTO в Цельсе. Задачи CTO в небольшой компании (около 50 человек) сильно отличаются от задач CTO в бигтехе. Не могу сказать, что какая-то позиция обязательно хуже или лучше - везде есть свои плюсы и минусы, плюс зависит от личных особенностей характера, целей и предпочтений.

Все задачи я разбил на три группы по их интересности и приятности для меня.

Самые интересные задачи

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

Создание и улучшение инженерной культуры в компании

Про инженерную культуру когда-то очень хорошо рассказал в своём докладе Дима Круглов. Термин достаточно широкий, и он включил в него пять компонентов:

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

Звучит круто, но достаточно размыто, что же по факту я делаю для развития инженерной культуры?

• Создание и написание инженерных стратегий - документов, описывающих существующую проблему и предлагающую определённое решение. Предположим, у нас плохо согласованы бизнес-цели и работа инженерного отдела или неудачно выстроена работа с инцидентами. Сначала эту проблему надо обнаружить - иногда это очень легко (например, если наступили какие-то неприятные бизнес-последствия из-за качества нашей работы), а иногда - сильно сложнее (особенно если сами сотрудники утверждают, что никакой проблемы нет). После диагностики нужно описать суть и предлагаемое решение проблемы - для этого я пишу сам или делаю ревью чьего-то документа, который потом шарится на обсуждение небольшой рабочей группе и в итоге публикуется на общее обсуждение. Подробнее о подобном процессе можно прочитать тут.
• “Чайка-менеджмент”. У этого выражения явная негативная коннотация, но иногда полезно позалетать в какие-нибудь треды с обсуждениями и посмотреть, насколько принятые на бумаге решения и ценности по факту отражаются и используются в работе команд. Если что-то не работает, это как минимум повод поговорить с командой (лучше не в агрессивном ключе, а в любопытствующем), а иногда и пересмотреть принятое решение. Заодно не выключаешься из операционного контекста. Главное - не нарушать работу команды и не принимать скоропалительных решений, особенно если ты не сильно погружен в контекст. Иногда достаточно понаблюдать и запомнить.

Продуктовая работа и согласование целей с бизнесом

Наши продукты состоят из двух основных частей - ИИ-ядро (если упрощать, то это “нейронки”) и их различные обвязки - интеграции с разными клиентами, веб-приложение, локальные развёртывания на оборудовании, разные форматы возвращения ответа и так далее. 

Работа над ИИ-частью сервисов со стороны может показаться достаточно прямолинейной - бери и улучшай метрики. По факту всё сильно сложнее - метрики можно увеличивать разные и разными способами. А ещё нужно постоянно балансировать между краткосрочными победами и долгосрочным рисёчем и следить за надёжностью и скоростью работы сервисов. Не будем забывать и о куче идей по расширению функциональности существующих сервисов, добавлению новых патологий и по старту новых проектов.

В такой ситуации проще простого слишком сильно распылиться и в итоге не сделать ничего. Задача менеджмента - сфокусировать усилия команд на выбранных ключевых направлениях. В этом процессе участвует много людей - ML-команды и их лиды, руководитель ML-отдела и я. Здесь моя задача - на основе фрагментарной и неполной информации помочь сформировать хорошую стратегию, которая в идеале приведёт нас к успеху. Для этого нужно владеть большим количеством контекста - текущее состояние проектов, планы всех команд, грядущие события, бизнес-планы, планы команды бэкенда, доступная инфраструктура для обучения, финансовое состояние компании, слухи, и это далеко не полный список. Фактическим результатом здесь является документ с описанием бизнес-фокусов на грядущий цикл работы (в нашем случае месяц). Раньше его писал я, сейчас делаю ревью документа, написанного руководителем отдела по итогам совместного обсуждения.

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

Кросс-опыление команд, унификация, обмен опытом

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

• есть специальный канал для общения ML и бэкенда/девопса
• есть мероприятия с техническими и продуктовыми докладами
• есть регулярные встречи тимлидов
• есть общие мероприятия на всю компанию раз в квартал.

Однако, множество интересных и важных решений и результатов всё равно остаётся внутри команд - пробуются новые архитектуры сеток, внедряются новые библиотеки, придумываются оптимизации и ускорения, меняются процессы. Одна из задач - разными способами следить за тем, что происходит , и способствовать распространению потенциально полезных для всех идей. Можно тегать людей из других команд, можно предложить рассказать о чём-то на ближайшем мероприятии (в том числе об отрицательных результатах) или вынести тему на обсуждение на тимлидское собрание. Ещё у команд много свободы в принятии решений, но по некоторым областям нам важна унификация и стандартизация, и за этим тоже надо следить и вовремя принимать меры по сдерживанию.

При этом идей и задач генерируется очень много, поэтому важно быть в контексте жизни разных команд, чтоб не предлагать и не рекламировать всё подряд - иначе быстро наступит насыщение и усталость от идей. Термин "кросс-опыление" мне почему-то не очень нравится, но, наверное, он достаточно точно описывает эту часть моих функций.

Принятие решений

Иногда стороны не могут договориться между собой или не знают правильного ответа (часто его и нет), иногда затягивают принятие сложных и неприятных решений. А иногда просто нужно вовремя принять какое-то важное решение, затрагивающее весь отдел или даже всю компанию. Можно сколько угодно советоваться, консультироваться, но есть ряд решений, которые всё равно придётся принимать тебе и брать за них ответственность. Вообще это довольно тяжелый для овладения скилл, подробнее можно почитать в конспекте книги The Engineering Executive's Primer(глава 8).

Помимо эмоциональной сложности (как же это так, вот так взять и самому принять решение и никто не подстрахует если что?), тут опять же важно быть в контексте и уметь при необходимости быстро погружаться глубже. Для этого важно и харды поддерживать на уровне, и обладать навыком фильтрации ненужной информации. А ещё желательно иметь замов и лидов, которые могут быстро и понятно погрузить в суть ситуации.

Консультации

Иногда люди обращаются ко мне за советом или ответом на конкретный вопрос:

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

Особенно приятно, когда реально удаётся помочь и подкинуть какую-то стоящую идею или навести человека на хорошее решение.

Развитие технического и общего бренда компании

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

Технические инновации, ML-эксперименты и распространение знаний

Конечно, команды сами постоянно предлагают и внедряют новые инструменты для облегчения и ускорения работы, тестируют новые ML-гипотезы и читают статьи. Но в рамках рабочего процесса не всегда есть возможность, время и желание изучать какие-то новинки или проводить аудит существующих практик и инструментов. Поэтому я стараюсь следить за свежачком - новые инструменты (например, для разметки), LLM-копайлоты, новые архитектуры нейронок, опенсорсные библиотеки, обновления версий. Ещё ищу слабые места в процессах разработки и эксплуатации, которые негативно влияют на нашу продуктивность или на качество итогового продукта. О чём-то достаточно просто написать в соответствующем канале - вдруг кто-то заинтересуется, что-то лучше попробовать самому и рассказать на мероприятии, а что-то нужно внедрять централизованно сверху.

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

Коммуникация с сотрудниками

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

Обычные задачи

Сюда относятся достаточно важные задачи, но у которых есть какой-то неприятный нюанс.

Общение с потенциальными и текущими клиентами по техническим вопросам

К этой категории относятся подобные задачи:

• Участие во встречах с новыми клиентами в качестве технического представителя компании
• Создание и проведение презентаций и написание документации для клиентов и пользователей - в том числе на английском
• Устная и письменная коммуникация с текущими клиентами по техническим вопросам

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

Сохранение коллектива

Сохранять коллектив - это одна из важнейших моих задач, но к средней категории я отнёс эту мисиию по причине её сложности. С одной стороны работать у нас клёво, и небольшая текучка это подтверждает. С другой стороны у нас весьма ограниченные финансовые ресурсы, особенно по сравнению с бигтехом, и постоянно приходится жонглировать бюджетом на повышения и придумывать какой-то вариант, который будет и честным, и позволит сохранить команду. Понятное дело, что на 100% все довольными не остаются почти никогда.

Найм

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

Срезание костов в облаке

После зарплат облачная инфра - наша самая большая статья расходов. Последние месяцы уделил этому особое внимание, особенно на фоне дефицита GPU - пробуем варианты с несколькими облаками, ужимаем ненужные ресурсы, дропаем лишние данные и ищем другие креативные способы подрезать ненужные расходы при сохранении удобства. От результата радость, безусловно, есть, но сам процесс не назову особо интересным.

Администрирование и помощь в тушении пожаров

У нас есть какое-то количество серверов, которые исторически администрирует не девопс, а я - сервер ClearML, сервер Mattermost, тестовый сервер с GPU, на котором гоняются Azure-пайплайны, офисный сервер для обучения с хранилкой данных, Home Assistant в офисе на Raspberry. Иногда на них что-то починить или обновить. Времени это много не занимает и вообще является довольно медитативным занятием, так что эти обязанности я с себя пока не снимаю.

Скучные или неприятные задачи

Административная работа

Одобрение отпусков, командировок, компенсации расходов, пожарная безопасность...

Регуляторика, ТЗ, ISO и другие бумаги

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

Копание в железе и решение офисных проблем

В питерском офисе стоит довольно много железа (компы сотрудников, сервера для обучения, роутер), а админа у нас нет - ни своего, ни на аутсорсе. Были попытки кого-то нанять, чтоб за всем этим следить, но как-то всё это заканчивалось не очень хорошо. Получается либо крайне невыгодно, либо вообще плохо. Вообще задач обычно не так много, но раз в год стабильно случается какой-нибудь трэш, из-за которого я сутки валяюсь в серверной. В последний раз порезался и окропил кровью RTX8000. Жертвоприношение было принято, всё работает. На самом деле пришлось софтверно подрезать лимиты через nvidia-smi -pl 150.

Увольнения

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

Итоги

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

• письменное фиксирование информации и задач, как рабочих, так и бытовых
• правила по поводу посещения тех или иных встреч
• время от времени брать менее важные, но приносящие удовольствие задачи - ML-эксперименты, подготовка выступлений
• умное делегирование - не сваливать всё, что неприятно, а учитывать сильные и слабые стороны, а также состояние - своё и тех, на кого делегируются обязанности
• обсуждение за пивком и кальяном перипетий бизнеса с коллегами по менеджерству - необязательно из IT-сферы
• конечно же, своевременный отдых и внутренняя эмоциональная гармония