Team Lead vs Engineering Manager в белорусском IT: чем реально отличаются эти роли и как под них нанимать

На практике Team Lead и Engineering Manager в Беларуси часто путают — особенно иностранные компании, которые впервые нанимают здесь руководителей разработки. А разница между ними принципиальная.

Представим первую ситуацию. Компания нанимает Team Lead, рассчитывая, что он возьмёт на себя работу с командой. Проходит полтора месяца, а сотрудники по-прежнему приходят к руководителю компании с вопросами о развитии, регулярных 1-на-1 нет, зато новый Team Lead активно участвует в код-ревью и продолжает много писать сам.

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

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

В белорусском IT Team Lead и Engineering Manager — это действительно разные позиции. У них отличается участие в разработке, ответственность за людей, набор полномочий и дальнейший карьерный путь. Отличается и рынок кандидатов: специалисты, которые хорошо подходят на одну из этих позиций, далеко не всегда подходят на другую.

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

Разберёмся, чем эти роли отличаются в Беларуси и как правильно искать кандидата под каждую из них.

Откуда путаница

Белорусский рынок унаследовал технически-первичную модель из более широкой постсоветской инженерной традиции. Самый сильный инженер в команде и был её лидом — тимлид, буквально «лидер команды», но по факту нечто среднее между сеньорным архитектором и ведущим разработчиком. Код был обязательной частью роли. Управление людьми — вторичным, часто разделённым с продакт-менеджером или delivery lead.

Западная культура, особенно после того, как Google в 2000-х формализовал разделение, выделила отдельный трек people manager — с явным разделением менеджмента и написания кода. Широко известный пост Чарити Мейджорс про engineer/manager pendulum закрепил современный западный взгляд: между двумя треками можно переключаться, но это две разные работы с двумя разными наборами навыков.

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

Кто такой Team Lead в белорусском IT

Team Lead в белорусском IT — это сеньорный инженер с дополнительной зоной ответственности. Ключевой признак, который отличает его от Engineering Manager, — он продолжает писать код. Обычно 30–70% рабочего времени, на небольших командах — иногда больше. Остальное уходит на архитектуру, ревью кода, техническое планирование, менторство джуниоров и миддлов, техническую координацию с другими командами.

Основные зоны ответственности:

• Техническое направление работы команды
• Стандарты качества кода, культура ревью
• Разбивка задач на реализуемые части
• Активация команды по техническим решениям
• Менторство джуниоров и миддлов
• Техническая координация с другими тимлидами

Не менее важно понимать, где полномочия заканчиваются. Полномочия тимлида — технические, а не HR. Он влияет на найм, но редко принимает финальное решение. Зарплаты обычно не контролирует. Проблемы с производительностью может эскалировать, но сам процесс перформанс-ревью, как правило, не ведёт. Сложные разговоры с людьми уходят выше — обычно к Head of Engineering, PM или CTO напрямую.

Линия репортинга: обычно на Head of Engineering, продакт-лида, delivery-менеджера или CTO. Размер команды: 3–8 инженеров.

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

Кем тимлид не является: он не в первую очередь people manager. Интервьюировать его как менеджера — с американским поведенческим форматом и упором на сценарии с 1-на-1 — значит не попадать в роль и отсеивать сильных кандидатов. Это базовая лидерская роль в белорусском IT, и именно под неё оптимизирована большая часть местного рынка найма тимлидов.

Что такое Engineering Manager в белорусском IT

Engineering Manager в Беларуси — это в первую очередь people manager. Код падает до 0–20% времени, а у тех, кто действительно хорошо справляется с ролью, — ближе к нулю. Что он вместо этого ведёт:

• Людей: 1-на-1, карьерное развитие, перформанс-ревью, сложные разговоры
• Найм: воронку интервью, решения по офферу, закрытие кандидатов
• Увольнения: перформанс-менеджмент, PIP, увольнения в связке с HR
• Компенсацию: назначение зарплат, апрув повышений, продвижение сотрудников
• Delivery: планирование ёмкости команды, исполнение роадмапа, координацию с другими командами
• Состав команды: кто в неё входит и в какой конфигурации

Линия репортинга: Director/VP Engineering, Head of Engineering или CTO. Размер команды: обычно 5–8 прямых подчинённых в Беларуси — меньше, чем стандартные 8–12 в больших американских компаниях.

Бэкграунд: 8–12 лет общего стажа, обычно с 2–3 годами на позиции тимлида и явным переходом в менеджмент. Публикации вроде LeadDev, формирующие современную дисциплину EM, относятся к этому переходу как к смене карьеры, а не к движению вверх по одному пути. 

