TGViewer
Сказки технического менеджера Сказки технического менеджера @tech_managers_tales · 446 subscribers
Post #23 444
Когда подчинение менеджеру это зло

Спойлер: всегда. Шучу.
На самом деле, какое-то подчинение в команде помогает, например, разделить ответственность - разработчик пишет код по ТЗ и не парится по поводу бизнес-целей фичи. Он просто доверяет менеджеру и делает то, о чём его просят. Все делают своё дело и все в выигрыше. Однако бывает и так, когда подчинение всё портит.

А портит всё оно тогда, когда от команды ожидается креативность и даётся большая степень свободы в принятии решений. Мол, вот вы команда, у вас есть всё, что нужно, мы не будем говорить вам ЧТО ИМЕННО делать, скажем только ЦЕЛИ, а дальше решайте сами. Пока-пока, ждём результатов! Такая модель хорошо зарекомендовала себя в т.н. "продуктовых" командах, которые имеют сами в себе всех нужных людей, чтобы добавить какую-то ценность в продукт. Например, новую фичу. Такой подход показал свою эффективность во многих компаниях в мире.

Так вот, про подчинение. Подчинение в таких командах может напрочь убивать те самые "креативность" и "свободу принятия решений". Там, где раньше менеджеру на очередную "супер идею" разработчики сказали бы, что это полная фигня - вырастает фильтр "а выгодно ли мне говорить что-то против?". Там, где QA мог тормознуть задачу сомнительного качества - он лишний раз подумает, не скажется ли это на его премии. Таким образом, подчинение может ухудшать итоговый результат. Структура команды вроде четкая, а вот конечная ценность пользователю наносится меньше из-за того, что создаётся почва для всяких компромиссов.

Так, а что делать то?
Если команда подходит под критерии о необходимости "креативности" и "свободы принятия решений", то у менеджера продукта не должно быть прямых подчиненных в команде. Разработчики должны быть подчинены руководителю разработчиков и так далее с каждой ролью. Менеджер должен управлять ими только в рамках функции команды и не принимать решений, влияющих на зарплаты и премии. В такой конфигурации в команде допускается продуктивный конфликт, когда никто не боится высказать своё мнение, даже если оно противоречит мнению менеджера. Менеджер не может просто "задавить" сотрудника своим словом, придётся более конструктивно и продуманно доказывать что делать и почему именно так. Зачастую, именно в таких конфликтах и рождается наиболее элегантное решение вопроса.
Конечно, это требует больше энергии со стороны менеджера, но что поделать - таков путь.
  • 👍 3
More from @tech_managers_tales
  1. Sep 16, 2026Готовлюсь сейчас к выступлению на Yandex Scale с провокационной темой доклада - "Мониторин…
  2. Aug 30, 2026Про личный опыт с Hermes Когда я прогуливаюсь вечерами и не только, у меня частенько возни…
  3. Aug 10, 2026Про еще один важный запуск Ой, совсем забыл поделиться, что с месяц назад был важный для м…
  4. Jul 20, 2026Саммари доклада с Infraconf 2026. Часть 2 про практику Продолжаю саммари доклада — теперь…
  5. Jul 2, 2026Саммари доклада с Infraconf 2026 Как обещал, публикую краткое содержание своего доклада "О…
  6. Jun 22, 2026Запись доклада с Infraconf 2026 Finally, готова запись моего доклада "Особенности observab…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →