Нанять HRBP или купить HR-софт — классический выбор build vs buy

В районе 50 сотрудников каждый founder ведёт один и тот же разговор с cofounder'ом: «нам нужен HR». Что значит «HR» в этот момент — обычно не стратегический people-менеджмент. Это «существующие системы ломаются, давайте больше не вести вакационный Excel».

Два пути отсюда:

1. Нанять HR Business Partner (HRBP).
2. Купить HR-софт.

На практике в итоге делают и то, и другое. Но порядок важен, и «оба одновременно» редко работает для 50-чел компании. Вот рамка решения.

Что HRBP реально делает

Инстинкт founder'а — HR это вакационный Excel, чеклист онбординга, оргструктура. Это HR-ops. Самые видимые 10% работы HRBP. Остальные 90% — что опытный HRBP проводит большую часть времени:

• Manager coaching: часовые 1:1 с first-time менеджерами, разбирая трудного report'а, реорганизацию, тяжёлый разговор.
• Compensation philosophy: построение band'ов, leveling, equity allocation principles. Привод правильных benchmark-данных.
• Talent-стратегия: куда компания должна нанимать дальше, кого продвигать, какие навыки отсутствуют.
• Трудные разговоры: lead'ить PIP, увольнения, расследования harassment'а.
• Culture-строительство: фасилитировать offsite'ы, дизайнить ритуалы, называть и адресовать дисфункцию.
• Manager-найм: помогать founder'у нанять ПЕРВОГО head-of-engineering, head-of-sales и т.п.

Это high-leverage работа, которую может делать только опытный человек. HRBP на 50 людях делает почти полностью эти 90%, не 10%.

Что HR-софт реально делает

HR-софт-предложение на 50-чел масштабе — ровно эти 10%: согласование отпусков, оргструктура, справочник сотрудников, базовые ревью, KB для HR-документов, может быть floor plan. Операционный слой.

Софт не может коучить first-time менеджера через 1:1. Софт не может фасилитировать PIP. Софт не может помочь founder'у нанять head-of-sales.

Что софт МОЖЕТ — снять операционный слой с того, кто его сейчас делает (обычно founder, COO или EA-doubling-as-people-ops), чтобы человек, который в итоге будет владеть People в компании, не тонул в трекинге отсутствий когда стартует.

Почему порядок важен

Если сначала наняли HRBP без софта — новый HRBP проводит первые 6 недель настраивая операционный слой сам (или ругаясь с командой какой инструмент). 6 недель senior-IC-уровня зарплаты на то что софт делает за 4 часа. Также сжигаете онбординг-терпение HRBP на задачу, на которую он не подписывался.

Если сначала купили софт без HRBP — у вас портал, handle'ящий очевидные workflow. 90%-работа не происходит. Founder подбирает slack на culture / coaching / hiring-решения, что нормально до ~75 людей и начинает видимо проваливаться выше.

Правильная последовательность для большинства компаний:

1. ~30 людей: купить операционный софт (портал). 4-часовая настройка. Founder продолжает делать стратегические вещи.
2. ~75 людей: нанять первого People-человека — мог быть HRBP, мог быть более junior People-ops + part-time advisor. Они приходят в работающий операционный слой.
3. ~150 людей: расщепить на две People-роли — одна операционная (People-ops manager), одна стратегическая (HRBP). Софт по-прежнему делает ежедневный routing.
4. ~300 людей: полная People-org. Софт теперь маленький кусок большего toolchain'а (ATS, HRIS, payroll, perf-mgmt — обычно разные вендоры).

Исключение: компании, покупающие софт слишком поздно

Видим часто: компания нанимает первого HRBP на 50 людях потому что «нужен HR». HRBP проводит следующий год тонущим в операционной работе, стратегические 90% не делаются, founder разочарован, HRBP перегружен, они расстаются на месяце 18, компания делает вывод «HR на нашем этапе не работает».

