👉 Кейс #22

👉Игорь:

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

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

В такой конфигурации логично сделать три шага:

1. Подчеркнуть важность вклада перед VP.

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

2. Перекалибровать ожидания.

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

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

3. Разобраться со скоупом.

Если по текущим задачам есть объективные косяки — имеет смысл мягко, но честно прожурить. Это часть взросления. Если наоборот — всё сделано хорошо, но сеньор не хлопает в ладоши — а чего бы в самом деле не порадоваться вместе и отметить успехи? Люди часто недооценивают свои результаты, пока кто-то не скажет: "Эй, вот здесь ты реально молодец".

А теперь — самая неприятная часть.

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

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

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

👉Александр Поляков:

Для начала вам с ним стоит выровняться в том, что такое сеньор и что такое стафф.

Возможно, у вас разное понимание этих позиций.

В моей картине мира умение довести проект до конца должно быть уже у сеньора. А также ответственность за результат, умение договариваться и много чего еще. Так что если смотреть на сухие факты (и только на те из них, которые есть в кейсе), этот разработчик не дотягивает еще даже до своей текущей позиции.

И да, если повысить видимость сейчас, то это тоже станет видно. Он точно этого хочет?

Ты, очевидно, не особо горишь желанием доверить ему еще один проект, раз пришел с таким вопросом.

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

1. Синхронизируйтесь в понимании точки A (текущее состояние) и точки B (куда нужно прийти, чтобы стать стаффом), без этого вы далеко не сдвинетесь и будете постоянно скатываться в подобные споры

2. Расскажи ему честно и открыто, чего ему сейчас не хватает

3. Выработайте план перехода

А возможность выступать на митингах можешь дать сразу, это ведь бесплатно)

👉Александр Орлов:

Судя по всему, решение о продвижении разработчика на позицию staff’а будет принимать VP of Engineering. Поэтому я бы прояснился с ним, рассказал ему про этого разработчика, его желание вырасти до staff’а, и то, что я думаю давать ему инфраструктурные проекты, чтобы он мог себя показать и принести impact компании на уровне staff’а.

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

Если ваш руководитель скажет: не, инфраструктурные проекты это хорошо, но для продвижения в staff человеку надо давать бОльший impact, тогда это будут не инфраструктурные проекты.

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