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