Пять лет назад я запустил небольшой сервис для логистики, будучи человеком, который уверенно отличает сервер от кофемашины только по звуку. Продукт рос, клиенты платили, а я всё чаще ловил себя на мысли, что нанимаю разработчиков, глядя им в глаза и надеясь на честность. Тогда мне казалось, что CTO — это просто самый дорогой и самый умный из программистов. Сейчас, пройдя через два увольнения технических директоров, суд с одним из них и полную переписку бэкенда с нуля, я могу честно рассказать, как я это пережил и что бы сделал иначе.
Первая ошибка была классической: я взял в CTO друга детства, который неплохо писал код на Python. Я отдал ему доступы ко всему, подписал договор на салфетке и пообещал долю в двадцать процентов просто за то, что он согласился пойти в непонятный стартап. Через год выяснилось, что вся архитектура живёт в голове одного человека, документации нет, на прод-сервере у него личный root, а бэкапы делаются вручную раз в месяц. Когда мы поссорились из-за стратегии, он ушёл, забрав с собой не только знания, но и уверенность инвесторов в том, что у компании есть хоть какая-то техническая база.
Вторая попытка была уже умнее, но всё равно не идеальной. Я нашёл сильного инженера с опытом в крупной продуктовой команде, но совершил новую ошибку: отдал ему место в совете директоров с правом вето на технические решения. Формально это выглядело как уважение к экспертизе, а на практике я перестал понимать, что происходит в собственном продукте. Только тогда до меня дошло, что нанять CTO — это не про поиск волшебника, а про построение системы, в которой один человек не может держать компанию в заложниках.
Главный вывод, которым я теперь делюсь с каждым основателем без технического бэкграунда: разделяйте роли. CTO не должен быть единственным архитектором и единственным человеком с доступом к продакшену. Мой текущий технический директор отвечает за стратегию, найм и качество инженерных решений, но код-ревью обязательно проходят минимум два человека, а доступы выданы по принципу минимальных привилегий. Если один специалист уходит, продукт не останавливается — и именно это, а не красивый резюме, является настоящим критерием зрелости команды.
Отдельно скажу про доли и договоры, потому что здесь неопытные основатели теряют компании чаще всего. Я теперь всегда оформляю вестинг с клиффом: доля начисляется постепенно, в течение четырёх лет, и первые двенадцать месяцев ничего не гарантируют. Обязательно подписывается соглашение о передаче всех прав на интеллектуальную собственность компании, а не человеку. И никаких устных обещаний: всё, что касается собственности, голосов и денег, живёт в документах, которые проверял мой юрист, а не я на бегу между звонками.
Ещё один практический приём, который мне очень помог: при найме CTO я привлекаю независимого технического консультанта, который проводит аудит кода и задаёт кандидату неудобные вопросы про масштабирование, безопасность и техдолг. Я не могу оценить эти ответы сам, но могу оценить, насколько кандидат раздражается, уходит от темы или, наоборот, спокойно объясняет сложное простыми словами. За два года такая практика отсеяла троих харизматичных, но пустых кандидатов, и я ни разу об этом не пожалел.
Если сформулировать коротко, то моя формула такая: наймите человека, который умеет строить процессы, а не только писать код; зафиксируйте права на бумаге; оставьте себе понимание того, как работает продукт хотя бы на уровне схемы; и никогда не позволяйте одному человеку быть единственной точкой отказа. Основатель без технического образования — это не слабость, а осознанная позиция, при которой ваша задача состоит в том, чтобы задавать правильные вопросы и создавать рамки, а не в том, чтобы писать код самому.
А теперь вопрос к вам, друзья: расскажите, как вы находили своего технического директора и какие условия в договоре оказались для вас самыми важными — вестинг, передача прав, ограничение доступов или что-то совсем неожиданное? Буду рад услышать ваши истории, потому что каждый такой опыт делает наше сообщество чуточку мудрее.
Первая ошибка была классической: я взял в CTO друга детства, который неплохо писал код на Python. Я отдал ему доступы ко всему, подписал договор на салфетке и пообещал долю в двадцать процентов просто за то, что он согласился пойти в непонятный стартап. Через год выяснилось, что вся архитектура живёт в голове одного человека, документации нет, на прод-сервере у него личный root, а бэкапы делаются вручную раз в месяц. Когда мы поссорились из-за стратегии, он ушёл, забрав с собой не только знания, но и уверенность инвесторов в том, что у компании есть хоть какая-то техническая база.
Вторая попытка была уже умнее, но всё равно не идеальной. Я нашёл сильного инженера с опытом в крупной продуктовой команде, но совершил новую ошибку: отдал ему место в совете директоров с правом вето на технические решения. Формально это выглядело как уважение к экспертизе, а на практике я перестал понимать, что происходит в собственном продукте. Только тогда до меня дошло, что нанять CTO — это не про поиск волшебника, а про построение системы, в которой один человек не может держать компанию в заложниках.
Главный вывод, которым я теперь делюсь с каждым основателем без технического бэкграунда: разделяйте роли. CTO не должен быть единственным архитектором и единственным человеком с доступом к продакшену. Мой текущий технический директор отвечает за стратегию, найм и качество инженерных решений, но код-ревью обязательно проходят минимум два человека, а доступы выданы по принципу минимальных привилегий. Если один специалист уходит, продукт не останавливается — и именно это, а не красивый резюме, является настоящим критерием зрелости команды.
Отдельно скажу про доли и договоры, потому что здесь неопытные основатели теряют компании чаще всего. Я теперь всегда оформляю вестинг с клиффом: доля начисляется постепенно, в течение четырёх лет, и первые двенадцать месяцев ничего не гарантируют. Обязательно подписывается соглашение о передаче всех прав на интеллектуальную собственность компании, а не человеку. И никаких устных обещаний: всё, что касается собственности, голосов и денег, живёт в документах, которые проверял мой юрист, а не я на бегу между звонками.
Ещё один практический приём, который мне очень помог: при найме CTO я привлекаю независимого технического консультанта, который проводит аудит кода и задаёт кандидату неудобные вопросы про масштабирование, безопасность и техдолг. Я не могу оценить эти ответы сам, но могу оценить, насколько кандидат раздражается, уходит от темы или, наоборот, спокойно объясняет сложное простыми словами. За два года такая практика отсеяла троих харизматичных, но пустых кандидатов, и я ни разу об этом не пожалел.
Если сформулировать коротко, то моя формула такая: наймите человека, который умеет строить процессы, а не только писать код; зафиксируйте права на бумаге; оставьте себе понимание того, как работает продукт хотя бы на уровне схемы; и никогда не позволяйте одному человеку быть единственной точкой отказа. Основатель без технического образования — это не слабость, а осознанная позиция, при которой ваша задача состоит в том, чтобы задавать правильные вопросы и создавать рамки, а не в том, чтобы писать код самому.
А теперь вопрос к вам, друзья: расскажите, как вы находили своего технического директора и какие условия в договоре оказались для вас самыми важными — вестинг, передача прав, ограничение доступов или что-то совсем неожиданное? Буду рад услышать ваши истории, потому что каждый такой опыт делает наше сообщество чуточку мудрее.