Что делать, если в команду пришел «эффективный» менеджер? Выявляем и обезвреживаем его в себе и коллегах

Любая работа полна сюрпризов. Сложности и нестандартные ситуации могут возникнуть в любой момент, даже там, где, казалось бы, каждый шаг пройден уже сотню раз и откуда их совершенно не ждешь.

В статье нашей студентки Ангелины, Product / Project Lead в Trood «Что делать, если в вашей команде появился «эффективный» менеджер?» описана жизнь продуктовой команды на протяжении полугода, где подробно показаны этапы противостояния процессного подхода и архаичного руководства.

Мы задали Ангелине пару вопросов и она поделилась с нами инсайтами по выявлению «эффективного» менеджера ещё на собеседовании, коммуникации внутри команды в стрессовое время, а также рассказала, как не бросить все на полпути.

— Конечно! Иногда таких менеджеров видно издалека, и от них нужно держаться как можно дальше. На мой взгляд, «эффективный» менеджер — это руководитель, который постоянно что-то требует от команды, при этом не помогая ей ничем, а возможно даже разрушая ее экосистему. Вообще, основная ценность менеджера в команде — это помогать в достижении поставленных целей. Если ты, как менеджер, этого не делаешь, зачем ты ей такой нужен?

За довольно большой срок работы в менеджменте, у меня получилось сформулировать ряд отличительных черт «эффективных» менеджеров:

• Когда у менеджера спрашиваешь, где план проекта, а он отвечает, цитата: «План в голове».
• Менеджер уверен, что знает лучше специалиста, как реализовать фичу и навязывает это решение.
  
• Менеджер ставит заведомо нереальные сроки сдачи фич.
  
• Менеджер не хочет вдаваться в подробности реализации своего продукта. «Я не должен разбираться, я должен руководить». Что при этом входит в понятие «руководить», история умалчивает.
  
• Менеджер устраивает трехчасовые созвоны с участием всей команды.
  
• Менеджер позволяет себе высокомерно относиться к команде.
  

Если вы видите подобные качества в себе или коллегах, у меня для вас плохие новости. К сожалению, это не анекдоты, не теория, это реальные рабочие ситуации, которые имеют место быть, и с ними нужно бороться.

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

Сложность состоит в том, что в режиме эмоционального давления в целом падает мотивация работать. Кто-то начинает защищаться и ставить свои ультиматумы. Человек начинает думать о защите своих базовых потребностей, а не об успехе продукта. Здесь начинается порочный круг: на команду давят, команда показывает результаты хуже, «эффективный» менеджер давит еще сильнее, результаты еще хуже.

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

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

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

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

И последняя рекомендация для продактов — старайтесь абстрагироваться от своего продукта.

Успех или неуспех продукта — это не ваше личное поражение или победа, это ваш опыт. Негативный опыт иногда ценнее позитивного, не забывайте об этом.

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

Для себя я четко осознавала пользу, которую я приобретаю, работая над этим продуктом и в этой команде:

• Для меня это был первый опыт построения B2C продукта с проектированием полной обслуживающей инфраструктуры, которую требовала специфика продукта.
• Я первый раз работала над нативным мобильным приложением, что тоже несло очень много новых инсайтов.
  
• Хорошие предпосылки и возможности для выпуска приложения и работы с ранними пользователями.
• Смешение и заимствование лучших практик топовых IT-компаний. Так как все ребята были из разных компаний, обмен опытом и видением по построению командной работы был уникальным. Все-таки, когда ты годами работаешь в одной компании, ты привыкаешь к одним паттернам, а что-то вообще начинаешь воспринимать как должное.
  
• Получилось поработать с новыми инструментами проектного управления и выстроить в них прозрачные процессы, где было удобно работать и техническим специалистам, и представителям бизнеса.

Несмотря на все сложности и нервы, которые возникали в ходе работы, фокус на получение опыта давал силы продолжать развиваться и развивать продукт.

— Да, предпосылки нездоровых процессов и коммуникации можно выявить уже на собеседовании. Задавайте больше вопросов об организации работы, структуре распределения обязанностей, ответственности, процессах планирования и достижения KPI. Здесь уже можно услышать звоночки, описанные мною выше, присущие «эффективному» менеджменту.

Также, внимательно слушайте вопросы, которые вам задают. Часто они исходят из реальных ситуаций в компании.

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

Еще один кейс, который меня очень «порадовал» несколько лет назад, когда я собеседовалась на бизнес-аналитика, у меня спросили: «Умеете ли вы программировать на языках JavaScript и Python?». Это явно не относится к навыкам бизнес-аналитика.

На встречный вопрос, для чего в данной компании бизнес-аналитику нужны такие навыки, я получила ответ: «Бизнес-аналитик должен уметь исправлять баги в коде, чтобы не отвлекать разработчиков от основных задач». Кажется очевидным, что в компании большие проблемы с пониманием процессов разработки ПО, тестированием и поддержкой. Лучше избегать работы в таких компаниях.

Если вам понравилась данная статья, то предлагаем вам ознакомиться с нашим недавним интервью с Владимиром Миролюбовым, автором телеграм-канала Product Management. Даже если вы не продакт, то в этой статье вы найдете для себя много полезного и мотивирующего 👇