# Менеджер разработки или стафф-инженер, что выбрать?

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

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

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

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

## Два карьерных пути работают по разным правилам

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

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

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

Материалы Уилла Ларсона Staff Engineer проводят полезное различие, которое скрывают многие карьерные матрицы. Он описывает несколько типажей стафф-инженера: Tech Lead, Architect, Solver и Right Hand. Компании может требоваться один из них, хотя в вакансии указана общая роль стафф-инженера. Поэтому название должности говорит меньше, чем задача, за которую компания хочет назначить ответственного. Я согласен с этой классификацией с одной оговоркой: в небольшом стартапе один человек может за квартал побывать в трех типажах, поэтому четких границ не будет.

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

## Рабочие будни видны в календаре

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

Обычная неделя менеджера может включать встречи один на один, планирование, подбор людей, калибровку оценок, продуктовые обзоры, разбор последствий инцидента и закрытый разговор с сотрудником, чьи результаты ухудшились. Самое тяжелое здесь связано с постоянным переключением. За обсуждением дизайна в 10:00 может идти разговор о вознаграждении в 10:30, а затем переговоры о сроках в 11:00. Для каждого нужна своя концентрация, и некоторые нельзя перенести только потому, что менеджеру хочется спокойно поработать после обеда.

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

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

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

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

## Полномочия и ответственность редко совпадают

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

Здоровая роль менеджера письменно отвечает на четыре вопроса. Кто подчиняется этому менеджеру? Какие решения он принимает самостоятельно? За какой результат поставки он отвечает? Кто разрешает конфликт между продуктовым объемом и возможностями разработки? Если ответы звучат как «все помогают» или «решаем вместе», скорее всего, ответственность в роли есть, а права принимать решения нет.

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

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

```text
Role: Engineering Manager / Staff Engineer
Scope: [team, domain, or company area]
Three decisions I own: [decision 1], [decision 2], [decision 3]
Outcome after 6 months: [observable change]
People whose support I need: [names or roles]
Conflict escalates to: [role]
Evidence used in review: [documents, metrics, outcomes]
```

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

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

## Вознаграждение зависит от уровня и устройства компании

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

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

Вместо спора о престиже используйте простой расчет:

```text
annual_cash = base_salary + expected_bonus
annualized_equity = realistic_value_of_grant / vesting_years
expected_total = annual_cash + annualized_equity
```

«Реалистичная стоимость» намеренно не равна цене привилегированной акции из презентации к офферу. Для публичной компании берите текущую рыночную стоимость и учитывайте колебания. Для частной компании просчитайте низкий или нулевой результат вместе с оптимистичным, учтите стоимость исполнения, налоги и срок исполнения опциона после увольнения. Формула не делает долю надежной. Она не дает самой большой и наименее ликвидной цифре управлять вашим решением.

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

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

Льготы тоже меняют сравнение. В одной компании у менеджеров может быть выше целевая премия, а в другой пакет для стафф-инженеров ничем не отличается. Компенсация дежурств, условия выходного пособия, родительский отпуск и стоимость обязательных поездок в офис влияют на реальную ценность предложения. Запросите письменные условия и сравните обычный год, плохой год для акций и уход через двенадцать месяцев. Это скучная работа, поэтому кандидаты часто ее пропускают и позволяют престижной должности скрыть слабое предложение.

## Влияние растет, когда вы устраняете ограничение

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

Широкий эффект от работы менеджера дают найм недостающего специалиста, разрешение вредного конфликта, ясное распределение ответственности, прекращение работы без бизнес-смысла, развитие старшего инженера до надежного лидера или согласование плана, который команда действительно выполнит. Новые церемонии без изменения решений создают деятельность, но не умножают результат. Популярный совет «не мешайте команде» неполон. Менеджер должен убирать бессмысленные помехи, но команде также нужны приоритеты, обратная связь и трудные решения.

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

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

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

## Стадия компании меняет обе роли

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

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

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

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

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

## Проведите пробу до смены должности

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

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

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

Каждую неделю оценивайте пробу по четырем пунктам от 1 до 5:

1. Энергия после основной работы, а не после похвалы.
2. Качество ваших решений после того, как задача стала неудобной.
3. Готовность других людей следовать вашему направлению без принуждения.
4. Желание улучшить навык после того, как вы увидели собственную слабость.

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

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

## Выбирайте по доказательствам, а не по самоощущению

Хорошее решение сочетает предпочтения, подтвержденные навыки, возможность и цену выбора. Фразы вроде «я умею работать с людьми» или «я создатель» слишком расплывчаты. Менеджеры строят организации. Стафф-инженеры проводят значительную часть времени с людьми. Ищите повторяющееся поведение под давлением.

Оцените каждое утверждение от 1, совершенно неверно, до 5, полностью верно. Ранний и ясный разговор о слабых результатах, готовность отказаться от регулярного программирования без чувства собственной бесполезности, желание отвечать за найм и способность восстанавливаться после конфиденциальных разговоров указывают на управление. Умение превращать неоднозначный технический риск в принятый план, влиять на команды вне своего подчинения и сохранять глубину через чтение и проверки указывают на работу стафф-инженера. Делегирование реализации после выбора направления нужно в обеих ветках.

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

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

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

## Решение можно изменить, но не бесплатно

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

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

Возвращающемуся менеджеру стоит ожидать калибровки масштаба. Пять лет управления не дают автоматически уровень principal engineer. Компания должна оценить техническую глубину, влияние между командами и нужный ей типаж стафф-инженера. Временный переход на роль старшего инженера может дать место для восстановления глубины, но до перехода договоритесь об уровне, зарплате, критериях успеха и дате пересмотра.

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

Зафиксируйте переход отдельным документом:

```text
Destination role and level: [role]
Skills already demonstrated: [evidence]
Skills to rebuild or learn: [skills]
Responsibilities that end on transition day: [list]
Support for the first 90 days: [leader, mentor, training]
Review date and success criteria: [date and evidence]
Fallback if the role is a poor fit: [agreed path]
```

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

Лучше всего карьерные варианты сохраняет история результатов на двух языках: людей и систем. Храните записи о решениях, итоги проектов, темы обратной связи, вклад в найм, выводы из инцидентов и примеры роста людей, которым вы помогли. Не копируйте конфиденциальные материалы. Записывайте достаточно контекста, чтобы объяснить, что изменилось благодаря вашему суждению.

## Роль должна соответствовать ограничению бизнеса

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

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

ИИ меняет расчет численности, но не это различие. Когда небольшое число инженеров может выдавать больше реализации, суждение и координация занимают большую долю ограничения. В Team & AI Audit, который я провожу через oleg.is, я сначала изучаю реальную работу и лишь затем рекомендую роли, инструменты или изменения фонда оплаты.

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