Карьерный рост инженера — это не всегда про переход в менеджмент. Есть и другой путь, в котором нет подчинённых, one-on-one и KPI, зато есть влияние на архитектуру, стратегию и технологическую зрелость компании. Уровни Staff и Principal Engineer — это не просто «старшие разработчики», а ключевые технические роли, которые помогают бизнесу двигаться вперёд.

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

Я — Кирилл Евсеенко, сейчас CTO в музыкальном сервисе Звук, до этого — C-3PO (Директор по технологиям и продукту) в онлайн-кинотеатре START. В IT больше 20 лет, и за это время я видел, как по-разному можно расти. В этой статье расскажу, чем Staff и Principal отличаются от Senior, когда компании действительно нужны IC-инженеры, и как создать условия для их работы.

Звук — это музыкальный сервис с миллионами треков, подкастов, аудиокниг, эксклюзивных плейлистов и разделом для детей.

В Звуке сейчас работает около 700 человек, из них примерно 500 — это инженеры, разработчики и продакты, распределённые по 6 продуктовым стримам и 19 продуктовым командам.

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

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

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

Личный опыт: как я пришёл к инженерному треку

Небольшая история. Когда я был ещё не очень опытным менеджером, ко мне пришёл Senior разработчик с амбициями. Я сделал его тимлидом — и довольно быстро стало понятно, что работа с людьми, их развитие и управление ему не по душе. Ему хотелось двигаться именно по инженерной вертикали. В итоге он ушёл из компании. Спустя время он нашёл себя в этой роли и вырос — всё у него хорошо.

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

Сегодня я хочу рассказать, как можно строить карьерные пути не только в сторону управления людьми (people management), но и через развитие в роли IC (Individual Contributor). Это полноценная инженерная ветка, специалисты которой приносят компании ценность и влияние на стратегическом уровне — через технологии.

Важно, что IC — это финальная роль, а не промежуточный этап. Она требует зрелости и от инженера, и от компании: среда, доверие, возможность влиять и нести ответственность — всё это должно быть.

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

Кому это будет полезно:

• Тем, кто хочет понять, как строить свой путь в инженерной ветке — от Senior до Principal.

• Тем, кто остаётся инженером по духу, но уже упёрся в потолок текущей роли и не хочет идти в people-менеджмент, а развиваться дальше хочется — просто непонятно, как.

• Тем, кто строит или развивает инженерную культуру в компании и хочет разобраться, какие уровни роста нужны и какие компетенции важны.

• Руководителям, которые хотят помогать IC-инженерам развиваться, но не до конца понимают, где проходят границы ролей и какие от них ожидания.

Эту статью можно рассматривать как фреймворк по развитию в инженерной вертикали — с примерами ролей, уровней, задач и подходов.

Карьерный рост — это не только переход в менеджмент

Начнём с общей картины: какие вообще бывают сценарии карьерного роста.

Стандартный вертикальный карьерный рост. Классический переход, когда, например, Senior-разработчик становится тимлидом, потом руководителем, а через какое-то время — даже CTO.

Смежный рост, когда человек переходит в соседнюю область. Разработчик может уйти в DevOps, стать data-инженером, ML-инженером или архитектором. А из этих треков тоже возможен рост, вплоть до CTO.

Горизонтальный рост — о нём в этой статье пойдёт речь. Это путь по инженерной ветке, где человек продолжает развиваться в технологии, но при этом остаётся IC.

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

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

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

IC vs Тимлид

Менеджерская и инженерная ветки отличаются, и это различие важно понимать.

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

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

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

В плане навыков инженерный трек опирается на system design, code review, работу с метриками производительности и архитектурное мышление.

Тимлид, напротив, фокусируется на процессах, стабильности и командной синхронизации — ретро, ритуалы, выравнивание, взаимодействие между участниками. Он влияет на результат через людей: проводит 1:1, работает с ИПР, KPI, занимается развитием команды.

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

От Senior до Principal: как растёт влияние

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

Senior Engineer

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

Обычно такой инженер работает в одном стеке, делает end-to-end фичи в пределах своей зоны ответственности. Например, он ведёт микросервис: пишет код, проводит ревью, в целом — всё стандартно.

