[Перевод] Исповедь CTO: путь развития технического директора в стартапе
О важности саморазвития основателей в быстрорастущих стартапах написано немало. Как правило, тексты подобной тематики посвящены роли CEO. Общие советы по лидерству могут быть полезны и для других ролей, но мне не удалось найти материалов, которые могли бы помочь основателям-технарям. После прочтения кучи форм S-1 стало ясно, что очень трудно найти CTO с нуля прошедших путь от MVP до IPO (при этом с основателями-CEO ситуация прямо противоположная). Мне этот факт показался интригующим — я решил копнуть глубже. Мне хотелось докопаться до сути и причин такого положения дел. Также меня это немного напрягает:, а что я если я не способен расти быстро? Мне стоит разобраться, пока не возникли реальные проблемы! Я хочу быть тем CTO, который сделает RevenueCat публичной компанией! (1)
Неужели основателям, не занимающим должность генерального директора, сложнее быстро развиваться? Может быть, дело в том, что у CEO обычно есть значительная поддержка? Как бы то ни было, всему есть свои причины. Возможно, я просто неправильно ставил вопрос. После разговоров со многими основателями-CTO стало ясно: стандартного определения технического директора не существует. Обязанности человека на этой должности могут полностью меняться в зависимости от компании и этапа ее развития. Вероятно, поначалу технический директор привносит заметный личный вклад, но вскоре все может поменяться. Опыт разных людей может значительно отличаться. К сожалению, у меня нет ответов для основателей, не являющихся CEO. Возможно, у меня нет ответов и для тех, кто стал CTO впервые. Как бы то ни было, я подумал, что будет полезно поразмышлять над тем, что я узнал, и как изменились мои обязанности за 3 года работы в RevenueCat.
Дилемма: CTO против VP of Engineering
Если говорить просто, то роль технического директора ближе к архитектуре и коду, в то время как VPE будет отвечать за процессы и управление. В качестве аналогии можно привести сравнение пути старшего/штатного инженера и инженерного менеджера.
На ранних порах вам понадобится CTO, который сможет собрать и организовать исполнителей, которые создадут MVP. На этом этапе основатель может быть очень полезен, поскольку необходимо определить видение продукта и культуру технических процессов. В идеале, технический директор должен разбираться в той проблеме, которую будет решать его стартап.
Что если продукт станет успешным? Что если продукт займет свою нишу на рынке? В таком случае вам нужно будет нанять больше инженеров, чтобы удовлетворять спросу со стороны потребителей. Это замечательная задача. Возможно вам повезет, и вы найдете финансирование, а может вы уже будете генерировать прибыль. Но чем больше ваш штат, тем выше требования к совершенству процессов. Неизбежно наступит тот момент, когда кому-то придется стать VP of Engineering. Наступление этого момента станет очевидным, как только существующие (или отсутствующие) процессы перестанут работать. В такой ситуации у вас есть несколько вариантов. Технический директор может взять роль VP of Engineering на себя, или в компанию можно нанять дополнительных сотрудников. Вероятно, это решение зависит от личных предпочтения и опыта в сфере управления. Для решения подобных задач нужен совершенно другой набор навыков, и может быть тяжело приобрести эти навыки в условиях, когда расти нужно очень быстро. Именно поэтому технический директор, как правило, нанимается со стороны.
Основатель может проявлять определенную гибкость. У него могут быть полномочия, которые позволят определить путь, по которому пойдет компания. Возможно, вы ненавидите управлять людьми, и хотите продолжать свои навыки и знания для того, чтобы напрямую работать с технологиями. А может быть, вам хочется улучшить свои управленческие навыки. Люди первого типа, как правило, более снисходительны к управленческим недостаткам основателей. Они присоединились к команде, потому что доверяли основателям, верили в их идеи и были уверены в том, что у них добрые намерения. Поначалу они могут предпочитать работать напрямую с вами, а не с человеком со стороны. В любом случае, в будущем в компании будет несколько уровней управления, так что если вы хотите идти по этому пути, и у вас нет опыта, то вам стоит учиться, и учиться быстро.
Брайан Хелмиг, соучредитель и технический директор Zapier говорит, что вам нужно найти то, что дает вам дофамин. Лично мне с компьютерами всегда было общаться проще, чем с людьми. Я не был уверен в выборе пути развития, но я предпочел заниматься тем, что связано с компьютерами. Я всегда любил работать с ними, и я могу сказать, что в роли инженера я более эффективен, чем в роли менеджера. После интеграции новой функции я чувствую себя более заряженным, чем после личной встречи.
Впрочем, как основатель, я получаю большие дозы дофамина в те моменты, когда у компании все хорошо. Когда покупатели рекомендуют наш продукт. Когда мы достигаем целей по доходам. Когда мы нанимаем инженеров лучше меня. Когда эти инженеры всем довольны и успешно решают амбициозные задачи. Когда код-ревью утомляет, но проходит в атмосфере сотрудничества, а не озлобленности.
Итак, в конечном итоге, я решил не просто следовать своим предпочтениям, а делать то, что более эффективно для компании на разных этапах ее развития. В конце концов, я умею решать задачи. Именно так я рассуждал о своей роли. Качества меня, как основателя, более важны чем моя должность технического директора. Если подходить с точки зрения долгосрочной перспективы, как крупный акционер, я должен делать все, что будет лучше для компании.
Как правило, перелом возникает в тот момент, когда у вас в команде от 8 до 12 инженеров. Впрочем, он может возникнуть и в другой момент, все зависит от продукта и окружающей среды. Мы, как полностью распределенная компания, столкнулись с несколькими переломными моментами, когда встраивали в рабочие процессы новые часовые пояса. В то время многим приходилось брать на себя обязанности CTO и VP of Engineering одновременно. Я пытался браться за работу, на которую другим не хватало ресурсов (я делал это временно и не очень хорошо). Это помогло мне найти болевые точки, наладить процессы и нанять тех, кто сможет брать эти задачи на себя.
Когда я узнал как другие учредители распоряжаются своим временем на разных рабочих этапах, мне удалось лучше сориентироваться в своей роли. С самого момента основания компании я веду дневник. На основе этих записей я расскажу о задачах, на которых был сфокусирован, и том, как развивалась моя роль.
2018: YC, MVP и первые сотрудники
Когда мы пришли в YCombinator, в компании были только Джейкоб и я. Джейкоб занимался SDK и фронтендом, а я работал над бэкендом. После YC мы наняли двух первых инженеров, которые взяли на себя обязанности Джейкоба и работали на полную ставку. Все мы жили в Сан-Франциско, и мы уже знали этих людей. У нас было простое (и почти полное) управление. Не было никаких накладных расходов, у нас были недельные спринты и мы продвигались очень быстро.
Эти дни были напряженными, но очень веселыми. Мы закладывали основы инженерной культуры и видели, как клиенты приходят один за другим. Большую часть времени я занимался разработкой первых версий функций, о которых говорили клиенты. Мы выполняли их запросы настолько быстро, насколько могли. Большинство запросов отрабатывались в этот же день.
Больше всего я тогда сомневался в том, что мы создаем продукт, который действительно нужен людям, и что он сможет развиваться и оправдает наш посевной раунд на 1.5 миллиона долларов.
Главные выводы: их слишком много, обобщить слишком сложно. Мы многое узнали, когда прошли через YCombinator. Наверное, стоит выделить общение с клиентами, умение создавать то, что делает их счастливыми и удовлетворение их потребностей. Именно это и очень быстрая поставка стали нашими основными ценностями.
2019: Идем в ногу с клиентами и развиваем технологии
Похоже, мы заняли свою нишу на рынке. К нам приходили клиенты, начали накапливаться заявки к поддержке, а производительность нашего API росла с каждым днем. К команде присоединился первый удаленный инженер из Тайваня. Поначалу разница в часовых поясах вызывала определенные трудности, нужно было адаптировать рабочие процессы. Впрочем, все обошлось. Мы хорошо справлялись с запросами клиентов и мониторингом.
Адаптация была простым и единоразовым процессом. Я проводил личные встречи (не очень часто, где-то раз в месяц), но заниматься управлением было довольно легко. Большинство разговоров все еще носили технический характер. Я все еще вносил свой вклад как рядовой исполнитель. Также я посетил несколько конференций.
В то время у меня были преимущественно технические заботы. В основном, я думал о масштабируемости наших систем. У всех наших инженеров был опыт работы с продуктом, и у нас были явные точки отказа. Я постоянно думал о том, чтобы ничего не сломалось. Масштабы постоянно выходили из моей зоны комфорта. Мы достойно справились с оптимизацией наиболее распространенных сценариев, миграцией инфраструктуры и избежали критических точек. Также мы погасили технический долг, накопившийся за прошлый год.
По сути, вплоть до четвертого квартала я был инженером по вызову. Я не хотел беспокоить других членов команды в нерабочее время и чувствовал, что как основатель технического отдела, я обязан обеспечить максимальную надежность. Я носил с собой ноутбук буквально везде. В конечном итоге мы обеспечили ротацию. Оглядываясь назад, я понимаю, что это стоило сделать раньше.
Главные выводы: не зацикливайтесь на масштабируемости, но не забывайте о мониторинге. Следите за потенциальными узкими местами и точками отказа. Эти проблемы вызывают стресс, но сталкиваться с ними не так уж и плохо. Как можно скорее наймите инженеров по вызову и обучите их, задокументируйте решения для известных инцидентов. Положитесь на свою команду. В техническом долге нет ничего плохого, если подходить к нему ответственно и пытаться найти тот продукт, который будет востребован на рынке.
2020: Делегирование и планирование будущей организации
В 2020 наша команда еще раз увеличилась вдвое. Мы наняли инженеров из Европы и Латинской Америки. К концу года у нас было по несколько сотрудников в каждой из команд (SDK, интерфейс, фронтенд, …). Нам удавалось работать над несколькими проектами и, наконец, мы взялись за более амбициозные задачи. Впрочем, нам нужно было улучшить координацию. На этом этапе нельзя было избежать работы над структурой управления.
В течение первого и второго кварталов я потратил большую часть времени на код-ревью, предоставление рекомендаций по архитектуре и немного писал код на стороне. Я по-прежнему оставался тем человеком, который разбирается в наших системах. К середине года стало очевидно, что я стал узким местом для выпуска новых функций. Также я проводил индивидуальные встречи, принимал участие в коллективных обсуждениях, и больше у меня не было времени писать код и внедрять его вовремя.
Я полностью перестал программировать. Вместо этого я поручил свои задачи другим инженерам и стал тратить больше времени на передачу знаний. Сначала казалось, что на это уходит много времени, но делегирование сдвинуло многие проекты с мертвой точки и дало многим инженерам сильное чувство сопричастности. Поначалу не писать код было очень странно. Мне казалось, что я не выполняю свою работу (или что я работаю непродуктивно). Это совершенно естественное чувство. Вскоре я понял, что освободился от программирования, и теперь могу видеть общую картину. Я смог задуматься о будущем инженерной структуры.
Что касается управления, я стал уделять больше времени разговорам о карьерном росте и начал работать с инженерами, чтобы они росли и развивались. Что касается продукта, нам не хватало ресурсов для того, чтобы правильно расставлять приоритеты, планировать и координировать спринты. Я сделал все возможное, чтобы раскрепостить людей и наладить общение.
Кроме того, мы прошли раунд финансирования A и начали проводить заседания совета директоров. Также у меня стало уходить много времени на рекрутинг.
Главные выводы: внедрять новые часовые пояса стало проще, когда они стали пересекаться. Снижение фактора автобуса очень важно для масштабирования команды инженеров. После того, как вы проверите рабочие процессы и они заработают, автоматизируйте их настолько, насколько это возможно. Если вы не видите леса за деревьями — бросайте программировать и делегируйте.
Будущее
В следующем году мы планируем удвоить нашу команду еще раз. Кажется, что переход от 20 к 40 сотрудникам более сложен, чем переход от 10 к 20. К концу 2021 года компания значительно изменится.
Думаю, я сконцентрируюсь на масштабируемости команды. Поймите меня правильно, конечно мы столкнемся с серьезными техническими проблемами, и у нас в планах много весьма амбициозных задач. За последние несколько лет мы много узнали о наших клиентах, проблемах и техническом стеке, который лежит в основе нашего решения. Работать с талантливыми инженерами, у которых есть навыки и энтузиазм для решения задач — большая часть для меня.
Я хочу и дальше нанимать лучших специалистов и поддерживать здоровую инженерную культуру. Это будет непросто. Мне придется тесно сотрудничать с руководителем отдела кадров, чтобы наладить и автоматизировать процессы, связанные с поиском, наймом, адаптацией и коммуникацией. Рефералы помогали ускорить развитие команды, но пора сосредоточиться на разнообразии в командах. Думаю, что у нас появятся возможности для найма джуниоров, я хотел бы помочь им полностью раскрыть свой потенциал.
Нам нужно будет улучшить наш инженерный менеджмент, чтобы сделать инженеров счастливыми и дать им больше возможностей. Кроме того, если мы хотим решать амбициозные задачи, нам нужно будет вложиться в процессы планирования. разработки и запуска продукта.
Я очень взволнован тем, что будет в следующем году. Конечно, в дополнение к существующим проблемам придут новые. Но иначе и не бывает. Проще не будет!
Надеюсь, этот текст был интересным и полезным. Я планирую возвращаться к этому посту и дополнять его новыми знаниями. Если вы впервые стали техническим директором, буду рад помочь, чем смогу. Не стесняйтесь писать мне в твиттер или на электронную почту.
Особая благодарность Алексу Плугару, Кэлвину Френч-Оуэну, Хави Сантане, Адаму Хоутону, Сэму Лауну, Саулу Диезу и Уиллу Ларсону за их советы и за то, что они нашли время поделиться своим опытом. И, конечно же, всей команде инженеров RevenueCat за то, что позволили мне поэкспериментировать с ними, за принятие моих недостатков и их откровенные отзывы.
(1) Со временем я узнал, что беспокойство и страх в основном вызваны синдромом самозванца, и что они безосновательны. Если компания вас перерастет, то это не обязательно плохо. На самом деле, это серьезная проблема! Основателю стоит с ней столкнуться. Сфокусируйтесь на найме тех людей, которые будут лучше вас, они помогут расти вам и сделают компанию лучше. Я все еще хочу помочь RevenueCat стать публичной компанией, и если это удастся, то мои обязанности и должность будут менее важны.
