01 ноября 2019

"Алло, мы ищем Team Lead-a!"

Всем привет.

Прошло 3 года с момента, когда я последний раз выходил на рынок труда (и написал по этому поводу статью), и вот я на нём уже опять. За это время я прошёл путь от Java программиста до руководителя всего отдела разработки компании Smilart, который включал в себя исследователей, админов и программистов.
Но в этот раз всё стало сильно серьёзней: мало того, что с работы пришлось уходить прямо "в никуда", так и всплыли настолько неприятные нюансы поиска работы на позицию Team Lead-a, что чуть не завели меня в депрессию. Но обо всём по порядку.


Начитавшись всяких книжек про "правильных" руководителей, посмотрев доклады с TeamLead Conf, я занял, как мне казалось, достаточно правильную позицию: в компании есть хорошие программисты, которые в состоянии забороть любую проблему на уровне кода, но есть куча других вопросов и задач, на хорошую проработку которых постоянно не хватает времени, но они критически важны - проектирование API и архитектура (и надо потратить кучу времени просто на изучение этих вопросов), постоянный анализ того что мы строим и куда идём, CI и подходы к тестированию нашего специфичного софта, регламенты работ и взаимодействия с бизнесом, разработка всякого полезного внутреннего инструментария и прототипов. Вот этим списков "непонятного" я и решил заниматься, помимо непосредственно управления разработкой. И было всё классно: пока ребята активно фигачили "понятное" иногда всё-таки прерываясь "на подумать со мной" в сложные моменты (не могу сказать, что всем нравились эти моменты brainstorm-а, потому что они возникали только в ситуациях, когда реально не было очевидных правильных решений, что приводило к замедлению темпа разработки и небольшой демотивации команды), я прикладывал все усилия, чтобы поток создания ценностей для продукта был максимальным, давал максимальную свободу в реализации. И все, как мне кажется, были счастливы: программисты писали код под максимально проработанные идеи иногда обсуждая вместе тонкие моменты, бизнес получал качественные фичи в максимально короткие сроки, а я занимался интересными мне концептуальными вопросами в разработке ПО, много читал и изучал нового и мало того, что не писал проектов на Java (только немного на Golang и ClojureScript), так можно сказать, что не писал его вообще (как минимум по сравнению с теми объёмами, когда был непосредственно программистом).
Я очень надеялся, что так будет вечно, но у песца были свои планы. И вот я на рынке труда.

Очевидным для меня решением было подаваться на аналогичные позиции Team Lead-a. Мне казалось, что вложенные мне в голову мысли о том, чем человек на этой позиции должен заниматься и какими навыками обладать, помогут мне быть достаточно конкурентноспособным, и я был в общем согласен с тем, что продвигаемые в обществе идеи верны: концентрация на людях, процессах создания ценности, работе с бизнесом, а имеющийся технический бэкграунд позволит выполнять роль помощника команды при решении сложных высокоуровневых и концептуальных задач, которые встречаются у всех. То есть такие люди нужны всем и меня с руками оторвут хотя бы на российском рынке труда :)
Но тут реальность показала совсем другую картину.

Таких вакансий очень мало в принципе

Ну это достаточно логично, что руководителей должно быть меньше, чем работников. Должен быть где-то один руководитель на 5-10 человек. 
Но в той же Москве 2000 вакансий Java разработчиков и только 77 вакансий Java Team Lead. Причём этот коэффициент (1 на 20 и больше) характерен и для других регионов. В крутых компаниях этот коэффициент ещё меньше, что не может не огорчать. Возможно влияние тут оказывает и то, что руководители редко меняют компании в принципе: как выдался шанс занять руководящую должность с соответствующими бенефитами, так и не спешат слезать с насиженного места.

Вывод: на рынке этих вакансий достаточно немного, если вообще есть в вашем регионе.

"Мы предпочитаем выращивать этих людей внутри компании"

