Все о должности тимлида: кто такие руководители команды разработки и как ими становятся

Когда рекрутер «пинает» тимлида и команду разработки — это нормально

Воронка подбора — это зеркало найма, то, как он проходит у вас в компании. Поэтому воронка бывает разной: у кого-то шесть-семь этапов, а у кого-то — все двадцать. В разработке hh.ru воронка выглядит так:

заявка на подбор → скрининг резюме рекрутером → согласование кандидатов техническими специалистами → интервью с командой → тестовое задание (опционально) → повторное интервью → оффер.

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

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

В результате сели за круглый стол: я, команда, рекрутер. И нарисовали схему:

• Как идет процесс
• Кто за что отвечает
• Какие максимальные сроки у нас заложены под каждый этап

Решили, что если накапливается определенное количество нерассмотренных кандидатов, то рекрутер пишет в общий чат и не стесняется нас «пинать»

Если кандидат нереально хорош, то эйчар может отправить сразу ссылку на вакансию — «кандидат горящий, важно не потерять!»

Когда мы это сделали — все зависания исчезли. Главное принять, что рекрутер тут — «пинатель», это его работа и не стоит на него за это злиться.

А еще от зависаний нас спасает сервис из экосистемы hh.ru —

Кандидаты у нас долго не залеживаются, поэтому приложил скриншот из соседнего отдела:

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

Настройте коммуникации

1. Уменьшать входящий трафик, делегируя и автоматизируя. Кстати, про это был классный доклад Алексея Катаева deusdeorum на TeamLead Conf 2019. 
2. Правильно работать с оставшимся трафиком.

Настраиваем почту

«Inbox Zero»1

Удалил совсем неважное.Пример: флуд-рассылка.2. Настроил раздел для неважного сейчас. Пример: Deploy status autoupdate3

Разделил важное на блоки. Пример: «Проблема на продакшене».Пример: «У нас есть классная идея. Давайте обсудим. Что думаете?».

Настраиваем мессенджер

1. Первый и главный — включить уведомления только о личных сообщениях и упоминаниях. 
2. Следить за актуальностью списка комнат/каналов. Лучше оставаться только в тех, где либо вам что-то интересно, либо вы кому-то нужны. Из всех остальных можно смело выходить. 
3. Настроить пуш-уведомления. Если соблюдать первый и второй пункты, то уведомления будут приходить в основном в тех случаях, когда информация каким-то образом вас касается. 
4. Не пренебрегать статусами. Когда необходимо сосредоточиться, очень помогает, например, статус «Не беспокоить». 

Демократический стиль

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

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

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

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

Частый ответ на вопрос о странном legacy решении в проекте

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

Кто такой Тимлид?

Описание профессии тимлид начну, пожалуй, с уточнения: это не специальность, а должность, или административная единица по другому, исключительно в сфере IT.

В дословном переводе с английского «Team Lead» означает  «лидер команды». Это руководитель-управленец, который возглавляет коллектив веб-разработчиков. Он является ключевым связующим звеном между заказчиком и исполнителями. Тимлид проводит переговоры, принимает заказы на разработку, которые потом преобразовывает в технические задания для специалистов.

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

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

Резюмируя вышеперечисленное, можно сказать, что тимлид это три в одном – программист высокого класса + менеджер-управленец + психолог.

Зная все технические тонкости  разработки веб-проектов, тимлид все-таки не осуществляет непосредственно сам исполнительскую работу. Он планирует, организует, оптимизирует процессы, распределяет обязанности с учетом возможностей каждого сотрудника. Часто Team Lead сам набирает себе команду. Ответственность за весь проект лежит на нем, даже если ошибки совершают исполнители.

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

Кому не подходит должность

Считаете, что вы способны возглавить команду? Будьте осторожны со своими амбициями, так как не каждый разработчик с организаторскими способностями может стать успешным тимлидом. Тщательно взвесьте свои возможности, чтобы не навредить проекту и не испортить отношения с сотрудниками.

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

