Как оценить вклад каждого инженера в команде

 Публичный пост
6 января 2022  1214

Пост написан под вдохновением книги Kim Scott “Radical Candor”.

Я никогда не задумывалась, что ребят в SWE команде можно попробовать разбить на два лагеря: rockstars и superstars. Под rockstars будем представлять вершину горного хребта или горы!

Начнем с superstars!

Это амбициозные ребята, которым вечно не сидится на одном месте, и они жаждут неперерывно челенджить себя. К ним относятся, к примеру, многие new grad студенты!

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

Перейдем к rockstars ⛰!

Мейнстримно считать [осень 2021], что каждый должен непременно стремиться быть superstar. Много тех, кто не жаждет грейдапа по иерархии вверх, а вместо этого хочет расти горизонтально, другими слова в “глубь” своих текущих компетенций. Вот эти ребята и есть rockstars! Они становятся все более и более скиловым в своей области, но не взвешивают на себя новые роли и обязанности. Они опора команды.

Для наглядности, superstars и rockstars можно представить, как два обхода по дереву SWE скиллов:

• superstars делают BFS, охватывая разные виды знаний и навыков
• rockstars пробираются к дебрям определённых знаний, делая DFS до самого листочка

Важно сказать, что каждый может быть в разные этапы жизни как superstars, так и rockstars, в зависимости от приоритетов человека на данный момент времени.

И вот мы подобрались к вопросу, который у меня возник после прочтения про superstars и rockstars:

Как же оценить вклад rockstar’ов?

Для сбалансированной команды нужны оба лагеря. Но часто rockstar’ов и вклад, которые они вносят в команду, недооценивают, оставляют в тени или просто не знаю, как оценить.

  1. В случае с superstars все достаточно прозрачно. Их рост, скорей всего, будет видим для менеджера/лида, который оценивает superstar на стадии ревью. Рост зоны ответственности и компетенций достаточно легко заметить и измерить.

  2. C rockstars все обстоит сложнее. Как правильно оценить их вклад, если они не являются непрерывными генераторами всего нового и не стремятся видимым образом увеличивать свои компетенции? Они растут, но внутри их текущей зоны ответственности, делая быстрее и качественнее все более и более непростые задачи. Совсем не прозрано, как сравнивать “быстроту выполнения” и “качество выполнения” задач. Часто rockstars все-таки оказываются сильно недооцененными.

На момент написания поста, я работаю я одной из крупнейших IT компаний в России ;) и замечаю большую текучку rockstar’ов. Основное внимание менеджеров/лидов и в целом кампании направлено на superstars. Их активно поощряют, мотивируют, о них говорят, тогда как rockstar’ы остаются в тени компании, и даже в тени менеджера. Часто, менеджер не замечает вклада rockstar, а если даже и замечает, то не знает, как оценить.

Если посмотреть на другие крупнейшие IT компании мира, то, по моим наблюдениям, политика Google тоже больше направлена на superstars, туда же можно отнести Amazon, Meta(ex Facebook). Но есть и те компании, которые стремятся больше поощрять rockstars — это Apple или Netflix, например.

Клево и очень важно достичь в этом баланса!

Поделитесь своими наблюдениями, возможно кто-то уже смог достичь этого баланса в своей команде:)

17 комментариев 👇

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

Многие компании отказались от performance review в классическом его виде.

Есть ли у вас свои методы оценки работоспособности / пользы разработчиков, без деления на рок-звезд, 10х инженеров и вот этого всего?

Или все же классическое review лучше?

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@rSTeWTpETmJf1EMj, в первую очередь performance review нужно для того, чтобы скорректировать рост разработчика. Если этого не делать, какая-то часть разработчиков зависает на уровне Junior/Middle и не двигается дальше.
Во вторую очередь, для коррекции направления развития. Если в компании нужна экспертиза в микросервисах и RabbitMQ, а разработчик хочет углубляться в реляционные БД, лучше всего это проговорить на Perfomance Review и принять решение как быть дальше - давать другие задачи, искать на текущий проект другого разработчика и т.п.

  Развернуть 1 комментарий

@auvoronov, это все хорошо решается на one-to-one с тех.руководителем. Причем своевременно, а не через полгода-год.

  Развернуть 1 комментарий

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

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

При этом нужно ли проводить именно перфоманс ревью вопрос спорный. Можно и другие подходы/фреймворки юзать, но только если есть четкое понимание проблем с конкретным инструментом. А если нет ничего, то лучше уже с перфоманс ревью, чем без всего :)

  Развернуть 1 комментарий
