Один конфликт, который я не мог сформулировать

Последние несколько лет я наблюдаю один и тот же паттерн. В каждой компании, где я работал – от финтеха до Microsoft – между продуктовой и инженерной командами существует трение. Не открытый конфликт. Скорее, постоянное ощущение, что мы говорим на разных языках.

Продуктовая сторона: “Нам нужна эта фича к третьему кварталу, мы заблокированы, почему так медленно?”

Инженерная сторона: “У нас проблемы с ёмкостью, безопасность требует ресурсов, техдолг накапливается.”

Я был по обе стороны. В Точке – строил платформу для 600+ человек в ИТ. В Майкрософте – работаю техническим менеджером программ в инженерной команде, которая обслуживает 2000+ разработчиков. И каждый раз чувствовал этот диссонанс, но не мог его чётко описать. Вроде бы все всё понимают, все профессионалы. Но конфликт воспроизводится снова и снова, в разных компаниях, с разными людьми.

Я решил копнуть глубже – не в процессы, а в социологию и психологию. Что делает этих людей разными?

Операционная разница – это следствие, не причина

Да, у продуктовых и инженерных команд разные клиенты. Продуктовая работает на внешнего пользователя, который голосует деньгами и оттоком. Инженерная – на внутреннего разработчика, который молча находит обходной путь и никогда не жалуется.

Да, у них разные горизонты. Продуктовая команда живёт спринтами и итерациями – быстрый рыночный отклик. Инженерная думает кварталами и годами – платформы живут долго.

Да, успех выглядит по-разному. Для продуктовой – фичи используются, NPS растёт. Для инженерной – всё работает, никто не жалуется. Незаметность.

Это всё описано в книге «Топологии команд» и десятках статей. Но вот что меня зацепило – почему в эти команды приходят люди с принципиально разным мышлением? И почему, когда они встречаются на совместном планировании, конфликт практически неизбежен?

Белбин: разные роли – разные инстинкты

Мередит Белбин описал девять командных ролей – устойчивых поведенческих паттернов, которые люди проявляют в команде. Не должности, не навыки – именно склонности. То, как человек по умолчанию действует, когда его не контролируют. Девять ролей делятся на три группы:

Мыслительные роли – те, кто думает:

• Генератор идей – креативный, нестандартно мыслит, предлагает решения, которых никто не видел. Слабость: витает в облаках, забывает про ограничения. Тот коллега, который на встрече говорит “а что если мы вообще всё переделаем?”
• Аналитик-стратег – трезвый, беспристрастный, взвешивает все варианты перед решением. Не поддаётся энтузиазму. Слабость: может казаться холодным и медлительным. Тот, кто на встрече молчит, а потом говорит “мы не учли три риска”.
• Специалист – глубокий эксперт в узкой области. Приносит знания, которых больше ни у кого нет. Слабость: зациклен на своей теме, может не видеть общую картину. Тот, кто знает всё про инфраструктуру, но не интересуется пользователями.

Социальные роли – те, кто координирует:

• Координатор – проясняет цели, распределяет роли, двигает команду к решению. Не обязательно формальный лидер, но все почему-то слушают именно его. Слабость: может делегировать свою работу.
• Исследователь ресурсов – энтузиаст, нетворкер, приносит идеи и контакты извне. Первый слышит о новом тренде, первый знакомится с нужным человеком. Слабость: теряет интерес, когда новизна проходит.
• Душа команды – сглаживает конфликты, поддерживает атмосферу, чувствует настроение группы. Слабость: избегает трудных разговоров, не может сказать “нет”.

Деятельные роли – те, кто делает:

• Мотиватор – напористый, энергичный, толкает команду вперёд через сопротивление. Слабость: может давить на людей, провоцировать конфликты.
• Реализатор – дисциплинированный, превращает планы в конкретные задачи и выполняет их. Слабость: негибок, сопротивляется изменениям.
• Доводчик – перфекционист, следит за деталями, доводит до конца. Тот, кто находит ошибку в документе за час до дедлайна. Слабость: тревожный, не умеет отпускать.

Теперь – если наложить эти роли на двух типов менеджеров, картина становится неожиданно чёткой.

Продуктовый менеджер

Основная роль – Исследователь ресурсов. Он по натуре смотрит наружу: изучает рынок, разговаривает с пользователями, приносит внешние сигналы в команду. Проводит интервью, ловит тренды, устанавливает связи. Комфортен с неопределённостью – ему нормально начинать без полной картины.

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

