Отжиматься за опоздания, начинать строчки с заглавной буквы, присылать селфи с рабочего места и получать +50$ к зарплате за общение на английском без Google Переводчика — наши герои поделились историями, после которых вам захочется расцеловать своих либеральных менеджеров.
Среди методов управления командой много дискуссионных, но микроменеджмент — практика, которая бесит практически всех без исключения. Мы полистали соцсети и поговорили с айтишниками: выяснили, какие руководители склонны к микроменеджменту, когда он однозначно вреден, а когда бывает необходим. А еще собрали истории пострадавших от микроменеджеров — на случай если вам нужны пруфы, что ежечасные отчеты не доводят до добра.
Своим опытом и мнением поделились:
- Алексей Мигутский — старший инженер в Microsoft;
- Ник Ягодин — продуктовый дизайнер в TRADE X;
- Саша Бло — директор продукта;
- Павел Романов — senior software engineer в американской компании, занимающейся частной авиацией, в прошлом руководитель направления в foodtech-компании.
Содержание
Что такое микроменеджмент и чем он плох
Микроменеджмент — интуитивно понятный термин: вмешательство менеджера в работу подчиненных по мелочам. И это всегда проблема. Во-первых, потому что зачастую менеджер слабо разбирается в чужом поле деятельности —едва ли гуманитарий подскажет технарю-программисту, как лучше кодить. А во-вторых, даже если замечания дельные, трудно работать, когда у тебя стоят над душой. Тайм-трекеры действуют на нервы, а лишняя отчетность и вовсе съедает рабочее время.
Микроменеджмент обычно не несет практической пользы для результата работы, но тратить силы подчиненных.
«писать на код» — это не то, что вы подумали, это опечатка
— Кадровый Пылесос (@kadrov_pylesos) November 7, 2022
Требования микроменеджеров могут варьироваться — от совсем фантастических и бредовых до относительно адекватных. Но работать в условиях постоянного контроля все равно сложно. Особенно айтишникам, которые занимаются по-своему творческой работой. Когда программист размышляет над задачей, время на эти размышления трудно вписать в тайм-трекер, а результаты — не всегда получается объяснить в отчете.
Есть тип людей, которые любят, когда им по шагам рассказывают, что нужно делать, и после каждого шага дают фидбек. Это своего рода подсознательное перекладывание ответственности. Правда, таких людей в программировании мало, так что микроменеджмент не пользуется популярностью.
Обычно микроменеджмент просто избыточен и никому не удобен. А иногда — нарушает неприкосновенность частной жизни. Многие айтишники работают на улаленке, зачастую без строго фиксированного рабочего графика — они привыкли сами планировать и работу, и личные дела. Такой ситуацией поделилась пользовательница Twitter, работающая по гибкому графику:
Ааааааааааааааааа почему моя новая лид хочет чтобы я согласовывала с ней походы к врачу, а предыдущей было просто достаточно уведомления в общем календаре, бля я хочу уволиться прямо сейчас, если бы я была достаточно смелой я бы так и сделала
— кофевино (@z_nuts) September 27, 2022
Истории, после которых обычно увольняются
Для большинства программистов, дизайнеров и спецов в смежных сферах микроменеджмент — красный флаг. Завидев его, сотрудник либо сразу увольняется, либо решает потерпеть, выгорает, и увольняется чуть позже.
Сектантские ритуалы по письменным инструкциям
В некоторых компаниях практики микроменеджмента буквально напоминают то ли сектантство, то ли садомазохизм. Эпичными правилами поделился пользователь Twitter Евгений Урбановский:
Был список принципов, всех не помню, док не сохранился (так бы приложил), но за любую ложь (включая случайно ошибки типа сделаю за 5 минут, а сделал за 10) — штраф в виде отжимания, а потом написать в общем чате за это СПАСИБО
— Евгений Урбановский (@eurbanovskiy) July 3, 2022
Помимо отжиманий в этой компании еще было много странных требований.
Первое правило секты — утром в чат скинуть фотку своего заспанного еблета
— Евгений Урбановский (@eurbanovskiy) July 3, 2022
Второе правило секты — выложить фотку заспанного еблета вечером и написать сколько часов отработал
Ритуал с обменом селфи утром и вечером у них письменно зафиксирован в инструкции. Там еще много интересного: например, рекомендация составлять план работы и отправлять его руководителю рано утром до начала рабочего дня. Выходит, планированием работник должен заниматься в свое личное время.
Чтобы сотрудники точно не ошиблись в своем планировании, инструкция снабжена примерами хорошего и плохого плана и отчетности:
Помимо составления таких прекрасных инструкций микроменеджеры, кажется, обладают еще одной суперсилой — читают мысли. И наказывают за них. Тот же пользователь писал, что его лишили части зарплаты за «скучающий вид» на созвоне.
Один раз мне не выплатили за 2 часа, потому что тимлид увидел, как я облокотился лицом на руку на созвоне и он обиделся, что мне скучно, он спросил знаю ли что значит мой жест?
— Евгений Урбановский (@eurbanovskiy) July 3, 2022
Потом меня уволили под предлогом «ты не справляешься, извини, но у нас тут бизнес» ©
В компании был еще один ритуал: рассказывать, кто сколько часов проработал и аплодировать. Не то что бы сверхурочная занятость ценилась и поощрялась — скорее работа «от звонка до звонка» порицалась.
А в общем чате компании все писали «отработал 12-16 часов»(я не шучу!) и все хлопают в ладоши, и как бы ты потом испытываешь чувство вины, что поработал скромные 11 + выходные по 8, ведь остальные такие крутые специалисты…
— Евгений Урбановский (@eurbanovskiy) July 3, 2022
Работа под чужим именем на несуществующую студию
Продуктовый дизайнер Николай Ягодин рассказал нам необычную историю со своего первого места работы.
Моя первая работа в дизайне была в большом американском продукте, который помогает заполнять и отправлять налоговые декларации в США. Я должен был оптимизировать процессы и упрощать интерфейс. Но есть нюанс: я работал под именем другого человека — фриланс-дизайнера Игоря.
Игорь в эту компанию устроился, работал-работал, а потом в один момент понял, что ему не хватает рук. Так он нанял меня, чтобы я работал за него, а он мог брать новые проекты. То есть я не ходил на звонки, а писал сценарии для возможных веток на звонке. Стоял сзади и махал руками. Был в наушнике на звонках. Подсказывал. Короче, жесть.
В целом, на фрилансе подобные ситуации нередки: опытные исполнители находят себе субподрядчиков. Но у фрилансера-начальника из этой истории были амбиции на построение собственной компании — но только без делегирования.
Параллельно Игорь решил, что хочет продавать себя как дизайн-студию. Он долго не мог определиться: то мы студия, то продуктовая команда, агенство, аутстафф, аутсорс. Каждый месяц менялся фокус. Сегодня нужно проектировать шоты на русском, а завтра — на английском. Сегодня позиционируем себя как подрядчик для госсектора, завтра — ищем западных клиентов на фрилансе. Это очень мешало.
Я старался сфокусироваться на развитии продукта. Пока он растет, клиент доволен Игорем, Игорь доволен мной, у меня растет зарплата. Но плюс к этому меня заставляли принимать участие в брейнштормах идей для развития студии — на которую мне, по сути, было плевать. Был парадокс: Игорь хотел студию, но проекты заходили на его имя — клиенты к нему обращались как к фрилансеру. Он боялся «делить» эту свою экспертность с другими и от имени студии искать клиентов не хотел. Разве что иногда заказчики приходили на имя его девушки, которая хорошо знала английский, но работала фултайм в другой компании.
Впрочем, героя истории, Игоря, в полной мере назвать микроменеджером нельзя: в одних вопросах он боялся делегировать, а в других делал это легко. Например, он не хотел сам заниматься наймом и поручал это другим.
Когда мы нанимали новых ребят, Игорь в последний момент куда-то уезжал, чтобы с ними не возиться. Было так:
— К нам с понедельника выйдет новый мальчик, Андрей. Поможешь ему освоиться?
— Да окей. На какой он проект пойдет?
— Не знаю, еще не решил. Скорей всего на твой, так как я улетаю на Бали, тебе с ним заниматься.
— Блин, я хз вообще, как работать со стажерами.
— Ну давай им задачи, разберетесь сами!
Полное отсутствие инструкций и конкретики — другая крайность, в которую могут впадать руководители. Это, впрочем, не противоречит микроменеджменту. Управленец может сначала отдать все на откуп подчиненным без пояснений, потом ужаснуться, что все идет не гладко, начать писать пошаговые инструкции и требовать отчеты.
В зарождающейся студии, в которой работал Николай, спорных правил было достаточно. Например, сотруднику выдавали единоразовый бонус 50$, если он показывал чек об оплате курсов английского и редко использовал Google Переводчик. Эти критерии оценки тоже были письменно зафиксированы, как и критерии оценки дизайн-скилов.
Всего инструкций было 7: по разным видам отчетов, тайм-трекингу. И вишенка на торте — просто «Еще одна инструкция»:
Намеренно испорченный код, который «чинил» стажер
Алексей Мигутский написал большой тред, в котором рассказал, как стажировался в EPAM. После кризиса 2008 года там прошла волна увольнений, и его направили в один из проектов на место ушедшего сотрудника. Задача: разобраться, почему новая версия WSDL сервиса не работает у заказчика. Менеджер сказал, что это должно занять максимум пару недель. Но у стажера ушло две недели только чтобы понять, что такое WSDL и как все там должно работать. И, поскольку заявленные сроки были сорваны, менеджер решил помикроменеджерить.
Как выглядела «ситуация под контролем»: в конце каждого дня мне нужно было писать письмо менеджеру, в котором я должен был расписывать чем я занимался КАЖДЫЕ ПОЛ ЧАСА. Со всеми ссылками и деталями. Чо делал, чо читал, с кем общался.
— Лёха даёт непрошенные советы 🧐 (@mr_mig_by) February 12, 2022
И он, сука такая, это реально читал, и раз в неделю ебал мне мозги в одностороннем порядке на тему «как хуево и медленно ты работаешь, так нельзя».
— Лёха даёт непрошенные советы 🧐 (@mr_mig_by) February 12, 2022
По ходу дела выяснилось, что коллеги по проекту вообще не были в курсе, что я студент, который работает на пол ставки за бесплатно. И стучали начальству на тему «а хули он не работает как все по 10 часов?»
— Лёха даёт непрошенные советы 🧐 (@mr_mig_by) February 12, 2022
В таком режиме я проработал еще почти 2 месяца.
— Лёха даёт непрошенные советы 🧐 (@mr_mig_by) February 12, 2022
Последние две недели я не писал никаких отчетов — я написал своему менеджеру, что он может «идти нахер со своими требованиями, я вообще студент, ничем не обязан». Первый опыт отстаивания своих границ!
К этому моменту я уже знал, что хлопну дверью и буду уходить.
— Лёха даёт непрошенные советы 🧐 (@mr_mig_by) February 12, 2022
Потому что нахера мне такой цирк, да еще и за свой счет? Теплый офис и халявный чай этого не стоят. А ценный опыт я уже получил сполна.
Я реально отчитывался за каждые полчаса работы. Прикол был еще и в том, что у меня была задача, которую никто не понимал. Передо мной уволили человека, который ей занимался полгода, его некрасиво выгнали, и он в отместку им немножко навредил перед уходом. Меня посадили с этим разбираться. Причем я сразу говорил, что ничего не понимаю. И в отчетах я так и писал: «Вот, последние полчаса читаю эту непонятную ерунду и понятия не имею, что с ней делать». Так я и работал пару месяцев. Под конец я нашел номер того уволенного сотрудника, позвонил ему. Он долго смеялся и сказал: «Ничего не делай, оно все равно не заведется».
Часто микроменеджмент — просто одно из проявлений неумелого менеджмента: когда руководитель плохо вникает в проблему и получает неудовлетворительный результат от сотрудника. А потом решает этого самого сотрудника во всем обвинить и начать контролировать.
Я вижу главную проблему микроменеджмента в том, что менеджер не умеет объяснять. Нужно уметь доносить до человека, чего ты от него хочешь и какой у вас рабочий процесс. Это большая проблема. Большинство менеджеров предполагают, что люди сами обо всем догадаются. И когда выясняется, что мысли они не читают, менеджер не понимает, почему все идет не по плану — и начинает контролировать их каждый шаг.
Алексей сталкивался с проявлениями микроменеджмента практически в любом месте работы — пусть и в менее абсурдных формах. Он считает, что часто этим грешат начинающие управленцы и бывшие программисты.
В каждой компании найдется человек, который любит помикроменеджерить. Особенно если он новый менеджер — трудно научиться делегировать. А в СНГ вообще многие менеджеры — это бывшие разработчики, которые внезапно становятся менеджерами и на своем опыте выясняют, как этим заниматься. Поначалу им кажется, что надо каждые полчаса пинать коллег с вопросом: «Ну чо там?»
У разработчиков вообще профдеформация есть: мы же обычно компьютеры контролируем, а они подчиняются полностью. С людьми по-другому, и когда начинаешь управлять людьми, трудно переключиться. Почти все проходят через этап микроменеджмента. Просто у некоторых есть менторы, которые подсказывают, кому-то коллеги намекают, что так делать не надо. А многие менеджеры застревают в этом на всю жизнь.
Зашквар или приемлемые практики?
Микроменеджмент в IT-среде — это почти что ругательное слово. Впрочем, Наталья Давыдова в своем треде пишет, что иногда видит этот термин в вакансиях в нейтральном контексте: там честно упоминают, что в компании принят микроменеджмент. Честность — это вроде как неплохо, но она советует обходить такие компании стороной:
Видим в вакансии слова «микроменеджмент"/"наноменеджмент» — закрываем ее нафиг без права пересмотра.
— Natalia 🌸 Davydova (@nat_davydova) January 14, 2022
Этот „микроменеджмент“ означает, что из вас достанут всю душу: „задачу сделал? а сейчас? а вот сейчас? А дай апдейт: тот, что 15-минутной давности — устарел“.
Среди самих менеджеров отношение к гиперконтролю двоякое. Большинство соглашаются, что избыточные отчеты и инструкции нерациональны. Но можно встретить и противоположные мнения — от менеджеров, которые устали быть слишком либеральными.
Прошел год с момента как я стал ПМом. Год я был либеральным и понимающим менеджером. Созвон раз в неделю, взяли таски и ушли работать на неделю. Но сегодня терпение кончилось, отныне: дейли митинги, микроменеджмент и раздача ежедневных люлюей.
— Andrei (@ykshev) October 12, 2022
Примерно 1 из 10 разработчиков способен организовать свою работу и выполнить взятые на себя задачи. Остальные 9 просто пинают всю неделю. Причем я говорю о людях с зп по верху рынка разработки.
— Andrei (@ykshev) October 12, 2022
Как я тебя понимаю, дай обниму 🫂
— Саша Реушкин (@alexreushkin) October 12, 2022
Негодование управленцев от плохой работы подчиненных вполне понятно. Но вот может ли микроменеджмент перевоспитать демотивированных сотрудников — открытый вопрос.
Микроменеджмент может временно помочь, если люди совсем не перформят, активно саботируют. Можно добиться от них сдачи куска работы к дедлайну, но глобально микроменеджмент проблему не решит — менеджер в таком случае работает не с причинами, а с проявлениями. Что-то показать заказчику команда сможет, но дальше придется разговаривать с людьми и разбираться в их мотивации.
Алексей Мигутский, старший инженер:
Когда управленец контролирует каждый шаг сотрудников, значит, им не нужно ни за что отвечать. Это приводит к тому, что люди только больше расслабляются и соблюдают формальные инструкции вместо того чтобы заниматься сутью своей работы.
Очевидно, это не стратегия, а индикатор того, что все плохо и будет только хуже. Микроменеджмент парализует команду и убивает мотивацию, создает тот самый bottleneck, когда один человек включен во все процессы и без него/нее никак. И зачем тогда сотруднику становиться лучше, если все равно придет кто-то и решит за тебя как делать твою работу?
Ситуации, когда микроменеджмент полезен
Мир не делится на черное и белое, поэтому мы — с помощью наших экспертов — решили поискать в микроменеджменте плюсы. Их оказалось не очень много. По мнению большинства, гиперконтроль реально полезен только в чрезвычайных ситуациях.
На случай инцидентов есть даже гайдлайны, иногда на государственном уровне — в них объясняется, как инциденты должны разруливать. И там есть роль Incident Commander — вот он может и микроменеджерить, и давать прямые приказы. Но прикол в том, что это обычно не менеджер делает, а специалист, эксперт, который понимает, что происходит. И, конечно, речь о ЧС, в долгосрочной перспективе нормальный бизнес так вести невозможно.
Если микроменеджмент сработал один раз — помог закрыть задачи в срок — это вовсе не означает, что он будет эффективно работать всегда.
Микроменеджмент может работать в условиях пожара на минимальном отрезке времени. Когда нужно собрать не очень мотивированных людей и сделать, «чтобы работало». Но есть одна проблема. Вместо того чтобы понять, как вы вообще дошли до жизни такой, что люди демотивированы и их пришлось микроменеджить, многие компании (особенно этим страдают компании из стран СНГ) считают это работающей стратегией. Мол, починили же или сделали в срок.
Но в длительной перспективе микроменеджмент — расшатывание фундамента организации, а там уже и до статьи на айти портале «Как рушатся империи: история компании X» недалеко. Грань тут очень простая: если ваша «помощь» или «фильтрация информации» приводит к тому, что в компании появляются ключевые люди, без которых невозможно ничего сделать, а рядовые работники не могут ответить на простой вопрос «куда мы идем?» — значит, пора что-то менять.
Павел Романов отмечает, что микроменеджмент — один из возможных, хотя и не лучших вариантов работы с джунами.
В качестве исключения подобный подход можно использовать только при работе с junior-ами. Но даже в этом случае намного эффективнее вводить в компании институт менторства и направлять джунов, а не «стоять над ними с палкой».
Как избежать микроменеджмента
Никогда не сталкивались с микроменеджерами разве что неопытные интерны. В той или иной мере, это частая практика: в любой компании может появиться человек, помешанный на контроле — по неопытности или в силу особенностей характера. До отжиманий с благодарностями дело, конечно, доходит редко — обычно речь идет о более мягких проявлениях.
Я сталкивался с микроменеджментом в разных формах:
- Излишний контроль от менеджеров за временем работы над задачами: например, требование регулярных и объемных отчетов, трекинг времени в Jira — при том что работали мы над своим продуктом, а не на аутсорс.
- Слишком плотное участие тимлида в разработке: в компании было разделение на people-менеджеров и техлидов, но тимлид в большей степени занимался именно гиперконтролем над middle и senior разработчиками, что, по сути, лишало смысла сам их найм.
- Неумение техлидов делегировать. Когда все процессы были завязаны на них, это приводило к затягиванию сроков решения простейших проблем.
Если терпеть гиперконтроль невозможно и нет смысла, разумный вариант — увольнение.
Я работала в корпорациях, скейл-апах и стартапах в нескольких странах. Микроменеджмент встречается практически везде. И хорошие компании с ним борются, а не очень хорошие — считают работающим инструментом. При этом у микроменеджмента много проявлений. От проверки, все ли разработчики пришли на работу к 9 утра (без особой на то причины), вмешательства в задачи на уровне «подай это, принеси то», вопросов «а почему на созвоне ты не включил (а) камеру?», до неэффективного онбординга и код ревью, где код просят переписать не по объективной причине, а потому что он просто не нравится техлиду.
Мой самый смешной и нелепый случай произошел в одном голландском стартапе, где CPO собирал 5 продакт менеджеров раз в неделю чтобы при нем зачитывались созданные юзерстори и он мог вносить коррективы. Я моментально объяснила что так нельзя, и после попыток изменить процесс нашла более удачное место работы.
Если покидать компанию не хочется, можно попробовать воздействовать на микроменеджера. Правда, люди с трудом меняют свои привычки, и не нужно питать иллюзий, что после одного замечания руководитель пересмотрит свою тактику.
Думаю, перевоспитать микроменеджера может только человек, которого он считает авторитетом. А еще во многих компаниях есть хорошая практика 360° feedback: когда коллеги, начальство, подчиненные дают всеобъемлющий фидбек о человеке, и он влияет на промоушн и бонусы к зарплате. А просто так всей командой на микроменеджера повлиять трудно. Можно разве что перестать работать, но это страшновато.
Еще вариант — итальянская забастовка: делаешь ровно то, что у тебя написано в контракте, и вся компания остановится. Потому что все мы делаем гораздо больше, чем указано в договоре.
