Найти тему

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

Это очень частый вопрос? И если отвечать максимально коротко, то ответ такой: никак.

Для начала бывают технические лидеры (или техлиды), а бывают руководители. Техлиды ведут техническую часть проекта. Они ответственны за качество кода, но не ответственны за команду и бюрократию. Они управляют кодом, который пишут участники проекта, но не вмешиваются в процесс. Технические лидеры – это старшие товарищи на проекте, с богатым багажом опыта. Во многих компаниях совершается одинаковая «классическая» ошибка – это назначение руководителем техлида (или старшего разработчика). Я называю это «убийством разработчика», но почему-то многие считают это логичным продолжением карьеры: разработчик – старший разработчик – техлид. Нет, не делайте так, техлид – это тот кто принимает технические решения, ревьюит код, менторит джунов и новеньких, но он не занимается руководством командой. Многие техлиды не хотят руководить, им нравится писать код и они эффективны именно в этом, но будут не эффективны как руководители или могут вообще уволиться через полгода, после «долгожданного повышения».

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

Есть много разных статей про руководство в которых подробно описан портрет хорошего руководителя, вот очень неплохую подборку совсем недавно скинул Костя Горский (кстати, подписывайтесь на его канал, Костя хороший). Но я лично считаю важным одно качество – проактивность. Именно поэтому ответ на вопрос: как стать? – Никак. Проактивность невозможно развить, она либо есть и хлещет, либо её нет. Точка. Проактивность двигает горы, потому что человека сложно остановить. Фразы вроде «так было всегда» и «мы не будем ничего менять» не действуют. Проактивный человек, а тем более руководитель, всегда задаёт вопрос: «Что я могу изменить, чтобы стало лучше?». Он задаёт его себе, задаёт своим коллегам, задаёт даже случайному прохожему на улице. И находит ответ. А дальше он пробует что-то менять, и если не получается, то снова спрашивает себя что он может изменить и далее по кругу.

Но проактивность – это необходимое, но не достаточное условие для того чтобы стать руководителем. Допустим человек обладает этим качеством и его делают руководителем. В чём здесь проблема? А она в том, что руководство – это абсолютно новые функции, которым, чаще всего, не учат. И в этом заключается ещё одна ошибка – процесс входа в должность отпускается на самотёк, вроде бы итак понятно что делать. Хотя нет, конечно бывают исключения, и если в вашей компании всё хорошо с процессами, то после назначения вам должна упасть куча встреч, объясняющих что теперь ваша работа будет совсем другой. Но если у вас не так, то (помним про проактивность) нужно пойти к своему руководителю и попросить его научить руководить. Можно не так, можно попросить его рассказать из чего состоит его день. Суть здесь очень простая – вам нужен ментор. Вы новичок в этой профессии, джун можно сказать. А к джунам всегда приставляют ментора. И уже потом я рекомендую вам закидываться кипой книжек на тему «что такое быть руководителем?»

И, наконец, третья ошибка. Руководителю придется смириться, что теперь его основная функция, KPI, хлеб и прочее – это управление. И только потом написание кода. Так, ну и в чём же ошибка? А она просто в том, что никто ничего такого не говорит новоиспечённым руководителям. Никто не объясняет, что нормально, к примеру, весь день ходить по встречам. И вот, став руководителем, у человека начинается жуткая депрессия, что он «не делает ничего полезного, а только по встречам ходит». Тут беда в том, что разработчиками эти же встречи не воспринимаются как работа, но скорее как необходимость. А тут встреч стало в 5 раз больше. И вообще, получается, не работаешь... Так вот, ребята-руководители – не писать код это нормально. Я вам говорю! 😉

Кстати, когда я понял, что встречи – основная часть моей работы, то смог привести в порядок остальную свою работу. Если мне нужно подумать над какой-нибудь проблемой. Или посидеть тщательно подготовиться к какому-нибудь мероприятию. Или ответить на какое-то большое письмо. В общем, речь о любой активности продолжительностью больше 15 минут. То я просто оформляю это как встречу. Например, у меня есть встреча «Завтрак» с 12 до 13.

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