Слепое пятно: Доводчик. Исследователь ресурсов блестящ в начале – он открывает направления, запускает инициативы. Но теряет интерес, когда новизна проходит. Запустил фичу – пошёл дальше. А нужно ещё отследить, достигла ли она метрики, итерировать после провалов. Продуктовый менеджер без склонности к Доводчику запускает вещи и уходит, не зная – сработало ли.

Платформенный менеджер

Основная роль – Аналитик-стратег. Он по натуре смотрит внутрь: оценивает риски, взвешивает архитектурные варианты, думает о последствиях на горизонте года. Не поддаётся хайпу. Когда все кричат “давайте быстрее”, он спрашивает “а что сломается?”

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

Слепое пятно: Координатор. Аналитик-стратег силён аналитически, но плох как мотиватор. Может казаться холодным. Платформенный менеджер без навыков Координатора строит технически безупречное – и никем не используемое. Потому что никогда не вкладывался в социальную работу по внедрению. Построил идеальную платформу, а разработчики продолжают обходить её самодельными скриптами.

Где происходит столкновение

Исследователь ресурсов видит возможность и хочет её реализовать сейчас. Аналитик-стратег видит риск и хочет сначала проанализировать. Оба правы. Но когда Исследователь приходит к Аналитику с горящим запросом – Аналитик воспринимается как тот, кто тормозит. А когда Аналитик предупреждает о накапливающемся техдолге – Исследователь не слышит, потому что это не звучит как возможность.

И ещё одна ловушка, о которой стоит сказать отдельно. Генератор идей – опасная роль для обоих типов менеджеров. Ни одна из ролей не нуждается в Генераторе как основном профиле – но именно его часто нанимают, описывая менеджера как «визионера». Генератор идей ненавидит ограничения и плохо работает в структурированных процессах. Обе роли требуют навигации в ограничениях и устойчивого исполнения. Результат найма Генератора на любую из позиций: блестящие идеи, минимальный результат.

DISC: фундаментальный парадокс

Если Белбин описывает что человек делает в команде, то DISC описывает как он это делает – его базовый стиль поведения. Четыре измерения, четыре способа реагировать на мир:

D – Доминирование. Прямой, решительный, ориентирован на результат. Человек с высоким D принимает решения быстро, берёт ответственность, не боится конфликта. На встрече это тот, кто говорит “хватит обсуждать, давайте решать”. Обратная сторона: может давить, игнорировать чужое мнение, разрушать командную динамику. Не терпит долгих согласований.

I – Влияние. Энтузиаст, убеждает через энергию и обаяние, ориентирован на людей. Высокий I легко устанавливает контакт, зажигает команду, продаёт идеи. На встрече это тот, кто вдохновляет и создаёт ощущение “мы точно справимся”. Обратная сторона: может быть поверхностным, принимать решения на интуиции, избегать неприятных деталей. Склонен переоценивать перспективы и недооценивать риски.

S – Постоянство. Терпеливый, стабильный, ориентирован на команду и гармонию. Высокий S – надёжный коллега, который никогда не подведёт и создаёт комфортную атмосферу. На встрече это тот, кто молча кивает и потом тихо делает всю работу. Обратная сторона: избегает конфликтов любой ценой, не умеет говорить “нет”, соглашается на нереалистичные обязательства. Боится перемен.

C – Добросовестность. Аналитик, ориентирован на качество и точность. Высокий C думает системно, видит риски, документирует, требует данных перед решением. На встрече это тот, кто открывает таблицу и говорит “давайте посмотрим на цифры”. Обратная сторона: может парализовать процесс бесконечным анализом, воспринимается как бюрократ, с трудом принимает “достаточно хорошо” вместо “идеально”.

Как это ложится на менеджеров

Продуктовый менеджер – это, как правило, высокий I с вторичным D. Влияние обеспечивает главное: построение доверия без формальных полномочий, проведение пользовательских интервью (люди открываются тёплым и энергичным людям), убедительные презентации для стэйкхолдеров, поддержание энергии в условиях неопределённости. Доминирование добавляет способность принимать решения при неполной информации и говорить “нет” стэйкхолдерам, когда нужно.

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

Почему они конфликтуют

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

