Есть стереотип, что движение вверх по карьерной лестнице - процесс естественный и желательный, и что по достижении определенного скила разработчику следует переходить на следующий уровень, ну например в тимлиды или ПО (project owner). На мой взгляд это представление неверно. Испытал это на собственном опыте, и теперь хочу поделиться с вами историей, как я управлял командой и какие выводы сделал о развитии карьеры в IT.
Те, кто собираются в тимлиды, поймут, какие подводные камни могут ждать. Тех, кто уже у руля, приглашаю к дискуссии в комментарии. Ну, а HR смогут взглянуть со стороны на сотрудника и его ощущения.
Как я попал в тимлиды
Когда у тебя достаточный опыт в кодинге, хочется попробовать чего-то ещё. Так было и у меня — я, что называется, «возжелал странного». Я работал фронтендером около 10 лет. В начале этой истории занимался разработкой маркетплейса в стартапе. Дела там шли явно не очень, концепция была интересной, но заинтересовать рынок у стартапа не получалось.
Начал искать предложения и вышел на крупного застройщика, который набирал айтишников под запуск приложения для жилого комплекса. Хм, интересно, откликаюсь. Провели собеседование — по скилам и опыту я был нацелен на должность разработчика, но, как оказалось, компания ищет тимлида с хорошими навыками написания кода.
На собеседовании я упомянул, что читаю лекции по React, а значит могу связно излагать материал и популярно объяснять некоторые вещи. ПО зацепился за эти скилы и сразу предложил мне позицию тимлида. Менторство в чем-то близко к управлению командой, а переход к новому для меня функционалу не виделся ему сложным.
Я не спросил, куда делся предыдущий тимлид. Думаю, он не выдержал сроки и его съели. Забегая вперёд, скажу, что, возможно, стоило разбить проект на более мелкие этапы и контролировать тщательнее.
Я был очень доволен, наконец дорос, думалось мне, и вообще "Тимлид" звучит гордо. Не то что какой то там разработчик, их вон и так как собак... А я теперь белая кость, код писать больше не надо, буду сидеть целый день, раздавать команды, строго смотреть на дейликах и поощрять подчиненных ценными советами и мудрыми наставлениями, попивая смузи где нибудь в парке. В общем всё, жизнь удалась. Вот в таком бодром настроении я вступил в должность.
Будни тимлида
Итак, началось: первая рабочая неделя, знакомство с командой и проектом. Посмотрел как выглядят продукты, заглянул в код. К сожалению понять что происходит я сходу не смог. Есть Jira в печальном состоянии, множество небольших задач, по большей части багов, всё в кучу, есть фичи которые вроде бы надо сделать, но кто, когда и в каком приоритете тоже не ясно. Начал выяснять детали попутно ближе знакомясь с ребятами.
Для себя я решил выделить из разработчиков пару ребят, кто связно и просто излагает, а также хорошо разбирается в проекте, и на первом этапе в случае любой непонятности спрашивать их совета. ПО рассказал о приоритетах.
Первые два дня члены команды написывали мне без перерыва: какую задачу взять следующей, где уточнить описание, здесь непонятно, там непонятно, кого спросить, куда смотреть. В ответ, устав писать, я просто звонил им. То есть, реально, я постоянно с кем то общался, кто-то от меня чего-то хотел и что-то просил. Хотелось просто сказать некоторым коллегам, ну отстаньте уже. Я же только недавно выдал задачу, а ты опять появляешься и что-то от меня хочешь. Может быть ты еще некоторое время ей позанимаешься и не будешь меня сегодня больше беспокоить?
Это было ну совсем не похоже на тот режим в котором я жил до этого — быстро написал свой код, всё работает, можно спокойно идти дальше загорать и купаться.
Начало приходить понимание, что когда ты отвечаешь за результат на всем проекте, да еще и не можешь на него напрямую влиять, для ответственного человека без здорового пофигизма это — головная боль.
В целом это напоминало мне управление большим кораблём, как мне представлялось ранее, только с тем нюансом, что вместо выбора курса постоянно приходилось выбирать кто из членов экипажа пойдёт затыкать очередную пробоину, при этом, в процессе затыкания их становилось не меньше, а больше, а ощущение хаоса только усиливалось. Как в анекдоте: было четыре бага, один исправили — стало шесть.
За неделю я начал испытывать почти что страх перед теми разрабами, кто хорошо и быстро справлялся с задачей. Мне снова требовалось уделять им время.
Любимыми же разработчиками были для меня те, кто брал таску и не трогал меня хотя бы полдня (а лучше день).
В итоге, прошла неделя, подумал я подумал, и решил что не для того роза цвела не для того я кучу лет прокачивал хард скилы, чтобы наконец стать начальником и пахать так, как будто этих 10 лет не было. Подумав два дня в понедельник утром написал ПО, что с задачей я не справляюсь, энтузиазма к этому ни в малейшей степени не испытываю и вообще мне очень жаль, но заниматься этим больше не буду.
Видимо со стороны мои действия не казались провальными, а движ, который я успел развести производил впечатление адекватного, но в ответ мне предложили, что бы вы думали, да — больше денег. Вероятно наниматель решил, что в связи со сложностью/запущенностью проекта я нибиваю цену. Но всё было проще, я хотел дальше писать любимый код попивая смузи на берегу моря, а не вот всё это ?. Я отказался, и оглядываясь назад очень рад такому решению.
На что обратить внимание будущему тимлиду
Расскажу о своих выводах, которые я сделал после опыта управления командой. Иначе говоря, что бы я сделал, если бы знал всё заранее.
Уровень скиллов команды
Мне стоило поинтересоваться, что с самоорганизацией команды, насколько плотная поддержка нужна разработчикам. Одно дело — распределять приоритеты и удерживать фокус, другое — загружать разработчиков 4 раза в день.
Сейчас я бы расспросил, куда делся предыдущий тимлид, узнал заранее о процессах, взвесил все расклады и включил критическое мышление, когда мне предложили сходу занять руководящую позицию.
База по управлению
Было бы лучше, если бы я сначала прошёл обучение по управлению командой. Книги, подкасты или хороший курс, чтобы понять, какие модули подтянуть перед стартом. До перехода можно попробовать себя в роли спикера, лидера сообщества, организатора.
Какого-то негатива или сомнения в моих профессиональных качествах от коллег я не заметил. Вероятно, со стороны мои действия выглядели вполне уверенно, но внутри я не ощущал себя лидером.
Адаптация в роли лидера
Я стал тимлидом без онбординга. Меня забросили в середину океана, чтобы я выплыл сам. Думаю, минимум месяц нужен, чтобы разобраться, как перестроиться с написания кода на управление.
Если в компании нет наставника или вводных, значит процессы не отработаны. В идеале нужно поучиться, понабирать стартовых задач, походить и посмотреть, как строит работу состоявшийся тимлид в этой компании.
Искреннее желание управлять
Я мог бы справиться, если бы поставил себе цель, но я начал понимать, что мне не по душе такой темп и суета. Мне было жаль потраченных сил и времени, если сравнить с прошлым опытом в разработке. Я понял, что надо увольняться, ломать себя дальше ни к чему хорошему не приведёт.
Готовность пахать
Возможно что быть хорошим руководителем — это склонность, заложенная в характере. Я трудолюбив. В каждом проекте, по мере накопления задач я выхожу на некую крейсерскую скорость, когда задачи решаются просто и быстро и не вызывают затруднения. С тимлидством так не получится. «Буду всех пинать, чтобы работали, а сам сидель балдеть» — это заблуждение. Нагрузка снижается в другом темпе. Нужно долго отрабатывать стиль управления, технические нюансы, и только потом, возможно, станет хорошо.
Согласие терять харды
Если ты хороший разработчик, сможешь писать код где угодно. А если ты тимлид, знакомый с флоу одной компании, в другой всё равно надо будет вникать в кучу процессов. Ещё ты забываешь разработку, а это куда более универсальный скил, который легче продать (я так полагаю).
Технологии не стоят на месте, на фронте каждый год появляется что то новое, меняются подходы, новые фишки, фреймворки. Ты выпал на 1-2 года, навык уходит, ты потихоньку начинаешь забывать что-то. Как будто бы ты перешёл в тренеры, вдохновляешь подопечных, радуешься их успехам и тихо деградируешь.
Что сейчас я бы сделал по-другому
Если бы взялся снова, отнесся бы к делу спокойнее, не ждал бы налаженных процессов или "работает, как часы" сразу. Это было бы хорошим результатом, например, через год.
На некоторое время предоставив подчиненным большую свободу действий, (пусть тащат из пула задачи на выбор), я бы разобрался с тем, какой продукт или фича являются приоритетными, за что конкретно и когда с меня будут спрашивать. Далее исходя из этого, планировал бы загрузку подчиненных и оптимизацию процессов.
Если не тимлид, то кто
Завязав с тимлидством я спокойно возобновил поиск работы и очень скоро вернулся к жизни фронтендера. Благо вакансий было (и есть) реально много. Сейчас делаю приложение для сотрудников Альфа-Банка. Уже полтора года даже не смотрю в сторону управления. Нагрузка вырастет, а зарплата практически не изменится.
Я убрал из портфолио строчку «тимлид». На собеседовании упоминаю, что опыт был, но я не горю желанием его повторять. Отказов или неудобных вопросов из-за этого я не получал, нормальные разработчики нужны всегда.
В обозримом будущем останусь разработчиком здесь или там.
Есть вариант — пойти в техлиды. Близко, интересно. Сейчас например развиваюсь в сторону написания мидлов (backend-for-frontend). Это шаг в сторону бэка, я начинаю понимать, как что устроено.
Задумываться о будущем однозначно надо. Это нормально, когда ты пишешь код в 20, 30, 40. Но ты же не сможешь писать его вечно? Захочется снизить нагрузку на глаза, сменить образ жизни на более подвижный, и вообще сидеть целый день перед компьютером вредно. В IT более чем реально накопить на старт какого нибудь своего простого, например торгового бизнеса, который не предусматривает большого вовлечения по времени. В общем буду думать в этом направлении. Всем спасибо )
Делитесь своими карьерными историями в комментариях. И до встречи в следующих статьях.