Реальная проблема: компания наняла HRBP на год раньше И не дала ему софт. Либо один фикс отдельно помог бы. Оба вместе дали бы другой результат.

Исключение: founder'ы, обращающиеся с HR-софтом как со стратегией

Зеркальный провал: founder покупает софт, объявляет «у нас теперь есть HR» и пытается вырасти до 200 людей без найма человека. Org работает на автопилоте, операционка правильная, и видимо проваливает стратегическую сторону — first-time менеджеров не коучат, компенсации становятся ad-hoc, первое жёсткое увольнение происходит — нет никого знающего как сделать это хорошо.

Софт — необходимая инфраструктура. Это не стратегия. На каком-то размере вам нужен человек, для которого People — это вся работа.

Простая рамка решения

Три вопроса:

В1: Сколько часов в неделю сейчас тратится на операционный HR (отпуска, справочник, онбординг-логистика)?

• <2 часов/нед: рано для софта. Управляйте Excel ещё немного.
• 2-8 часов/нед: покупайте софт. ROI мгновенный.
• 8+ часов/нед: должны были купить уже давно.

В2: Сколько открытых менеджерских / стратегических HR-вопросов нерешено прямо сейчас?

• Примеры: «Должны ли мы иметь промо-уровни?», «Что наша политика по удалёнке?», «Как мы найдём head of engineering?», «Платим ли мы по рынку нашим сеньорам?»
• 0-2: рано для HRBP. Founder справляется.
• 3-6: нанимайте. Вопросы будут только размножаться.
• 7+: должны были нанять HRBP полгода назад.

В3: Какой headcount?

• <50: обычно ничего пока. Софт на 30-40 если операционный слой ломается, HRBP позже.
• 50-100: софт точно, HRBP на верхней границе диапазона.
• 100+: оба.

Если ваши ответы кросс-валидируют (много нерешённых стратегических AND много операционных часов AND headcount 90), ответ — «оба сейчас, софт первым потому что быстрее развернуть».

Неправильные причины нанять HRBP

Несколько паттернов, которые ведут к mis-hire:

• «Наша культура страдает, нужен кто-то чтобы починить». Культуру чинит behavior лидерской команды, не HRBP. HRBP может помочь назвать и приоритизировать работу, но не может изменить поведение лидерства, если лидерство не bought in.
• «Нужен кто-то для compliance / legal stuff». Это юрист + payroll-провайдер, не HRBP.
• «Performance-ревью на носу и никто не знает как». Консультант спроектирует первый ревью-цикл за неделю. Нанимать HRBP для one-time process-design — overkill (и им будет скучно).

Правильная причина нанять HRBP: есть постоянный поток judgment-call-решений с участием людей в вашей компании, который никто в лидерской команде не имеет bandwidth'а или экспертизы handle'ить хорошо. ВОТ recurring-нужда.

Как софт вписывается в долгую

Даже на 300 людях с полной People-org вы продолжаете использовать тот же портал, который купили на 30. Фичи, которые важны, расширяются (custom-поля, глубокие ревью-циклы, больше отчётности), но daily-touchpoint UI для «кто работает, кого нет, как запросить отпуск» не меняется. Покупка софта рано не значит что вы перерастёте — просто используете больше из него.

HRBP, который присоединяется позже, обычно ценит существующий софт-стек. Порталы, которые они ненавидели — те, что требовали ручно конфигурить approval chain для каждого сотрудника, или не интегрировались с IdP, или не имели API чтобы тянуть данные в стратегическую аналитику, которой они реально хотели заниматься. Порталы, которые любили — те что handle'или скучное невидимо, чтобы они могли фокусироваться на coaching менеджеров.

Связанное чтение

• Что такое корпоративный портал и когда он реально нужен компании
• 360 ревью без боли — процесс, шаблоны компетенций, кейс
• HR-стек для компании 50 человек — что точно нужно, что точно нет