Куда расти сеньору, если не в тимлиды: экспертный трек в ИТ

Короткий ответ. Экспертный трек (IC-трек) — это карьера инженера, где растёт масштаб технического влияния, а не число подчинённых: senior → Staff Engineer → Principal Engineer, плюс роли архитектора ПО и доменного эксперта. Карьера разработчика без менеджмента в России возможна, но в большинстве компаний не оформлена как грейд: должности principal в штатном расписании нет, публично описанный staff-трек — единичные случаи. Главный тезис: экспертный трек не выдают, его собирают — через зону ответственности шире одной команды, артефакты (дизайн-доки, ADR, стандарты) и видимость решений; должность приходит после того, как роль фактически исполняется.

Пять-десять лет опыта. Задачи повторяются, новую подсистему вы собираете по памяти и заранее знаете, где она треснет. А наверх ведёт одна дорога: в тимлиды. «Не хочу быть тимлидом» здесь не каприз: менять проектирование на планирование спринтов и найм — не тот обмен. Дальше неприятное. Вопрос «куда расти сеньору», когда управленческий трек отпадает, упирается не в амбиции, а в то, что альтернатива нигде не описана в матрице компетенций. Ни строчки. Потолок сеньора оказывается потолком здания, а не этажа.

Что такое экспертный трек и IC-трек простыми словами

Экспертный трек (IC-трек) — это карьера инженера, в которой растёт масштаб технического влияния, а не число подчинённых, а специалист влияет на продукт через технологию и архитектуру, а не через управление людьми. IC — сокращение от individual contributor; «IC-трек» и «экспертный трек» в русском обиходе означают одно и то же. Staff+ — зонтичное обозначение всего, что выше сеньора на этой линии.

Куда расти сеньору внутри IC-трека, определяет не название роли, а три вещи:

• масштаб решения — от задачи в рамках требований до самих требований;

• горизонт планирования — от спринта до двух-трёх лет жизни системы;

• число команд, на которые влияет решение, — от одной до домена целиком.

Технический лидер здесь не перестаёт быть инженером. Он перестаёт быть инженером одной команды.

Тимлид или эксперт: развилка по типу влияния и ответственности

Тимлид и эксперт на IC-треке различаются предметом ответственности: тимлид отвечает за команду — сроки, найм, 1:1, KPI команды, развитие сотрудников; эксперт — за техническое решение и за то, что за архитектуру не придётся расплачиваться через два года. Развилку обычно объясняют проще: работа с людьми против работы с кодом. Из-за этого упрощения ошибаются дважды: сначала уходя в менеджмент, потом из него.

Наставничество есть на обоих треках: у тимлида это развитие сотрудника, у эксперта — менторство по техническим вопросам. Но дальше карьера senior-разработчика расходится несимметрично, и тому, кто не хочет в тимлиды, это на руку: технические навыки деградируют быстрее управленческих. Если всё-таки в менеджмент — От middle до тимлида (/blog/ot-middle-do-timlida).

Роли экспертного трека: кто такие Staff, Principal, архитектор и доменный эксперт

Рост разработчика после senior распадается на четыре роли: Staff Engineer, Principal Engineer, архитектор ПО и доменный эксперт. Оговорка, которая экономит месяцы. Названия в компаниях означают разное: где-то архитектор защищает решения и может сказать «нет», где-то рисует схемы без права вето. Ориентир — зона ответственности в оффере, а не строчка в трудовой. Уровни до развилки: Как расти миддлу и сеньору (/blog/kak-rasti-middlu-i-senioru).

Staff Engineer — технический лидер нескольких команд

Staff Engineer — это инженер, который технически ведёт несколько команд сразу: кросс-командные задачи, архитектура подсистем, внедрение практик, роль переговорщика, когда две команды одинаково уверены в своих взаимоисключающих решениях. Ситуация знакомая: оба решения защитимы, а контракт нужен один. Отличие от сеньора: сеньор решает задачу в рамках требований, staff влияет на то, какими эти требования будут.

Principal Engineer — техническая стратегия компании

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

Архитектор ПО — проектирование систем и защита решений

