Привет! Меня зовут Абакар, я работаю главным техническим лидером разработки в Альфа-Банке.

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

Тему также разбирал в видео на 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.

Это всё был лишь свод рекомендаций, а не жёсткий набор правил. Принимая решение, исходи только из того, что ты хочешь и как ты думаешь. Если хочешь стать техлидом — дерзай!