Тоже достаточно известный факт, если интересоваться этой областью в принципе. И причины понятны: когда человек "свой", то и доверия к нему больше, он знает всю внутреннюю кухню компании и у него возможно даже нет проблем с авторитетом среди бывших коллег. Но тут есть другая известная проблема: когда из самого лучшего разработчика мы делаем менеджера, то можем получить в итоге минус один хороший разработчик и при этом плюс один плохой менеджер. Но если человек сам идёт на эту позицию осознанно, у него всё хорошо с soft skills, то может получится отличный вариант. Но какая вероятность, что звёзды так успешно сойдутся?

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

"У нас нет должности Team Lead-a"

Как оказалось, у некоторых компаний нет таких позиций в принципе. У них scrum команды, где каждый занимается всем подряд, из выделенных ролей только product owner, который выступает неким лидером, но он не про технологии или саму команду, а только про продукт.
Ну круто, что сказать. Хоть у кого-то есть "самоорганизующаяся команда профессионалов ...", всё как по заветам отцов Agile.

Вывод: некоторые компании пытаются провести эксперименты с плоскими иерархиями и самоорганизующимися группами, соответственно в них ты как руководитель совсем не нужен.

"Всё замечательно, но у вас не хватает опыта разработки в <язык программирования/технология>"

И вот это самый проблемный пункт: в очень большом числе вакансий, которые публикуются для поиска руководителя группы, на самом деле преследуют задачу поиска техлида. В этих вакансиях стоит просто "запрещающий" набор требований и навыков. По сути, ты должен быть самым крутым разработчиком в команде в первую очередь. Видел такие комбинации в рамках одной вакансии как "профессиональное развитие членов команды" и "написание Unit тестов". И это для руководителя группы. Не скажу, что чем-то из этого я не умею заниматься, но это как минимум подозрительно видеть такой разброс в задачах.
В моей предыдущей картине мира есть команда, в ней есть хотя бы один техлид, который может запилить что угодно самостоятельно и выступает основным консультантом по кодовой базе, техническим вопросам и используемым технологиям, и есть руководитель, который больше про людей, процессы, анализ и взаимодействие с бизнесом. Команда весело пилит фичи и постепенно развивается, техлид упарывается по технологиям и программированию, team lead - по людям, процессам и бизнесу.
Как я недавно узнал из одного митапа для техлидов от Яндекса, за рубежом как раз часто принято разделять должности техлида и team lead-a (видимо там народ начал о чём то догадываться), а у нас по прежнему культ превозмогания и челленджа. Как мне кажется, это просто давняя традиция бизнеса играть на чувстве гордости программистов - "А тебе слабо ещё и вот этим заняться?" Нам же прикольно решать сложные технические задачи, почему бы не загрузить нас ещё чем то полезным. "Всё для бизнеса, всё для победы!"
Не поймите меня неправильно - я не считаю органичным, когда люди не проходят все ступени развития в отрасли. Иметь технический бэкграунд чтобы управлять командой точно нужно по разным причинам, но стоит ли делать на это такой упор на позиции руководителя? Как минимум есть вопросы насчёт осуществимости этой идеи в плане того, что голова у человека тупо не резиновая помнить все детали всех областей, которыми ты когда-то занимался. Это как с computer science - не обязательно помнить от туда всё, главное знать основные вещи и знать как искать детали.
Так и тут. В какой то момент ты перестаёшь мыслить библиотеками и языками программирования, а оперируешь сервисами и людьми, которые эти сервисы создают. Только повышая уровень абстракции можно бороться со сложностью разработки ПО. Для всего остального есть техлиды :)

Вывод: если хотите хорошо трудоустраиваться, то вам не стоит отходить от "сохи" далеко. Все эти пропагандируемые идеи про важность команды, людей и процессы пока что не находят существенного отражения в подавляющем большинстве сознании тех людей, кто строит компании и нанимают в них. В лучшем случае, ваше понимание, что вы работаете не с роботами, а с людьми и делаете продукт, будет восприниматься как приятный бонус. Самое забавное, что все эти навыки вам гарантированно пригодятся в реальной работе и в существенной степени помогут вашей команде, но сейчас они точно идут в разрез с той одёжкой, по которой большинство компаний встречают. На текущий момент у меня сложилось ровно такое впечатление. Есть приятные исключения, но их немного и мне пока не повезло с ними встретиться или согласиться на их условия. На рынке так мало толковых разработчиков, что все пытаются нанимать именно их в первую очередь, называя их как угодно. Про общую зрелось бизнес-процессов в нашей отрасли и говорить не буду, нам есть куда расти.
Ещё есть нюанс, что в некоторых компаниях названия должностей напрямую привязаны к зарплатной ставке. Соответственно предложить большую котлету денег можно только назвав человека Team Lead-ом.

