Во дворе устанавливали шлагбаум. Один человек в рабочке занимается непосредственно установкой, а остальные четыре в коженках контролируют, подсказывают, тычут пальцем. В моем IT-опыте тоже так было: на одного бедного разраба приходилось 4 менеджера. Стало интересно разобраться, норм ли это и как починить 🙌

Даже на основе моего скромного опроса стало понятно: простого вывода здесь не будет 😵‍💫

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

Посмотрим подробнее на сцену 1+4.

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

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

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

В итоге встреча превращается не в способ принять решение, а в голосовой интерфейс согласования.

Понять, какой случай у вас, очень просто. Если после звонка стало понятно: - кто принимает решение, - кто делает следующий шаг, - какие зависимости сняты, - что больше не надо обсуждать повторно, – значит, возможно, координация была дорогой, но полезной.

Если нет это управленческий провал.

Так давайте просто срежем пару слоев менеджмента! Оказывается, я не один такой умный 😅

Google в ранние годы успел попробовать плоскую организацию и довольно быстро пришёл к выводу: вопрос не в том, нужны ли менеджеры, а в том, какие менеджеры нужны и за что именно они отвечают. Не буду пересказывать статью, ее стоит прочитать.

Как начать решать эту проблему сегодня:

Во-первых, распределяем роли. Кто решает приоритет? Кто решает сроки? Кто решает scope? Кто решает технический компромисс? Я бы начал с RACI. Простой понятный инструмент, наглядно показывающий, почему вы буксуете на согласованиях.

Во-вторых, кровно отстаивать культуру звонков. Только встречи с понятной аджендой и до 7 человек. Остальное закрываем асинхронными каналами (чаты, вики и т.д.).

В-третьих, надо смотреть на handoff’ы (передача контекста между командами). Если работа организована по фазам, функциям и представительствам, а не вокруг потока ценности, менеджеров почти неизбежно становится больше, потому что кто-то должен сшивать разрывы.

В-четвёртых, стремимся к автономии команд. Странно насаждать обязанности и не давать полномочий. Это называется галерой.

И, наверное, самое важное наблюдение: лечим не роли, а процессы. Если просто «срезать менеджеров», но оставить сломанную систему решений, работа никуда не исчезнет. Она просто переедет на техлидов, инженеров, аналитиков или разработчиков 💩

Интересно было бы почитать про дизайн эффективной IT-системы. Роли, задачи, артефакты?

Подводим итог: настоящая ценность управленца — создавать процессы, которые никто не замечает. Фишки крутятся, заказы мутятся, но при этом команда не погибает на звонках и бесконечных слоях согласования. Вот это настоящий вызов для проджекта. Именно с этого я бы начинал, когда заходит речь про выгорание и текучку.