Архитектор ПО — это специалист, который проектирует систему целиком и отвечает за последствия. Чем занимается архитектор ПО: системный дизайн, дизайн-документы и их защита на design review, ADR по значимым решениям, технический радар, ответственность за нагрузку и отказоустойчивость. Отдельный вопрос на входе — пишет ли архитектор ПО код. Где-то это обязательное требование, где-то нет.

Доменный эксперт и консультант — экспертиза в предметной области

Доменный эксперт — это специалист, ценность которого в знании предметной области, а не стека: банковский расчётный день, розничные остатки, промышленная телеметрия. Он понимает, почему система устроена именно так, и отличает легаси от требования домена — то самое «странное» место, которое новичок порывается выпрямить. Часто такие специалисты уходят в консалтинг и пресейл.

Как выглядит оформленный staff-трек на практике: пример Т-Банка

Т-Банк — один из немногих российских работодателей с публично оформленным staff-треком: staff-инженеры, по описанию компании, — «специалисты, которые определяют архитектуру, стратегию и практики для нескольких команд или доменов», а карьера staff-инженера — «путь лидера без перехода в менеджмент». Зоны ответственности: проектирование архитектуры и защита дизайн-документов, разработка сложных систем в роли software-эксперта, консультирование руководителей команд и отделов, оптимизация инженерных процессов.

Требования там же:

• от 5 лет опыта разработки;

• от 2 лет в роли архитектора или техлида;

• проектирование высоконагруженных распределённых систем;

• глубокое знание одного из стеков: .NET, Java, Python, Go, Scala или C++;

• готовность продолжать писать код;

• оценка результата через бизнес-метрики.

Два пункта ломают привычное представление о «чистом» IC-треке. Первый — опыт техлида или архитектора: околоуправленческий опыт всё-таки нужен. Второй — оценка через бизнес-метрики, а не через техническое совершенство решения. Обозначение «Staff+» компания использует без детализации подуровней.

Сколько платят на экспертном треке: цифры и чем они не являются

Публичных зарплат по staff-инженерам в России практически нет — и это само по себе показывает, насколько трек нераспространён. Ближайший ориентир — медиана архитекторов ПО: 400 000 ₽ (Хабр Карьера, первое полугодие 2026, выборка 45 226 зарплат). Деньги упираются не в грейд, а в тип компании: в продуктовой компании со зрелой инженерной культурой staff+ оплачивается сопоставимо с менеджментом того же уровня влияния; где такой культуры нет, потолок сеньора и есть потолок. Ниже три источника с разными методиками и выборками: сравнивать значения можно только внутри одного. Данные сервиса Grades даны по небольшой выборке, 660 записей: это ориентир, а не рыночная норма. Диапазоны по ролям руководителей — контекст, а не официальные вилки.

Зарплата архитектора ПО в срезе Хабр Карьеры — единственная открытая цифра, прямо описывающая экспертную роль: внутри этого среза она более чем вдвое выше рыночной медианы. Но это медиана по специализации, а не «грейд архитектора». Разрыв senior → lead в данных Grades, 160–200 тыс. ₽ или 43–54%, корректен только внутри Grades: переносить его на рынок или на переход senior → staff нельзя.

Ещё одно, что легко упустить за процентами. Рост медианы на 4% при прогнозе ЦБ РФ по инфляции 4,5–5,5% означает, что в реальном выражении зарплаты не выросли: во втором полугодии 2025 отдельные специализации прибавляли 15%, в первом полугодии 2026 максимум по срезу — 7%.

Экспертный трек не выдают — его собирают: что делать, если в компании его нет

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

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

2. Производить дизайн-документы и ADR по значимым решениям. По тем, где выбор неочевиден, а цена ошибки растянута во времени. «Обсудили в чате» через полгода не существует: ни решения, ни причин, по которым его приняли. Артефакт — дизайн-док и ADR в репозитории.

3. Ввести и зафиксировать практику. Стандарт код-ревью, шаблон разбора инцидента, правила именования в контрактах API. Устная договорённость практикой не считается. Артефакт — документ, которым пользуются другие команды.

4. Сделать решения видимыми за пределами команды. Design review с приглашёнными из соседних команд, внутренний доклад, разбор инцидента для всех — а не постмортем, который дочитали трое. Артефакт — запись доклада и протокол review.

