Тимлид — это, как известно, глава команды, то есть руководитель подразделения. У успешного тимлида есть специфические компетенции, повышенные хард-скилы и множественные софт-скилы. Однако нужно ли, имея весь этот позитивный багаж, идти на роль тимлида? И можно ли со всеми этими качествами нанести пользу компании и себе, не занимая позиции тимлида?



‎Я расскажу, зачем не быть тимлидом, обладая при этом всеми необходимыми компетенциями. Расскажу о методе двух императоров, чтобы описать модель, когда в команде помимо настоящего тимлида есть «как бы» тимлид, человек с тимлидскими навыками. А также, поскольку тимлид не бывает бывшим, отдельно пройдусь по особенностям найма экс-тимлидов на синьорные позиции.


Откуда берутся тимлиды без команды


Расскажу на примере себя. Я давно в айти, после вуза занималась виртуализацией, была архитектором. Потом пришла в «Лабораторию Касперского», сменив сферу деятельности с архитекторской на микрокернел. Так и сдауншифтилась — была тимлидом, стала синьором. Поэтому статья, которую вы читаете, — не только рассуждения, но и личный опыт.

‎Мой сценарий дауншифтинга не единственный. Иногда тимлид сохраняет сферу деятельности и даже компанию — но должность меняет на синьорскую. А еще бывает, что синьор уже дорос до тимлида, но пока не получил повышения и тимлидских обязанностей.

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

Тимлид и синьор: сходства и различия


Для начала хочу проговорить прописать, чем отличаются должности тимлида и синьора в практическом плане.

Что делает тимлид


Я пообщалась с коллегами-экс-тимлидами, и мы стали вспоминать, что высокий статус бывает проблемой при найме. Компании говорят: чувак, у тебя слишком много софт-скиловых навыков, ты оверквалифайд для нас, мы тебя в синьоры не возьмем.

Что это за навыки?
  1. Развитие команды.
  2. ‏‏Проведение собеседований.
  3. ‏‏Внедрение лучших практик разработки.
  4. ‏‏Отчетность и оценка.
  5. ‏‏Сопровождение компонента и работа с техподдержкой.

Я поглядела, чего хотят от тимлидов на хедхантере, и обнаружила дополнительные требования (иногда весьма забавные):
  1. Участие в церемониях.
  2. Проведение тимбилдингов.
  3. Ведение документации.
  4. Описание моделей взаимодействия функциональных подразделений в рамках выделенных ‎‏‏‎процессов. (Вам не кажется, что это даже выговорить трудно?)
  5. Работа с обратной связью и ожиданиями со стороны команд заказчика.
  6. Актуализация и контроль соблюдения регламента разработки.
  7. Согласование с заказчиком готовой работы.
  8. Создание презентаций.

А еще ведь хард-скилы:
  1. Обеспечение безопасности, доступности, надежности, отказоустойчивости и прочих QA для своего компонента.
  2. Ревью кода.
  3. Декомпозиция задачи.
  4. Разработка функционала.
  5. Оценка сроков реализации.
  6. Управление бэклогом.

Короче, тимлид делает много. Очень много.

А что делает синьор


В том же хедхантере читаем, что должен делать синьор. Три пункта!
  1. Разработка многопоточных [отказоустойчивых, масштабируемых — нужное подчеркнуть] информационных систем
  2. Сопровождение существующего ПО компании
  3. Тестирование результатов работы

Четвертый — участие в чем-нибудь опционально. А у тимлида четыре собеседования по три часа в неделю! И остальные задачи тоже никто не отменял.

Вывод безжалостен: синьор — более расслабленная, лайтовая, приятная позиция.

«Сколько. Ты. Зарабатываешь?»


Что по деньгам? Мне понравились данные Хабр Карьеры за первый квартал 2022 года:

image

Клево, да? Вы не перепутали: ведущий разработчик, тимлид, получает меньше, чем синьор?

(Окей, окей, медианная зарплата больше у тимлида, ладно.)

Перекос случился, потому что сейчас синьоры очень нужны. Не всегда так будет. Но в любом случае разница останется небольшой.

Получается, вы апнулись до тимлида, получили больше административных обязанностей, даунгрейд по скилам — потому что тимлиды со всеми своими обязанностями не особо успевают кодить — и не получили при этом серьезной прибавки по деньгам.