Общие выводы


  • В общем, не надо вам в team lead-ы ;-)
  • Всегда думайте наперёд - а что вы получите на выходе с текущей должности, о чём сможете написать в CV по результатам работы.
  • Уход в нишевые области -  это достаточно рисковые инвестиции, которые надо для себя как-то обосновывать. Чем выше риски, тем выше должно быть вознаграждение и нужно ли предлагаемое вознаграждение конкретно вам.
  • Постоянно отслеживайте тренды и не отрывайтесь от рынка слишком далеко, чтобы сохранить привлекательность для работодателей.
  • Если на новой должности вам предлагают дополнить свой багаж новыми знаниями - подумайте, не вывалится ли из него что-то уже полезное.


Очень надеюсь, что со временем весь этот разброс и шатание пройдут. Забавно, что эта ситуация напоминает аналогичные проблемы с devops - каждая компания понимает его по-разному. Надеюсь, что компании поймут ценность процессов и работы с людьми и начнут называть всё своими именами. А пока, я решил срочно возвращаться в разработку, чтобы восстановить свои навыки и устроиться на хорошую работу. Буду надеяться, что все те светлые идеалы про команды и процессы не успеют забыться, когда я вернусь на ту позицию, на которой смогу наносить непоправимую пользу в максимальном масштабе :)

7 комментариев:

  1. Спасибо за пост.

    А можно пожалуйста немного поподробнее про обязанности тимлида? Я к сожалению пропустил этот раздел литературы про разработку :)

    [В моём понимании] проектирования апи и архитектуры на одну команду не так уж много (максимум четверть рабочего времени + раздумья надосуге). Если команд много и задачи появляются каждый день, тогда да - но этим обычно уже занимаются архитекторы. Вот и получается, что то, что тут описано, это либо это должность менеджера проекта в постоянном взаимодействии с другими проектами, либо архитектора в той же ситуации.

    Что я упускаю?

    ОтветитьУдалить
    Ответы
    1. Дополнительные задачи (кроме как управления разработкой) разнятся от компании к компании, если не даже не между группами. Поэтому приходится заниматься тем, что выгоднее с точки зрения трудозатрат в конкретной команде.

      Удалить
    2. Ворвусь со своей ссылкой – https://github.com/tlbootcamp/tlroadmap. Мы тут проинтервьюировали кучу разных компаний, задавая им вопросы о том, что они ожидают от тимлида. Из того, что получилось, сформировали большой майндмеп, который как раз на этот вопрос и отвечает.

      Удалить
    3. Вот посмотришь на это дерево, особенно на ту часть, что под Техлидом и хочется свернуться в клубок и заплакать.
      Ну как это всё уместить в голове, особенно если ты занимаешься более-менее серьёзным backend-ом.
      С одной стороны, компаниям никто не запретит хотеть чего-то подобного от кандидатов и реальный рынок вакансий заставит их подкорректировать требования,
      как только они увидят, что очередь к ним как то не то что не выстраивается, так и люди сами отказываются проходить такой жесткий отбор.
      С другой стороны - видимо есть люди, которые всё это умеют. Ну не из воздуха (я надеюсь) эти требования взялись.
      В любом случае - с таким подходом ни тимлидам хорошо не будет: хрен куда устроишься по таким требованиям и будешь вынужден всеми силами держаться за прежнее место, ни компании никого не найдут.
      Оно нам точно надо?

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

    ОтветитьУдалить
  3. Логично дальше расти - в архитектуру )))
    А работу то нашли в итоге?

    ОтветитьУдалить
    Ответы
    1. Почему в архитектуру?
      Есть пара местных вариантов. Надеюсь, что в декабре уже выйду на работу.

      Удалить