5. Зафиксировать на перформанс-ревью, что зона ответственности шире грейда. Не «я хочу расти», а перечень: кросс-командные решения, стандарт, доклад. Артефакт — формулировка в матрице компетенций или в целях на полугодие.

6. Дать роли имя. Если грейда нет, просить не грейд, а формулировку зоны ответственности в оффере: «отвечает за архитектуру домена X и практики в командах A, B, C».

Отметьте, чего у вас нет: дизайн-док, ADR, разбор инцидента, стандарт, запись доклада, зона ответственности в матрице компетенций.

Теперь честная часть, которую в таких списках обычно опускают. Если шаги 4 и 5 после двух-трёх заходов упираются в «у нас так не принято», это уже ответ. Не повод зайти в четвёртый раз с презентацией получше. Трека в компании нет, и под конкретного человека он не появится — даже под очень хорошего. Вопрос решается сменой места. 

Кому экспертный трек не подходит и когда это плохая идея

Инженерную линию карьеры подают как безусловно хороший вариант, но экспертный трек — плохая идея в трёх случаях: мотив «меньше общаться с людьми», компания без инженерной культуры, цель — только доход.

• «Ухожу, чтобы не общаться с людьми». Это не менеджмент для тех, кто не любит людей. Коммуникаций столько же, просто другого типа: убеждать инженеров, у каждого из которых своё мнение; защищать решение на review перед теми, кто пришёл его ломать; писать документы так, чтобы их дочитывали. Кто уходит из тимлидов ради тишины, разочаровывается второй раз подряд.

• Компания без инженерной культуры. IC-трек имеет смысл там, где много команд и продукт высокой сложности — SaaS, банковские системы, — или где рискуют потерять ключевых людей. В компании на пятнадцать разработчиков влиять кросс-командно не на что: команд две, домен один. Роль вырождается в «тот же сеньор, но за всё отвечает» и кончается выгоранием.

• Мотив — только деньги. Тут всё арифметически просто. Если задача — увеличить доход, а не масштаб влияния, то без оформленного грейда это медленнее, чем смена работы: сборка роли занимает месяцы, а рынок пересматривает вилку сразу.

Чем экспертиза в проектной и аутстафф-модели отличается от продуктовой

В проектной и аутстафф-модели формального грейда staff или principal обычно нет: он не описан в штатном расписании, и экспертиза растёт иначе — через смену доменов и типов систем. Мы видим это на своих командах: инженер за несколько лет проходит банк, ритейл, промышленность — каждый раз другой ландшафт и другое легаси.

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

Рынок платит за это по-разному: за глубину в одном продукте — на staff-треке, за широту паттернов — в архитектуре и консалтинге. Развилка простая. Хотите principal в продукте — идите в продуктовую компанию с оформленным треком. Хотите архитектурную широту и разные домены — проектная модель даёт её быстрее.

Частые вопросы про экспертный трек

1. Можно ли вернуться из тимлидов в разработку?

   Да, но чем дольше пауза, тем дороже возврат: технические навыки деградируют быстрее управленческих. Вывод — не выпадать из кода полностью.

2. Staff Engineer и техлид — это одно и то же?

   Нет. Техлид отвечает за техническую часть работы одной команды, staff — за архитектуру и практики нескольких. Отсюда и различие «техлид или архитектор»: у первого периметр — команда, у второго — система.

3. Сколько зарабатывает архитектор ПО в России?

   По данным Хабр Карьеры за первое полугодие 2026 (выборка 45 226 зарплат), медиана зарплат архитекторов ПО — 400 000 ₽ при медиане по ИТ-рынку России 191 000 ₽. Это медиана по специализации, а не вилка грейда, и сопоставлять её с данными других исследований нельзя.

4. Нужно ли архитектору писать код?

   Зависит от компании. В описании staff-трека Т-Банка готовность продолжать писать код указана прямым пунктом. Выясняется на собеседовании, а не после выхода.

5. Обязательно ли быть тимлидом, чтобы стать архитектором?

   Формально нет, фактически часто да: в требованиях встречается опыт техлида или архитектора от 2 лет. Засчитывается техническое лидерство, а не управление людьми.

6. Что делать, если в компании нет грейда выше senior?

   Собирать роль без грейда: зона ответственности шире команды, артефакты, видимость решений, фиксация на перформанс-ревью. Порядок — в разделе выше.