После 10 лет разработки я думал, что знаю всё о плохих менеджерах. Но когда сам стал тимлидом, обнаружил в себе те же токсичные паттерны, на которые жаловался — и это было больнее всего.
Если вы разработчик — вы будете кивать, думая «наконец-то кто-то понимает». Если вы менеджер — возможно, узнаете себя. И это нормально, ведь осознание проблемы это первый шаг к её решению.
Ставьте лайк, если тема зашла, дальше будет ещё интереснее.
Смерть от тысячи синков
Представьте: вы в состоянии потока. Наконец-то разобрались с багом, который неделю висел в проде. Наушники надеты, мир исчез, вы вот-вот найдёте решение...
— «Хей, есть пять минут? Быстренько созвонимся!»
Появляется ваш менеджер со «срочным» вопросом о приоритетах. Эти пять минут превращаются в тридцать. И когда вы возвращаетесь за стол, та прекрасная ментальная модель, которую вы выстроили? Испарилась. Понадобится ещё час, чтобы вспомнить, где вы остановились.
Плохие менеджеры не понимают, что программирование требует глубокой концентрации. Они относятся к инженерам как к рабочим на конвейере, которые могут поставить работу на паузу и продолжить в любой момент. Они назначают митинги на самое продуктивное время и удивляются, почему продуктивность падает.
Проблема «это же просто кнопка»
Ещё одна вещь, которая сводит разработчиков с ума: менеджеры, которые никогда не писали код, принимают технические решения. Это как если бы человек, который никогда не водил машину, выбирал вам автомобиль, ориентируясь только на цвет сидений.
Я видел, как менеджеры обещали фичи, которые технически невозможны. Как устанавливали дедлайны, не посоветовавшись с командой. И хуже всего — предлагали «простые» изменения, которые на самом деле невероятно сложны. А когда разработчики пытаются возразить, их называют «не командными игроками».
Трагедия в том, что некоторые из этих менеджеров сами были инженерами. Но они так долго не работали с кодом, что забыли, каково это на самом деле. Они помнят разработку через розовые очки, где всё было проще и быстрее, чем в реальности.
Синдром невидимого инженера
Ничто не убивает мотивацию быстрее, чем наблюдать, как твой менеджер присваивает себе твою работу. Вы проводите ночи и выходные, выполняя невозможный дедлайн, создавая элегантное решение сложной проблемы. И на общем митинге ваш менеджер презентует это как «то, что Я доставил в этом квартале».
Хорошие инженеры решают проблемы. Плохие менеджеры заявляют, что решили их сами. И это не всегда злой умысел — иногда менеджеры искренне верят, что «обеспечение команды ресурсами» означает, что они сделали работу. Но попробуйте объяснить это инженеру, который на самом деле написал код.
Если узнали себя — подписывайтесь на канал, буду делиться опытом и с той, и с другой стороны.
Воронка митингов
Разработчики шутят об этом, но это больно и реально: менеджер, который мог отправить письмо, но вместо этого назначил встречу. Потом пригласил всю команду «для видимости». Потом сделал её регулярной, «чтобы оставаться на одной волне».
Ваш календарь становится кладбищем продуктивности. Стендапы по 45 минут. Митинги, чтобы спланировать другие митинги. Ретроспективы, где ничего никогда не меняется.
Инженеры выбрали эту профессию отчасти потому, что они любят создавать вещи. Каждая ненужная встреча — это время, украденное у того, чем они действительно хотят заниматься.
Театр обратной связи
Ежегодный ассесмент — это где умирает доверие. Ваш менеджер, которого вы почти не видели весь год, кроме как на митингах, внезапно имеет мнение о ваших «зонах роста». Он цитирует тот самый PR, который занял слишком много времени (игнорируя контекст), или упоминает, что вам нужно «быть более заметным» (не давая времени на что-то заметное).
Фидбек в общих слова, явно скопирован из HR-шаблона или ChatGPT. Повышение, которое вам обещали? «Может быть, в следующем году». Повышение зарплаты? «Бюджетные ограничения».
А тем временем новый сотрудник с вдвое меньшим опытом, но вдвое большими политическими навыками только что получил повышение до Senior.
Но есть нюанс
Вот здесь всё становится сложнее. После перехода в менеджмент я обнаружил нечто неприятное: я начал демонстрировать те же самые паттерны поведения, на которые жаловался раньше.
Менеджмент — это одиночество. Это работа, где вы постоянно принимаете решения с неполной информацией, балансируете между конкурирующими приоритетами и да — сидите на тех же душащих митингах, которые ненавидят инженеры.
Большинство менеджеров не злодеи. Они часто так же фрустрированы, как и их инженеры, зажатые между требовательными топ-менеджерами и выгоревшими командами. Их оценивают по метрикам, которые они не могут напрямую контролировать. Их просят делать больше с меньшими ресурсами. Их критикуют со всех сторон.
Менеджеры, которые сводят инженеров с ума? Обычно они тоже в стрессе. Они прерывают, потому что их самих прерывают. Они принимают плохие технические решения, потому что на них давят принять хоть какое-то решение. Они присваивают себе заслуги, потому что так они научились выживать в корпоративной игре.
Понимание этого не оправдывает плохой менеджмент, но даёт перспективу. И что важнее — указывает на то, как должен выглядеть хороший менеджмент.
Как разорвать порочный круг
Лучшие менеджеры, которых я знал — те, кого разработчики действительно уважают — поняли несколько вещей:
Они защищают время для фокуса как святое. Структурируют коммуникацию, отклоняют ненужные встречи, не дают прерывать работу. Когда им что-то нужно, они напишут: «Не срочно, глянь когда будет время».
Они остаются достаточно техническими для принятия обоснованных решений. Возможно, они не кодят каждый день, но понимают что к чему. Они задают вопросы вместо того, чтобы делать предположения. И самое главное — они доверяют техническому суждению своей команды.
Они щедро раздают похвалу и лично берут на себя вину. Хвалить всегда публично: «Команда справилась/решила». Наедине с боссом: «Я должен был это предусмотреть».
Они дают фидбек осмысленно. Они не ждут ежегодной оценки, чтобы поделиться наблюдениями — они дают конкретную, своевременную обратную связь на основе работы, за которой они действительно следили. Когда приходит время ревью, нет сюрпризов, и они борются за повышения своей команды.
Выводы
Правда в том, что инженеры не ненавидят менеджеров — они ненавидят плохой менеджмент. И, побывав по обе стороны, я могу сказать: переход от инженера к менеджеру сложнее, чем большинство себе представляет. Вы по сути учитесь совершенно новой работе, а все ожидают, что вы сразу будете в ней идеальны.
Но это не оправдание. Если вы менеджер и узнали себя в этих жалобах — пора честно взглянуть на себя. А если вы разработчик, фрустрированный своим менеджером, учтите: возможно, он тоже тонет. Иногда лучшее, что можно сделать — честно поговорить о том, что нужно вам обоим для успеха.
Лучшие команды, которые я видел — не те, где инженеры и менеджеры друзья (хотя это приятный бонус). Это команды, где обе стороны понимают свои роли, уважают вызовы друг друга и идут вместе к общей цели.
Когда это происходит — когда разрабы чувствуют, что их слышат, а менеджеры чувствуют поддержку, когда техническая реальность встречается с бизнес-потребностями, не разрушая ни одну из сторон — вот тогда команды создают невероятные вещи. Не потому что должны, а потому что хотят.
Ставьте лайк, если статья была полезна. Подписывайтесь на дзен — буду делиться опытом из жизни разработчика и тимлида. А если хочется подглядеть за моей жизнью и тем, как я жонглирую ролями (спойлер: не очень ловко), то добро пожаловать в мой телеграм канал
А в комментариях расскажите: какие отношения у вас с вашим менеджером? Или может вы узнали себя?