То есть, когда продуктовый менеджер говорит “они вечно всё усложняют и тормозят” – это I встречает C. А когда платформенный менеджер говорит “они не думают о последствиях” – это C встречает I. Не злой умысел. Не некомпетентность. Просто два способа видеть мир.

Ловушка высокого S

Отдельно про Постоянство. Ни одна из двух ролей не подходит для доминирующего S-профиля – но многих привлекает менеджмент именно из-за S-качеств: коллаборативность, терпение, забота о команде. Продуктовый менеджер с высоким S избегает трудных разговоров о приоритизации, говорит “да” слишком многим стэйкхолдерам, никогда не создаёт сфокусированный план. Хорошо любим, неэффективен. Платформенный менеджер с высоким S не может отказать продуктовым командам, избегает разговора “ваш запрос сломает архитектуру”, получает платформу, которая делает всё плохо, пытаясь угодить всем.

D без баланса – тоже проблема

Высокий D без I у продуктового менеджера превращается в бульдозер – менеджер “знает что нужно пользователям” и игнорирует исследования. Классический антипаттерн “мини-генеральный директор”. Высокий D без C у платформенного менеджера превращается в безрассудство – менеджер давит выкатывать платформенные изменения быстро, без анализа последствий. Это особенно опасно: платформенные ошибки бьют по всем одновременно.

Мой опыт: когда это ломается

Я это видел изнутри. В финтехе, где я строил платформу, продуктовые команды воспринимали нас как тех, кто тормозит. “Нам нужна эта возможность, а платформа ещё не готова.” А мы видели, что если сделать быстро и грязно – через полгода всё посыпется, и остановятся все продуктовые команды одновременно. Мультипликатор урона огромный.

Но самый показательный кейс случился позже – когда я работал техническим менеджером программ в крупной технологической компании. Мой руководитель – менеджер с продуктовым мышлением. Классический I/D по DISC: энергичный, ориентированный на нарратив, стэйкхолдеров, видимость результатов. Координатор по Белбину – двигает людей к согласованию, хочет, чтобы все были “на одной странице”.

Я – C/D. Аналитик-стратег + Специалист. Мой инстинкт – сделать работу, показать данные, дать результат. Не обещать заранее. Не продавать.

Конфликт воспроизводился с пугающей регулярностью.

Данные vs нарратив

Я построил дашборд по надёжности сборок – с графиками, трендами, процентами. Для меня это и был результат: метрики улучшились, вот данные. Для руководителя – это создало “больше путаницы”. Он хотел не графики, а историю: что было, что стало, почему это важно для продуктовых команд, какие следующие шаги. Одну страницу, не десять.

То есть, я доставлял C-ответ (точные данные) – а от меня ждали I-ответ (убедительный нарратив). Оба подхода валидны. Но они не совпадали.

В какой-то момент я сказал: “Ты не доверяешь моим данным”. Он ответил: “Я хочу историю за ними. И более ясный нарратив”. Мы говорили об одном и том же – но на разных языках. Я интерпретировал его запрос как недоверие (C-реакция: “данные объективны, если ты их не принимаешь – значит не доверяешь мне”). Он интерпретировал мои данные как отсутствие ясности (I-реакция: “если я не могу пересказать это стэйкхолдерам за две минуты – значит ясности нет”).

Молчаливая работа vs видимость

Мой стиль – сделать, потом рассказать. Не давать пустых обещаний. Показать результат, когда он есть. Для C-профиля это естественно: работа говорит сама за себя.

Для I-профиля руководителя это выглядело как отсутствие прогресса. Он прямо сказал: конфликт между нами “в основном из-за отсутствия результатов и прогресса в тех областях, которые ты ведёшь” – плюс “проблемы коммуникации и культуры”. При этом результаты были. Но они были невидимы, потому что я не вкладывался в их коммуникацию.

Вот она, классическая ловушка платформенного менеджера: молчание платформы дороже крика продукта.

Прямота, которая воспринимается как грубость

Однажды руководитель хотел добавить себя в технический чат команды. Я ответил: “Ты не будешь это читать, будешь игнорировать. Давай оставим чат маленьким.” Это D встречает D. Я защищал границу, которая для меня была операционно важной. Он услышал пренебрежение. Он ответил: “Я читаю технические чаты, даже если не всё понимаю. Я хочу, чтобы все были в контексте.”

