На работе записывали экран, требовали 2 отчёта в день и контролировали, что я ем

Эту историю мне рассказал анонимный человек, и я решил написать об этом статью в своем блоге.

Я Android-разработчик. Два года назад я попал в ловушку микроменеджмента. Мой менеджер потребовал от меня составить ежедневный план, следил за каждым моим шагом и даже следил за продолжительностью моих обеденных перерывов. Я расскажу вам, как я осознал проблему, дошел до точки кипения и нашел выход из ситуации.

Два года назад я устроился на работу Android-разработчиком в небольшую компанию. Во время интервью менеджер блестяще рассказал о важности командной работы. Он много раз говорил о доверии к работникам. Он особо подчеркнул, что они придают большое значение инициативе.

Я всем очень доволен. Я развиваюсь здесь уже два года и стремлюсь расти дальше.

Офис комфортный, продукт перспективный, команда небольшая и дружная, есть много возможностей для роста. Ну, по крайней мере, так кажется.

В первую неделю я заметил нечто странное. Менеджеру (назовем его Александр) требуется подробный план работы на каждый день. Он не хотел строить планы на неделю или больше. Мне нужно отправить ему сообщение до 10 утра. В нем я описываю все, что собираюсь сделать сегодня. Вечером мне пришлось написать подробный отчет: что я сделал и чего не сделал.

Меня также удивила организация проверки кода. В предыдущих компаниях мы использовали GitLab. Александр настоял на личной проверке каждой строки моего кода.

Александр требовал, чтобы каждое техническое решение принималось по согласованию с ним. Даже такие базовые вещи, как обработка типичных сетевых ошибок в Retrofit или какую библиотеку использовать для асинхронных запросов (сопрограммы или RxJava), мне приходилось заранее обсуждать с ним лично. В прошлом в разных модулях проекта использовались оба инструмента, но Александр придерживался своего мнения даже в тех случаях, когда необходимо было следовать существующему стилю кода.

Сначала я пытался убедить себя, что это нормально. Возможно, у компании есть какие-то особые требования к качеству. Но затем начали происходить очень странные вещи. Александр попросил меня присылать ему скриншоты каждые два часа. Таким образом он мог «отслеживать прогресс».

Он настоял на установке программы, которая регистрировала бы время, проведенное им за компьютером. Однажды он даже отругал меня за «слишком долгий» обеденный перерыв, который составил 62 минуты вместо положенных 60 минут.

При проверке моего кода он настоял на том, чтобы все элементы были названы так, как он считал правильным. Даже если название понятно и соответствует общим правилам, он все равно может быть чем-то недоволен.

например, ему нужно было изменить название раздела в приложении с userProfile на userData, даже несмотря на то, что эти сущности имели разное назначение в архитектуре приложения и могли вызвать путаницу в компонентах навигации. Мои доводы были проигнорированы.

Это происходит постоянно каждый раз. Каждая строка кода подлежит такому контролю.

Как у меня закончилось терпение

После трех месяцев работы я не знала, чем себя занять. Моя производительность снижается. На реализацию простой функции, которая обычно занимает всего несколько часов, у меня ушло несколько дней из-за бесконечных доработок, меняющихся требований и «микро-доработок».

Однажды я потратил целую неделю на реализацию экрана профиля пользователя, потому что Александр четыре раза менял свое мнение о том, каким должен быть макет и как должны работать анимации. Сначала он запросил XML-макеты и пользовательские переходы между фрагментами, затем настоял на переписывании в Jetpack Compose с анимациями Material 3, затем решил, что лучше использовать отдельные Activity вместо фрагментов в основном контейнере, а в конце цикла начал жаловаться на производительность компонуемых объектов и попросил снова вернуться к XML.

Похожий случай произошел со мной, когда я улучшал производительность приложения. Я обнаружил, что список продуктов в RecyclerView прокручивается медленно из-за неоптимизированных запросов к базе данных и интенсивной обработки изображений в основном потоке. Я придумал решение: оптимизировать работу с базой данных и перенести обработку изображений в фоновый поток.