Крайне сложно быть тимлидом, если вам трудно налаживать коммуникативный контакт с коллегами и вы не можете конструктивно давать обратную связь

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

Особенности подбора

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

Ориентир на команду

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

Участие в HR-процессах

Тимлид тесно взаимодействует с HR-ом по вопросам подбора, адаптации и обучения персонала. У ИТ-специалистов свое видение на эти процессы, не всегда совпадающее с мнением HR. 

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

Слабые внутренние кандидаты

Самый лучший вариант — выбрать тимлида из разработчиков внутри компании. Он уже знает процессы и легко сможет управлять командой. Но не все сеньоры готовы становится тимлидами — в этом основная сложность.Если потенциальные претенденты есть, можно провести оценку 360 и оценить готовность сотрудника по личностным и управленческим скилам.

Ответственность за проект и команду

Тимлид не может уйти, когда команда столкнулась с проблемой

Он должен подавать пример и помогать коллегам, и при этом не важно, чья эта была ошибка

Рекрутеру стоит спросить о сложных кейсах в опыте тимлида: как он действовал, как помогал команде и на сколько часто такие ситуации возникали. 

Шаг номер 1. Знание — сила!

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

Про тимлидство существуют сотни статей, видео, книг, курсов и т.д. Фильтровать нужно тщательно.

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

• М. Уоткинс «Первые 90 дней». Хорошая и вдумчивая книга о том, как успешно адаптироваться к переходу на новую должность. Чем заняться в первые 90 дней. И о том, что эта адаптация, как системный процесс, нужна не просто конкретному индивиду, а всей компании в целом.

• Дж. Ханк Рейнвотер «Как пасти котов». Книга для начинающих или будущих управленцев вполне хороша и толкова (пусть и немного стара). Однако для людей с опытом, наверное, будет немного кэпской.

• Ф. Брукс «Мифический человеко-месяц». Расскажет об управлении проектами: как надо, как не надо, и почему 9 женщин за 1 месяц не смогут родить ребенка. Есть мнение, что книга несколько устарела, тем не менее, если вы в этом не очень разбираетесь, то она обогатит вас полезными идеями.

• Э. Голдратт. «Цель. Процесс непрерывного совершенствования». Классический художественный роман, объясняющий на разных примерах теорию ограничения систем. Чтиво интересное и полезное. 

• Д. Ким, К. Бер, Д. Спаффорд. «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему». Очень интересная и поучительная книга, которая в художественном формате рассказывает о том, как в ИТ подразделении улучшают процессы работы, приходят к DevOps идеологии и спасают бизнес.

• Т. ДеМарко «Deadline. Роман об управлении проектами». Еще одна книга в художественном формате. Легкое и интересное чтение об управлении ИТ проектами.

• Т. ДеМарко, Т. Листер «Вальсируя с Медведями». Порекомендовал бы эту книгу для средних и крупных проектов. Излечивает от наивности, открывает глаза на происходящее. Показывает, что случиться может много чего и рассказывает, как с этим жить и работать.

• М. Дорофеев «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо». Книга не про программирование, но программистам, тимлидам, менеджерам точно пойдёт на пользу. Очень толковая книга по личной эффективности, организации задач и т.п. Всем настойчиво рекомендую.

• М. Ильяхов, Л. Сарычева «Новые правила деловой переписки». Замечательная книга. Смело её рекомендовал бы и разработчикам, и менеджерам, и вообще примерно всем. О том как в переписке быть толковым, уважительным, приятным и эффективным. Очень многим этого не хватает.

• А. Орлов «Джедайские техники конструктивного общения». Коротко, по делу, с примерами. Однозначно рекомендую. И в работе пригодится, и в быту.

• М. Гоулстон «Как разговаривать с мудаками». Книга придаёт понимание того, что не все проблемные отношения и коммуникации можно разрешить рациональными доводами, и что делать в таких случаях. Ну и о себе можно задуматься тоже:)

