По мере роста стартапа, рабочие процессы в нем должны меняться. Я понял, что для инженеров это особенно важно. Моя роль, как соучредителя и CTO значительно изменилась за последние годы. Изменились мои повседневные обязанности и задачи, и мне пришлось несколько раз менять свой подход к работе, чтобы помочь компании выйти на новый уровень.
В первые дни компании команда состояла из трех парней работавших по ночам и выходным, пиля в подвале то, что позже стало Zapier. Перед запуском мы сделали три или четыре версии продукта. С тех пор прошло шесть лет, сейчас мы обрабатываем сотни миллионов запросов к нашему API, а в нашей команде трудятся 80 специалистов со всего света (включая более двух десятков инженеров).
Рост от тех дней, когда нас было трое, до нынешних времен был весьма непростым. Если хотите, можете почитать выводы, которые я сделал за это время. В противном случае, предлагаю вам ознакомиться с уроками, которые встречались на моем пути, когда я рос как CTO-новичок.
Дерево развития технического менеджмента в стартапе
Пока мы не ушли слишком далеко, давайте разберемся – кто, черт возьми, вообще такой CTO? Именно этот вопрос я задавал себе, когда мы нанимали в команду первую пару инженеров. CTO – доброжелательный вечный диктатор, который в мире ПО занимается тем, что следит за кодом? Или это какой-то супер-менеджер или супер-хакер?
Я спрашивал совета у многих людей. Я обратился к техническим директорам из Buffer, Unbounce и других стартапов, которые были немного крупнее нас. И я получил ответ: на самом деле никто не знает. Это нечеткая роль, которую не удастся загнать в какие-то рамки. В процессе общения я обнаружил ряд общих закономерностей роста небольших технологически ориентированных стартапа и сформулировал то, что технический директор должен делать на каждом из этапов развития.
Поскольку я нерд и люблю играть в видеоигры, мне наиболее наглядным кажется дерево развития. По мере того, как вы набираетесь опыта в игре, вы повышаете свой уровень и в определенные моменты вы можете выбирать разные ветки развития.
Вот как может выглядеть дерево развития СTO в стартапе.
Хакер-одиночка (1-2 инженера)
Это как раз то самое время, когда мы работали в подвале. Это было веселое и скоротечное время. Вы много чего делаете, нет почти никаких накладных расходов на коммуникацию и общение, потому что все работают синхронно. Вы просто пытаетесь понять что сработает, а что – нет.
Небольшая команда кодеров (2-6 инженеров)
Как основатель стартапа, вы хотите развивать команду, поэтому начинаете нанимать людей. Обычно все начинают с найма друзей. Некоторые говорят, что не стоит нанимать друзей, но я считаю, что на этом раннем этапе это здорово. Вы знаете, что можете работать с ними, вы знаете, насколько они умны, и они просто отлично подходят. Этап появление небольшой команды — это то самое время, когда технический директор начинает чувствовать боль перехода от хакерства к чему-то другому. Это все еще неплохо, потому что у вас всего пара инженеров. Накладные расходы на связь довольно небольшие. Вы все еще в значительной степени синхронизированы. Вы понимаете что происходит. Ничто вас не удивляет.
Рост команды (6-12 инженеров)
Дальше все становится несколько странно. Вы перестаете разговаривать с каждым из членов команды. Вам придется взяться за жуткое таинство менеджмента, для меня это было нечто принципиально новое – в отличие от понятного и естественного для меня программирования. Именно на этом этапе накладные расходы на коммуникацию при написании кода значительно возрастают. Возможно вам придется задуматься о найме людей, не являющихся вашими друзьями. Все усложняется, потому что начинают происходить вещи, о которых вы и не подозревали. На этом этапе все происходит очень быстро, а также вы столкнетесь с первым разветвлением в дереве развития.
Организация команды (12+ инженеров)
С командой такого размера вы, вероятно, работаете в разных областях. Одновременно хорошо справляться и с людьми, и с кодом, вам не удастся, так что придется сделать выбор:
VP of Engineering: фокус на управлении
CTO: фокус на написании кода и архитектуре
VP of Engineering – это человек, который налаживает процессы, внедряет инструменты, которые повышают общую продуктивность, и помогает инженерам заниматься разработкой. Если вы останетесь CTO, то будете и дальше заниматься вещами, связанными с непосредственным написанием кода. Именно CTO знаком со всей системой от и до, а также знает где у нее спрятаны скелеты в шкафах.
Стоит ли вам быть CTO?
Я не был готов к принятию такого решения. Я даже не знал, что мне придется сделать выбор. Я думал, что CTO де-факто будет менеджером. Похоже, такое мнение существует более чем в половине стартапов, с которыми я общался. Вне зависимости от того, по какому пути вы пойдете (менеджерскому или техническому), вам придется найти человека, который возьмет на себя вторую ветку.
Чтобы принять решение, стоит вспомнить свои истоки. Чему вы уделяли больше времени, насколько вы уверены в себе и к чему хотели бы вернуться?
На первых порах в вашей команде будет всего один или два инженера. Все ваше время будет уходить на написание кода, и это прекрасно. Когда в вашей команде будет порядка 6 человек, все также будет неплохо. Порядка 80% времени будет уходить на написание кода, а 20% – на общение. И ощущаться рабочий процесс будет все еще неплохо. Вы будете во всем уверены примерно на 90%
А потом все станет значительно труднее. Вы будете заниматься непосредственной работой вполовину меньше времени, поскольку будете заняты наймом новых и новых сотрудников. Сотрудников, которым нужно помогать, будет становиться все больше и больше, и это не так здорово, потому что вам придется заниматься этим и писать код в тех же объемах, что и прежде. На этом этапе и нужно решить чем вы хотите заниматься – управлением или разработкой. Как вам такое движение по дереву развития?
Вам просто нужно найти то, от чего у вас вырабатывается дофамин
Этот прекрасный совет я получил от одного основателя стартапа. Вы чувствуете себя хорошо, если вам удается кому-то помочь справиться с задачей? Или вы получаете удовольствие от решения технических задач? Именно ответы на эти вопросы должны помочь вам понять по какому пути вам стоит пойти.
Четыре урока от CTO из разных стартапов
Я поговорил с 15 основателями и CTO, пытаясь решить, на чем сосредоточиться. Я спросил каждого о том, что они подмечали на своем пути и сложностях, с которыми они столкнулись. В этих разговорах постоянно всплывали четыре темы:
1. Смиритесь с переломными моментами
Я спрашивал всех об их самой большой ошибке — о том, какой опыт удавалось из нее извлечь и какой и как они ее исправляли. Затем я спрашивал их о том, как они будут пытаться ее предотвратить. Все перед ответом немного задумывались, а затем говорили что-то вроде «Знаешь, наверное я бы и не стал. Нам стоит пройти через такие моменты чтобы по-настоящему понять что мы пытаемся сделать. Чтобы узнать как сделать правильно, нужно познакомиться и с обратной стороной».
Если выражаться на языке CTO: относитесь к переломным моментам как к масштабированию сервиса. Если вы будете сталкиваться с узкими местами, то вам придется их устранять. Это намного эффективнее, потому что предсказывать их появление очень сложно – особенно в стартапах.
2. Ничейная земля
Именно так я могу назвать команду, в которой трудятся от 6 до 12 инженеров. В таких командах всего происходит понемногу, и это очень сбивает. Вы будете замечать, что говорите фразы в духе «Почему этот человек не знал об этом? И неужели он не знал, как ему следует поступить?» Если вы сталкиваетесь с подобными вопросами, то совмещать обязанности больше не получится – нужно будет заняться чем-то одним, а вторую половину задач передать тому, кто сможет с ними справиться. Вы не настолько гениальны, чтобы справляться с двумя ролями одновременно, но вы и не настолько глупы, чтобы игнорировать такое положение дел. Вы как бы застреваете посередине.
На этом этапе общение может помочь навести мосты. Если вы заметите, что говорите фразы вроде «Почему X сделал это?», то вам стоит начать чаще проговаривать определенные вещи. Повторяйте до тех пор, пока люди не начнут закатывать глаза и говорить «Опять то же самое». Это важно, потому что так вам удастся обеспечить равный уровень понимания среди всех сотрудников.
3. Структурная мимикрия
Очень часто я слышал, как CTO говорят что-то вроде: «Ну, мы видели, как это делают в Spotify или «Мы видели, как Amazon делает это». Эти люди перенимали структуру других компаний. Если вы, как технологическая компания, занимаетесь разработкой инноваций, то вам не следует изобретать инновационные методы управления. Не стоит и придумывать что-то новое в структуре своей компании. Новшества нужно привносить через ваши технологии, код и продукты.
Находите то, что покажется вам интересным, и пробуйте применять это в своей компании. Со временем ваша компания станет уникальной посредством смешения идей и способов организации, которых нет ни у кого. Возможно, вам удастся что-то придумать самостоятельно, но это не должно быть вашей целью. Вам стоит попытаться понять чем занимаются другие люди и стремиться избавлять себя от лишних хлопот.
4. Сосредоточьтесь
Последний урок основан на моих личных ошибках. Когда мы начали нанимать инженеров, мы думали, что большее количество людей позволит нам выполнять большие объемы работы. Вначале основатели и первая пара нанятых сотрудников буквально жонглировали. Нам казалось, что каждый может работать над двумя или тремя проектами — и это было нормально. Значит, четыре инженера могут вести от восьми до двенадцати проектов одновременно, верно? Нет, это была ужасная мысль.
Чем больше проектов, тем больше нитей коммуникации. Намного сложнее отслеживать все процессы и быть уверенным в том, что все всё понимают. Оглядываясь назад, я думаю, что когда мы наняли больше людей, стоило оставить рабочую нагрузку на том же уровне, а может даже немного ее снизить.
Мы просто выбирали один проект, на котором все сосредотачивались. Мы давали всем понять, что это наш главный приоритет. Были и какие-то второстепенные задачи, но они были вторичными, главной была наша основная цель.
Надеюсь, что мой опыт поможет тем, кто пытается ориентироваться в мутных водах ранних этапов стартапов, особенно в роли CTO. Было бы здорово, если бы я знал все это заранее, но тогда, может быть, я не получил бы всего этого опыта. Тем не менее, путаться, откладывать решения на потом и разбираться на ходу абсолютно нормально. Все это нормально, потому что на ранних порах у стартапов возникают самые разнообразные нужды.
- Обсуждение на HackerNews
- Телеграм-канал «HackerNews на русском»