Поэтому подумайте: вы точно хотите стать тимлидом? Или вам нужны деньги? Если деньги — лучше оставайтесь синьором и развивайтесь горизонтально, осваивайте новые области, получайте экспертную позицию.

На что хватит времени синьору и не хватит тимлиду


Я упомянула, что тимлиды не успевают кодить (по крайней мере, в том объеме, что им бы хотелось). Остановлюсь на этом поподробнее.

Кто не кодит, тот тимлид


Тимлиды не могут нормально погрузиться в архитектуру и дизайн. Сколько всего может опробовать синьор: новые фреймворки, подходы, паттерны, так построено, сяк, по-другому перестрою, попробую применить хоть и не в продакшене, но на уровне прототипа, хоть где-то… Когда на это есть время у тимлида? Да никогда. Новые фреймворки попробовать некогда! Даже не подходы, а просто фреймворки.

Совсем бросать кодить, конечно, нельзя. Тимлид должен уметь писать код. Но периодически нужно хватать себя за руку: если кодить слишком много, не останется времени на другие задачи, которые кроме тебя выполнить некому. Часто падает CI — кто опять здесь виноват? Нет, не ты. Но ответственен за то, чтобы починить, конечно, ты.

Получается, чтобы оставаться тимлидом, нужно продолжать кодить, но привыкнуть кодить меньше. Если это не для вас — опять же рекомендую вернуться на позицию синьора и расти по горизонтали, то есть развиваться в другой области. Это совершенно нормально и даже похвально: например, вот история, как мой коллега Евгений Мацюк вместо тимлидства изучил автотесты и создал Kaspresso — OpenSource-библиотеку для написания UI-тестов в Android.

Как начать расти по горизонтали


В первую очередь нужно понимающее начальство, к которому можно прийти и сказать: так и так, руководить — не хочу, освоить новую нишу — хочу. В «Лаборатории Касперского» мы поддерживаем подобные начинания — потому что хорошего тимлида против его (ее) воли не вырастишь, а синьоры-специалисты ничуть не менее ценны. Приходите к нам!

Не обязательно идти по проторенной тропе «Джун, мид, синьор, тимлид, менеджер» — предложим и опции горизонтального развития, и дауншифт на ваш вкус. У нас работает целая внутренняя система, в которой поддерживается профессиональный рост сотрудника, — для каждого ставятся цели и предлагаются карьерные возможности. А если вам нужно профессионально прокачаться — создадим полноценный индивидуальный трек обучения (подробнее — на странице наших бенефитов).

Поделитесь опытом, синьор!


Ну и немаловажно, что синьоры могут в свое удовольствие передавать опыт: ездить на конференции, писать статьи на Хабре, да хоть книгу свою. А где тимлиды в этот момент? Правильно, проводят тимбилдинги! Или работу согласуют с заказчиком. Ну и участвуют в церемониях, как любезно подсказывают вакансии на хедхантере.

Как управлять командой методом двух императоров


Есть византийская концепция старшего и младшего императора. Старший император — это человек (в нашем случае тимлид), который принимает решения. Младший император — наиболее вероятный преемник, а у нас — просто потенциальный тимлид, старшего смещать не обязательно :) Или вечный младший император, такой пожизненный принц, который комфортно расположился в роли младшего и на роль тимлида не стремится.

Также младший император может подменить, если старший заболел, или в поход ушел, или в отпуск. Не знаю, ходил ли император в отпуск, но мы, тимлиды, ходим :)

Я рассмотрю этот метод с разных позиций:

  • тимлида — как принимать в команду младшего императора и работать с ним;
  • опытного сотрудника — нужно ли приходить в команду с условным дауншифтом-тимлидом;
  • управляющего компанией — зачем вообще позволять складываться ситуации с двумя императорами.


Зачем нужен младший император


Итак, я старший император. Зачем мне этот софт-скиловый в команде? Польза от него будет? А если что-то не так пойдет — как отследить?

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

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

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

Получается, наш младший какую-то зону ответственности на себя взвалит и будет счастлив. А я, старший император, в свою очередь буду счастлив, что меньше нужно держать в голове и в руках.

image
Методологии разделения ролей

