Небольшое число, которое легко понять неправильно
В 2020 году CTO Zerodha Кайлаш Надх написал, что технологическая команда примерно из 30 человек построила и масштабировала сложный брокерский стек. Компания работала в жёстко регулируемой отрасли, обслуживала большую активность и не имела отдельной армии узких специалистов: многие инженеры были full-stack и отвечали за систему целиком.
Из этого хочется сделать удобный лозунг: большая команда не нужна. Но маленькая команда Zerodha — следствие множества связанных решений, а не экономия в штатном расписании.
Сложность считается как долг
Каждый новый язык, облачный сервис и микросервис требует обновлений, мониторинга и человека, который поймёт его ночью. Zerodha сознательно предпочитала простой стек и самостоятельное владение ключевыми системами. Технологические расходы команда рассматривала как инженерную задачу, а не как неизбежный процент от выручки.
Это заставляет спрашивать перед внедрением: какую измеримую проблему решает новая технология, кто будет её сопровождать через три года и как мы уйдём, если она не оправдается?
Full-stack здесь означает ответственность
Не обязательно, чтобы один человек одинаково хорошо рисовал интерфейс, настраивал сеть и оптимизировал базу. Важнее отсутствие организационных щелей. Инженер понимает путь операции, может увидеть production-метрику и не перебрасывает проблему между шестью командами.
Такой подход требует сильных людей, прозрачного доступа к системе и доверия. Он плохо сочетается с микроменеджментом и десятком согласований на deploy.
Build vs buy без религии
Zerodha много строила и хостила сама, чтобы быстро реагировать на регуляторные изменения и контролировать критичный торговый контур. Но самописное не бесплатно: безопасность, отказоустойчивость и обновления становятся вашей бессрочной обязанностью.
Полезная граница проходит по конкурентному преимуществу и риску. Торговое ядро и опыт клиента могут заслуживать собственного кода. Почтовая рассылка, бухгалтерия или типовая аналитика — редко.
Бизнес-модель защищала инженерные решения
Zerodha была прибыльной и bootstrapped, то есть не обязана была каждый квартал доказывать гиперрост внешнему инвестору. Компания пишет, что не ставит сотрудникам метрики количества открытых счетов, установок и совершённых сделок.
Это снижает давление на функции, созданные только ради графика. Но отсутствие growth-таргетов не отменяет экономику и конкуренцию. Оно лишь даёт возможность выбирать долгосрочное доверие вместо краткосрочного поведения пользователя.
Где маленькая команда ломается
Если задач больше, чем можно честно закрыть, небольшая команда превращается в постоянное дежурство. Если знания живут в головах, уход одного человека опасен. Если нет времени на тесты, простота становится мифом.
Поэтому устойчивой маленькой команде особенно нужны автоматизация релизов, наблюдаемость, простые runbook, парное владение критичными системами и право отказываться от лишних функций.
Практика для обычного бизнеса
Составьте карту технологий и у каждой укажите владельца, годовую стоимость и причину существования. Найдите сервисы, которые дублируют друг друга. Ограничьте число способов решить одну задачу. Для нового инструмента требуйте план эксплуатации, а не только демо.
Дайте разработчикам видеть результат в production и разговаривать с поддержкой. Маленькая команда сильна короткой обратной связью; если разбить её процессами на отделы, останется только маленькая численность.
Zerodha — не доказательство, что 30 человек достаточно любому финтеху. Это доказательство, что организационная простота может быть конкурентным преимуществом, если бизнес готов последовательно её защищать.