Демократия в стартапе не работает
Почему тиран во главе бизнеса окКак и многие начинающие предприниматели, когда-то я верил в демократию в бизнесе. На деле оказалось, что стартаперам нужен тиран.
Изначально мы разрабатывали сервис автоматического создания мобильных приложений для интернет-магазинов и ресторанов GetShopApp.com с мыслью, что у нас будут работать абсолютно самостоятельные люди, способные отвечать за свой кусок и при этом чувствовать некое единение от общего дела.
Как и многие начинающие предприниматели, когда-то я верил в демократию в бизнесе. На деле оказалось, что стартаперам нужен тиран.
Изначально мы разрабатывали сервис автоматического создания мобильных приложений для интернет-магазинов и ресторанов GetShopApp.com с мыслью, что у нас будут работать абсолютно самостоятельные люди, способные отвечать за свой кусок, и при этом чувствовалось бы некое единение от общего дела.
Это было круто, пока первый раз не кончились деньги. А произошло это как раз потому, что было очень много демократии: разработчики придумывали «фичи», продавцы думали о каналах продаж, но при этом мы были как Лебедь, Рак и Щука, что поломало весь бизнес. Часто бывает, что команда «пилит» какую-то «фичу», потому что она кажется классной, не согласовав план её разработки с маркетологами и продавцами. Эта видимая демократия на самом деле анархия, поскольку, решая локальную задачу, не связанную с запросами клиентов, программист вредит компании. Хороший продукт — не тот, у которого самый классный дизайн или есть много классных функций, а тот, который меняет жизнь пользователей, делает их довольными, а акционеров — богатыми. Когда финансы подходят к концу, а продукта всё нет, стоит проявить диктаторские черты: запретить делать «вещи в себе» и вернуть разработчиков к решению общей задачи.
Нередко возникает впечатление, что молодая и талантливая команда может обойтись без руководителя вовсе и самостоятельно перевернуть мир. Это ошибка: всегда нужен суровый дядька Черномор. Например, у меня работают молодые разработчики, окончившие СУНЦ (школу при МГУ, которая набирает победителей олимпиад со всей России), а затем факультет ВМК. Полгода ушло только на то, чтобы заставить их слушаться, потому что каждый был самым умным. Талантливых людей очень сложно убедить работать так, как нужно компании.
Когда я начал говорить своим программистам, что придуманное ими за месяц можно было сделать за день, они обижались. Пришлось объяснить, что если они продолжат работу в таком темпе, то все остальные не получат зарплату. Чтобы сплотить команду, я иногда намеренно вводил её в стресс, делал себя врагом разработчиков. Это их сильно сплачивало. Например, за то, что iOS-разработчик вовремя не сделал свои задачи, я наказал не его, а начальника отдела разработки. Во-первых, это сделало сотрудников ближе, во-вторых, сильно подстегнуло разработчика, поскольку ему стало стыдно. Следующий месяц он практически ночевал на работе.
Замашки диктатора сотрудники прощают лишь в том случае, если им сопутствует полная открытость. Вся команда всегда знала, что происходит с компанией: когда клиенты счастливы, когда они нас ругают, когда инвестор резко прекратил транши. Мы всегда собираемся все вместе и вместе решаем, что делать дальше. Открытость — это то, что объединяет и делает нас единым организмом. Очень важно вытаскивать людей из состояния «моя хата с краю» в состояние «я делаю общее дело».
Казалось бы, этому очень способствует совместное владение бизнесом. Но это очень опасный путь — никогда не давайте сотрудникам долю. В самом начале проект, как правило, не может платить его участникам много. Поэтому ты всех привлекаешь в капитал. Сразу получается схема: генеральный директор забирает себе 40%, ещё 30% отдаёт техническому директору, 20% — исполнительному, остальное — финансовому. Потом может случиться следующее: один из дольщиков решит уйти из бизнеса, а его доля к тому моменту будет стоить очень дорого. У компании может не быть денег, чтобы её выкупить, а два основателя могут так и не найти общий язык.
Очень показательный пример был с проектом Generate Club. Ребята познакомились в Tolstoy Yandex Summer Camp и придумали там проект, в котором каждому выделили равную долю по 20%. Уже в ходе акселерационной программы ФРИИ команда начала разваливаться. С изначальной гипотезой бизнеса, продажей мультилендингов (интернет-страница меняется в зависимости от запросов пользователя), успешно стартовать не получилось. Продажи давались очень тяжело, и при поиске новых ниш или моделей бизнеса фактически каждый из членов компании пошёл в свою сторону. Проект не дожил до конца акселерационной программы и развалился. Примерно полтора месяца все его участники сидели без денег и разъехались по разным городам. Только двое из них решили как-то продолжать работу. В итоге фаундер и его партнёр договорились с другими участниками об уменьшении их доли до 5% и продолжили развитие бизнеса. По факту в проекте появились три «мёртвых души».
Еще один проект, которому я помогал, попал в похожую ситуацию. Проект занимался онлайн-подачей молебнов. Они договорились с одним монастырём в Нижегородской области, всё запустили, я добился для них встречи с батюшкой из храма Христа Спасителя, но за день до неё команда распалась из-за разных взглядов на жизнь и бизнес. Они видели абсолютно два разных сценария развития компании, и каждый настаивал на своём. Если бы изначально основатель стартапа дал разработчику не долю, а опцион и зарплату, то компанию удалось бы сохранить. Изначально лучше давать опцион 1–3%, а потом обсуждать дальнейшую мотивацию.
Иногда отличным мотиватором для программистов может стать ментор. Мы нашли своего случайно. Когда общались с потенциальным инвестором, он решил провести собеседование с нашей командой. Я был не против, но заметил, что у него нет компетенции оценивать разработчиков. Тогда я предложил выбрать технического директора из любой портфельной компании инвестора. Денег в итоге привлечь не удалось, зато так мы познакомились с техдиректором iiko.net Кириллом Сухоносенко. После интервью с моей командой он сказал, что все ребята очень талантливые, но в силу возраста ещё не видят некоторых особенностей в архитектуре продукта, важных в средней и долгосрочной перспективе. Ему понравились ребята, и он был готов бесплатно встречаться с нашим техническим директором и другими разработчиками, чтобы корректировать их планы и что-то подсказывать. Сама команда восприняла эту новость на ура. Разработчики всегда с уважением относятся к более опытным, но не пафосным коллегам-технарям. Менеджерам такое признание заслужить сложнее.
Демократия — очень крутая штука, когда мы создаём атмосферу самореализации, но, увы, в нашей стране в любом проекте всё равно должен быть человек, который может принять решение и всем дать по балде. Всегда должно быть понятно, кто берёт на себя ответственность.