Александр попросил меня прислать ему подробный план работы. Я создал план из 8 пунктов. Затем он попросил уточнить конкретные сроки завершения каждого подпроекта. С тех пор он настаивал на предоставлении отчетов о ходе выполнения каждого подпроекта каждый час. Работа, которую можно было выполнить за один день, заняла неделю.

Ситуация достигла критической точки, когда я в точности выполнил его указания по созданию системы обновления данных. Закончив работу, он вдруг заявил, что все нужно переделать. Причина в том, что «общая структура еще не определена».

Я попытался объяснить, как можно улучшить существующие решения без полной переделки. Он отверг все предложения, будучи уверенным, что его решение единственно правильное. По его словам, я просто не получил полной картины.

Я стал все чаще работать сверхурочно, а также по выходным, но результаты по-прежнему не удовлетворяли Александра. Мне кажется, что как бы я ни старался, этого недостаточно.

Еженедельные собрания команды были особенно унизительными. Александр попросил каждого рассказать о проделанной работе.

На моей последней работе обсуждение кода проходило в системе контроля версий, и любой желающий мог оставлять комментарии к определенным строкам кода, а автор работал над ними без каких-либо проблем. Однако Александр предпочитает публичные обзоры профессиональным обзорам кода.

Он всегда открыто комментировал мою работу, указывая даже на самые мелкие недостатки. Он мог доставить мне неприятности, потому что я не использовал WeakReference для предотвращения утечек памяти в своем адаптере, или потому что я не оптимизировал запросы к базе данных Room с помощью индексов, или потому что я не перенес длительные операции из потока пользовательского интерфейса в Dispatchers.IO. В то же время его критика была неконструктивной, а скорее направленной на то, чтобы унизить команду перед ними.

У Александра также была привычка неожиданно подходить к моему столу. Он молча стоял позади меня, глядя на экран. Иногда он просто наблюдал несколько минут, а затем уходил, не прокомментировав ничего.

Обратите внимание: Принцип победителя или как связан спорт и успехи на работе.

Что еще он сделал:

• Если я опаздывал хотя бы на две минуты, он присылал мне сообщение: «Где ты? Почему не работаешь?»
• Всякий раз, когда я был в отпуске, он звонил мне как минимум дважды, чтобы спросить о статусе какого-нибудь задания, хотя я все подробно записывал перед отъездом.
• Он даже прокомментировал то, что я ел на обед: «Это вредно для здоровья, вы не сможете эффективно работать, если будете это есть».

Когда я понял, в чем причина

Я обедал с Игорем, старшим разработчиком, который работает здесь уже три года. Он рассказал мне всю историю за кофе. Оказывается, наш Александр раньше был разработчиком, причем не особо талантливым. Его повысили просто потому, что он долгое время работал в компании, а не из-за каких-либо лидерских качеств, которыми он обладал. Теперь он явно больше не годится для лидерства. Излишний контроль — это всего лишь способ скрыть свою неуверенность и страхи.

Я спросил Игоря, почему никто не сказал Александру, что так работать невозможно. Айгер сказал, что двое сотрудников пытались поговорить. Александр был уверен в своем подходе. Он искренне верил, что без его постоянного контроля все развалится. Затем двое сотрудников просто уволились; они не могли выносить такой стиль управления.

Постепенно я понял. Я и раньше слышал о микроменеджерах, но не осознавал, что работаю с одним из них.

Последней каплей стал наш грандиозный запуск. Мы отставали от графика, поскольку каждая задача проходила 3–4 раунда доработки. Александр обвинил меня перед всей командой в том, что я недостаточно «ответственен» на работе. Хотя я почти каждый день задерживался допоздна, пытаясь все успеть.

Мои коллеги замолчали, и я понял, что ситуация не изменится. Александр не изменил свой стиль управления, и компания не обнаружила проблему, пока она не начала серьезно влиять на бизнес.

