Кратко: сохраняйте маленькие автономные продуктовые команды, общие платформенные сервисы и лёгкие управленческие «ограждения» (governance). Детальный план на $1$–$3$ года.
Общие принципы
- Автономия + выравнивание: команды имеют ответственность за продукт и KPI, сверху — ясные цели и архитектурные guardrails.
- Малая численность команд: быстрые решения и коммуникация.
- Центры экспертизы (платформа, безопасность, data) — чтобы не дублировать усилия.
- Инновации как встроенная практика (регулярно выделенное время и бюджет).
Структура по горизонтали (рекомендуемая)
- Продуктовые «сквады» (cross‑functional): каждая содержит инженеров, PM, дизайнеров. Оптимальный размер команды: $6$–$10$ инженеров + PM + дизайнер.
- Платформа/инфраструктура (DevOps, SRE, CI/CD, internal tools) — обслуживает ряд сквадов.
- Функциональные центры (Security, Data/ML, QA, UX) — экспертиза и стандарты.
- Лёгкая матрица: сквады ориентированы на продукт, эксперты — в шаре компетенций (chapters/guilds).
Роли и span of control
- Ключевые роли: CEO, CTO/Head of Product, Head of Engineering, Head of People/HR, Head of Sales.
- Менеджеры: прямой контроль $\le$$8$ человек; team leads для координации при росте.
- Когда в домене появляется $>3$ сквадов — вводите area lead / product area manager.
Пошаговый план по времени
- Короткий срок ($0$–$6$ мес):
- Определить продуктовые домены, назначить владельцев (PM).
- Формировать первые сквады ($6$–$10$ человек).
- Настроить CI/CD, deploy pipeline, базовые SLO/SLI.
- Ввести ежемесячные цель‑результатные метрики (OKR).
- Средний срок ($6$–$18$ мес):
- Создать платформу и shared services, выделить security/data teams.
- Ввести chapters/guilds для карьерного роста и обмена практиками.
- Формализовать архитектурные принципы, код‑ownership, API contracts.
- Внедрить процессы: code review, trunk based development, feature flags.
- Долгий срок ($18$–$36$ мес):
- Масштабирование структуры: area leads, product line managers при необходимости.
- Централизованное управление наймом и обучения, четкие L&D‑пути.
- Поддержание R&D‑подов/скворков для прорывных инициатив.
Управляемость и процессы
- OKR на квартал + ежемесячные ревью прогресса.
- Лёгкая операционная отчетность: deployment frequency, lead time, MTTR, customer NPS.
- Пороговые триггеры: при росте команды свыше $10$ инженеров — ввести team lead; при $>3$ сквадов в домене — area lead.
- Документировать архитектуру и контрактные границы API, чтобы автономия не превратилась в «хаос».
Сохранение инновационности
- Выделять время/ресурсы: минимум $10\%$ инженерного времени на эксперименты или hackathons; резерв бюджета на прототипы.
- Малые R&D‑поды ($2$–$5$ человек) с чётким временем на результат.
- Публичные демо и «fail fast» культура; быстрые MVP и измерение гипотез.
Управление техдолгом и качеством
- Регулярный тех‑долговой спринт: резервовать $15\%–20\%$ срока команды на техдолг и рефакторинг.
- SLO/SLI и error budgets для приоритизации надежности vs фич.
Кадры и карьера
- Чёткие технические и менеджерские треки карьерного роста.
- Найм: при планируемом росте штата ориентироваться на «плавный» найм, чтобы удерживать onboard качество (онбординг, наставничество).
Ключевые метрики для контроля
- Deployment frequency (цель: деплой хотя бы раз в неделю для активных продуктов).
- Lead time for changes.
- MTTR.
- Customer NPS / retention.
- Employee engagement / eNPS.
Риски и меры
- Риск бюрократии: держать governance минимальным — решения по реализации на командах, стратегические решения централизованно.
- Риск раздувания технологий: фиксированные архитектурные принципы и обязательный review для новых платформ.
- Риск выгорания: разумные периоды работы над инновативными задачами и техдолгом, наблюдение метрик нагрузки.
Короткая «чек‑лист» при росте
- Сформировать автономные сквады ($6$–$10$ чел).
- Назначить platform team и security/data.
- Ввести OKR и ежемесячные ревью.
- Резервировать $10\%$ времени на инновации и $15\%–20\%$ на техдолг.
- Разделять зоны ответственности и документировать API/контракты.
Если нужно, могу привести пример конкретной организационной карты для текущего числа сотрудников — укажите текущий headcount и соотношение product:eng:design.