Igor Kustov Java & Go Developer in Search 6 января 2022

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

  Развернуть 1 комментарий
Yury Katkov в шаббатикале 6 января 2022

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

На горизонтальном уровне гребцы знают все друг про друга, и если уметь их разговорить, не сильно нужны ни метрики, ни классификации. Кто самый ленивый? Да вот погляди, Юра ж, это и так всем понятно, он еще и туповат, и пуллреквесты у него говно и код отстой! А кто гуру в SVG-анимации но не любит разговаривать? Да вот Маша. А кто может со всеми договориться, кого надо запугать, кому надо пообещать, сроки отсрочить, ресурсов прибавить, соседнюю команду припахать? Да Ксюха, кто ж еще?

  Развернуть 1 комментарий

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

Было бы круто сравнить опыт других людей, пока я кажется не догоняю)

оффтопное брюзжаение 25-летнего деда:
от super/rockstars, ninjas, evangelists, etc чет жутко корёжит последние пару лет, мб это мой личный загон)

  Развернуть 1 комментарий

Хмм, когда мне рассказывали про Radical Condor, там было больше про Feedback framework, интересно узнать что-то другое. Насчет фидбека основным фокусом было 2 пункта: нужно действительно хотеть помочь человеку фидбеком (Care personally) и при этом быть откровенным(Challenge Directly)

4 вида фидбека
4 вида фидбека

P.S.Reference на статью

  Развернуть 1 комментарий

На момент написания поста, я работаю я одной из крупнейших IT компаний в России ;) и замечаю большую текучку rockstar’ов.

Да и пофиг. Один рокстар свалит от компании на зарплату побольше, компания почешет репу и другого наймёт на зарплату побольше. Вуаля, повышение состоялось.

  Развернуть 1 комментарий

На момент написания поста, я работаю я одной из крупнейших IT компаний в России ;) и замечаю большую текучку rockstar’ов. Основное внимание менеджеров/лидов и в целом кампании направлено на superstars. Их активно поощряют, мотивируют, о них говорят, тогда как rockstar’ы остаются в тени компании, и даже в тени менеджера. Часто, менеджер не замечает вклада rockstar, а если даже и замечает, то не знает, как оценить.

Читал и думал, блин, неужели коллега яндексоид))) Хотя на самом деле до этой статьи никогда не задумывался о такой проблеме

  Развернуть 1 комментарий

@arsentiev, тоже работаю в "одной из крупнейших", но в нашем уютненьком БЮ кажется что все не так, по крайней мере с разработкой, по крайней мере пока что)

  Развернуть 1 комментарий

@natix, наверное я не совсем правильно сформулировал свою мысль: я не наблюдаю вышеописанную проблему у себя в БЮ, но мое понимание системы ревью говорит о том что такая проблема есть/должна быть исходя из того на что(в моем понимании) смотрят на ревью

  Развернуть 1 комментарий

@arsentiev, возможно, у нас и ревью не совсем стандартное для "крупнейших", но отношение в итоге такое, что технически крутым ребятам почет и увожение, а если ты недостаточно хардскилловый, то попробуй в тимлиды пойти, может там на что сгодишься (не всегда конечно так, это скорее мой кейс, да)) )

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

  Развернуть 1 комментарий

Интересные мысли!

Если честно в компаниях поменьше (я пока избегаю ФААНГов) дисбаланса внимания между этими типами людей я не заметил. Да и в больших компаниях я думаю это больше зависит от команды, чем универсальный подход везде (даже на Вастрике были такие истории).

"Суперстары" могут быть в целом заметнее, как раз из-за того, что они часто/много задают вопросы, подмечают проблемы и предлагают решения. Но тут все сильно упирается в систему оценки и менеджера (лида/продакта). То есть очень сильно влияет человеческий фактор.

Кстати, Виолетта, а ты сама себя к какому типу относишь? :)

  Развернуть 1 комментарий

@Danya-Z, а почему считается, что те, кто развиваются вширь, чаще задают вопросы, подмечают проблемы и предлагают решения? Мне кажется, это зависит от сугубо личных качеств, и хороший "рокстар" делает это так же часто, как хороший "суперстар"

  Развернуть 1 комментарий

@boolet37, я не уверен про то, что "так считается" прям. Но в целом это даже логично. Что бы развиваться вширь неизбежно придется коммуницировать с большим количеством людей за пределами своей команды и зоны ответственности.

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

Это безусловно зависит от личных качеств и характеристик.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб