Эфемерность погонов

Есть такая корпоративная болезнь. Тихая, незаметная, но очень дорогая. Её не видно в квартальных отчётах, она не попадает в post-mortem после провала продукта, о ней не говорят на ретро. Но она присутствует почти в каждой компании, которая пытается расти и масштабировать что-то серьёзное.

Называется просто: раздать звания — и думать, что проблема решена.

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

Начнём с самого начала. Компания растёт. Или хочет расти. Нанимают людей, выстраивают структуру, начинают думать о грейдах. И тут включается самый простой и самый разрушительный способ решить вопрос: взять и расставить людей по уровням исходя из того, сколько они работают, насколько они лояльны и насколько их страшно потерять.

Junior — только пришёл. Middle — поработал год-два, не косячит. Senior — старожил, знает как тут всё устроено. Lead — ну, надо же куда-то расти, дадим Lead.

Всё. Система грейдов готова. HR доволен, у людей есть карьерная лестница, стейкхолдеры видят структуру. Красота.

Только одна проблема: к реальным компетенциям это не имеет никакого отношения.

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

Вот так и рождаются Senior-ы, которые никогда в жизни не принимали настоящих решений.

Это важный момент, который часто упускают. Система пустых погонов работает. На коротком горизонте — очень даже хорошо работает.

Человек хочет расти — дай ему Middle, и он останется ещё на год. Не нужно поднимать зарплату до рыночного уровня — дай Senior, и он почувствует себя оценённым. Нужно удержать ключевого сотрудника — сделай его Lead, и он будет лоялен. Всё это реальные инструменты удержания, которые HR-ы применяют ежедневно, и с точки зрения краткосрочной задачи они вполне рациональны.

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

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

За годы практики я научился различать три характерных типа. Они встречаются везде, просто в разных пропорциях.

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

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

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

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

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

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

И вот ты смотришь на своих Senior-ов и понимаешь: нет ownership. Нет инициативы. Нет готовности сказать "я отвечаю за этот результат". Есть готовность делать — но только если скажут что и как. Есть готовность отчитываться — но только о том, что уже сделано, а не о том, что надо было сделать по-другому.

Это не катастрофа сама по себе. Но это стена, об которую разбивается масштабирование.

Всё сказанное выше — это про всех: разработчиков, дизайнеров, аналитиков, менеджеров. Но есть роль, на которой эта проблема проявляется особенно жёстко. И эта роль — Product Owner.

Потому что PO — это роль, которую легче всего имитировать и сложнее всего реально исполнять.

Я сталкивался с этим регулярно. Заходишь в компанию, которая занимается реальным продуктом с реальными пользователями и реальными деньгами на кону. Смотришь на структуру — всё красиво: есть PO, есть Middle PO, есть Senior PO, где-то на горизонте маячит Lead PO. Думаешь: отлично, есть с кем работать.

А потом начинаешь копать.

Спрашиваешь: кто принимает решение о приоритетах в бэклоге? Оказывается — "согласовываем с руководством". Кто общается с пользователями, собирает фидбек, понимает боли клиентов? "Ну, у нас есть поддержка, они иногда передают...". Кто несёт ответственность за метрики продукта? "Ну, это у нас в KPI есть, но там сложно посчитать..."

И вот перед тобой человек с табличкой "Senior Product Owner", который никогда сам не расставлял приоритеты, не разговаривал с пользователями системно и не мог внятно объяснить как его работа влияет на результат продукта.

Это не его вина. Это вина системы, которая назвала его PO, но не дала ни инструментов, ни полномочий, ни понимания что эта роль вообще означает.

PO в такой ситуации становится просто красивым названием для должности "менеджер задач". Принимает задачи сверху, транслирует вниз. Следит чтобы всё было в Jira. Присутствует на стендапах. Выглядит занятым.

Звание есть. Роли нет.

Есть несколько причин, по которым роль Product Owner-а особенно уязвима для этой проблемы.

В отличие от разработчика (написал код, работает — не работает) или дизайнера (сделал макет, красиво — не красиво), результат работы PO сложнее измерить напрямую и быстро. Это создаёт огромное пространство для имитации деятельности. Можно очень убедительно выглядеть занятым, не делая ничего реально важного.

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

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

Был PO год — стал Middle. Два года — Senior. Никто особо не думает о том, что реально изменилось в его компетенциях. Просто прошло время, надо что-то сделать.

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

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

— не могут защитить своё решение перед стейкхолдером без поддержки сверху

— не понимают как их бэклог связан со стратегией продукта

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

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

Оба варианта болезненны. Но откладывать этот разговор ещё болезненнее.

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

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

Расскажи мне о последнем разговоре с реальным пользователем твоего продукта. Не про поддержку, не про опрос в форме. Живой разговор. Что ты узнал.

Расскажи мне о последний раз когда ты сказал "нет" стейкхолдеру. Что происходило дальше.

Эти три вопроса дают мне картину быстрее чем любое CV или грейд в HR-системе.

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

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

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

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

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

Из своей практики скажу: система которая работает — это оценка по нескольким факторам одновременно. Delivery — что реально сделано и с каким результатом. Quality — как сделано, насколько это устойчиво и правильно. Hard Skills — реальные инструменты и знания. И Mentoring — потому что зрелый специалист это тот, кто умеет растить других, а не только себя.

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

Причём важный момент: не время решает. Человек может пройти путь от Junior до Senior за полтора года если реально работает и реально растёт. А может сидеть на Middle пять лет — если система позволяет. Настоящий грейдинг выравнивает это.

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

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

Если ты читаешь это и узнаёшь свою компанию — не паникуй. Это решаемо. Но решаемо только если ты готов к честному разговору.

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

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

Третий шаг — ввести реальные критерии. Что значит Middle в вашей компании, в вашем контексте, для вашего продукта. Конкретно. Измеримо. Понятно каждому.

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

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

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

Я это видел. И именно поэтому говорю об этом прямо.