Привет! Меня зовут Абакар, я работаю главным техническим лидером разработки в Альфа-Банке.
В этой статье я хочу поделиться своим опытом: рассказать о специфике моей позиции, ключевых сложностях и подводных камнях. Возможно, это поможет тебе снять розовые очки — особенно если ты сейчас задумываешься о том, чтобы стать техническим лидером.
Тему также я разбирал в видео на YouTube — буду рад, если посмотришь !)
А помогать мне сегодня будет наша любимая четверка пингвинов.
1. Точно ли тебе это нужно ?
Самый первый вопрос на который стоит ответить самому себе это: «Точно ли тебе это нужно и какую цель ты преследуешь ?» На такой вопрос может быть много ответов.
Например:
Финансы. Зарплата техлида обычно выше, чем у разработчика. Но конкретные цифры зависят от компании и ваших навыков переговоров.
Ответственность. Желание брать на себя больше решений и влиять на продукт, а также получать ценный опыт.
Карьера. Восприятие лидерства как следующей ступени роста.
Как понять, что хочешь повысить доход? Здесь всё субъективно: кто-то просто хочет покупать более дорогие вещи, а у кого-то долгосрочные цели вроде инвестиций, в том числе в самого себя.
Что даёт этот опыт? Навыки технического лидера полезны даже вне работы. Такая позиция прокачивает общение, стратегическое мышление и умение обучать других. Даже если потом вернёшься в разработку, этот опыт останется с тобой.
Разобравшись с мотивацией, ты поймёшь, какие факторы важны для движения к цели. В моём случае главным стимулом было желание быть лидером, помогать команде решать проблемы и создавать сильные технические решения. Такой опыт не только полезен сейчас, но и улучшает финансовые перспективы в будущем.
Возможно, после этих размышлений ты пересмотришь своё решение. Например, повысить доход можно не только через лидерство. В любом случае, всегда можно попробовать и вернуться назад. Я знал разработчиков, которые становились лидами, а потом снова переходили в разработку — это нормально.
В любом случае всегда можно попробовать и вернуться, если поймешь, что это не твое. На моей памяти я знал двух разработчиков, которые ходили в лиды, а потом возвращались и это вполне нормально.
Вывод: для начала определись на 100 %, хочется тебе пробовать себя на позиции технического лидера или нет :)
2. Техническая подкованность
Бывал ли ты на позиции senior-разработчика или работал с такими специалистами? Если да, то наверняка заметил, что у них сильный технический бэкграунд. Они умеют решать сложные проблемы и глубоко разбираться в вопросах. Я даже писал статью про один особенно запутанный кейс.
Как техлид, ты тоже должен уметь решать такие задачи. Если в твоей команде есть senior-разработчики, они придут за помощью именно к тебе — и ты должен быть готов. Без технической экспертизы сложно оценивать уровень подчинённых и действовать в критических ситуациях.
По опыту работы техлидом мне приходилось погружаться в недра фреймворка, решать проблемы с технической реализацией наших внутренних библиотек, помогать разработчикам решать проблемы отрисовки и обратной совместимости приложения, помогать разработчику понять какое из существующих решений наиболее оптимально и принесет меньше проблем в будущем. Если посмотреть на этот список, то для всего этого нужно быть технически подкованным.
Вывод: если ты думаешь, что технический лидер не погружается в технические вопросы глубоко и за него это делают разработчики, то ты довольно сильно ошибаешься. Возможно, позиция технического лидера это не то, чего ты на самом деле хочешь.
3. Отстаивание своей позиции
Часто придётся сталкиваться с разными мнениями. Важно не просто отстаивать свою позицию, но и аргументировать её, чтобы найти лучшее решение. Самый простой пример:
Команда хочет вынести логику по расчёту процентов по вкладу на фронт приложения (фронты — Android/iOS/веб).
С одной стороны, лиды мобилок и веба могут быть против, так как такую логику в идеале необходимо хранить на бэкенде — она может меняться.
А если она меняется, то придется релизить три платформы вместо одного бэкенда.
Но есть момент, в том, что пользователю будет гораздо комфортнее видеть расчеты процентов без лишних запросов на бэкенд, так как это будет банально быстрее.
Вот мы и пришли к тому, что техлид выбирает то, что будет выгоднее для достижения общей цели, а не только отстаивает свою позицию.
Бывают и обратные ситуации. Например, когда фичу просят выпустить без тестирования и ревью. Здесь нужно стоять на своём, даже если бизнес давит. Конечно, большой бизнес может тебя и прожать, но биться нужно до последнего.
Вывод: если тебе не нравится объяснять людям свою позицию и почему ты так рьяно отстаиваешь ее или у тебя вообще не бывает какой-либо четкой позиции, возможно, работа техническим лидером будет приносить тебе разочарования :)
4. Стратегическое мышление
Стратегия важна, но нужен баланс.
Если ты постоянно зависаешь в задачах, которые дают краткосрочную выгоду и совсем не думаешь о будущем, будет не очень.
Если ты постоянно витаешь где-то в облаках, помышляя о грядущих делах, проблем также будет много.
Допустим, ты — лид команды Android-разработчиков. Каждый релиз ты тушишь баги в проде, но не улучшаешь процессы. В какой-то момент нужно остановиться и спросить: «Почему багов так много?» Может, проблема в ревью, CI или взаимодействии с тестировщиками. Найдя причину, нужно её устранить — иначе прогресса не будет и ты станешь белкой в колесе.
Эта ситуация похожа на ту самую притчу про пилу:
Некий человек увидел в лесу дровосека, с большим трудом пилившего дерево совершенно тупой пилой. Человек спросил дровосека:
— Уважаемый, почему бы вам не наточить свою пилу?
— У меня нет времени точить пилу, я должен пилить, – простонал дровосек.
Отсутствие стратегического мышления очень похоже на ситуацию из анекдота: если ты постоянно сосредоточен на решении локальных проблем, то твоему отделу просто не будет хватать времени на развитие, как и тебе самому.
Вывод: если не умеешь вовремя остановиться и подумать наперед, то тебе будет сложно на позиции технического лидера)
5. Фокусировка внимания
Становясь техлидом, ты превращаешься в «селебрити» проекта.
Давай рассмотрим на примере. Когда ты разработчик в фичевой команде, к тебе может приходить продакт твоей команды, или твой напарник с другой платформы, или тестировщик. В целом, плюс-минус, на этом регулярные коммуникации заканчиваются.
На позиции технического лидера в тебя будут влетать с разного рода вопросами: разработчики, технические лидеры других направлений, продакты команд, тестировщики, аналитики, дизайнеры и этот список можно продолжать дальше.
Давай посмотрим на абстрактный пример рабочего мессенджера какого-нибудь техлида (все совпадения случайны)
Разработчик 1: «О чёрт, все пропало! Помнишь, я вливал в релиз свою доработку? Кажется, она сломала нам прод».
Разработчик 2: «Блин, да этот разработчик N вечно придирается ко мне на ревью, так и хочется пойти поругаться с ним».
Продукт овнер: «У нас тут такая интересная идея: хотим пользователю после негативного отзыва на наше приложение блокировать использование телефона. Чтобы ему неповадно было нам плохие отзывы оставлять. Крутая идея?»
Дизайнер: «Прикинь, что придумали для нашего Android-приложения: сделаем градиентный экран, который начнет проигрывать популярные хиты 90-х годов и главное, чтобы экран выглядел точь-в-точь как на iOS».
Специалист сопровождения: «У нас тут критичный баг, неизвестно какая команда, нужно срочно починить».
Понятно, что выше приведён сатиричный и гиперболизированный пример. Но это похоже на то, что происходит в мессенджере лида (если увеличить в несколько раз количество входящих сообщений). Осталось это сверху приправить большим количеством созвонов.
Знаешь, что самое интересное? Придётся научиться их всех игнорировать.
Важно уметь не реагировать на всё и сразу. У тебя в голове должен быть чёткий план по твоим приоритетам (который можно обговорить со своим руководителем).
К примеру, если тебе написали 10 разработчиков и у каждого свои проблемы, важно уметь в первую очередь ответить тем, кто решает задачи, которые у тебя сейчас в приоритете. Никто не будет рад, если ты начнёшь успешно решать проблемы всех и каждого, но при этом проваливать свои личные цели, которые ты согласовал со своим руководителем.
Также важно выращивать личностей в своей команде, которым можно будет делегировать те или иные вопросы, — это тоже сильно поможет облегчить жизнь.
Вывод: если тебе не нравятся коммуникации с другими людьми, не стоит рассматривать позицию технического лидера. Коммуникаций будет много :)
6. Конфликты
Конфликты неизбежны.
Вообще конфликтовать приходится, даже если ты просто разработчик в фичевой команде. На позиции разработчика, если тебе совсем не нравятся конфликты/споры, можно от этого отгородиться, и этим будет заниматься технический лидер.
Важный дисклеймер. Я говорю о здоровом конфликте, когда вы в ходе дискуссии пытаетесь прийти к консенсусу. Не стоит бояться таких конфликтов, нужно наоборот хотеть их и учавствовать в них. Хорошие решения невозможно принимать без конфликта и дискуссии. Это важный момент.
Техлид должен уметь дискутировать. Если боишься конфликтов, тебя будут «продавливать» на неоптимальные решения. Если не любишь конфликты, то работа технического лидера будет постоянно выжигать тебя, и ты так долго не продержишься.
Давай рассмотрим пример, с которым я сталкивался довольно часто, и как разработчик, и как технический лидер. Кто-то захотел вкинуть задачку твоему разработчику, но ты видишь, что она не ложится ни в вашу техническую стратегию, ни в потребности продуктовой команды этого разработчика. В такой момент нужно встать на защиту своего подопечного, даже если это приведёт к конфликтной ситуации. Естественно, свою позицию нужно отстаивать, не переходя на эмоции.
Вывод: если ты боишься или не любишь конфликты, не стоит становиться техническим лидером :)
7. Борьба за ресурсы
Ресурсы всегда ограничены.
На позиции технического лидера за них придется побороться. Допустим, ты понимаешь, что определенную техническую фичу нужно реализовать как можно быстрее, так как это в будущем принесет большую пользу проекту. «Нам очень нужно вложиться в ускорение отрисовки контента на экране, так как по нашей аналитике пользователь уходит с экрана уже через 3 секунды ожидания, если он не увидел контент».
И в этот момент критически важно доказать человеку, который распределяет ресурсы (CTO, CIO, etc...), что именно твоя задача важнее остальных. И если ты умеешь доказывать свою позицию на основе метрик и зафиксированных показателей, то тебе поможет этот навык.
Но как бы ты не подготовил цифры, все равно есть вероятность, что тебе откажут. К этому нужно быть готовым, главное в такие моменты не опускать руки.
А как доказать, допустим, что именно твой подчиненный больше заслуживает инкриза по зарплате, чем разработчик из соседнего направления или проекта? И таких примеров у тебя наберется большое количество.
Вывод: если ты не выносишь борьбы за ресурсы и заниматься рутиной по нахождению нужных метрик, не стоит становиться техническим лидером :)
8. Стрессы
Стресс — часть работы.
Можно сказать, что стрессы бывают и на позиции обычного разработчика. Но там их сильно меньше.
На позиции технического лидера тебе часто придется сталкиваться с большим количеством неопределенности, с ограниченными сроками, с ошибками разработчиков и со своими ошибками тоже. При всем при этом ещё нужно думать о том, чтобы развивать своих разработчиков. Не просто составить условный ИПР (индивидуальный план развития) и благополучно забить на него, а действительно вести работу над слабыми сторонами разработчика и давать ему адекватную обратную связь.
Как я уже писал выше, теперь к тебе довольно часто будут заходить за той или иной информацией. Все это приводит к стрессам и тут есть только один рабочий вариант.
Не принимать ничего близко к сердцу, делать свою работу как профессионал.
Если ты знаешь о проблеме, сделай всё, что в твоих силах для её решения. Она может разрешиться. А может и не разрешиться. Но в обоих вариантах нужно быть спокойным.
На моей практике был пример, когда мы отдавали в релиз важную техническую функциональность и выяснилось, что мы не учли большое количество нюансов, с которыми пришлось разбираться в ускоренном варианте. И к слову, мы успешно со всем справились. Если бы я в том кейсе сильно нервничал и не спал по ночам помогло бы это решить проблему?
Нужно уметь вовремя отпустить ситуацию и спокойно лечь спать, чтобы на следующий день решать проблему с новыми силами.
Вывод: если не умеешь справляться со стрессом, то к сожалению позиция технического лидера сильно ударит по твоему здоровью и ты на ней долго не удержишься.
9. Увольнения
Это часть работы.
Одна из самых сложных для меня частей.
Когда я был разработчиком, то уровень перформанса и компетенций зависел только от меня (что довольно прикольно и удобно). А о техническом лидере очень многое говорит его команда, поэтому об уровне технического лидера судят в том числе по уровню его команды.
Я уже писал выше о том, что технический лидер должен вкладываться в развитие своих разработчиков, но бывают кейсы, когда как ни старайся не получается вывести человека на необходимый уровень перформанса. В таком случае и для разработчика, и для компании лучшим вариантом будет расстаться. Возможно, человеку не очень подходит сама компания, и в другой он расцветет и станет топ-перформером. Либо человеку в данный период жизни просто не достаёт необходимого уровня концентрации, такое тоже вполне может быть.
Важная задача техлида не затягивать этот момент. Если понимаешь, что смысла бороться дальше нет — как можно скорее расставаться, чтобы не тратить впустую и свое время, и время разработчика. Если техлид не будет заниматься такой работой, то он очень быстро пойдет на дно вместе со своей командой.
Вывод: увольнения на позиции техлида — это часть работы, её нужно просто принять.
10. Ты — пример
Когда становишься техническим лидером, то не просто получаешь новую должность — ты превращаешься в ролевую модель для своих разработчиков. Они неосознанно копируют твои привычки, манеру общения и даже отношение к работе.
Давай посмотрим на несколько примеров, они конечно утрированы, но зато довольно наглядные:
Если ты грубишь коллегам или игнорируешь вопросы, разработчики начнут вести себя так же.
Если открыто признаёшь ошибки и спокойно принимаешь критику — команда научится конструктивному диалогу.
Ты пропускаешь сырой код в релиз? Команда решит, что «и так сойдёт».
Требуешь тщательного ревью и тестирования? Разработчики начнут серьёзнее относиться к своей работе.
Не разбираешься в новых технологиях? Команда тоже перестанет развиваться.
Кричишь, когда что-то идёт не так? Команда будет бояться сообщать о проблемах.
Разработчики будут невольно перенимать твою манеру общения с коллегами, отношение к смежным направлениям и так далее. Ты просто обязан быть профессионалом соблюдающим все нормы этики.
Вывод: ты — пример, стоит вести себя подобающе. Об этом всегда нужно помнить. Тебе необходимо сдерживать свою агрессию или контролировать манеру общения в тех или иных случаях. Если тебе от этого некомфортно возможно не стоит думать о позиции технического лидера :)
P.S
Это все был лишь свод рекомендаций, а не жесткий набор правил. Принимая решение исходи только из того, что ты хочешь и как ты думаешь. Если хочешь стать техлидом — дерзай!
