GreenCore 
Тендеры и лиды
Информация
Если спросить любого CTO или руководителя разработки, считает ли он микроменеджмент проблемой, ответ почти всегда будет очевидным. Конечно, это плохо. Конечно, это снижает мотивацию. Конечно, это мешает команде.
Но дальше начинается самое интересное.
Те же самые компании, которые на словах борются с микроменеджментом, на практике выстраивают процессы, в которых он становится нормой. Через контроль задач, ежедневные статусы, обязательные синки, ручное согласование решений и постоянную проверку «а точно ли всё идёт по плану».
И в этот момент микроменеджмент перестаёт быть управленческой ошибкой. Он становится частью операционной модели. Проблема в том, что его РЕАЛЬНАЯ стоимость почти никогда не считается!
С точки зрения менеджмента микроменеджмент выглядит логично.
Есть риски → нужен контроль. Есть сроки → нужно давление. Есть неопределённость → нужно больше прозрачности.
На короткой дистанции это действительно работает. Команда становится более управляемой, задачи двигаются, ошибки быстрее обнаруживаются, что, соответственно, сильно притупляет внимание руководящего звена. За ширмой эффектинвости очевидных проблем не замечает никто, прайс — в том числе.
Исследования Harvard Business Review показывают, что избыточный контроль снижает продуктивность сотрудников за счёт падения автономии и вовлечённости. И соль здесь в том, что эффект от микроменеджмента — краткосрочный, а его стоимость — накопительная.
Если убрать абстрактные разговоры про «мотивацию» и «культуру», микроменеджмент имеет вполне конкретные финансовые последствия.
Во-первых, падает скорость принятия решений. Любое действие требует согласования. Любая инициатива проходит через фильтр менеджера. Это незаметно на уровне одной задачи, но критично на уровне системы. Команда начинает двигаться не со своей скоростью, а со скоростью самого узкого горлышка.
Во-вторых, растёт скрытая стоимость времени. Каждый дополнительный созвон, каждая проверка, каждый промежуточный статус — это время, которое не тратится на разработку.
По данным Atlassian, сотрудники тратят до 30–40% рабочего времени на встречи и коммуникации, значительная часть которых не создаёт прямой ценности. В инженерных командах это особенно болезненно. Потому что разработка требует фокуса. И каждый разрыв внимания снижает эффективность.
На рынке РФ микроменеджмент имеет дополнительные причины.
Во-первых, высокая неопределённость. Проекты часто стартуют с размытыми требованиями, сроки сжаты, бизнес-ожидания завышены. В такой среде контроль кажется единственным способом удержать ситуацию.
Во-вторых, дефицит управленческой зрелости. Многие тимлиды и руководители выросли из сильных инженеров, но не прошли полноценную трансформацию в менеджеров. В результате управление подменяется контролем.
В-третьих, недоверие как системный фактор. Исторически в российских компаниях уровень доверия ниже, чем в западных. Это отражается и на IT-командах: менеджеры чаще стремятся «проверить», чем «делегировать».
Есть важный эффект, который редко обсуждают напрямую. Микроменеджмент почти не влияет на слабых специалистов. Они и так требуют контроля... но он критически влияет на сильных!
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13470 тендеров
проведено за восемь лет работы нашего сайта.
Сильный инженер ценит автономию. Возможность принимать решения, влиять на продукт, работать без постоянного давления. Когда этого нет, происходит простая вещь: он либо снижает вовлечённость, либо уходит.
Исследования Gallup показывают, что низкая вовлечённость напрямую связана с качеством управления и уровнем автономии сотрудников. И это уже не про культуру, а про деньги непосредственно.
Потому что потеря сильных инженеров — одна из самых дорогих ошибок в IT. Самое интересное начинается, когда микроменеджмент доходит до уровня продукта: замедляются релизы, увеличивается time-to-market, растёт стоимость разработки.
И в какой-то момент компания начинает проигрывать не потому, что у неё плохая технология, а потому, что она попросту не успевает. Добавьте сюда довольно жесткие условияя конкурентного рынка и получите острый крит, очевидно.
Исследования McKinsey & Company подтверждают, что скорость вывода продуктов на рынок напрямую влияет на рост бизнеса. Микроменеджмент же эту скорость системно снижает.
В практике GreenCore микроменеджмент чаще всего проявляется не напрямую, а через симптомы. Команда вроде бы работает, задачи — закрываются, но при всём этом великолепии сроки сдвигаются (ну, мы стараемся минимизировать). Перегруз ощущается, а результата — нет.
Если мы начинаем это замечать, то не бросаемся «учить менеджеров», а пытаемся провести анализ «потоковой» работы:
И почти всегда выясняется, что значительная часть времени команды уходит не на создание продукта, а на обслуживание системы контроля. И тут мы в GreenCore осозанем: проблема не в людях, а в модели управления. Чем раньше, тем лучше...
Микроменеджмент редко возникает из желания «всё контролировать», а скорее вырастает из страха. Страха не уложиться в сроки. Страха допустить ошибку. Страха потерять контроль над процессом. Парадокс в том, что попытка снизить риски приводит к их росту.
Потому что система становится медленнее, менее гибкой и менее устойчивой. Скрытая стоимость микроменеджмента — это не про атмосферу в команде, а финансовую составляющую процесса скорее. По факту — снижается скорость, затраты — растут, команда потихоньку, но разочаровывается в проетке, разваливается.
Не жёсткий контроль делает команду сильной, а грамотное управление, направленное на минимизацию простоев с четким распределением зон ответственности внутри команды. В IT главный ресурс — это не часы работы, а способность команды самостоятельно двигаться вперёд без постоянного внешнего давления.
Ну, во всяком случае, мы так счмитаем.
Это способность команды самостоятельно двигаться вперёд без постоянного внешнего давления.
Потому что в IT главный ресурс — это не часы работы.