• Роадмап тимлида https://tlroadmap.io/ Очень полезный инструмент, который поможет разобраться, какие бывают требования к тимлидам, понять, что с ними делать и как подтягивать свои знания. Также подойдет как хороший инструмент для того, чтобы обговорить со своим руководителем на начальном этапе работы, что же конкретно от вас ожидается.

• Курсерный курс https://www.coursera.org/specializations/product-management Долгий и основательный курс, который покрывает всё про управление проектами. Выявление требований, план рисков, декомпозиция и распределение задач, аджайл техники и прочее. Вы справедливо можете заметить, что этот курс нужен менеджерам проектов, а не тимлидам. Теоритечески — да, а на практике возможно, что если у вас менеджер проекта и есть, то в каких-то деталях он может не очень разбираться. Тогда понадобится ваше участие.

• Регулярные двухнедельные тимлидские конференции от ребят из подкаста Podlodka https://podlodka.io/tlcrew Там много хороших докладов и душевное отзывчивое комьюнити, с которым можно порой пообсуждать в деталях то, за что обычно деньги берут на платных индивидуальных консультациях.

С чего всё началось

У нас было три небольших группы разработки. Каждая жила по своим правилам, у каждой был свой список задач, свои цели и свой лид, одним из которых был я. В какой-то момент все три группы объединили в одну команду, а меня назначили тимлидом этой новой команды. Команда — распределённая, разброс по часовым поясам — от Москвы до Новосибирска, из 11 человек только двое сидели рядом в офисе, 5 человек, включая меня, работали удалённо. В таких условиях была опасность превратиться в группу программистов, каждый из которых получает задачу и выдаёт кусок кода. А мне хотелось построить команду, в которой люди будут участвовать в жизни продукта, который мы делаем.

Где научиться специальности?

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

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

Курс «TeamLead» от SkillBox

SkillBox – онлайн-университет современных профессий в области маркетинга, дизайна, программирования и менеджмента. Участник проекта Skolkovo, обладатель премии Рунета за 2018 и 2021 годы.

• Чему научитесь: освоите навыки управления командой разработчиков, принципы подбора персонала; изучите методологии Agile, Scrum и Kanban; сможете эффективно решать бизнес-задачи; узнаете системы мотивации работников.
• Формат обучения: практические видеоуроки, самостоятельные домашние задания с проверкой преподавателем и исправлением ошибок, защита дипломного проекта; всего 82 урока, сгруппированные в 28 тематических модулей.
• Преимущества: доступ к материалам курса навсегда с учетом всех обновлений; преподаватели-практики; разбор реальных кейсов; диплом о прохождении подготовки; отсрочка платежа до 12 месяцев.
• Длительность курса: 6 месяцев.
• Кому подойдет: начинающим специалистам, middle и senior-программистам.
• Стоимость: около 39 000 рублей, возможна рассрочка по 6 900 рублей в месяц.

Посмотреть курс

Интенсив «Тимлид разработки» от SkillFactory

SkillFactory – онлайн-школа по работе с данными, лидер в сегменте Data Scientist, участник проекта Skolkovo. На рынке онлайн-образования с 2021 года.

• Чему научитесь: прокачивать навыки эффективного управления командой разработчиков; настраивать командные процессы; грамотно разрешать конфликтные ситуации; превращать бизнес-задачи в технические задания; планировать архитектуру будущего проекта.
• Формат обучения: вебинары, Q&A сессии, индивидуальные и групповые практикумы.
• Преимущества: формирование команды в процессе обучения; ментор на протяжении всего цикла обучения; работа в компактных группах.
• Длительность курса: 4 месяца.
• Кому подойдет: middle и senior-разработчикам.
• Стоимость: около 95 000 рублей за весь курс, или в рассрочку по 7 91 рублей на 12 месяцев без процентов.

Посмотреть курс

3. Онлайн-интенсив «Бизнес и управление» от Нетологии

