Иногда читаю статьи про “правильную” структуру разработки.

Там всё красиво: Head of Delivery тимлиды senior PM архитекторы процессы регламенты масштабируемость.

В реальной жизни всё обычно намного прозаичнее. Если компания небольшая и портфель проектов только начинает расти, никакой идеальной структуры нет. Потому что когда у тебя: несколько проектов команда разработчиков ограниченная маржа нанять сразу несколько дорогих тимлидов с рынка — это быстрый способ съесть всю прибыль delivery.

Поэтому на старте обычно происходит то, что со стороны выглядит как лёгкий управленческий хаос.

Руководитель delivery: помогает PM ходит на сложные звонки с клиентами участвует в оценках иногда лезет в архитектуру иногда разбирает продакшн-пожары. И это нормально.

Почти любая команда проходит через несколько стадий. 1. Стадия героизма Все делают всё. Тимлидов ещё нет. Senior разработчиков может быть один, а может не быть вообще. Много ручного управления. Много опыта конкретных людей.

2. Стадия роста Появляются первые сильные разработчики. Кого-то постепенно начинают подтягивать до senior. Кто-то начинает брать на себя больше ответственности. Руководитель начинает понемногу выходить из операционки.

3. Стадия делегирования Появляются тимлиды. Они забирают: часть технических решений часть управления командой часть delivery. А руководитель начинает больше заниматься портфелем проектов и экономикой.

4. Стадия системы В какой-то момент основная работа руководителя становится другой. Не управлять задачами. А строить вещи, которые потом работают без него: процессы стандарты повторяемые практики правила запуска проектов.

Самое важное во всей этой истории — вовремя замечать, когда команда переходит из одной стадии в другую. И не пытаться управлять командой из 40 человек так же, как когда вас было пятеро.