Comments 29
Я под начальством микроменеджера менеджеров работаю. Всё так. Нижестоящие руководители деградируют, а управление всё хуже и хуже. Он изо всех сил пытается это компенсировать еще большим микроменеджерством, но почему-то это имеет обратный эффект
Уволился с последнего места работы из-за постепенного перехода с нормального режима работы на микромененджмент. Это жесть!!! После увольнения еще неделю приходил в себя.
Это к сожалению так не работает. Если вы способны так себя вести без вреда для своего психического состояния то значит вам и микроменеджмент не страшен. Проблемы у тех людей для которых возможность принимать свои решения важна и влиять на решения окружающих важны. Ну и не только это, наверное, вообще возможность чувствовать себя взрослым человеком а не ребенком в детском саду которому говорят когда какать а когда кушать.
Микроменеджер — человек не на своем месте, занявший слишком высокое для себя место. Из-за этого он просто не умеет мыслить по менеджерски абстрактно, и просто бегает за всеми и пытается сделать работу за них.
Теперь я знаю, что внедряют в нашей конторе. Это слово не произносят, но введение тотального контроля - некоторых коллег уже обязали каждый день заполнять отчёты, что они делали, и отчитываться на каждую открытую страницу в браузере; внедрение выученной беспомощности - когда тебя за попытку решить проблему быстрее, потому что ты знаешь как, бьют по рукам "вы нарушаете бизнеспроцесс", нажать эту кнопочку имеют право только "специального обученные люди" и т.д. и т.п.,это очень "мотивирует". А потом люди уходят целыми отделами и начинается хаос.
А я один раз в жизни делал микроменеджмент будучи тимлидом...
Один из подчиненных (бог баз данных с 20-летним опытом) по любому чиху отправлял на клиента HTTP 500 и в результате было невозможно выяснить, в каком классе и даже в каком модуле произошла ошибка.
Не помогло ни объяснение что http-состояния тоже делятся на группы и какое состояние в каком случае было бы адекватно использовать, ни притягивание за уши OSI-модели — ничего. Он считал что тут нечего рассусоливать и в случае чего он быстро найдет причину.
И находил! И быстро находил! Пока не ушел на больничный... В конце концов я сдался и персональным приказом обязал его использовать только HTTP 400 и обязательно с трансляцией номера строки, где вызвалось исключение.
Я надеялся позднее сесть вместе с ним, разобрать каждое исключение и раскидать их по соответствующим состояниям, но из-за "давай-давай" со стороны дирекции этого так и не произошло :(
Это не микро-менеджмент, это менеджмент здорового человека. Вы исправили ошибку вашего подчиненного, а не на ступеньку ниже по иерархии. И исправили не просто так — это реально могло помешать в работе.
Он делал все правильно. Если в приложении возник exception, то это и должно быть 500. Просто в этом случае в продакшене детали exception должны писаться в лог, а в девелопменте еще и возвращаться на клиента в теле ответа. А 400 это вообще про другое.
Исключение может возникнуть по очень разным причинам. Причины эти сгруппированы логически и хорошо расписаны здесь. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
Поинтересуйтесь на досуге.
Т.е., по-вашему это нормально при недоступности БД вернуть клиенту 400? Я уже писал в тут в другом месте "исключение" это именно исключительная ситуация, которая никак не может быть нормально обработана приложением. Если исключение возникает в результате, допустим, ошибочного пользовательского ввода, то это с самого начала неправильно — такой ввод должен быть проверен и отфильтрован еще до того, как это исключение возникает. Бывает, конечно, технически такая ситуация когда что-то проверить можно только что-то вызвав и получив либо результат, либо исключение. В таком случае это исключение надо перехватывать как можно раньше (лучше всего при самом вызове) и возвращать вызывающему коду ошибку каким-либо другим способом (паттерн "try-out", какой-нибудь объект наподобие "ErrorResult", код ошибки в конце концов). "Наверх" приложения исключение должно попадать, по сути, только в двух случаях — системный сбой (например, нехватка памяти, недоступность БД или внешнего сервиса) либо ошибки в коде самого приложения (например, вызвали что-то что нельзя с null).
Исключительно ИМХО. Может быть нужно было поставить задачу - быстрая диагностика ошибок любыми разработчиками (уменьшение bus factor), а не делай код ошибки как я сказал. Просто тоже совсем недавно столкнулся с требованиями от высоко стоящего менеджмента, касающиеся логирования, которые ни к чему хорошему не привели. Так как снизу гораздо лучше видно как искать и исправлять ошибки.
Спасибо за хорошо структурированную статью. Суть и причина проблемы хорошо раскрыты, материалы тоже годные.
(Не)много критики.
Если вы нашли в себе черты микроменеджера и вам страшно или не хочется делегировать, то вы должны помнить: вы не можете всё досконально знать за всех, если только у вас не огромная голова, как у Мегамозга, и нет маховика времени, как у Гермионы. Сто процентов, что вы не будете достаточно компетентны и не сможете физически всё успевать делать за всех.
Вы считаете, что человеку с серьезной психологической проблемой и годами выработанным неэффективным паттерном решения этой проблемы достаточно такого легкого внушения, чтобы "раскаяться и стать на путь истинный"?
Боюсь, что истинные микроменеджеры вас не услышат, а без этого не ясна цель, с которой была написана заметка. Кто целевая аудитория и зачем было все это писать?
Спасибо за отзыв и критику!
Целевая аудитория была разная:
1. Те, кого микроменеджерят. Чтобы они лучше поняли что происходит и "занесли" почитать/посмотреть материал руководителям.
2. Руководители. Чтобы хотя бы попробовали провести самодиагностику.
3. Будущее руководители. Чтобы были предупреждены как лучше не делать.
4. Бизнес. Чтобы лишний раз задумался что там на уровне руководства у него делается. В докладе я привел пример как владелец не задумывался долгое время, а потом пришлось частью бизнеса поделиться.
С одной стороны я считаю вполне справедливым и оправданным замечание, что люди из категории 2 не все смогут признать проблему.
С другой стороны после доклада ко мне многие подходили и говорили "спасибо, я посмотрел доклад, подумал, и, похоже, я кое в чем микроменеджерю". Если удалось достучаться хотя бы до кого-то из какой-то категории – я считаю, что уже потрудился не зря.
Занимаюсь микроменеджментом. С удовольствием этого бы не делал, но команда такая как есть и изменить ее возможности нет.
Ждем продолжение под названием "Микросервис - горе в проекте"
Напрашивается ассоциация с детной семьей) Она промелькнула в примере про велосипед, но реально совпадений гораздо больше.
Кстати, родитель, когда, допустим, микроуправленчески пинает своего отпрыска по поводу уроков, и сам очень сильно стрессует.
В теме микроменеджмента очень важно обсудить понятие выученной беспомощности.
Которой не существует. Простое объяснение и исходная статья. Там вообще всё сильно сложнее, нейронауки всё это время не стояли на месте.
Проблема не в том, что команда становится беспомощной, проблема в том, что команда отключает мозг т.к. всё равно сверху будет дан приказ, а пока и поспать можно.
С точки зрения адаптировавшегося специалиста под микроменеджером он прекрасно умеет справляться с задачами. Начальство сказало копать - копаю, не сказало - не копаю. Платят хорошо, в свободное время делай что дозволено, ответственности ноль, а думает пусть тот, кому за это платят. Проблемы бизнеса - не проблемы сотрудника (а то, что бизнес готов выделять долю такому микроменеджеру - ну так, может не микроменеджер здесь дурак?).
С точки зрения других менеджеров, на том же уровне иерархии или выше проблем тоже нет: работа работается, задачи закрываются, микроменеджер весь в поте бегает - хорошо работает.
Итого недовольных стороны потенциально всего две - высшее начальство, для которого такой менеджмент это риск, но локально удобен и творческие специалисты, которые не могут действовать по указке, но и уволить начальника тоже не могут.
Для кого статья-то в итоге? Пока больше кажется советом микроменеджеру как обойти все подводные камни и выпросить себе долю в бизнесе.
Спасибо за пояснение про выученную беспомощность. Интересно было узнать, что исследования двинулись дальше.
Тем не менее на общую канву происходящего это не влияет. В приведенных вами статьях объясняется, что пассивность - это естественное состояние и вывести из него может ощущение контроля, подтвержденное на практике. Именно этого микроменеджмент и не дает делать людям.
По поводу того, для кого статья - я сформулировал в комментарии выше https://habr.com/ru/companies/oleg-bunin/articles/744104/comments/#comment_25709946
Видимо я неправ, но что-то не увидел отрицательных сторон, для исполнителя.
Допустим для работы мечты, когда прям фан работать, верно, что это вредно.
Но для обычной работы, нормальный вариант.
Просто выполнять (в разумных рамках конечно), то что требует работодатель (менеджер) и получать з/п.
А все сэкономленные ресурсы (нервные/умственные), тратить на собственные проекты или самообразование.
Имхо, профитно.
Если Вас заставляют плавать в спасательном жилете, то через некоторое время, когда Вы смените работу или сменится труководитель, Вас бросят в воду без жилета и Вы станете тонуть
Если вы менеджер среднего звена, то всё плохо, на самом деле. В вашу работу непрерывно вмешиваются, и вам все время прилетает за то, что делаете все не так. А как только вы начинаете тупо выполнять указания (с ожидаемым результатом - все разваливается, потому что ваш руками водитель мягко говоря неоперативен и не владеет информацией, ибо нельзя объять необъятное), вас наказывают за то, что всё управление разваливается, потому что "вы совсем не в состоянии работать? Я что, постоянно за вас думать должен? Для чего вы тогда на этом месте?" Цитата подлинная.
Поделюсь и своей болью.
На паре прошлых мест работы микроменеджерам приходила в голову гениальная идея, чтобы все переписки велись только в общих чатах. И речь была не только о каких-то серьёзных вопросах, а вообще обо всех. То есть нельзя было даже написать в личку QA, что задача готова к тестированию, либо написать в личку front-end разработчику контракт API.
Мало того, что это было психологически некомфортно, так ещё и замусоривало чат для всех, кроме довольного микроменеджера
Есть проблема, о которой не говорят, либо делают это редко. Считается, что если больше доверять сотрудникам и развивать их, они будут больше брать на себя и развиваться.
Но в IT в том числе многие сотрудники желают быть в детской позиции: мол, вы нам скажите, как делать правильно, а то у нас лапки. И это далеко не джуны. Они могут заваливать первое, второе, десятое самостоятельное задание, а тебе отвечать за результат, и ты невольно начинаешь их микроменеджерить
Микроменеджер — горе в команде