Будничные вопросы ИТ в Еком и Маркетплейсах, клиентский путь и UX, digital tech, microservices от Digital CTO - Андреева Алексея (@MotoLeszek)
Канал личный - мой работодатель не имеет отношение к тому, что здесь публикуется.
Post #650
65
Поговорим про тему, с которой сталкивался почти каждый и не только в ИТ - микроменеджмент. Мое мнение простое: в ИТ ему не место вообще. Её годами подтверждают различные исследования DORA, но сегодня я специально поискал еще и тех, кто с этим спорит. Получилось интереснее, чем можно было ожидать.
Знакомые истории:
➡️ Статус в чатике каждые два часа.
➡️ Задача в трекере, расписанная до уровня "какую строчку поправить".
➡️ "Дай-ка я сам гляну в код".
➡️ Созвон, чтобы обсудить, почему не успели из-за созвона.
Почему в ИТ это особенно больно:
🖇Результат инженера почти всегда живёт в голове. Каждое "ну что там?" выбивает из контекста. А переключение контекста - 15 минут
🖇 Руководитель, через которого проходит каждое решение, становится самым дорогим узким горлышком в системе. Очередь на согласование растёт, lead time вместе с ней
🖇 Ответственность испаряется: команда переходит в режим "сказали - сделал" и перестаёт думать про последствия самостоятельно
🖇 Ошибки начинают прятать, и всплывают они потом инцидентом, обычно в пятницу вечером
🖇 Первыми уходят сильные. Остаются те, кому удобно, что за них думают
DORA прямо пишет: "high-trust, generative culture predicts software delivery and organizational performance". Google в Project Oxygen разбирал, чем лучшие менеджеры отличаются от остальных, и вторым пунктом в списке стоит "Empowers the team and does not micromanage". А HBR в статье про тревожного микроменеджера ловит главный парадокс таких руководителей: "I want you to take total leadership on this project - just make sure you run everything by me first"
Теперь по противоположному взгляду на вещи - Пол Грэм в статье "Founder Mode" пишет про Брайана Чески из Airbnb, который последовал классическому совету "hire good people and give them room to do their jobs", и, по словам Грэма, кончилось это плохо. После чего Чески переключился на подход, подсмотренный у Джобса, с погружением в детали и встречами через голову руководителей. Грэм пишет, что без такого погружения легко "hire professional fakers and let them drive the company into the ground". HBR в одной из статей пишет: "живая помощь руководителя повышает результат, если человеку она нужна и пришла вовремя". Ну и классика от Энди Гроува: плотность контроля должна зависеть от зрелости человека в конкретной задаче.
Если вчитаться, то микроменеджмент никто из них не защищает. Грэм пишет про основателя, который должен знать продукт лучше всех и не прятаться за оргструктурой. HBR - про помощь, которую человек сам готов принять. Гроув - про новичка, которого ведут плотнее, пока он не вырос. Погружение в детали и микроменеджмент - разные вещи: первое про понимание продукта, второе про недоверие к людям. И founder mode моментально превращается в микроменеджмент, когда его включает не основатель, а руководитель среднего звена с той самой тревожностью из HBR.
Мой взгляд на нормальный менеджмент в ИТ:
🖇 Цель и критерии готовности, DOR/DOD на берегу
🖇 Рамки и guardrails: архитектурные принципы, бюджет, SLA, требования ИБ
🖇 Прозрачность через артефакты, метрики и демо. Без допросов
🖇 Плотное сопровождение по Гроуву: для новичка в задаче или во время пожара на проде, и временно
В общем надо управлять результатом и рамками, а не руками инженеров. Микроменеджмент это налог на недоверие, и платит его вся команда скоростью, качеством и людьми. С приходом ИИ-агентов инженеру надо самому ставить им задачи и проверять результат и без самостоятельности тут дальше не уехать. Если руководителю не хватает уверенности в команде, лечить надо найм, цели и прозрачность, а не частоту статусов.
Больше интересных новостей об ИИ, ритейле, екоме и маркетплейсах 👉 Подписаться на канал
#управление #HR #мотивация #agile #мнения
Знакомые истории:
➡️ Статус в чатике каждые два часа.
➡️ Задача в трекере, расписанная до уровня "какую строчку поправить".
➡️ "Дай-ка я сам гляну в код".
➡️ Созвон, чтобы обсудить, почему не успели из-за созвона.
Почему в ИТ это особенно больно:
🖇Результат инженера почти всегда живёт в голове. Каждое "ну что там?" выбивает из контекста. А переключение контекста - 15 минут
🖇 Руководитель, через которого проходит каждое решение, становится самым дорогим узким горлышком в системе. Очередь на согласование растёт, lead time вместе с ней
🖇 Ответственность испаряется: команда переходит в режим "сказали - сделал" и перестаёт думать про последствия самостоятельно
🖇 Ошибки начинают прятать, и всплывают они потом инцидентом, обычно в пятницу вечером
🖇 Первыми уходят сильные. Остаются те, кому удобно, что за них думают
DORA прямо пишет: "high-trust, generative culture predicts software delivery and organizational performance". Google в Project Oxygen разбирал, чем лучшие менеджеры отличаются от остальных, и вторым пунктом в списке стоит "Empowers the team and does not micromanage". А HBR в статье про тревожного микроменеджера ловит главный парадокс таких руководителей: "I want you to take total leadership on this project - just make sure you run everything by me first"
Теперь по противоположному взгляду на вещи - Пол Грэм в статье "Founder Mode" пишет про Брайана Чески из Airbnb, который последовал классическому совету "hire good people and give them room to do their jobs", и, по словам Грэма, кончилось это плохо. После чего Чески переключился на подход, подсмотренный у Джобса, с погружением в детали и встречами через голову руководителей. Грэм пишет, что без такого погружения легко "hire professional fakers and let them drive the company into the ground". HBR в одной из статей пишет: "живая помощь руководителя повышает результат, если человеку она нужна и пришла вовремя". Ну и классика от Энди Гроува: плотность контроля должна зависеть от зрелости человека в конкретной задаче.
Если вчитаться, то микроменеджмент никто из них не защищает. Грэм пишет про основателя, который должен знать продукт лучше всех и не прятаться за оргструктурой. HBR - про помощь, которую человек сам готов принять. Гроув - про новичка, которого ведут плотнее, пока он не вырос. Погружение в детали и микроменеджмент - разные вещи: первое про понимание продукта, второе про недоверие к людям. И founder mode моментально превращается в микроменеджмент, когда его включает не основатель, а руководитель среднего звена с той самой тревожностью из HBR.
Мой взгляд на нормальный менеджмент в ИТ:
🖇 Цель и критерии готовности, DOR/DOD на берегу
🖇 Рамки и guardrails: архитектурные принципы, бюджет, SLA, требования ИБ
🖇 Прозрачность через артефакты, метрики и демо. Без допросов
🖇 Плотное сопровождение по Гроуву: для новичка в задаче или во время пожара на проде, и временно
В общем надо управлять результатом и рамками, а не руками инженеров. Микроменеджмент это налог на недоверие, и платит его вся команда скоростью, качеством и людьми. С приходом ИИ-агентов инженеру надо самому ставить им задачи и проверять результат и без самостоятельности тут дальше не уехать. Если руководителю не хватает уверенности в команде, лечить надо найм, цели и прозрачность, а не частоту статусов.
Больше интересных новостей об ИИ, ритейле, екоме и маркетплейсах 👉 Подписаться на канал
#управление #HR #мотивация #agile #мнения
- 👍 3


