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

По моим наблюдениям, процентов 80 разработчиков на рынке не видели оформленного карьерного фреймворка (системы грейдов) ни разу в жизни. Работодатель тоже часто не предлагает четкой лестницы развития. В итоге мы попадаем в карьерный хаос: должности и роли путаются, грейды присваиваются на глаз, а зарплатные «вилки» скрыты за семью печатями. Следующее повышение обещают после яблочного Спаса — и то, если сам напомнишь о нем.

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

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

Спойлер: карьерные фреймворки — не панацея, но мощный инструмент, который может навести порядок и помочь вам планировать свое развитие.

Что такое карьерный фреймворк (система грейдов)?

Но для начала стоит разобраться в определениях, чтобы избежать недопониманий. 

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

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

Хорошо выстроенная система грейдов сразу отвечает на три ключевых вопроса:

1. Как мне вырасти до следующего уровня? Разработчик видит конкретные требования к навыкам и опыту для повышения. Исчезает ситуация, когда сотрудник в растерянности: «Что еще прокачать, чтобы доросло до сеньора?» — все критерии перехода прописаны заранее.

2. За что мне платят и сколько? Зарплата привязана к уровню, а не к умению торговаться на собеседовании. Это устраняет случаи, когда два middle‑разработчика получают разную зарплату без объективных причин.

3. Кто за что отвечает и чего от кого ждать? Система грейдов обеспечивает прозрачность и предсказуемость: и сотрудники, и менеджмент говорят на одном языке уровней, понимают зону ответственности каждого.

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

Отсюда вытекает известная проблема: переходя в новую компанию, разработчик вдруг узнает, что его прежний титул там не котируется. Без общепринятого стандарта звания junior/middle/senior плавают в зависимости от масштаба и требований компании.

Тезис выше может работать и по другому: например, если работаешь 2–3 года мидлом и понимаешь, что банально по годам уже можно и сеньором стать, а в твоей компании нет такой возможности. Тогда приходиться выходить на рынок и скорее всего устраиваться в аналогичную компанию без внятных грейдов, но уже сеньором. Да, бывает и такое.

Крупные IT-компании обычно делают систему грейдов более гибкой и градуированной. Помимо привычного деления Junior/Middle/Senior, вводятся цифровые уровни (L3, L4, L5…) или промежуточные ступени вроде Junior +, Middle +. Это позволяет тоньше дифференцировать рост внутри одного номинального уровня. 

Кроме того, на определенном этапе могут разветвляться карьерные треки: например, для разработчиков высокого уровня часто предусматриваются два пути развития — эксперт в технологии (Staff/Principal Engineer) или менеджер (Team Lead/Engineering Manager). Грейдирование отражает и эту вилку: можно расти в «глубину» как сильный технический специалист или переходить «в ширину», беря на себя руководящие функции — в зависимости от интересов человека и потребностей бизнеса.

Итак, карьерный фреймворк — это карта карьерного пути внутри компании. В идеале такая карта делает карьеру предсказуемой, зарплаты — справедливыми, а требования — прозрачными. Звучит замечательно, не правда ли? Почему же тогда вокруг столько хаоса? Но прежде чем ответить на этот вопрос, разберемся в том, как должен выглядеть идеальный фреймворк и чему он нас может научить.

Один из публично доступных карьерных фреймворков от Dropbox.

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

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

Что же представляет собой их карьерный трек? Это довольно внушительный документ, охватывающий множество дисциплин: backend и frontend разработчики, мобильные инженеры, специалисты по безопасности, SRE, ML‑инженеры, QA — для всех прописаны уровни от самых младших до очень высоких.

В Dropbox решили, что каждая роль заслуживает четкого описания критериев успеха на каждом этапе — и проделали титаническую работу. Уровни обозначены как IC1, IC2, IC3... (Individual Contributor) для разработчиков, и M‑линейка (M3, M4…) для менеджеров. Грубо говоря, IC1–IC3 соответствуют диапазону Junior‑Middle, IC4 — Senior, IC5 — Staff, IC6 — Principal, IC7 — Senior Principal (еще более высокий архитектурный уровень). Есть и параллельная ветка для Engineering Manager (от менеджера команды до директора).

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

Интересна философия, которую Dropbox заложил в основу. Там прямо говорится: карьерный фреймворк — это не чек‑лист для промоушена dropbox.tech.

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

Например, от Middle ждут уверенной реализации задач в рамках команды, от Senior — влияния на смежные команды и архитектуру, от Staff — влияния на технологическое направление компании и наставничества многих команд. Такой упор на вклад (а не только на технические навыки) — отличительная черта современных карьерных моделей.

Кроме того, в их фреймворке есть две части для каждой роли: Level Expectations (общие ожидания по масштабу влияния, самостоятельности, лидерству для данного уровня) и Core/Craft Responsibilities (конкретные обязанности и навыки по специальности).

Это, кстати, перекликается с тем, что много где практикуется: разделение универсальных компетенций (результативность, коммуникация, наставничество, культура) и сугубо профессиональных (технических) навыков.

Для нас с вами Dropbox Framework ценен не только как справочник, но и как пример оформления. Любой может зайти и посмотреть, как крупная компания из Кремниевой Долины описывает уровни для, скажем, Frontend‑разработчика или QA‑инженера. Это отличный бенчмарк. Вы можете даже попробовать оценить себя по их матрице: вдруг окажется, что вы соответствуете на 70% уровню Senior по версии Dropbox, а где‑то не дотягиваете в навыках наставничества — тогда будет понятно, над чем поработать.

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