Из soft-скиллов важны: самостоятельность в принятии решений, умение аргументировать, наставничество и взаимодействие с коллегами на равных. Это зрелый член команды, который умеет договариваться и двигать задачи вперёд.

Примеры задач на этом уровне:

1. Оптимизировать производительность одного из API-методов: сократить время ответа с 2000 до 150 мс

2. Добавить поддержку нового способа авторизации в сервис (например, SberID)

3. Провести код-ревью сложного MR-разработчика и предложить улучшения

4. Добавить фичу «скрыть плейлист» в мобильный API с учётом обратной совместимости

5. Интегрировать сторонний сервис push-уведомлений в backend

Staff Engineer

Это следующая ступень, на которой инженер как технический лидер, как правило, влияет уже не на одну, а на несколько команд. Staff Engineer внедряет лучшие практики и стандарты, принятые в компании. Формального подчинения у него обычно нет, но его техническое мнение весомо, и команды к нему прислушиваются.

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

Из soft-скиллов особенно важны фасилитация технических обсуждений и умение аргументировать инженерные решения. Staff Engineer должен не просто «починить», а объяснить, почему это важно, почему техдолг — это инвестиция, и как это повлияет на бизнес. Он помогает команде договариваться по делу, «по-инженерному», и может менторить не только джунов и мидов, но и синьоров.

Примеры задач на этой роли:

1. Разработать план миграции с MongoDB на PostgreSQL для четырёх сервисов и унифицировать стек

2. Внедрить архитектурный стандарт логирования и трассировки во всех backend-сервисах

3. Провести анализ метрик latency и переработать retry-политику запросов

4. Быть техническим лидером реализации проектной инициативы по изменению системы кодирования контента и приведению её к стандарту

5. Договориться с продактом относительно интеграции кросс-командной фичи

6. Понять, что сделано или спроектировано не очень корректно с точки зрения целей, и аргументированно договориться, что можно улучшить

Principal Engineer

Это следующая ступень в инженерной вертикали. Principal Engineer уже влияет не на отдельные команды, а на стратегию всей компании и её технологический ландшафт. Это те самые «дяди-инженеры», которые формируют техническую культуру и задают стандарты, с которыми будут работать остальные. Часто они взаимодействуют напрямую с бизнесом или CTO, чтобы выстраивать долгосрочные планы развития.

Principal Engineer определяет долгосрочный вектор развития, влияет на инженерные практики, принимает участие в платформенных и инфраструктурных решениях, работает совместно с пирами и другими командами. Он также может участвовать в бюджетировании, потому что всё больше компаний фокусируются на технической ценности (cost value) и хотят понимать, куда идут инженерные инвестиции.

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

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

Примеры задач:

1. Разработать и защитить техническую стратегию развития платформы на 1,5 года

2. Провести аудит зрелости инженерных практик в компании и предложить план улучшений

3. Вмешаться в инициативу, где продукт навязывает неустойчивое решение, и убедить изменить курс

4. Настроить взаимодействие между продуктом и внешними партнёрами

5. Провести аудит инфраструктуры, баз данных, кэшей, API, выявить узкие места и предложить улучшения, которые позволят ускорить отклик на 30–50%

Principal и Staff: курс и реализация

Резюмируя разницу между этими двумя высокими ролями:

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

Staff Engineer действует в рамках своей области — внедряет практики, ищет локальные улучшения, решает кросс-командные задачи. Это технический лидер, чьё влияние сосредоточено внутри конкретных команд или стримов.

Principal — куда идём, Staff — как именно это реализуем на практике.

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

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

Что после Principal

Это финальная роль или после неё ещё есть куда расти? Вопрос логичный: вот вы доросли до Principal, стали влиять на стратегию, задачи серьёзные — а дальше что?

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

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

IC и Архитектор: где граница зон ответственности

IC-инженер работает вглубь — он пишет код, реализует собственные инженерные решения и активно участвует в их проработке. Это тот, кто сам делает руками и берёт на себя реализацию ключевых компонентов.

Архитектор, напротив, работает на более высоком уровне — например, в терминах C4-модели, API-интерфейсов, интеграций между системами. Его фокус — как устроена система в целом. Он понимает все системы компании, думает о совместимости, масштабируемости и отказоустойчивости.

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

