Оригинал опубликован 12 января, 2022
Calvin French-Owen является соучредителем и техническим директором Segment и занимается в основном созданием инфраструктуры бэкенда Segment и конвейера обработки данных.
Содержание
Много лет назад мой друг Грег написал о том, как он прошел путь от одного из первых сотрудников Stripe до ее технического директора.
Этот пост вызвал у меня большой интерес. Это был первый честный взгляд, который я увидел, показывающий "внутренности" роли CTO.
Вы начинаете с того, что пишете кучу кода и знаете, как работают все системы. Вы находитесь на связи 24 часа в сутки 7 дней в неделю. Вы - главный помощник при возникновении серьезных производственных проблем. Со временем вы начинаете отдавать свои детальки "лего" товарищам по команде.
И когда команда растет, возникает большой экзистенциальный вопрос: Что вообще должен делать технический директор?
Большинство корпоративных ролей относительно четко определены. Генеральный директор собирает средства и нанимает команду руководителей. Финансовый директор управляет денежным балансом компании и формирует бюджеты. COO обеспечивает эффективную работу процессов в компании. CRO отвечает за количество продаж...
Но роль технического директора более туманна. На ранних этапах CTO более или менее эквивалентен "самому техническому сооснователю" (во всяком случае, мы так определили это название). Но по мере роста организации роль должна меняться.
Я разговаривал с кучей основателей ранних стадий о роли "технического директора". Большинство из них, похоже, столкнулись с той же дилеммой, что и я, когда мы наняли вице-президента по инженерным вопросам: они не знают, что делать!
Вот схема, которую я хотел бы иметь во время моего путешествия.
Архетипы CTO
Хотя для технического директора не существует определенной роли, есть несколько различных архетипов, в которые он может входить. Это наиболее распространенные "фигуры", которые необходимо заполнить по мере роста компании.
Для каждой из них я привел несколько примеров разных руководителей, чтобы вы могли понять, как они выглядят. Если вы хотите стать лучше, начните читать их блог/твиттер.
Народный лидер
Некоторых технических директоров можно назвать вице-президентами по инженерным вопросам. Они отвечают за развитие инженерной организации и следят за тем, чтобы она работала эффективно.
Вероятно, они отвечают за такие вещи, как подбор персонала, лестница инженеров и распределение штата. У них есть глубокое понимание того, как выглядит эффективно функционирующая организация.
Я с ним не знаком, но могу сказать, что Уилл Ларсон из Calm относится к этому лагерю. Он фантастический менеджер по работе с людьми и буквально написал книгу о подборе персонала и руководстве командами инженеров. Если вы прочтете несколько его постов в блоге, то заметите, что он - эксперт в системном подходе к построению организации.
В Segment Тидо Карриеро очень успешно справился с этой ролью. Он начинал как наш вице-президент, а затем выстроил эти процессы в продуктах и дизайне. Он разработал план рекрутинга и выравнивания персонала в масштабах всей компании (помимо многих других вещей, Тидо дико хорош).
Архитектор
Некоторые технические директора любят размышлять о том, что может сделать следующая версия системы.
Они являются экспертами в области технологий и проводят много времени, размышляя о технических решениях, которые могут открыть большие возможности для повышения эффективности инженерных решений.
В компании Segment роль архитектора выполняли Рик Брэнсон, Альберт Страсхейм, Ахилл Руссель и Даниэль Сен-Жюль (хотя многие другие тоже внесли свой вклад). Они создали многие строительные блоки, которые позволили нам масштабировать наш конвейер на каждый следующий шаг: Dedupe, Centrifuge, разделение между Ctlplane и Dataplane, а также наши новые API. Я обнаружил, что эти люди (особенно Альберт) также хорошо разбираются в оценке поставщиков и ведении переговоров.
Честно говоря, я хотел бы, чтобы мы больше формализовали эту роль, просто потому, что она может иметь огромное влияние. Всякий раз, когда у нас появлялся строительный блок, достойный нашего сервиса, он неизбежно служил нам долгие годы.
Я бы сказал, что Армон и Митчелл из Hashicorp попадают в этот лагерь. Джефф Дин официально не носит титул CTO, но мне кажется, что он также играет подобную роль.
R&D-инженер (инженер-исследователь)
Некоторым техническим директорам нравится подталкивать компанию к созданию следующего большого продукта.
Трудно найти людей, у которых есть желание месяцами толкать компанию в новом направлении без особого прогресса.
Тем не менее, такие сотрудники необходимы. Компании нужны такие люди, если она хочет изобрести себя заново.
В Segment я бы сказал, что именно эту роль чаще всего выполняли я и мой сооснователь Илья (а также ранние PM Кевин, Алекс и Сперандио). Эти исследования и разработки привели к запуску нескольких крупных направлений, таких как Cloud Sources, Functions и нашего Dev Center.
Я работал со многими бывшими сотрудниками Cloudflare, и все они упоминают, что Джон Грэм-Камминг тоже относится к этому лагерю.
В Cloudflare есть небольшой набор инженерных команд, которые живут вне основной команды. Они создают новые интересные прототипы продуктов до уровня MVP, а затем смотрят, не заинтересуется ли какое-то подразделение, чтобы подхватить и перенять их. По-видимому, именно таким образом был создан Cloudflare Workers, а также другие продукты.
Маркетинг / Работа с клиентами
Последний архетип технического директора сосредоточен на маркетинге и взаимодействии с клиентами.
Если вы занимаетесь маркетингом для разработчиков, ваши клиенты захотят услышать мнение человека, который одновременно является высокопоставленным и очень техничным. Такие технические директора часто участвуют в конференциях, встречаются с крупными клиентами, пишут посты в блогах и занимаются другими формами идейного лидерства.
Вернер Фогельс из AWS, вероятно, является лучшим примером технического директора, занимающегося маркетингом и работой с клиентами. Несомненно, есть и другие подобные ему.
Когда я не занимался R&D, то чаще всего вступал в эту роль.
Статус основателя помог мне получить исторический и глобальный контекст для Segment. Многолетняя практика написания технических статей помогла мне писать для нашего блога так, чтобы это было аутентично и находило отклик у наших пользователей и потенциальных сотрудников.
Секретная суперспособность этих технических директоров заключается в том, что они получают огромное количество отзывов от клиентов. Одна из самых ценных вещей, которые вы можете сделать в этой роли, - это синтезировать их и убедиться, что эти отзывы доходят до продуктовых команд.
Что скрывается за именем
Несколько слов о должности технического директора...
Большинство основателей, с которыми я общаюсь, зацикливаются на титуле CTO и не задумываются о том, почему он вообще должен существовать.
Безусловно, существуют веские причины для присвоения звания технического директора. На мой взгляд, есть три причины, по которым компании могут это сделать.
Участие в публичных мероприятиях - выступать на конференциях или в дискуссиях с "большим" титулом может быть гораздо проще. Если вы часто выступаете с такими докладами, титул CTO может оказаться полезным.
Упрощение процесса найма - кандидаты всегда охотнее общаются с людьми, которых воспринимают как лидеров. Если вы кандидат, у вас не так много информации о том, как все устроено в компании, поэтому титул - это косвенное подтверждение.
Авторитет инженера - дополнительные полномочия, которые дает титул, могут помочь компаниям внести изменения, которые они могли бы не сделать в противном случае. На мой взгляд, этот пункт немного глуп, поскольку большинство технических директоров перестают писать код. Тем не менее, я слышал о некоторых технических директорах, принуждающих к соблюдению инженерных норм своим указом.
Как бы то ни было, старайтесь меньше беспокоиться о титуле как о собственности и больше думать о титуле как об инструменте. Это инструмент, который должен служить вам, а не наоборот!
На своем пути я неоднократно обсуждал с Тидо возможность отказа от должности технического директора. К концу моей работы в Segment в организации появились другие люди, которые, как мне кажется, могли бы извлечь из этого больше пользы.
Мой собственный путь
Чтобы сделать это более конкретным, я могу рассказать вам о своем пути после присоединения Тидо. Это небольшая мешанина, поэтому я классифицирую проекты по их общим признакам.
Бренд (блоггинг): нам нужно было очень быстро нанять отличных инженеров, и у нас были проблемы с их привлечением. Я начал публиковать контент для создания Segment как "бренда мирового класса", который также использовался в качестве внутренней документации. Позже Рик подхватил это и начал нашу популярную серию бесед "Segfault".
Переработка домена склады: у нас был крупный проект по переработке конвейера складов. Я помогал команде ограничить масштаб и определить некоторые цели (не кодинг). Большая часть тяжелой работы пришлась на команду, занимающуюся складами.
Переработка домена центрифуга: похожая история, у нас была большая переработка в процессе работы. Я работал с небольшой командой, чтобы довести его до ума и распределить работу между большим количеством членов команды (опять же, инженеры в команде сделали большую часть работы).
Разработка новой функции (доставка событий): еще в начале работы над Segment у нас была проблема, связанная с тем, что мы не могли сообщить людям, что происходит с их вызовами API. Я работал с командой, помогая уточнить требования и дать обратную связь по архитектуре + набору функций для решения проблемы клиента.
управление инженерами: Я занимался управлением и руководством несколькими небольшими командами, в основном тратя время на постановку целей, анализ показателей, найм сотрудников, карьерный рост и сужение требований.
R&D новых возможностей (центр разработчиков): продвигал 0 > 1 версию нашего центра разработчиков. Это было немного халтурно, но помогло доказать, что мы хотим стать платформой, и сняло ряд возражений по продажам.
Разработка новых функций (функции): на основе работы, проделанной нами по созданию центра разработчиков, мы продвигали новый продукт (функции), который должен был разблокировать пользовательские сценарии использования и профессиональные услуги.
кросс-функциональная работа (digital): Мы с Ильей объединились с очень интересной кросс-функциональной командой, чтобы построить мост между продажами, маркетингом и EPDS. Особенно полезно было иметь основателей, которые могли бы работать в разных подразделениях компании.
Среди всего этого было приличное количество публичных презентаций, записей в блогах, анализов данных, звонков по продажам и разговоров с клиентами.
Если все это кажется немного случайным, то так оно и есть. Это сродни роли Рида Хоффмана в качестве "главного пожарного в Paypal". Я видел много основателей, которые постоянно хватаются за важные (но, возможно, неинтересные) проблемы компании и бегут к огню.
Решите, где вы хотите быть
Если вы еще не поняли, создание стартапа требует множества различных навыков! И должность технического директора может дать вам большую свободу действий, чтобы использовать свои сильные стороны.
Но вот мой совет: думайте о себе в первую очередь как об основателе, а во вторую - как о техническом директоре. Оставайтесь скромным и не позволяйте титулу технического директора мешать вам делать то, что лучше для компании.
Есть одна общая черта у большинства успешных основателей: они, как правило, умеют приобретать новые навыки в процессе работы. Лучшие основатели, которых я знаю, не бегут от этой постоянной "серии мини-игр", а принимают ее. Поэтому, если есть возможность, вникайте в каждую новую проблему, с которой сталкивается компания.
Помните, что вы всегда можете нанять кого-то, кто будет соответствовать любому из этих архетипов. Но вы не можете нанять больше основателей.
Другие переводы автора
Раз вы дочитали до конца, буду рад видеть вас в своём тг канале. Сейчас активно пишу выжимки по эссе Пола Грэма. Ежедневно по 1-2. Записи по этой теме находятся по тегу #пг. Силой никого не тяну :)