Самая большая ошибка, которую совершают разработчики после повышения до руководителя — они продолжают работать разработчиками. Я тоже совершил эту ошибку. Нет, я не уходил из IT и не менял компанию. Даже должность особо не изменилась. Но став руководителем я понял, что занимаюсь совершенно другой работой.

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

Нет. Руководителю платят не за то, что он сам принимает правильные решения. Ему платят за то, что правильные решения принимает команда даже тогда, когда его нет рядом. Именно в этот момент я понял одну неприятную вещь: я не вырос в разработке. Я просто сменил профессию.

Разработчики романтизируют роль руководителя. Кажется, что теперь всё будет иначе. Больше зарплата. Больше влияния. Можно принимать решения. Можно делегировать неприятные задачи. Можно не брать тикеты из спринта. Можно наконец-то перестать постоянно писать код. Реальность намного скучнее. И намного тяжелее.

———

Есть главное заблуждение. Руководитель — это не человек, который принимает решения. Руководитель — это человек, который остаётся крайним за последствия. Всегда.

Можно написать плохой код. Неприятно, но обычно последствия ограничатся одним сервисом. Совсем другое дело — ошибиться в людях. Нанять не того разработчика. Отдать критичный проект человеку, который пока не готов. Не заметить, что сильный инженер давно выгорел. Или месяцами откладывать разговор, который нужно было провести ещё вчера. Цена таких ошибок почти всегда выше стоимости любого технического факапа. Потому что разгребает их уже вся команда.

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

Ещё заблуждение – руководитель постоянно говорит людям, что делать.

Нет. Если каждое решение проходит через тебя — ты плохо делаешь свою работу. Поздравляю. Ты стал самым дорогим, самым медленным и самым ненадёжным API в компании. А самое плохое даже не это. Команда постепенно перестаёт думать самостоятельно. И именно руководитель обычно становится причиной этого.

Есть ещё одна иллюзия. Разработчики часто смотрят на своего лида и думают: «Что-то он вообще почти не кодит». Мне тоже когда-то так казалось. Потом я впервые увидел собственный календарь:

Встречи. Найм. Увольнения. Конфликты. Архитектурные обсуждения. Планирование. Разговоры 1:1. Попытки защитить команду от очередной “очень срочной” инициативы бизнеса. И вечером, если повезёт, можно открыть IDE.

Работы стало не меньше. Она просто перестала быть похожей на разработку.

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

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

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

Нет. Это вообще не следующий уровень. Это другая профессия. С другими правилами. С другими навыками. С другими ошибками. И с совершенно другой ценой каждого решения.

———

Поэтому, если однажды тебе предложат стать руководителем, не думай, что тебя повышают. Скорее всего, тебе предлагают сменить профессию.