Если честно, без корпоративной шелухи, то рост разработчика — это не про грейды и не про количество технологий в резюме. Это про расширение зоны неопределённости, которую ты способен закрыть самостоятельно.
При этом техничка — необходимое условие: без неё никуда, особенно в начале пути. Просто она перестаёт быть достаточной: чем дальше, тем больше роста происходит в ответственности, коммуникации и решениях, а не в новых фреймворках.
Junior → Middle: от «делаю по инструкции» к «делаю сам»
Джун решает задачу, если ему дали алгоритм. Мидл — сам разбивает задачу на шаги и доводит до конца.
Ключевой сдвиг здесь: перестать ждать, что кто-то придёт и скажет, что делать. Мидл — это человек, которому можно дать задачу и забыть. Он вернётся либо с результатом, либо с вопросом, который нельзя было решить без тебя.
Учить технологии на этом этапе — нужно и полезно. Глубина в языке и фреймворке помогает быстрее закрывать задачи, понимать тонкости и краевые случаи, раньше включаться в обсуждение архитектуры — уже не «мне сказали так сделать», а «я понимаю, почему так». Техническая база на этом этапе — главный двигатель роста, и вкладываться в неё точно стоит.
Тонкость в другом: обучение — это топливо, а не сам рост. Курс по архитектуре или сертификат помогают, если ты параллельно расширяешь самостоятельность. И не меняют ничего, если нет: можно собрать коллекцию сертификатов и остаться человеком, которому нужен алгоритм на каждую задачу.
Middle → Senior: от «делаю сам» к «отвечаю за результат»
Синьор отличается от мидла в том числе глубиной знаний — и это важно признать: синьор знает стек глубже, видит граничные случаи, понимает, как инструмент устроен изнутри и где он сломается. Но глубина — не главное различие. Главное: синьор берёт ответственность за исход, а не за процесс.
Мидл говорит: «я сделал свою часть, но аналитик не дал требования / смежники не ответили / влеты помешали». Синьор говорит: «фича не поехала — это моя проблема, и я её решу. Пойду к аналитику, пойду к смежникам, расставлю приоритеты, но доведу до прода».
Именно поэтому синьору не обойтись без переговоров: результат почти всегда зависит от людей за пределами его команды. Переговоры — это не «дополнительная нагрузка», это ядро роли. Важная оговорка: переговоры — навык, а не черта личности. Интроверсия — не приговор (лучшие переговорщики часто как раз те, кто умеет слушать), но избегать коммуникации на этом уровне уже не получится.
Ещё один признак синьора: он видит последствия своих решений на 2–3 шага вперёд. Мидл решает задачу. Синьор думает, как это решение отзовётся через полгода, какие зависимости создаст, что сломает.
После синьора дороги расходятся
Разберём три разных трека:
- Team Lead / Engineering Manager — управленческий трек: люди, процессы, найм, развитие, обратная связь.
- Tech Lead — техническое лидерство в команде: архитектура, стандарты, качество. Часто гибридная роль: лидерство плюс заметная доля кода.
- Staff / Principal Engineer — инженерный трек (individual contributor): влияние на несколько команд через архитектуру, стратегию и менторство.
Стать принципалом можно и из синьора, минуя лидские позиции — это другой трек, а не следующая ступень после тимлида. В реальных компаниях роли размываются: тимлид часто тянет и роль техлида, в небольших командах — вообще всё. Но суть у треков разная, и качать придётся разное.
Team Lead: отвечаю за людей и результат команды
Тимлид — это уже не про «я самый сильный инженер». Это про то, что команда выдаёт результат лучше, чем без тебя.
Что меняется:
- Ты больше не пишешь лучший код в команде. Ты создаёшь условия, чтобы его писали другие.
- Ты защищаешь команду от хаоса сверху и снизу: фильтруешь влеты, договариваешься со стейкхолдерами, выбиваешь ресурсы.
- Ты принимаешь неприятные решения: кого-то хвалить, кому-то говорить «нет», кого-то двигать, а кого-то — нет.
- Твоя главная метрика — не «сколько я сделал», а «сколько команда сделала и не выгорела».
Мне очень нравится формулировка одного моего разработчика: «если ты не пишешь код — твой инструмент это слово». У тимлида слово должно быть отточено так же, как код у инженера: письма, документы, фидбек, сложные разговоры. Это единственный твой инструмент — и плохое владение им напрямую определяет, насколько ты плох на этой позиции.
Многие сильные синьоры спотыкаются на этом переходе, потому что не могут отпустить код. Это нормальная цена трека: работа теперь в людях и процессах, а не в коммитах.
Tech Lead: отвечаю за техническое направление
Техлид — не «начинающий менеджер» и не «синьор с прибавкой». Это роль, в которой ты отвечаешь за технические решения команды: архитектуру, стандарты, качество, управление техдолгом. При этом ты остаёшься инженером и, скорее всего, продолжаешь писать код — но уже не «лучший код в команде», а код там, где он даёт максимум пользы: сложные места, обучение примером, прототипы.
Главная ловушка техлида — стать бутылочным горлышком: все архитектурные решения через тебя. Работает ровно до первого масштабирования. Настоящий техлид растёт тогда, когда его решения принимаются без него — через стандарты и договорённости, которые он оставил после себя.
Principal / Staff: отвечаю за технологию на уровне организации
Принципал — это не «тимлид на стероидах». Это человек, который влияет на то, как работают несколько команд одновременно, оставаясь инженером, а не менеджером.
Он не управляет людьми напрямую. Он влияет через:
- архитектурные стандарты, которые принимают другие,
- менторство других лидов,
- техническую стратегию на кварталы вперёд,
- способность договариваться на уровне бизнеса и защищать технические решения перед руководством.
Принципал — это тот, чьи решения масштабируются без его прямого участия. Он не может быть в каждой команде, но его подход работает везде.
Главный сдвиг: от «сделать хорошо здесь и сейчас» к «сделать так, чтобы хорошо было везде и надолго».
Плюсы и минусы каждого трека
Прежде чем нестись в менеджмент «потому что грейд выше» — посмотри честно, что тебя там ждёт.
Team Lead / EM
Плюсы:
- результат умножается через людей: команда как рычаг;
- путь к Director / VP.
Минусы:
- код почти исчезает;
- рутина процессов и 1:1;
- найм и увольнения — эмоционально тяжёлая часть;
- слово — твой главный инструмент, и по нему тебя будут судить.
Подходит тем, кому интересно «кто» и «зачем» больше, чем «как».
Tech Lead
Плюсы:
- остаёшься в техничке и в коде;
- инженерное влияние плюс лидерство.
Минусы:
- двойная нагрузка: код и лидерство одновременно;
- мало формальных полномочий — влияние нужно зарабатывать;
- масштаб — чаще всего одна команда.
Подходит сильным инженерам, которым интересно вести техническое направление без HR-части.
Principal / Staff
Плюсы:
- максимум технического влияния без менеджмента;
- стратегия и самые сложные задачи.
Минусы:
- влияние без полномочий: идеи надо продавать;
- результат отложен и его сложно «пощупать»;
- вакансий мало, конкуренция высокая.
Подходит тем, кто любит инженерию больше процессов, а пишет и договаривается не хуже, чем кодит.
Два честных замечания напоследок.
Первое: переход в менеджмент — это не повышение, а смена профессии. Классическая ошибка — двигать в тимлиды лучшего инженера «потому что вырос». Это разные работы, и успех в одной не гарантирует успеха в другой.
Второе: треки совместимы и обратимы, хоть обратный переход (из менеджмента в инженерию) и непростой. Попробовать можно недорого: взять менторство джуна, поруководить подпроектом, поучаствовать в найме. Если не зажгло — это дешёвый способ понять, что трек не твой, и не тратить годы.
Что общего у всех уровней
Рост — это всегда сдвиг от «я делаю» к «я отвечаю», и дальше — к «я создаю условия, чтобы другие делали».
| Уровень | Что делает | За что отвечает |
|---|---|---|
| Junior | то, что сказали | за выполнение шагов |
| Middle | то, что нужно | за свою задачу целиком |
| Senior | то, что нужно — и доводит до прода | за результат фичи |
| Team Lead | создаёт условия | за людей и результат команды |
| Tech Lead | задаёт техническое направление | за технические решения команды |
| Principal | задаёт стратегию | за технологию организации |
Чего в этой лестнице нет
- Списка технологий как меры роста. Учить стек нужно всегда, а в начале пути — особенно: без базы не будет и самостоятельности. Но знать 20 фреймворков и остаться мидлом — реально: уровень определяет зона ответственности, а не перечень навыков.
- Красивых диаграмм. Архитектура — это переговоры, а не картинки.
- Курсов и сертификатов. Инструменты, а не рост: помогают, если параллельно растёт самостоятельность.
- Стажа. Можно 10 лет просидеть на одном уровне, если не расширять зону ответственности.
И честно, самое неприятное
Рост часто выглядит не как «стало интереснее», а как «стало больше ответственности и меньше определённости». Чем выше уровень, тем меньше готовых ответов и тем больше нужно договариваться, рисковать, брать на себя.
Именно поэтому многие талантливые инженеры останавливаются на синьоре — не потому, что «не могут дальше», а потому что дальше начинается не следующий грейд, а выбор профессии: людьми, направлением или стратегией. Навыкам там можно научиться. А вот нравится ли тебе заниматься этим каждый день — вопрос честности с собой, и ответ «нет» — тоже нормальный ответ.
И ещё одна деталь, о которой обычно молчат: в момент перехода ты снова становишься джуниором. Не по грейду в зарплатной ведомости — по сути. Каким бы треком ты ни пошёл, на старте это одна и та же роль: менеджер младшего звена. Твои ресурсы — твоя команда и влияние на неё, и всё. Вышестоящие формулируют желания — «хочу» — без полномочий и дополнительных рук: чужие бэклоги тебе не подчиняются, и ради цели придётся выпрашивать, уговаривать, меняться. Продавать свои решения наверх ты пока не умеешь, а часто и не можешь: переспорить уже принятое решение или изменить процесс — не твой уровень. А бывают руководители, до которых не достучаться в принципе — вплоть до того, что за них приходится думать, писать и договариваться, пока они ставят подписи.
И со всем этим, скорее всего, придётся мириться: следующий уровень — лиды лидов, руководители кластеров — совсем другая доступность. Мест там в разы меньше, и когда одно освобождается, его почти всегда закрывают внутренним кандидатом, не выходя с вакансией на рынок.
Звучит мрачно, но в этом и есть честная цена выбора: в новой профессии ты снова начинаешь снизу — со всеми детскими болями джуна. Просто твой стек теперь не язык и фреймворк, а люди, процессы и договорённости.
Вот это, если честно, и есть настоящий рост.
Что почитать
На русском:
- Должность — тимлид (Хабр) — «тимлид — интерфейс команды разработки»: про границы роли и чужие обязанности, которые к ней «прилипают».
- Почему хорошие инженеры не всегда становятся хорошими тимлидами (Слёрм) — про переход «инженер → менеджер» и как примерить роль до прыжка: менторство, Tech Lead на подпроекте.
- Камиль Фурнье, «От разработчика до руководителя» — русский перевод «The Manager’s Path»: путь от ментора до техдиректора.
На английском:
- StaffEng — Уилл Ларсон — бесплатно и по делу про staff/principal-уровень.
- The Pragmatic Engineer — Гергей Орош — про переходы между уровнями и реальность больших техкомпаний.
- Таня Рейли, «The Staff Engineer’s Path» — как быть лидером без формальной власти.