Критично важное уточнение для иностранных работодателей: сильные белорусские кандидаты, увидев в оффере «Engineering Manager», часто предполагают, что будут продолжать существенно кодить. Когда реальная роль оказывается чистым people management, они либо отказываются на поздней стадии, либо уходят в течение первого года. Проговаривайте объём кода в описании вакансии открытым текстом. Если написания кода «почти нет», так и пишите: «почти нет».

Сравнение по параметрам

Сравнение в тех терминах, от которых зависит успех найма:

• Объём кода: тимлид 30–70%. EM 0–20%, обычно ближе к нулю.
• Основная метрика успеха: у тимлида — техническая производительность команды и качество кода. У EM — показатели по людям, удержание.
• Прямые подчинённые: у тимлида 3–8 с мягкой властью. У EM 5–8 с жёсткой.
• HR-полномочия: у тимлида — ограниченные. У EM — полные.
• Карьерный трек: тимлид ведёт к Staff Engineer, Principal Engineer или Head of Engineering. EM — к Director, VP или CTO по менеджерскому треку.
• Глубина пула в Беларуси: тимлиды — много. EM — меньше.
• Типичный бэкграунд: тимлид — это повышенный сеньор. EM — бывший тимлид, выбравший менеджерский путь.
• Фокус воронки интервью: у тимлида — системный дизайн и техническое лидерство. У EM — поведенческие интервью и сценарии по работе с людьми.
• Премия к сеньору-разработчику: у тимлида — на 15–25% выше. У EM — на 25–40% выше, с частичным пересечением по вилке со Staff Engineer.

Реальные вилки

Конкретные диапазоны на 2026 год, в актуальной картине белорусского рынка.

Team Lead: $6 500–9 500 в месяц для сильного кандидата в мейнстримном стеке. Выше — на дефицитных специализациях вроде Rust, инфраструктурного Go или ML-платформы, где предложение по тимлидам действительно ограничено.

Engineering Manager: $7 500–11 000 базы в месяц. Иногда выше, если роль включает координацию нескольких команд, репортинг напрямую в VP или ответственность за целый R&D-филиал.

Обе роли несут более крупный переменный компонент, чем IC-позиции. Годовые бонусные таргеты обычно 15–25% против 8–15% у сеньора-разработчика. 13-я зарплата — на обоих. Нематериальный слой обычно богаче: семейная медстраховка, увеличенный бюджет на обучение и конференции, иногда бюджет на командировки для координации с другими офисами или тимбилдингов.

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

Глубина пула: кого реально можно нанять

Без иллюзий по срокам и доступности.

Пул тимлидов в Беларуси глубокий. В Java, Python, JavaScript, TypeScript и, всё активнее, Go можно рассчитывать на нескольких сильных кандидатов за нормальный цикл 6–8 недель. В дефицитных стеках вроде Rust или ML-инфраструктуры пул сужается, но даже там кандидатов на трек тимлида больше, чем чистых IC-сеньоров, — потому что переход из сеньора в тимлида это стандартная траектория в местных компаниях. Специализированная практика подбора бэкенд-разработчиков, как правило, даёт шорт-лист за 3–4 недели по чётко описанной вакансии тимлида.

Пул Engineering Manager намного меньше. Большинство сильных кандидатов на EM в Беларуси пришли из определённого набора компаний со зрелой культурой people management — крупные продуктовые компании с местным R&D, небольшое число аутсорсеров, которые выстроили нормальные менеджерские лестницы, и локальные офисы международных команд. Парк высоких технологий собирает у себя большинство таких работодателей, что и концентрирует пул — но одновременно означает, что все сильные EM друг друга знают и знают рынок.

Последствия дефицита — практические. EM-кандидаты жёстче торгуются, чаще ходят с параллельными офферами и заметно хуже принимают несогласованные описания вакансий. Реалистичный срок: 10–14 недель на сильного EM, дольше — если специфика узкая (управление инфраструктурными командами, ML-командами, распределёнными командами через часовые пояса).

Если вы собираете полный лидерский слой — тимлиды плюс EM плюс Head of Engineering — важна очерёдность. По возможности сначала наймите EM: он поможет закрыть тимлидов и разработчиков. Если поиск EM длится дольше, чем позволяет delivery, стартуйте с тимлидов — сильный тимлид спокойно ведёт команду на протяжении цикла найма без потерь.

Как написать описание вакансии, которое привлечёт нужного кандидата

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

• Объём кода в процентах (или «практически нет»)
• HR-полномочия: может ли этот человек нанимать, увольнять, назначать зарплаты
• Количество и структура прямых подчинённых
• Линия репортинга
• Одна-две конкретные задачи на первый квартал, из которых видна реальная форма роли

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

Чего делать точно не стоит:

• Не используйте «Team Lead / Engineering Manager» как взаимозаменяемые в одном описании вакансии. Для местного кандидата это моментальный красный флаг — показатель того, что компания сама не решила, что ей нужно.
• Избегайте гибридов вроде «Engineering Team Lead» или «Senior Engineering Manager», если ответственность реально не совпадает с этой конкретной комбинацией
• Не описывайте роль через идеальный день на работе, не указав раскладку по времени. «Балансируете между кодом и людьми» — это не спецификация, это описание любой лидерской роли за всю историю IT

Как отличается воронка интервью

Для Team Lead воронка выглядит примерно так:

• Технический дип-дайв по системам, которые кандидат строил
• Раунд системного дизайна на уровне senior/staff
• Кодовая сессия — да, они кодят и ждут, что их об этом попросят
• Сценарии технического лидерства: конфликты на ревью, компромиссы по техдолгу, разногласия по архитектуре
• Один-два поведенческих раунда с фокусом на менторство и кросс-командное взаимодействие

Для Engineering Manager воронка выглядит примерно так:

• Поведенческое интервью в формате STAR или аналогичной структуре
• Сценарии по людям: найм, увольнения, сложные разговоры, работа с низкой производительностью, удержание сильных, которые собрались уходить
• Сценарии по delivery: сорванные сроки, конфликты по роадмапу, кросс-командные зависимости
• Сценарии по стейкхолдер-менеджменту
• Опционально — короткое техническое обсуждение, но не полноценный раунд кодинга

Отдельно про кодовые интервью для EM: это спорная практика на местном рынке. Многие сильные EM-кандидаты от них отказываются, а требование пройти кодовое интервью отсеивает квалифицированных людей по неправильному критерию. Если техническая грамотность действительно важна (а она обычно важна), проверяйте её через техническое обсуждение, а не через live-coding. Тот менеджерский трек, который описывает Уилл Ларсон на staffeng.com — и который в целом усвоили белорусские EM, — рассматривает кодовые интервью на менеджерские позиции как сигнал того, что компания не определилась, кого ищет.

Что иностранные работодатели путают чаще всего

Быстрый список ошибок, которые всплывают почти на каждом найме:

• Название позиции — «Engineering Manager», а описание — как у тимлида (или наоборот)
• Ожидание, что EM будет кодить 50% времени, — на сеньорских уровнях это не работает
• Ожидание, что тимлид будет вести перформанс-ревью и назначать зарплаты без HR-партнёра
• Повышение сильного сеньора сразу в EM без промежуточного этапа — people management отдельный навык, который нарабатывается 1–2 года
• Прогон американской EM-воронки на белорусских кандидатах на тимлида — с последующим непониманием, почему pipeline рассыпается
• Отсутствие ясности по HR-полномочиям на старте — это один из первых вопросов сильных кандидатов, и туманные ответы гасят оффер

Когда какую роль нанимать

Рабочая рамка для принятия решения:

• Команда 3–6 инженеров, delivery простой: Team Lead
• Команда 5–8 инженеров, delivery с несколькими стейкхолдерами: Engineering Manager
• Команда 8+ или структура с суб-командами: обе роли, тимлиды репортят в EM
• Международный R&D-центр с автономным местным delivery: EM наверху, тимлиды под ним
• Аутсорсинг или сервисный контракт: почти всегда структура без EM, только с тимлидами

Многие белорусские компании работают по схеме «тимлиды + Head of Engineering» без отдельного EM-слоя. Head of Engineering исполняет функцию EM для нескольких тимлидов сразу. Это легитимная схема и часто правильная для команд до 20 инженеров. Если вы собираете именно такую многослойную структуру, услуга комплексного подбора команды, которая параллельно закрывает тимлидов, разработчиков и EM, обычно сжимает сроки заметно сильнее, чем последовательный найм.

Для сотрудничества по модели аутсорсинга, а не in-house команды, схема «только тимлиды» почти всегда лучше. EM-функцию несёт провайдер на своей стороне. Аутстаффинг recruitment.by работает именно так по умолчанию: вы получаете инженерную команду плюс техническое лидерство, а инфраструктура account-management и people-management остаётся на стороне провайдера.

Как сделать оффер правильно

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

Начните с определения. Решите, что вам нужно: технический лидер, который пишет код, или people manager, который отвечает за delivery. Опишите вакансию под это решение. Постройте воронку. Фильтруйте под конкретные навыки, которые вы ищете.

Если хочется второго мнения по описанию роли или всей интервью-воронке до того, как они уйдут в мир, команда IT-рекрутинга в Беларуси может вычитать описание вакансии, сверить компенсационную вилку с рынком и провести стресс-тест воронки — как её на самом деле проходят сильные локальные кандидаты.