Публикация была переведена автоматически. Исходный язык: Русский
Мы — команда, которая работает над созданием ML-алгоритма для умного ранжирования предложений в агрегаторе. Наша цель — не просто сортировать карточки “по цене или рейтингу”, а понимать контекст, поведение пользователя и выдавать персонализированные рекомендации, которые действительно работают.
Но по мере роста задач мы столкнулись с тем, что привычная структура уже не выдерживает темпа и сложности этих задач. Мы начали внедрять принципы холократии — и делимся, как это проходит на практике.
Почему холократия?
ML-продукты на стыке инженерии, математики и пользовательской логики — это не про “сверху вниз”. Они требуют гибкой координации между специалистами с разной экспертизой:
- дата-сайентисты
- инженеры
- специалисты по оценке качества (eval)
- продуктовые аналитики
- и бизнес.
А значит, система управления должна быть тоже гибкой и “сетевой”.Холократия — это не “хаос” и не “все делают всё”.Это модель, где:
- У каждого есть чёткая роль,
- Роли объединяются в круги по функциям или целям,
- Команды сами определяют свои приоритеты и зоны ответственности,
- Власть делегируется туда, где есть экспертиза, а не наверх.
Что мы уже внедрили в нашей команде:
Создали 3 круга:
1. ML Research — эксперименты, метрики, подходы
2. Infra & Deployment — доставка моделей в прод, CI/CD, мониторинг
3. Product Logic — взаимодействие с UX и продуктом, а также с бизнесом
Внутри каждого круга — гибкие роли.
Собрания теперь короткие и по делу — без долгих апдейтов.
Обсуждаем только блокеры, ключевые решения и пересборку ролей, если что-то не работает.
Что пока не вышло идеально (но мы работаем над этим):
1. Трудности с делегированием стратегических решений — пока фаундеры остаются центром стратегического вектора.
2. Нам предстоит научиться “отдавать” это в круги, не теряя фокус.
3. Роли не всегда обновляются вовремя — Кто-то продолжает выполнять задачи “по инерции”, даже если ответственность уже формально передана.
4. Есть “сопротивление” — особенно со стороны тех, кто раньше работал в классической иерархии — обсуждаем это открыто, внедрили формат “ревью ролей” + внутренние обучения по холократии.
Что планируем дальше:
- Визуализировать структуру кругов и ролей
- Настроить прозрачный фреймворк для пересмотра ролей каждые 6 недель
- Обучить фасилитаторов в каждом круге — чтобы синки были эффективными и не “висели на фаундере”
Что даёт нам холократия как команде?
- Быстрее принимаем архитектурные и продуктовые решения
- Улучшаем кросс-функциональное взаимодействие
- Меньше “бутылочных горлышек”
Мы — команда, которая работает над созданием ML-алгоритма для умного ранжирования предложений в агрегаторе. Наша цель — не просто сортировать карточки “по цене или рейтингу”, а понимать контекст, поведение пользователя и выдавать персонализированные рекомендации, которые действительно работают.
Но по мере роста задач мы столкнулись с тем, что привычная структура уже не выдерживает темпа и сложности этих задач. Мы начали внедрять принципы холократии — и делимся, как это проходит на практике.
Почему холократия?
ML-продукты на стыке инженерии, математики и пользовательской логики — это не про “сверху вниз”. Они требуют гибкой координации между специалистами с разной экспертизой:
- дата-сайентисты
- инженеры
- специалисты по оценке качества (eval)
- продуктовые аналитики
- и бизнес.
А значит, система управления должна быть тоже гибкой и “сетевой”.Холократия — это не “хаос” и не “все делают всё”.Это модель, где:
- У каждого есть чёткая роль,
- Роли объединяются в круги по функциям или целям,
- Команды сами определяют свои приоритеты и зоны ответственности,
- Власть делегируется туда, где есть экспертиза, а не наверх.
Что мы уже внедрили в нашей команде:
Создали 3 круга:
1. ML Research — эксперименты, метрики, подходы
2. Infra & Deployment — доставка моделей в прод, CI/CD, мониторинг
3. Product Logic — взаимодействие с UX и продуктом, а также с бизнесом
Внутри каждого круга — гибкие роли.
Собрания теперь короткие и по делу — без долгих апдейтов.
Обсуждаем только блокеры, ключевые решения и пересборку ролей, если что-то не работает.
Что пока не вышло идеально (но мы работаем над этим):
1. Трудности с делегированием стратегических решений — пока фаундеры остаются центром стратегического вектора.
2. Нам предстоит научиться “отдавать” это в круги, не теряя фокус.
3. Роли не всегда обновляются вовремя — Кто-то продолжает выполнять задачи “по инерции”, даже если ответственность уже формально передана.
4. Есть “сопротивление” — особенно со стороны тех, кто раньше работал в классической иерархии — обсуждаем это открыто, внедрили формат “ревью ролей” + внутренние обучения по холократии.
Что планируем дальше:
- Визуализировать структуру кругов и ролей
- Настроить прозрачный фреймворк для пересмотра ролей каждые 6 недель
- Обучить фасилитаторов в каждом круге — чтобы синки были эффективными и не “висели на фаундере”
Что даёт нам холократия как команде?
- Быстрее принимаем архитектурные и продуктовые решения
- Улучшаем кросс-функциональное взаимодействие
- Меньше “бутылочных горлышек”