Я привела три самых известных методологии, но все люди разные, и методологий, которые описывают, насколько они разные, куча — выбирайте на свой вкус.

Красно-желтые флаги: что делать, если младший император делает не то, что вам нужно


Какие бывают проблемы с этим всем? Я разделила их на красные и желтые флаги. Красные — совсем не так, желтые — надо переосмыслить решение.

Желтые флаги
  1. Младший мало делает полезной работы. Вы рассчитываете, что мачурного товарища драйвить не нужно, а его разносит: все подряд интересно, но ничто не доведено до конца. В таком случае с младшим императором нужно поговорить — может, что-то изменится.
  2. Уменьшилась скорость ревью с участием младшего. Может, он хочет самоутвердиться (и это зло), а может, он искренне хочет помочь (и делает неумело). А может, он разглядел, что кто-то в команде на регулярной основе оставляет неинициализированные переменные, открывая новые возможности атакующему (и тут младшему честь и хвала).
  3. Стало больше конфликтов. Конфликты — это не плохо, но младшему своими действиями увеличивать их число не всегда полезно.
  4. Если решения принимаются не вами или в обход вас. Здесь стоит подумать: может, я не умею делегировать, разрешить человеку принять решение и взять ответственность? То есть флажок уже вам ;)

Красные флаги
  1. Первый красный флаг — появляется младший император и резко сокращается скорость принятия решений. Товарищ технически опытный, но из тех людей, которые не могут остановиться. Он идет в рисерч и копает, и уже нашли решение, но он не может остановиться.
  2. Другой красный флаг — настроения саботажа. Это когда после принятия решения у младшего возникли сомнения, которыми он решил поделиться не с вами, а с другими членами команды. Идеальных технических решений нет, и сомнения, может, и по делу, но колебания и смена стека зачастую дороже недостатков имеющейся системы. А расшатывание команды просто губительно.
  3. И наконец, иногда человек оказывается технически бесполезен. Взяли на техпозицию — а он просто не тянет. Печально, но что ж.


Зачем мне быть младшим императором


Рассматриваю две ситуации:
  1. Вы сознательно дауншифтитесь.
  2. Вы созрели стать тимлидом, но решили остаться синьором.

Прокачаться технически


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

Больше времени тратить на себя


Это другая точка ворк-лайф-бэланс. Принято считать, что, что бы ни происходило в другой нашей, нерабочей жизни, мы всегда на коне. А ведь иногда мы не на коне и не хотим быть. Может, мы хотим отправиться в Тибет открывать третий глаз. Может, хотим больше времени тратить на подготовку к ультрамарафону.

Изучить новую область деятельности


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

Вернуться в зону комфорта


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

Красно-желтые флаги: когда увольняться из младших императоров


Желтые флаги


  1. «Меня достало». Возможно, поможет отпуск, но возможно, у вас полноценное перегорание. Одно скажу точно — переходить на тимлидскую позицию в таком настроении не надо.
  2. «Хочу много денег и пива». Напомню свои слова: зарплаты сопоставимы, вряд ли вы станете заметно богаче. А если и станете — тимлидские заботы накроют с головой, не останется времени тратить деньги и пить пиво.
  3. «Мои заслуги никто не признает». Возможно, стоит вложиться в работу с психологом, но переходить на позицию тимлида — едва ли.

Красные флаги


  1. Первая история — это когда тимлид против моего вмешательства, бывает такое. Вы вроде договорились с человеком, и все шло хорошо, и вы были душа в душу — и тут вдруг (а может быть, с самого начала) «не ходи, не надо». Не умеет человек делегировать, не может он доверять. Все ваши начинания будут замыкаться.
  2. Вторая история — когда слишком много административки, состояние «прод в огне». Он горит, горит, и его надо тушить вашими человеко-часами. Времени у вас больше не будет — лучше уходите, пока не выгорели вместе с продом.
  3. И наконец, красный флаг другого рода — позитивный. Если вам хочется нести ответственность, вы чувствуете, что была команда — стала моя команда, был компонент — стал мой компонент, то вам нужно уходить из младших императоров. И становиться старшим — то есть тимлидом.


Зачем руководителю компании система двух императоров


Теперь с высоты птичьего полета — зачем в помощники к работающему тимлиду брать еще одного человека? Который тоже вполне себе и денег хочет, и грамотный.