В терминах специализации:

• IC — это глубина в конкретной области (бэкенд, фронтенд, ML и т.п.)

• Архитектор — это ширина: он понимает, как устроены разные системы и как их соединить в единое устойчивое целое.

Но уровень Principal — не финальная точка. В инженерной ветке есть развитие дальше — на уровень Fellow.

Fellow и Distinguished: легенды инженерного мира

Про эту роль пока знают немногие. Я сам узнал о ней сравнительно недавно. В грейд-сетках крупных зарубежных компаний самые высокие ступени занимают именно инженерные роли, и среди них — Distinguished и Fellow (названия могут отличаться: где-то это архитекторы, где-то инженеры).

Важно понимать: не каждая компания вообще может эволюционировать в эту сторону, и не каждой компании, как и не каждому инженеру, этот путь нужен.

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

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

Fellow — это, как правило, разработчики чего-то супер-прорывного для бизнеса или индустрии. Пример: Марк Руссинович — единственный  Fellow и архитектор Azure Cloud.

По взаимодействию: Distinguished ниже Fellow, но оба играют роль force multiplier — специалистов, к которым можно прийти с любым инженерным вопросом и получить системный, продуманный ответ. Они влияют на концептуальное развитие инженерной стратегии всей компании.

Грубо говоря, Distinguished — это технологическая роль, а Fellow — скорее продуктовая.

Несмотря на то что это обе инженерные позиции, по сути:

• Distinguished Engineer — это Ultimate CTO,

• Fellow — это Ultimate CPO, только в инженерной ветке.

Несколько интересных историй

А теперь немного легенд и историй из индустрии — как Fellow выглядит в разных компаниях.

Полулегенда из Microsoft:

Fellow — это специальная позиция для тех, кому нельзя позволить создать свою компанию, потому что она может заруинить текущую.

Рассказ от CTO Samsung:

Главная задача Fellow — пить кофе и думать. И глядя на то, как они это делають, вся компания тоже начинает думать лучше.

История от Apple: 

Fellow в Apple — это почётный статус. Стив Возняк и Фил Шиллер носили это звание. Они делились визионерским взглядом, представляли компанию на ключевых мероприятиях, курировали спецпроекты.

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

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

Я знаю, что в T-Bank на всю компанию есть один Fellow, который делает крутые прорывные штуки. В других российских компаниях такие позиции мне не встречались.

Если подвести промежуточный итог: моя задача как руководителя — вовремя замечать потенциал в инженерах и помогать им выходить на следующий уровень. Но как это на практике?

Как помочь инженерам расти

Есть несколько вещей, на которые стоит опираться, если вы действительно хотите развивать IC-инженеров в команде.

1. Давать сложные, амбициозные задачи

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

2. Создавать среду для обмена знаниями

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

3. Дать право принимать решения и брать за них ответственность

Инженеры должны не просто выполнять то, что им говорят, они должны сами определять, что важно делать. Это и есть рост — когда человек становится двигателем изменений, а не просто исполнителем.

4. Формировать понятные критерии роста:

• Прозрачная карьерная лестница для IC с чёткими ожиданиями — это как раз те самые матрицы компетенций

• Регулярные 1:1, на которых вы обсуждаете не только задачи, но и траекторию развития

При этом очень важно понять, когда IC действительно нужен, потому что не в каждой команде, не в каждом продукте и не на каждом этапе зрелости эта роль необходима.

Когда без IC не обойтись

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

1. Крупные компании и технологически сложные продукты

Обычно это крупные компании, о которых я уже упомянул. Это могут быть крупные SAAS продукты, банковские продукты, либо продукты, где очень много инженерных команд, которые необходимо подружить между собой и управлять на инженерном уровне. 

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

2. Существенный риск потери ключевых сотрудников

Если в команде есть сильные инженеры, и вы чувствуете, что можете их потерять, — это повод подумать о создании для них отдельной вертикали роста. Особенно если они хотят развиваться именно в глубину технологии, а не в менеджмент.

Важно: это должно быть не только про амбиции конкретного человека, но и про интересы бизнеса. IC — это не способ «удержать талант любой ценой», а вложение в инженерную ценность. 

Итоги

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

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

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