Нетология – одна из лучших образовательных онлайн-платформ в России с 2011 года, участник проекта Skolkovo. Является обладателем премии Рунета в области онлайн-образования на протяжении трех лет, с 2021 по 2021 годы.

• Чему научитесь: финансовому моделированию; проверять гипотезы и определять направление развития проекта; управлять конфликтами; собирать команду; использовать подход бережливого производства; приоритизировать задачи и контролировать их исполнение.
• Формат обучения: 14 тематических мини-интенсивов, каждый из которых состоит из 8 видео по 10-20 минут, 2-х промежуточных и одного итогового теста.
• Преимущества: практика и тренировка; помощь в подборе мини-интенсива.
• Длительность курса: в свободном графике, в зависимости от выбора интенсива.
• Кому подойдет: начинающим специалистам.
• Стоимость: каждый модуль стоит около 15 000 рублей.

Посмотреть курс

Страх №1. Ты не востребован на рынке

Буду получать меньше, чем сейчас

• 144–294 тыс. рублей, если являетесь профессионалом, который, возможно, менторит пару человек, но едва ли исполняет весь набор функций тимлида.
• 175–357 тыс. рублей, если вы тимлид небольшой команды.
• 225–491 тыс. рублей, если вы тимлид большой команды в 10-30 человек или менеджер менеджеров.

Как победить страх, что ты не востребован на рынке

• Это повышает вашу уверенность в завтрашнем дне. Дает понять, что если что-то пойдет не так (компания обанкротится, вы выгорите, ваш руководитель сойдет с ума и т.д.), вы всегда сможете найти себе что-то еще.
• Позволяет оценить ваши навыки. Длительное время сидя на одном месте трудно понять, а как вы справляетесь. На собеседовании вы получите максимально честный и жесткий фидбэк.
• Дает понимание рынка: что и где требуется от тимлидов, какие полезные практики и процессы применяются и чем они могут быть полезны вам в текущей ситуации.

Ходить по собеседованиям не обязательно значит хотеть сменить работу. Это не страшно, за это не наказывают.
Teamlead Roadmap

Профессиональный рост в IT

Рассмотрим типичную IT-компанию. Как и в других отраслях, здесь возможен рост «по горизонтали» и «по вертикали».

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

Вертикальный — это переход на лидерские позиции (техлида, тимлида) или руководящие должности. О нём мы сегодня и поговорим.

Это — обычная схема профессионального роста:

1. junior developer (специалист начального уровня);
2. middle developer (специалист среднего уровня);
3. senior developer (специалист высокого уровня);
4. technical leader (технический лидер);
5. team leader (лидер команды).

Иногда выделяют дополнительные промежуточные ступени, например junior+ (это джун, который совсем чуть-чуть не дотягивает до миддла).

Стать тимлидом можно и раньше — со ступени middle-разработчика.

Senior developer может выбирать направление на свой вкус: стать техлидом, который управляет ходом работ, но больше погружён в архитектуру и качество кода, или же тимлидом, который тоже управляет командой, но более ориентирован на коммуникации. Эти роли одинаково авторитетны. В редких компаниях тимлид может руководить техлидом, но обычно они работают параллельно и на равных.

Если техлид достиг «потолка» в своей должности, но не хочет расти «параллельно» и идти в тимлидерство, он может углубиться в техническую часть, например в экстремальное программирование.

Приведите в порядок встречи один на один

Пример формата записи результатов и договорённостей по итогам встречи

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

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

Психологическая роль

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

Организуйте ежемесячные встречи с разработчиками. Сценарий таких встреч каждый месяц повторяется. Поначалу разработчик говорит, что всё ок, всё хорошо, проблем нет. Но основная сила психолога в вопросах. В беседе узнается, что и систему оценки на проекте в прошлом месяце можно улучшить, и взаимоотношения между отделами подтянуть, а ещё было придумано оригинальное решение, которое можно вынести как базовое и написать по нему гайд. Ведь на другом проекте возникли такие же проблемы и решали их дольше, чем нужно. Беседу обязательно надо конспектировать, потому что в ней могут быть отличные мысли. Их можно и нужно претворять в жизнь. После таких бесед часть проблем нивелируется. Так как процесс итеративный, он помогает устранять проблемы и не занимает много времени. Такие встречи не нужно превращать в совещания отделов. Это должны быть именно тет-а-тет беседы в спокойной обстановке. Так вы сможете решить даже сложные личностные проблемы.