К слову, помимо Dropbox, существуют и другие общедоступные фреймворки: упоминались примеры Rent The Runway, Medium, KickStarter, Monzo и т. д. (некоторые энтузиасты даже собирают коллекции таких открытых «лестниц»). Если кому‑то из читателей известны качественные публичные материалы на эту тему — добро пожаловать в комментарии, поделитесь ссылками. Это пойдет на пользу всему сообществу.

Почему во многих компаниях до сих пор нет грейдов?

Вернемся к главному вопросу статьи. 

Если опросить разработчиков, многие подтвердят: в их компаниях формальной системы грейдов нет. Максимум — где‑то слышали о намерении «внедрить карьерную лестницу», но руки до этого не дошли. По моему опыту, когда штат разработчиков переваливает за полсотни, менеджмент начинает задумываться о структурировании ролей и уровней. Идея грейдов часто пылится в бэклоге HR‑инициатив, но реализация откладывается на потом. Почему? Есть несколько причин:

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

2. Культура и опыт. Если фаундеры или руководители ранее не работали в компаниях с четкой системой грейдов, они могут просто не осознавать ценности этой затеи. Либо считают, что и так все понятно: «растем органично, каждый сам выстраивает свою карьеру». А некоторые и вовсе боятся, что введение формальных уровней свяжет руки менеджерам или вызовет недовольство сотрудников. Проще не поднимать эту волну.

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

Результат? Мы получаем тот самый карьерный хаос, о котором шла речь в начале статьи.

Хаос без системы: основные боли для разработчиков

Какие проблемы возникают, когда карьерный трек не прописан и грейды отсутствуют? Я попробовал, опираясь на свой опыт повспоминать разные кейсы, и сформулировал их ниже.

Рассмотрим самые болезненные точки – многие из них, уверен, знакомы middle- и senior-специалистам:

• Непонятно, как расти. В компаниях без фреймворков разработчики часто не понимают, как расти. Критерии размыты. Люди растут на ощупь, без ясных ориентиров. Это демотивирует и вынуждает искать рост вне текущей компании.

• Перекосы в зарплатах и титулах. Без грейдов зарплата зависит от переговоров, а не от уровня. Два middle‑разработчика могут получать очень по‑разному — просто потому, что один лучше торговался. А иногда мидл зарабатывает больше сеньора не потому, что круче, а просто так сложилось при оффере. Титулы обесцениваются, а доверие к системе падает.

• Неясные обязанности, ответственность. Когда нет четкого разделения по уровням, часто страдает распределение ролей. Кто должен код‑ревьюить новичков? Кто принимает архитектурные решения? А кто ведет самые сложные фичи или отвечает за качество релиза? В идеале на эти вопросы отвечает структура команд и грейдов: например, code review делают все Senior+, архитектуру утверждает Staff engineer, тестирование покрывает QA II уровня и т. д. Без этого решается по ситуации: сегодня ревьюит самый свободный, завтра — вообще некому ревьюить. В одной команде тимлид = самый опытный инженер, в другой — менеджер проектов. Возникает организационная путаница. Я наблюдал пример, когда в компании без грейдов решение, кого назначить лидом нового проекта или наставником джунов, принималось «с потолка» продакт‑менеджером — просто потому, что не было формальной системы ролей. Конечно, это вызывало вопросы и обиды: почему именно он лидер, а не я?

• Перегрев ожиданий и выгорание. В отсутствие понятных рамок люди сами придумывают себе планку. Многие убеждены, что через N лет в индустрии они автоматически становятся Senior, и начинают требовать соответствующей зарплаты (привет перегретому рынку последних лет). Компания может упереться: «Ты не тянешь на наш уровень сеньора» — а сотрудник не понимает, почему не тянет, если формальных критериев нет. Назревает конфликт. Либо обратная ситуация: разработчик перерабатывает, тянет задачи выше своего грейда (неформального), надеясь на повышение, но формального признания не получает и выгорает. Без понятной системы легко накачать завышенные ожидания или упустить моменты, когда человек перерос свои задачи.

• Отсутствие обратной связи и развития. Карьерный фреймворк обычно идет рука об руку с процессом регулярной оценки и развития: менторство, ревью навыков, план развития под новые требования. Если же системы нет, менторство пущено на самотек, регулярная оценка ограничена парой дежурных фраз на перформанс‑ревью. Никто не отслеживает системно, какие скилы прокачал сотрудник за год и что ему надо подтянуть для роста. В итоге профессиональное развитие становится личным делом самого разработчика. Кто‑то справляется, а кто-то – нет.

В совокупности все это превращается в тормоз для карьеры. 

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

Что делать разработчику, если в компании нет карьерной лестницы?

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

Что можно сделать прямо сейчас:

• Изучите публичные фреймворки (Dropbox и др.). Это поможет понять требования и зоны роста.

• Оцените себя трезво. Сравните себя с уровнем выше. Где провалы? Что можно прокачать?

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

• Найдите ментора или карьерного консультанта. Взгляд со стороны часто точнее внутреннего ощущения.

• Прокачивайте софт- и бизнес-скилы. Рост — это не только код, но и коммуникация, влияние, планирование.

• Следите за рынком, но без паники. Не ведитесь на чужие звания, сверяйте себя с реальными требованиями вакансий. Не гонитесь за званием ради звания.

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

Отсутствие карьерного фреймворка — не повод превращать свою карьеру в хаотичное плавание. Берите управление в свои руки.

Вместо эпилога

Мне искренне хочется, чтобы в нашем IT‑сообществе тема прозрачных карьерных траекторий выходила из тени. Многие проблемы «хаоса грейдов» решаемы, если о них говорить и совместно искать решения.

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

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

Также веду свой тг‑канал о карьере, буду рад вашей подписке!