Сказ о том, как мы тимлида разработки искали
Пикабушники, привет!
В конце прошлого года передо мной как HR встала задача: в команду разработки срочно потребовался технический лидер. Не просто крутой сеньор, а человек, способный управлять фулстек-разработчиками, выстраивать диалог с менеджерами проектов и делать процесс более прозрачным и эффективным.
Специфика: сайты для B2B-компаний на Битриксе. Техническая база — обязательна.
Но, как выяснилось в ходе поиска, техническая база - это лишь половина дела...
Январь – февраль 2026 года
Мы готовились к тому, что поиск затянется. Однако реальность превзошла ожидания и за месяц с небольшим мы получили 746 откликов!!
Честно говоря, такого наплыва за такой короткий срок не ждали, поэтому не рассчитали силы.
После скрининга резюме осталось чуть более 40 человек, которые предварительно походили по всем параметрам. А на первичные собеседования мы пригласили уже 25 кандидатов.
Это было много. Утомительно. Но очень показательно.
Главный фильтр, по которому мы отбирали кандидатов, — не стек, а гибкость
Мы быстро заметили закономерность: большинство кандидатов с блестящим техническим бэкграундом спотыкались на одном и том же вопросе: «Как вы будете выстраивать коммуникацию между разработкой и менеджерами проектов?». Ответы часто сводились к: «Я ставлю задачу, а они её принимают». К сожалению, это не та работа, которая нам была нужна зимой 2026-го.
Нам нужен был человек, который понимает, что тимлид - это мост, который приведет тебя к цели, а не стена, на которую нужно взбираться (или биться об нее). То есть в нашем понимании он должен быть управлять не только кодом, но и ожиданиями, сроками, конфликтами, приоритетами. У нас уже были менеджеры проектов, были разработчики, но не было системной связи между ними. Новый лидер должен был наладить эту связь с нуля.
Поэтому на собеседованиях мы обращали больше внимания на софт-скиллы: эмпатию к менеджерам, разрешение споров между сотрудниками, умение объяснить разработчикам, зачем им нужно выполнить ту или иную задачу, а не просто сказать “надо”.
Мы сделали ставку на управленца, а не на супертехнаря
После собеседований мы пересмотрели портреты финалистов и… сделали выбор, который для кого-то покажется неочевидным.
Мы пригласили кандидата, у которого не было самого глубокого технического стека среди всех, но у него была сильная управленческая база и опыт работы именно руководителем менеджеров проектов. Он знал, как организовать процесс так, чтобы задачи не висели мертвым грузом, а люди не выгорали. Он понимал боль проектного менеджера. И у него был потенциал быстро дорасти в технической части, потому что база у него была хорошая - Битрикс он знал, но не на уровне просветленного.
Все же мы решили рискнуть. Потому что научить человека новым инструментам проще, чем переучить его жёсткому и не гибкому стилю управления.
Что в итоге?
Человек уже в команде.
Пока рано говорить о громких победах, но первые недели показывают, что управленческий скелет работает. Надеемся, что его потенциал полноценно раскроется именно в нашей команде и мы наконец получим тот самый “мост”, которого так не хватало.
Мораль такова: всем, кто ищет сотрудников, советую присмотреться к кандидатам с сильным управленческим опытом, даже если они не самые крутые в мире технари. Иногда это оказывается лучшей инвестицией.
А вы что думаете? Стоит ли рисковать, как мы, или лучше брать проверенного технаря?