Станьте «большим братом». Lead несет ответственность за работу своего подразделения. Он должен быть в курсе задач, сроков исполнения и качества функциональности на выходе для каждого разработчика. Однако, в процессе работы не стоит впадать в крайности. Пословица «Всё хорошо в меру» работает здесь отлично. Старайтесь не вмешиваться, если всё идёт хорошо. При этом всегда держите руку на пульсе и предотвращайте кризисные ситуации. Сотрудник комфортнее всего работает, когда на него не давят сверху, но при этом он чувствует влияние невидимого «большого брата», который является не контроллером, а советчиком.

Внедряйте «безликий код». Самый долгий и трудный процесс — привести код вашего отдела к «безликому коду», когда нельзя по стилю определить, кто его написал. Это направление правильное и трудное. Если возможна вариативность решения, вы встретите несколько лагерей. Чтобы в случае кризисной ситуации в ваш адрес не посыпалось «вот решили тогда так, а это оказалось плохо, и сейчас все минусы всплыли», необходимо дипломатично решать каждый вопрос. Помните, что с базовыми решениями, которые вы разрабатываете и согласовываете, будут работать другие люди. Делайте удобно для них.

Сокращайте этапы подбора и тестовое задание

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

Пары собеседований достаточно, чтобы принять решение по кандидату. Если вы увеличиваете их до трёх, четырёх, пяти (да, и такое бывает) — рискуете дойти до финала с пустыми руками.

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

Где искать

С должностью тимлида ситуация как и с другими ИТ-вакансиями: спрос намного превышает предложение.

Хабр

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

Есть два основных варианта: 

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

ИТ-конференции 

Самое удачное место для деловых знакомств. HR может представить команду, рассказать о компании и найти ценных кандидатов.

Кадровое ИТ-агентство

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

Оставляйте заявку на нашем сайте (ссылка на главную) — мы поможем найти классного специалиста.

Остались вопросы?

Сколько получают Тимлиды и как найти работу?

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

Так, по Москве уровень зарплаты может достигать 400 тысяч рублей и более, при этом минимальная планка тоже высокая – около 100 тысяч рублей. В других регионах зарплаты гораздо ниже, примерно от 50 до 300 тысяч рублей.

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

Если вы еще не знаете где лучше искать работу тимлида, то можно воспользоваться услугами сайта HH или SuperJob, который предлагает самые свежие вакансии от всех лучших сайтов по трудоустройству.

Избегайте вопросов-клише на собеседовании

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

В каком направлении вы хотите развиваться?

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

Ещё один лайфхак: спросите, чем кандидат гордится. Этот вопрос разрядит напряжённую обстановку и расслабит человека, ведь всем приятно рассказывать о своих достижениях.

Заключение

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

Я думаю, что по аналогии с военными, нам — заказчикам, также страшно при поиске нового персонала. Нам закрадывается мысль: «Если я возьму плохого, кто отвечать будет?» И в следствии защитной реакции мы придумываем себе волшебные слова «серебряные пули» в надежде что они сами по себе решат все наши проблемы. Кандидаты сами будут понимать подходят они или нет и откликаться будут только действительно классные и нужные ребята.  И подобно тем военным, мы выстреливаем в интернет слова: Middle, Senior, 2 года коммерческой разработки, Spring Boot, Nodejs, Angular, Kubernates. 

Но как показывает моя практика, в большинстве случаев это только трата времени. 

В конечном счете я предлагаю вам попробовать приложить 20% усилий, чтобы получить 80% результата.

А именно — формализовать минимальные технические требования и прояснять их еще до встречи с HR или заказчиком.