Во-первых, у вас нет единой точки отказа. Говоря умнее — бас-фактор повысится. Это же круто!

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

В-третьих, два императора нужны, когда вы создаете большой компонент с большой зоной ответственности. Помните правило: архитектура продукта повторяет структуру организации, которая его разрабатывает? Слишком распределенная компания напишет микросервис. А если вы все в одной переговорке едите пиццу и пьете пиво, то, скорее всего, получится монолит, как бы вы ни сопротивлялись. Так вот, чтобы не получился слишком большой кусок монолита, который вы не сможете разделить, нужен младший император.

В-четвертых, в компании будет кузница кадров. Речь не только о младшем императоре, который станет старшим. У него могут быть собственные подчиненные. Вроде как это и не отдельная команда, потому что ответственный все равно старший император. Но при этом в случае чего младшего с его людьми можно отпочковать. И возможно, бросить на другие задачи.

Например, у нас была команда, которая в рамках одной системы делала производительность. А потом команду выделили, и она стала делать производительность для другой части. А потом еще для третьей, а потом команда увеличилась до пятнадцати человек — и окончательно стала самостоятельной.

Правила поведения императоров


Общее положение — требуйте друг от друга разговаривать словами через рот. Говорить и слушать других — простой софт-скиловый навык, который в рабочей среде столь же необходим, сколь и досадно редок.

Как старшему императору общаться с младшим


  1. Не подавлять и доверять. Младший император — обычно полноценный синьор, зачастую образованный. Для того чтобы быть с ним в синке, чтобы он разделял ваши архитектурные идеи и сам предлагал подходящие, — для этого необходимы свобода действий и доверие.
  2. Давать ошибаться. Мой любимый Carnegie Mellon University, который делает самые крутые книжки по software architecture, сформулировал парадигму обучения: «пока студент контролируемо ошибается, мы его не поправляем». Пусть упадет, набьет шишечки. Возможно, предложит какое-то решение. А если мы с самого начала дадим человеку решение готовое — он ничему не научится.
  3. Итак, позволяйте младшему императору падать — принимать неправильные решения. Кстати, может быть, вы были неправы: какое-то его решение окажется более правильным, чем ваше. Поэтому пусть человек попробует.
  4. Уважать. Тут понятно: без уважения не сработаетесь.

Как младшему императору общаться со старшим


  1. Пытаться не конфликтовать (а конфликтовать не пытаться). Он все равно старший, у него ответственность, его, если что, вызовут на ковер, он там будет лежать и поддакивать, когда его распинают за то, что там у вас прод горит. Не вы будете. Поэтому старший император имеет право вето, он должен быть начальником в любом случае.
  2. Предлагать альтернативные идеи. Ради новых идей, чтобы слышать другую компетентную точку зрения, — ради этого и берут младшего императора.
  3. Ну и очень полезно здесь — так называемый фрейм пользы — думать: я вот такой образованный, я-то вообще уже молодец, если я останусь на этой позиции, какую пользу я смогу нанести себе и другим? Думать через этот фрейм пользы, на мой взгляд, очень важно каждый раз, когда вы вступаете в любую коммуникацию внутри компании. Как с точки зрения младшего императора, так и вообще с любой точки зрения.

Фух. Устала. У нас софт-скиловая статья такая, совершенно не техническая — для меня формат непривычный.

Вывод: как я вижу ситуацию с тимлидами в целом


  1. Нанимать тимлида на не тимлидскую позицию — рекомендую. Человек, который был и специалистом, и руководителем, справится с задачами и будет рад, что ему не приходится ставить их себе самому. К тому же напомню про зарплаты: тимлид в среднем по рынку делает больше, а получает столько же, переманить хорошего спеца на роль синьора вполне возможно и даже может быть выгодно.
  2. Тимлидам становиться синьорами — рекомендую, если есть такое желание. Нет ничего постыдного в том, чтобы отказываться от управленческой деятельности, когда она вам не близка и вы стали руководителем благодаря своей выслуге лет. Не бойтесь осуждения: смею предположить, что решение стать из тимлида синьором скоро станет мейнстримом.
  3. И напомню про фрейм пользы — с его помощью вам будет удобно оценить происходящее в работе. Постоянно спрашивайте себя: не фигню ли я делаю какую пользу я могу нанести в этой ситуации?


