Overhead coefficient: невидимый налог на каждого инженера

В инженерной организации на 50 человек, которую мы инструментировали в феврале 2026 года, месячный overhead-коэффициент составил K = 0.37. То есть на каждый $1 прямой разработческой работы приходилось 37 центов косвенных расходов: митинги, code review, ramp-up и доля зарплаты CTO/EM/DevOps, размазанная по команде. CFO три года использовал плоский коэффициент 30% для loaded cost. Реальное число было на 23% выше, и почти никто в компании об этом не знал.

Главная проблема была не в самом разрыве. Главная проблема: 30% — это один бакет, и даже после того, как разрыв обнаружен, внутри ничего нельзя оптимизировать. Отчёт Boston Consulting Group 2024 года про распределение G&A в софтверных компаниях фиксирует ту же картину на масштабе индустрии: компании, которые показывают overhead одной строкой, не могут его сократить, а компании, которые декомпозируют его на три компоненты, режут его на 8–15% за два квартала.

{/* truncate */}

Почему плоский множитель прячет действенную стоимость

Стандартное финансовое отношение к engineering overhead — это какая-то версия "зарплата × 1.3 = loaded cost". Для строки в payroll это работает. Для любого решения тоньше, чем headcount-бюджет, схема ломается.

Отчёт McKinsey 2023 Tech Talent Tectonics квантифицировал разрыв: верхний квартиль инженерных организаций даёт в 4–5 раз больше выручки на инженера, чем нижний квартиль, и этот разрыв сильнее коррелирует с тем, насколько чётко прямая работа отделена от косвенной, чем с headcount или уровнем зарплат. Вы не можете улучшать то, что не видите, а один коэффициент прячет три очень разные сущности.

Если разобрать бакет, обнаруживаются три компоненты:

Компонента	Что это	Сокращается?
taskTotal	Прямое время разработки, привязанное к Jira issue	Нет — это сама работа
nontaskTotal	Митинги, code review, ресёрч, ramp-up, "no-issue" coding	Да — операционно
adminSalary	Распределённый management overhead (CTO, EM, DevOps, архитекторы)	Частично — структурно

Внутри одного квартала реалистично двигается только одна из них — nontaskTotal. Две другие либо являются самой работой, либо организационной архитектурой, которая не меняется без реструктуризации. Если все три обрабатываются как одно число, CFO задаёт вопрос "можем ли мы порезать overhead?" — и получает пожимание плечами. Если они разделены, ответ звучит как "да, на 28% в строке митингов, вот список повторяющихся встреч на аудит".

Формула, помесячно, без усреднения

PanDev Metrics считает overhead-коэффициент по (department_id, year, month) по простой формуле:

K = adminSalary / (taskTotal + nontaskTotal)

В этом определении важны три вещи:

1. Помесячно, без усреднения. Усреднённый K бессмыслен, потому что nontaskTotal качается сезонно: Q4 planning, январский re-baseline, летние отпуска все проявляются в данных. Мы видели это в собственных метриках, и шесть месяцев работы с ошибочными целями нам стоило именно использование годового среднего.
2. adminSalary конфигурируется, не измеряется. Это фиксированная доля зарплат CTO + EM + DevOps + архитекторов, аллоцированная на департамент. Она не двигается со sprint velocity. Это полезное свойство: оно отделяет структурную стоимость от операционной.
3. Знаменатель — общее tracked-усилие команды. taskTotal приходит из IDE-телеметрии heartbeats, заджойненной с Jira issue_key. nontaskTotal приходит из f_mv_activity_total_user_daily_today, отфильтрованного по строкам без привязанного issue: митинговые блоки, свободный ресёрч, code review на чужих ветках.

Внутри OverheadCoefficientCronJob запускается ежедневно и инкрементально обновляет текущий месяц. Когда исторические ставки меняются (например, сменилась зарплата или департамент инженера), OverheadCoefficientFullRecalcCronJob пересобирает всю историю. Мы убедились на практике: без recalc-job одна ретроспективная HR-правка тихо корраптит шесть месяцев финансовых отчётов.

Подробный разбор того, как taskTotal и nontaskTotal встают в формулу loaded rate, в Loaded Hourly Rate: настоящая стоимость часа инженера. Как смешанные ставки (контракторы на hourly, FTE на monthly) попадают в K — в Hourly vs. Monthly Rate в смешанных командах.

Три департамента, три разных K

Самое полезное упражнение, как только K посчитан per department, — поставить их рядом. Та же организация на 50 человек, разбитая по трём командам, в феврале 2026:

Департамент	taskTotal	nontaskTotal	adminSalary	K	Заметка
Backend (18 инженеров)	$76K	$24K	$32K	0.32	Тяжёлый автономный coding, мало митингов
Frontend (16 инженеров)	$61K	$28K	$30K	0.34	Чуть больше дизайн-синков, admin тот же
Data (8 инженеров)	$24K	$14K	$18K	0.47	Малая команда, фиксированный adminSalary размазывается тонко

Одна компания, один стиль управления, K — от 0.32 до 0.47. K у Data-команды на 47% выше, чем у Backend, не потому что Data-инженеры неэффективны, а потому что adminSalary — это фиксированная стоимость, разнесённая по меньшему количеству оплачиваемых часов. Это структурный overhead, его в основном нельзя порезать; его можно только амортизировать ростом команды или принять как цену специализации.

Действенный сигнал в этой таблице — nontaskTotal Frontend на 15% выше, чем Backend. Это операционный рычаг.

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

K качается по месяцам — и это самое важное

Второе упражнение, которое окупает себя, — построить K помесячно для одной команды. Вот Frontend-команда за полный год:

Месяц	taskTotal	nontaskTotal	adminSalary	K	Драйвер
Янв	$48K	$32K	$30K	0.38	Новые OKR, re-baselining
Фев	$61K	$28K	$30K	0.34	Steady state
Мар	$63K	$26K	$30K	0.34	Steady state
Апр	$58K	$27K	$30K	0.35	Easter / начало отпусков
Май	$62K	$25K	$30K	0.34	Steady state
Июн	$55K	$24K	$30K	0.38	Отпускной провал в числителе
Июл	$49K	$22K	$30K	0.42	Пик отпусков, K растёт
Авг	$54K	$23K	$30K	0.39	Восстановление
Сен	$64K	$27K	$30K	0.33	Сильный осенний цикл
Окт	$66K	$29K	$30K	0.32	Лучший месяц года
Ноя	$58K	$32K	$30K	0.33	Pre-Q4 push, больше митингов
Дек	$42K	$34K	$30K	0.39	Holiday-просадка + planning-митинги

K в январе на 12% выше steady-state. Декабрьский Q4 — на 18% выше. Любой бюджет на плоском годовом K перезаряжает занятые месяцы и недозаряжает спокойные. Из-за этого per-feature cost reports скачут до 25% от реальности между январём и октябрём, даже если базовая работа не менялась.

Контр-следствие: правильная единица измерения engineering overhead — это скользящий 3-месячный K, а не годовое среднее. Плоский год скрывает swing больше, чем когда-либо даёт большинство efficiency-программ.

Где живут реальные сокращения

Из трёх компонент только nontaskTotal двигается на квартальном горизонте. Детализация под ним — то, на что финансовому лидеру стоит смотреть.

В организации на 50 человек nontaskTotal = $74K. Разбивка выглядела так:

Подкатегория	$	Доля
Регулярные митинги (standup, planning, retro)	$21K	28%
Code review на чужих ветках	$18K	24%
Ad-hoc syncs и 1:1	$15K	20%
Ресёрч / spike без issue	$11K	15%
Ramp-up и pair programming	$9K	12%

28% на регулярных митингах — заголовок. Ни один из этих митингов не был архитектурным. Это были операционные, инерционные календарные события, которые никто не отменял 18 месяцев. 90-минутный еженедельный sync на девять инженеров стоил $4.2K в месяц по loaded rate команды. Отмена не сломала ничего. Через два месяца K упал с 0.37 до 0.33 — 10% сокращения overhead без redesign процесса и без изменения headcount.

Это и есть контр-наблюдение: большинство engineering overhead не архитектурное и не стратегическое; это календарная инерция, которую финансы могут аудитить так же, как аудитят SaaS-счёт. Отчёт Doodle 2024 State of Meetings по календарной телеметрии 6 500 организаций оценил стоимость лишних регулярных митингов в $25 000 на сотрудника в год для knowledge workers. Цифра выглядит завышенной, пока не посчитаете её из вашего собственного K — и она ляжет в 10–15% от диапазона Doodle.

Про операционные рычаги вокруг context-switching и multi-project tax, которые накапливаются поверх — наша более ранняя статья Engineering ROI: как реально измерить.

Чего наши данные про K не говорят

Точное вычисление K требует надёжного разделения task vs. non-task времени. Если команда не умеет тегать митинги или не линкует IDE-активность к Jira issues, K будет смещён в большую сторону: слишком много времени попадает в "unclassified", которое система засчитывает в nontaskTotal, надувая числитель и завышая overhead. Мы видели команды, которые в первый месяц на платформе показывали K = 0.55 и наблюдали, как он садится к 0.34 на третьем месяце по мере выправления Jira-гигиены.

Второе ограничение: K — это финансовая метрика, не productivity. Команда с низким K не обязательно продуктивнее. Она может пропускать code review, откладывать документацию или копить tech debt, который через шесть месяцев всплывёт ростом nontaskTotal. Правильное чтение K — "какая доля оплаченного инженерного времени в этом месяце ушла в shippable работу", это вопрос cost allocation, не качества.

Третье ограничение: распределение adminSalary — это бухгалтерский выбор. Объективно правильного способа разнести зарплату CTO по трём департаментам не существует. Какой бы метод вы ни выбрали (по headcount, по salary, по time-tracked involvement), применяйте его консистентно. Тренд K важнее абсолютного уровня, и тренд имеет смысл только если правило аллокации не меняется под вами.

Как использовать K в финансовом обзоре

Самая быстрая отдача — сделать три вещи в этом квартале:

1. Посчитать K per department per month за trailing 12 месяцев. Если у вас стоит PanDev Metrics или эквивалент с IDE-трекингом, это один SQL join. Если нет — входные данные всё равно восстанавливаются: Jira time-tracking как прокси для taskTotal, calendar API как прокси для митингового nontaskTotal, HR-система для adminSalary.
2. Построить K помесячно, не как годовое среднее. Найти сезонность. Большинство команд показывает январский и Q4 пики 12–20%. Любой forecast per-feature cost без этого профиля промахивается на размер пика.
3. Один раз в год аудитить nontaskTotal. Вытащить список регулярных митингов, нагрузку code-review-shadow и часы no-issue coding. 28% доля регулярных митингов почти никогда не выдерживает проверки. Мы ни разу не видели команду, которая бы провела такой аудит и не нашла минимум три митинга на отмену.

Для общего CFO-фрейма того, как K вкладывается в инженерный финансовый дашборд — CFO's Guide to Engineering Metrics: что спрашивать и почему.

Число за числом

Overhead-коэффициент — это самое чистое единичное число, которым CFO может оспорить тезис "engineering это дорого, и тут ничего не поделать". Как только K разложен на компоненты, разговор смещается с "не переплачиваем ли мы за инженерию?" на "это какая часть overhead — операционная или структурная?". У первого вопроса нет ответа. У второго обычно есть.

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