В тот вечер я решил поискать новую работу. Это произошло не потому, что я сдался, а потому, что я понял, что не смогу стать экспертом в таких условиях. К тому же я все еще впадал в разврат — тратил время на бесконечные переделки вместо того, чтобы изучать что-то новое и решать действительно интересные задачи.

Я решил уйти

Чтобы облегчить задачу моему преемнику, я составил подробное описание текущей задачи в Confluence. В то же время я активно ищу новую работу. Теперь мой стиль интервью полностью изменился.

Во время каждого собеседования я уделяю особое внимание рабочему процессу компании. Я спросил, как организована работа команды. Мне интересно, как продвигается проверка выполненных работ. Я выяснил, были ли сотрудники независимы в принятии решений. Я узнал, сколько времени проходит от зарождения идеи до выпуска готового продукта.

Многих рекрутеров такой подход удивляет, но я точно знал, чего хочу избежать.

После месяца поисков я нашел подходящую компанию. Во время собеседования я честно рассказал о своем опыте и о том, почему я покидаю свою нынешнюю должность. Удивительно, но мой новый менеджер сам имел опыт микроменеджмента и полностью понимал мою ситуацию.

Когда я сказала Александру, что ухожу, он отнесся к этому спокойно. В целом ему было все равно. Я объяснил, что мне нужно больше независимости. Я хочу расти как профессионал, а не просто следовать инструкциям. Он выразил свое возражение. Оказывается, его превосходный контроль «помог мне стать лучшим человеком».

Этот разговор окончательно убедил меня, что я принял правильное решение. Наше понимание ситуации совершенно иное. Для него постоянный контроль — признак заботы. Для меня это признак недоверия.

Уроки, которые я извлёк

За последний год на новой работе я стал больше обращать внимание на микроменеджмент в своей команде:

1. Микроменеджмент редко можно преодолеть снизу. Если менеджеры не признают проблему, а вышестоящие лица ее не видят, изменить статус-кво будет практически невозможно.
2. Есть несколько признаков, которые помогут вам распознать склонность к микроменеджменту во время собеседования. Будьте осторожны, не сосредотачивайтесь слишком сильно на процессе и не игнорируйте результаты. Вы можете получить неясные ответы на вопросы об автономии сотрудников. Фразы типа «мы уделяем пристальное внимание деталям» вызывают подозрения».
3. Микроменеджмент не способствует развитию карьеры. Невозможно развить самостоятельность и инициативность в условиях постоянного контроля.
   
4. Эмоциональное выгорание — неизбежный результат микроменеджмента. Постоянный стресс и ощущение несоответствия ожиданиям могут привести к серьезному снижению мотивации.
   

Несколько месяцев назад я связался с некоторыми из моих бывших коллег. Оказывается, после меня ушел еще один разработчик, и теперь команда состоит в основном из младших сотрудников, которые понятия не имеют, как все сложится. Александр продолжил использовать свой стиль управления, но проект все равно не был завершен в срок.

Теперь я работаю в дружной команде, где мое мнение ценят и доверяют мне принимать независимые решения. Вместо того чтобы тратить свою энергию на борьбу с системой, я могу использовать ее для решения интересных задач и роста.

Я веду блог под названием «Курительные комнаты известных IT-компаний». Здесь я пишу о рабочих ситуациях, о которых обычно не говорят. Я оставил на канале таблицу, в которой перечислены нормальные и ненормальные показатели работы руководства — вы можете с ней ознакомиться.

Все герои этого канала рассказывают свои истории анонимно, потому что такая честность либо привела бы их к увольнению, либо позволила бы им снова трудоустроиться. Но вы узнаете о том, как веб-мастер зарабатывал миллионы в месяц, работая на четырех работах, как программист пришел в IT-индустрию без необходимого образования, как разработчик ушел из токсичной команды, и о многих других историях.

Подписываясь на канал «Курилки известных IT-компаний», вы поддерживаете творчество автора.