Эту историю мне рассказал человек, который захотел остаться анонимным, а я решил написать статью для своего блога.
Я Android-разработчик. Два года назад я попал в ловушку микроменеджмента. Мой руководитель требовал ежедневные планы, контролировал каждое действие и даже фиксировал продолжительность моих обеденных перерывов. Расскажу, как я распознал проблему, дошел до точки кипения и нашел выход из этой ситуации.
Два года назад я устроился на должность Android-разработчика в небольшую компанию. На собеседовании руководитель красиво говорил о важности командной работы. Он много рассказывал о доверии к работникам. Особо подчеркивал, как они ценят инициативу.
Меня все устраивало. Я пришел с двухлетним опытом разработки и с желанием расти дальше.
Офис — уютный, продукт — перспективный, команда — небольшая и дружная, возможности для роста — большие. Ну, или так казалось.
Уже на первой неделе я заметил странности. Руководитель (назовём его Александр) требовал подробный план работы на каждый день. Он не хотел планов на неделю или более долгий срок. До 10 утра я должен был отправлять ему сообщение. В нём я описывал всё, что собирался делать сегодня. А вечером я должен был писать подробный отчёт: что удалось сделать, а что нет.
Меня также удивила организация code review. В предыдущих компаниях мы использовали GitLab. Здесь же Александр настоял на том, что он лично будет проверять каждую строчку моего кода.
Александр требовал согласовывать с ним каждое техническое решение. Даже базовые вещи, например, как обрабатывать типичные ошибки сети в Retrofit или какую библиотеку использовать для асинхронных запросов — корутины или RxJava — всё это я должен был предварительно обсудить с ним лично. Проект исторически использовал оба инструмента в разных модулях, но Александр настаивал на своём мнении даже там, где следовало придерживаться существующего стиля кода.
Поначалу я пытался убедить себя, что это нормально. Может быть, у компании какие-то особые требования к качеству. Но затем начались совсем странные вещи. Александр требовал, чтобы я отправлял ему скриншоты экрана каждые два часа. Так он мог «отслеживать прогресс».
Он настоял на установке программы, которая записывает время работы за компьютером. Однажды он даже отчитал меня за «слишком долгий» обеденный перерыв, который длился 62 минуты вместо положенных 60.
При проверке моего кода он настаивал на том, чтобы все элементы были названы так, как он считал правильным. Даже если название было абсолютно понятным и соответствовало общим правилам, его могло что-то не устроить.
Например, он требовал изменить название раздела в приложении с userProfile на userData, хотя эти сущности имеют разное назначение в архитектуре приложения и создают путаницу в навигационных компонентах. Мои аргументы игнорировались.
Это происходило постоянно. Каждый раз. Каждая строчка кода подвергалась такому контролю.
Как у меня закончилось терпение
Через три месяца такой работы я уже не знал, куда себя деть. Моя продуктивность падала. На реализацию простой функции, которая обычно занимала пару часов, у меня уходили дни — из-за бесконечных переделок, изменений требований и «микрокорректировок».
Однажды я потратил целую неделю на реализацию экрана с профилем пользователя, потому что Александр четыре раза менял своё мнение о том, как должен выглядеть макет и как именно должны работать анимации. Сначала он требовал верстку на XML с кастомными переходами между фрагментами, потом настаивал на переписывании на Jetpack Compose с Material 3 анимациями, затем решил, что лучше использовать отдельную Activity вместо фрагмента в основном контейнере, а в конце цикла начал жаловаться на производительность компоузаблов и снова требовал вернуться к XML.
Подобный случай произошел, когда я улучшал производительность приложения. Я обнаружил, что список товаров в RecyclerView тормозил при прокрутке из-за неоптимизированных запросов к базе данных и тяжелых операций с изображениями в главном потоке. Я предложил решение: оптимизировать работу с базой данных и перенести обработку изображений в фоновый поток.
Александр потребовал, чтобы я прислал ему подробный план работ. Я составил план из 8 пунктов. Затем он потребовал для каждого подпункта указать точное время выполнения. После этого он настоял на ежечасных отчетах о прогрессе по каждому подпункту. Работа, которую можно было сделать за день, растянулась на неделю.
Ситуация достигла пика, когда я полностью сделал систему обновления данных по его указаниям. После завершения работы он вдруг заявил, что всё нужно переделать. Причина была в том, что он «не до конца продумал общую структуру».
Я пытался объяснить, что можно улучшить текущее решение без полной переделки. Он отвергал все предложения с полной уверенностью, что только его решение правильное. По его словам, я просто не понимал полной картины.
Я всё чаще стал задерживаться допоздна, работать по выходным, но результат всё равно не устраивал Александра. Появилось ощущение, что сколько бы я ни старался, этого всё равно будет недостаточно.
Особенно унизительными были еженедельные командные встречи. Александр просил каждого рассказать о проделанной работе.
На моей прошлой работе код обсуждали в системе контроля версий, где каждый мог оставить комментарий к конкретной строке кода, а автор спокойно мог их проработать. Но Александр предпочитал публичные разборы вместо профессионального code review.
Мою работу он всегда комментировал публично, отмечал даже самые незначительные недочеты. Он мог устроить разбор полетов из-за того, что я не использовал WeakReference для предотвращения утечек памяти в адаптерах, или потому что я не оптимизировал запросы к Room базе данных через индексы, или из-за того, что длительные операции не были вынесены из UI-потока в Dispatchers.IO. При этом критиковал он не конструктивно, а с явным желанием унизить перед командой.
Александр также имел привычку неожиданно подходить к моему столу. Он молча стоял за спиной и смотрел на экран. Иногда он просто наблюдал несколько минут, а потом уходил без комментариев. В другие разы он начинал давать советы и указания, даже если я работал над сложной задачей, где требовалась концентрация. После таких перерываний я тратил много времени, чтобы снова сосредоточиться на работе.
Что ещё он делал:
При малейшем опоздании (даже на 2 минуты) он писал мне сообщение: «Где ты? Почему не на работе?»
Когда я брал день отпуска, он звонил мне минимум два раза, чтобы спросить о статусе некоторых задач, несмотря на то, что я всё подробно записывал перед уходом.
Он даже комментировал, что я ем на обед: «Это вредно, ты не сможешь эффективно работать после такой пищи».
Когда я понял, в чем причина
Я обедал со старшим разработчиком Игорем, который работает здесь уже три года. За кофе он рассказал мне всю подноготную ситуации. Оказывается, наш Александр раньше сам был разработчиком, причем не блиставшим талантами. Его повысили просто потому, что он давно сидел в компании, а не из-за каких-то лидерских качеств. И теперь он явно не в своей тарелке на руководящей должности. А чрезмерный контроль — это просто способ скрыть свою неуверенность и страх.
Я спросил у Игоря, почему никто не говорит Александру, что невозможно так работать. Игорь сказал, что двое сотрудников, пытались поговорить. Александр был уверен в своём подходе. Он искренне верил, что без его постоянного контроля всё развалится. Потом эти двое сотрудников просто уволились, они не выдержали такого стиля управления.
Постепенно до меня начало доходить. Раньше я слышал о микроменеджерах, но не осознавал, что работаю с одним из них.
Последней каплей стал наш крупный релиз. Мы не уложились в сроки, потому что каждая задача проходила через 3-4 круга переделок. Александр при всей команде обвинил меня в том, что я «недостаточно ответственно» подхожу к работе. Хотя именно я оставался допоздна почти каждый день, пытаясь успеть всё сделать.
Коллеги молчат, я осознал, что ситуация не изменится. Александр не поменяет свой стиль управления, а компания не увидит проблемы, пока это не начнёт серьёзно бить по бизнесу.
В тот вечер я принял решение искать новую работу. Не потому, что я сдался, а потому что понял: в таких условиях я не могу развиваться как специалист. Более того, я деградировал — тратил время на бесконечные переделки вместо того, чтобы учиться новому и решать действительно интересные задачи.
Я решил уйти
Чтоб упростить работу человеку, который придет на мое место, я сделал подробные описания текущих задач в Confluence. В то же время я активно искал новую работу. Теперь мой подход к собеседованиям полностью изменился.
На каждом собеседовании я уделял особое внимание рабочим процессам в компании. Я спрашивал, как организована работа команды. Интересовался, как проходит проверка выполненной работы. Выяснял, есть ли у сотрудников самостоятельность в принятии решений. Узнавал, сколько времени проходит от появления идеи до выпуска готового продукта.
Многие рекрутеры удивлялись такому подходу, но я точно знал, чего хочу избежать.
Спустя месяц поисков я нашёл подходящую компанию. На собеседовании я честно рассказал о своём опыте и почему ухожу с текущего места. Удивительно, но мой новый руководитель сам сталкивался с микроменеджментом и полностью понял мою ситуацию.
Когда я сообщил Александру об уходе, он воспринял это спокойно. В целом, ему было все равно. Я объяснил, что мне нужно больше самостоятельности. Я хочу расти как специалист, а не просто следовать указаниям. Он возразил. Оказывается, его гиперконтроль «помогал мне становиться лучше».
Этот разговор окончательно убедил меня в правильности моего решения. Мы понимали ситуацию совершенно по-разному. Для него постоянный контроль был проявлением заботы. Для меня это было проявлением недоверия.
Уроки, которые я извлёк
За прошедший год на новой работе я многое понял о ситуации с микроменеджментом в команде:
Микроменеджмент редко удаётся победить «снизу». Если руководитель не осознаёт проблему, а вышестоящее начальство её не видит — изменить ситуацию практически невозможно.
Есть признаки, по которым можно определить склонность к микроменеджменту ещё на собеседовании. Нужно обратить внимание на чрезмерный интерес к процессам вместо результатов. Возможно вам дадут неясные ответы на вопросы о самостоятельности сотрудников. Подозрительны фразы типа «мы очень внимательны к мелочам».
Микроменеджмент токсичен для профессионального роста. Под постоянным контролем невозможно развивать самостоятельность и инициативу
Эмоциональное выгорание — неизбежное следствие микроменеджмента. Постоянный стресс и ощущение, что ты не оправдываешь ожиданий, приводят к критическому снижению мотивации.
Пару месяцев назад я списался с бывшими коллегами. Оказалось, что после меня ушёл ещё один разработчик, и теперь команда состоит в основном из джуниоров, которые не знают, как может быть по-другому. Александр продолжает свой стиль руководства, а проекты всё так же не укладываются в сроки.
Сейчас я работаю в здоровой команде, где моё мнение ценят, а решения доверяют принимать самостоятельно. Я больше не трачу энергию на борьбу с системой, а направляю её на решение интересных задач и развитие.
Я веду блог «Курилка известной IT-компании». Там пишу про ситуации на работе, о которых не принято говорить. Оставил в канале таблицу с нормальными и ненормальными проявлениями менеджмента в работе — можно свериться.
Герои этого канала рассказывают свои истории анонимно, потому что за такую честность их или уволят, или больше не возьмут на работу. Но зато вы узнаете как вебмастер работал на четырех работах и зарабатывал миллион в месяц, как программист попал в IT без нужного образования, как разработчик уволился из токсичного коллектива и другие истории.
Подписываясь на телеграм-канал, вы поддерживаете работу автора.