Цветы и помидоры от благодарных читателей принимаю в комментариях :)

Комментарии (7)


  1. Mayurifag
    07.07.2022 17:02

    Вы не перепутали: ведущий разработчик, тимлид, получает меньше, чем синьор

    Я правильно читаю график? В 90+ процентиле вакансий на хабр карьере у сеньоров зарплата больше $280k/yr? Есть ссылка с фильтром посмотреть вакансии? Кажется, что какие-то статистические выбросы попали в выборку. Может быть часть вакансий подразумевали как раз годовую оплату, но на количество месяцев в году не делили эту сумму и так вписали в помесячную.


    1. AnnaTref Автор
      07.07.2022 18:56
      +3

      Мопед не мой. И статистика не моя. Можно зайти на Хабр карьеру, посмотреть их новую стату и задать им вопросы (регистрация бесплатна, но они хотят знать вашу зарплату).


  1. lebedec
    07.07.2022 18:11
    +2

    О, император — это что-то новенькое, плюсик хотя бы за нескучную терминологию. 

    Вообще в российских компаниях процветает какое-то извращенное применение слова тимлид. Часто так называют чистого менеджера, руководителя целого направления или подразделения с десятками сотрудников. Наверно, потому что начальники боятся слова “руководитель” в штатном расписании. При этом, разработчиков, в обязанности которых входит менеджмент небольшой команды называют просто сениорами.

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

    Тимлиды не могут нормально погрузиться в архитектуру и дизайн. 

    В хорошо организованной компании у тимлида команда не больше чем на 5 человек. В таких условиях он может и обязан погружаться в архитектуру и дизайн. Иначе зачем он вообще нужен?  

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

    Можно, конечно, сказать, что есть тимлид тимлидов — сотрудник у которого в зоне ответственности руководство сразу несколькими командами(бригадами). Но зачем? Его можно просто назвать руководителем. 


    1. AnnaTref Автор
      07.07.2022 19:14
      +2

      Про погружение тимлида в архитектуру и дизайн. (1) если у тимлида 5 человек, то он тратит время на этих 5 человек: проревьювить Олю, разобраться с грустью у Пети, отрефлексировать предложение Васи, объяснить основы secure coding Жене, починить пайплайн Тимофею, (2) если у тимлида компонент, то он должен поговорить с суппортом про текущие проблемы, договориться о ресурсах инфраструктуры на тестирование, обсудить интеграционные тесты, сделать статусную презентацию по движению компонента. Это не очень много, но время занимает. И значит меньше времени, чтобы нарисовать flow в деталях, обновить информацию о принятых архитектурных решениях, сравнивать разные варианты реакции на событие по скорости, проверить отказоустойчивость компонента, выбрать из fail-open vs fail-close vs fail-safe vs fail-secure и последовательно продумать внедрение подхода.... и пр и пр. Тимлид чаще всего знает дизайн своего компонента (причем чаще всего потому, что его сам писал), но его не хватает чтобы развивать этот дизайн, потому что у него слишком много задач. Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов.


      1. lebedec
        07.07.2022 20:49
        +1

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

        Рассуждения тут логические. Кто может убедится в адекватности принятых технических решений? Оперативно, а не стратегически. Тот, кто разбирается в этих технологиях в контексте текущей ситуации. Менеджер гуманитарий не может физически вам собрать компоненты для релиза, верифицировать оценки, или понять в кого перенаправлять техническую проблему. Только тимлид.  

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

        • разобраться с грустью у Пети: PeopleOps 

        • объяснить основы secure coding Жене: ментор 

        • поговорить с суппортом про текущие проблемы: бизнес аналитики и PO  

        • договориться о ресурсах инфраструктуры на тестирование: QA и DevOps инженеры  

        • сделать статусную презентацию: PO, техпис, продуктовый дизайнер 

        Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов. 

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


  1. RPG18
    07.07.2022 19:29

    Зачем дауншифтить понятно, а зачем идти в лиды? Из статьи вырисовывается что лучше идти в техлиды и архитекторы, чем в лиды.


  1. johnfound
    08.07.2022 01:08
    +3

    Тимлид без команды, это то же самое как тимлид с командой, только без команды.