Оба правы. Но формулировка “ты не будешь читать” – это D без I. Прямота без эмпатии. Если бы я сказал “я беспокоюсь, что чат разрастётся и потеряет фокус – давай я буду присылать тебе еженедельную сводку” – тот же результат, другое восприятие.

Что я вынес из этого

Когда я перешёл из роли инженерного менеджера в технического менеджера продукта – я почувствовал на себе этот сдвиг. Начал думать больше о скорости цикла, о внедрении, о том, как быстрее проверить гипотезу. Аналитик-стратег во мне не исчез, но Исследователь ресурсов начал просыпаться. Оказалось, что роль формирует мышление не меньше, чем мышление формирует выбор роли.

А конфликт с руководителем – он не про “кто прав”. Он про то, что C/D и I/D по-разному упаковывают одну и ту же реальность. Я упаковываю в данные и действия. Он – в историю и контекст. Ни один из форматов не полон без другого.

Три вещи, которые я теперь делаю иначе:

• Когда не согласен – пишу короткий документ на одну страницу с двумя вариантами, метриками и конкретными действиями на следующую неделю. Не спорю устно. Это прямо отвечает на запрос I-профиля: “короткий, ясный, письменный формат”.
• Когда чувствую, что разговор уходит в “ты мне не доверяешь” – заменяю на “что тебя убедит?” или “какую метрику мы оба примем как критерий успеха?”. Это переводит спор из личного в системный.
• Раз в неделю отправляю короткий апдейт: сделано / не сделано / заблокировано / следующий шаг. Без обещаний. Только факты. Это сохраняет мой стиль “результат, а не обещание” – но даёт видимость, которую ждёт I-профиль.

Три конфигурации – три типа боли

Характер трений кардинально меняется в зависимости от организационной структуры.

Равные по статусу – самая распространённая конфигурация. Трения вокруг приоритизации и видимости. Побеждает тот, у кого больше организационного веса – не тот, кто объективно прав. Внешнее давление на продуктового менеджера всегда громче внутреннего давления на платформенного – поэтому при прочих равных платформа проигрывает ресурсную борьбу.

Продуктовый менеджер управляет платформенным – структурно проблематичная конфигурация. Инстинкт продуктового менеджера – оптимизировать под результаты для пользователя. Платформенная работа, которая не обеспечивает конкретную фичу в ближайшем горизонте, ощущается как накладные расходы. Часто бессознательно. Проактивная архитектурная работа постоянно вытесняется, потому что не привязывается к целям этого квартала. Платформенный менеджер перестаёт поднимать вопросы техдолга – и долг молча растёт.

Платформенный менеджер управляет продуктовым – зеркальная проблема. Инстинкт платформенного менеджера – строить правильно, полно и надёжно. Продуктовый менеджер начинает писать более детальные спеки, проводить формальные процессы согласования. Время цикла растёт. Гипотезы проверяются медленнее. “Сделай правильно или не делай вообще” становится культурой – и убивает скорость итераций.

Наиболее чистое решение – ни один из двух типов менеджеров не управляет другим. Оба подчиняются руководителю, который понимает обе модели и удерживает напряжение осознанно. Как только один тип подчиняется другому – вы делаете ставку на то, что менеджер способен последовательно преодолевать собственные инстинкты. Это слишком высокая ставка.

Что это значит на практике

Конфликты между продуктовым и платформенным менеджерами – это не сигнал о плохих людях или плохом менеджменте. Это сигнал о плохо спроектированных интерфейсах между командами. И о том, что люди с разными поведенческими профилями по-разному обрабатывают одну и ту же информацию.

Когда продуктовый менеджер говорит “они тормозят” – скорее всего Влияние встречает Добросовестность. Что делать: попросить платформенного менеджера объяснить не “что сложно”, а “какой риск это несёт для продукта”.

Когда платформенный менеджер говорит “они не думают о последствиях” – скорее всего Добросовестность встречает Влияние. Что делать: попросить продуктового менеджера показать данные за решением, а не только энтузиазм.

Когда оба избегают конфликта и соглашаются на всё – оба имеют высокий S (Постоянство). Что делать: явный процесс приоритизации с внешним арбитром.

Это нужно принять. Конфликт между этими двумя типами – не баг, а фича кросс-функциональной организации. Задача руководителя – не выбрать победителя, а создать условия, где оба профиля дополняют, а не уничтожают друг друга.

Вопрос к вам: в вашей компании – кто побеждает по умолчанию? :)

Успевайте в срок!

Станислав