4 записи с тегом "scaling"

Engineering Director, хорошо ведший организацию на 50 человек, обычно неверный человек, чтобы вести 500. Не потому что талантлив меньше — потому что на 500 это другая работа, а не та же с удвоенной интенсивностью. Исследования First Round Review по 300+ инженерным лидерам стабильно показывают: переходы на ~80, ~150 и ~300 инженерах — там, где кластеризуется большинство выгораний и тихих уходов старших лидеров.

Это гайд, основанный на данных, о четырёх переходах Engineering Director при росте от 50 до 500 — что отпустить, что взять, и что наши IDE heartbeat данные говорят о признаках Director'а, который не сделал сдвиг.

Как документируют Matthew Skelton и Manuel Pais в Team Topologies, коммуникационный overhead между инженерами растёт квадратично: при 10 людях — 45 потенциальных каналов связи; при 100 — почти 5 000. При 10 инженерах вы знаете каждого. Слышите каждый разговор. Ревьюите большинство PR. Всё работает — потому что вы сами клей, скрепляющий систему. При 100 это невозможно. CTO, который пытается управлять 100 инженерами так же, как управлял 10, выгорит, создаст узкие места и будет наблюдать, как падает качество. Переход от 10 к 100 — самый сложный организационный вызов для CTO стартапа, и данные — единственный способ пройти его, не потеряв рассудок.

На стадии Seed ваш CTO пишет код и выпускает фичи. К Series B у вас 40 инженеров в нескольких командах, и CTO не делал коммитов уже несколько месяцев. Инженерные метрики, которые важны на каждом этапе, совершенно разные — и ошибка здесь может означать разработку не того, наём не так и рассказ инвесторам истории, не совпадающей с реальностью. Фреймворк T2D3 (Triple, Triple, Double, Double, Double), определяющий ожидания роста SaaS, требует инженерной velocity, масштабирующейся вместе с амбициями по выручке.

Вот как эволюционировать инженерные метрики по мере роста вашего SaaS-стартапа.

Управление организацией из 500+ разработчиков в телекоме — как управление маленьким городом. У вас есть инфраструктурные команды, поддерживающие критически важные сетевые системы, продуктовые команды, создающие клиентские приложения, платформенные команды, поддерживающие внутренний инструментарий, и команды интеграции, соединяющие всё это воедино. Они распределены по нескольким офисам, часовым поясам, а иногда и странам.

В таком масштабе нельзя полагаться на племенные знания, еженедельные синки или управленческую интуицию. Нужны данные. Инженерные метрики обеспечивают систематическую видимость, делающую управление разработкой в крупном масштабе возможным.