Как давать фидбэк

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

👉Вы недовольны человеком только потому, что его мнение отличается от вашего. Нормально давать фидбэк про то, как он выражает это мнение, но критиковать за противоположную вашей точку зрения точно неправильно.
👉Вы уже полностью разочаровались в человеке. Если вы не готовы встать на его сторону и поддержать его, лучше передайте свой фидбэк его менеджеру, и двигайтесь дальше.
👉Вы не объективны – конкретная проблема вызывает слишком много эмоций, либо вы не до конца уверены в своем фидбэке.
👉С момента события, про которое дается фидбэк, прошло слишком много времени.
👉Получатель фидбэка сильно джуниорнее вас. Если не быть очень аккуратным в том, что вы говорите, вы рискуете очень сильно навредить.

Читать полностью…

Как помочь плохо перформящей команде

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

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

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

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

Что важно понимать – если обстановка внутри компании не дает возможности использовать такие основанные на здравом смысле подходы, то каких бы опытных менеджеров вы ни нанимали, ситуации они не изменят.

Читать полностью…

Ретроспектива произошедшего с LLM в 2024

Мы тут периодически обсуждаем влияние AI на индустрию – рост количества некачественного кода и уязвимостей, сложности поиска работы джуном, да и вообще неясные перспективы для всех нас в будущем. Многие аргументы, которые я вижу в обсуждениях, основаны на не очень корректнос представлении о том, что мы сейчас знаем про LLM, их ограничения и будущие тренды.

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

👉Инференс стал дешевле на порядок, вызов младших моделей теперь стоит совсем копейки
👉Размер контекста существенно вырос
👉Локально можно запускать довольно мощные модели, сравнимые с GPT-4
👉Тренировка на синтетических данных работает, причем иногда лучше, чем на органических
👉В целом плато способностей LLM, которым периодически любят пугать, пока не видно
👉Генерация простых веб-приложений из промптов стала сравнительно неплохо работать
👉Использовать LLM обычному пользователю все труднее, нужно больше знаний об их устройстве, ограничениях и доступной инфре, чтобы добиваться нормальных результатов

Читать полностью…

PR/FAQ про AWS Lambda

В Amazon очень сильно развита культура письменных коммуникаций. В частности, обсуждение любой идеи нового продукта или фичи начинается с детально описанного документа, известного под названием PR/FAQ. В чем суть – вы пишете пресс-релиз так, как будто продукт уже вышел, включая туда понятное читателям описание сценариев его использования, преимуществ перед конкурентами, и даже цитаты счастливых пользователей. Помимо пресс-релиза, туда же вы включаете ответы на самые частые вопросы, которые раскрывают уже более глубокие темы как с точки зрения пользователей, так и с точки зрения бизнеса.

Отличный пример такого PR/FAQ – по ссылке в заголовке. К десятилетию запуска AWS Lambda ребята из команды решили выложить свой документ с дополнительными комментариями. Очень рекомендую почитать, можно забрать хорошие идеи, если вы тоже придерживаетесь культуры письменных коммуникаций.

Читать полностью…

Последняя часть цикла про командообразование

Прямо под Новый год Дмитрий Болдырев закончил свой гигантский цикл статей про то, какие фазы проходит группа людей, постепенно превращаясь в слаженную команду.

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

Читать полностью…

Лучшие посты за 2024

Конечно же я расчитываю, что весь год каждое утро вы начинали с того, что читали новый пост в канале (а днем еще и обязательно тыкали на рекламную ссылку). Но если вдруг так случилось, что какие-то дни вы пропустили, я подбил дайджест самых популярных постов за этот год!

👭Команда
Как проводить оффбординг
Эффект IKEA
Как выражать признание другим людям
Экономия на зарплате вредит бизнесу
Осмысленные карьерные разговоры
Запугивающие вопросы
Про удержание сотрудников

↔️Процессы
Советы по управлению долгими проектами
Как писать статус-репорты
Гайд по внутренним коммуникациям
Очередь задач вместо сторипойнтов
20% на техдолг не работают
Парадокс Тога

🥰Культура
Эффект Мертвого моря
Критика современной культуры менеджмента
Как не терять контакт с реальностью
Культурный контракт с сотрудником
Опасность метрик в менеджменте

🤝Найм
Гайд по поиску работы engineering manager
Рекрутеров можно заменить броском монеты

✨Личная эффективность
Практики таймменеджмента, которые работают
Аудит своей занятости

А вообще, с наступающими праздниками всех! Держим пальцы крестиком, чтобы LLM в следующем году не заменили всех менеджеров и инженеров, не появилось бы новых черных лебедей, а постов про скрам писалось бы меньше 🎄

Читать полностью…

Зима, праздники, мандарины и … время для саморазвития!

После того, как все друзья будут поздравлены, подарки распакованы, а новогодние сериалы посмотрены, — самое время заглянуть в блог «Это МТС». На своем карьерном сайте МТС выпустиламного полезных материалов, которые помогут добиться успехов в карьере в новом году.

Например, можно узнать:

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

Читать полностью…

Зарплата не растет так быстро, как хотелось бы

Это самая большая проблема для опытных айтишников. Знаю многих коллег, кто полгода фигачит, помогает команде достигать целей, ждет перформанс ревью, а вместо повышения - «спасибо» от руководителя и максимум +10-20% к зп.

Как в начале карьеры, когда ЗП быстро росла, уже не будет.

Главный фактор роста дохода для айтишника – набор аудитории в свой блог и продажа обучающих продуктов.

Чтобы начать получать дополнительный доход к зарплате и вырасти X3-5 в деньгах, подписывайтесь на канал Сергея Дмитриевского, ex-тимлида Авито.

Он заработал 24 млн на своих обучающих продуктах и перестал зависеть от результатов перформанс-ревью.

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

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

Подписывайтесь, здесь личный опыт как айтишнику зарабатывать на своих продуктах:
/channel/+gkR2XkdX6Kw1NjRi


Реклама. ИП Дмитриевский, ИНН 325503042208, erid:2SDnjbyuwVu

Читать полностью…

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

Читать полностью…

Иногда для счастья нужно съесть конфету, а иногда — хорошенько поорать.

КРОК дропнули новогодний подарок мечты — всем нам нужно такое в конце года (кстати, ведро для ора еще и разыгрывают).

Читать полностью…

Рабочие группы как инструмент принятия решений

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

В статье предлагают решать эту проблему выделением рабочих групп:

👉Сначала формируется бэклог всех нерешенных вопросов на уровне компании, гильдии или другой горизонтальной структуры.
👉Раз в какое-то время этот бэклог приоритизируется на общем собрании лидов.
👉Каждому вопросу из топа выделяется небольшая рабочая группа из 3-5 человек, из их же числа выбирается руководитель. Рабочая группа отвечает за то, чтобы детально разобрать вопрос и приготовить прототип решения.
👉Прототип ревьюится общим собранием, собирается обратная связь, рабочая группа дорабатывает решение и заходит на еще одну итерацию.

Такой подход, конечно, не панацея, и в зависимости от культуры компании его надо докручивать. Например, чтобы избежать бесконечных циклов доработки решения рабочей группой, сюда хорошо вписывается принцип disagree and commit.

Читать полностью…

Про бесполезность еженедельных командных созвонов

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

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

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

Читать полностью…

Как работать с риском

Начало обещающей быть очень классной серии статей про управление рисками. Вот некоторые из идей оттуда:

👉Чтобы оценить риск, надо отдельно смотреть на его импакт, и на вероятность его реализации. В большинстве случаев подробная численная оценка вам не нужна, и достаточно сравнительной оценки рисков по матрице 2х2 или 3х3. А если хочется закопаться, то вот офигенный учебник с примерами.
👉Действия для митигации риска чаще всего касаются одной из шкал – вы либо уменьшаете импакт, либо вероятность. Для митигации реальных сложных рисков обычно приходится двигать его сразу по обеим шкалам несколькими действиями.

Читать полностью…

Таксономия целей

Конец года – время целеполагания, как личного, так и командного. То, получится ли достичь цели, и как именно это произойдет, во многом зависит от того, как она будет сформулирована. Держите разбор аж 14 видов целей с примерами и границами применимости!

Читать полностью…

Не будем утомлять вас рассказами о ДМС, крутых офисах и других плюшках. Вот главное о том, почему тимлиды выбирают Т-Банк:

✔️Актуальный стек. Здесь следят за трендами и быстро внедряют новое.
✔️Вы окажетесь среди профессионалов, у которых можно многому научиться.
✔️Улучшения может предложить каждый. Здесь знают, как устроен продукт, и влияют на его развитие.
✔️Здесь развивают комьюнити. Можно участвовать в митапах и подкастах.

Больше о вакансиях здесь

Читать полностью…

Главные фейлы за 2024

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

Расскажите о своих главных менеджерских продолбах за прошедший год, и чему они вас научили!

Читать полностью…

Когнитивная нагрузка

Cognitive load – супер-важная концепция в менеджменте как команд, так и отдельных людей. Например, в той же книге Team Topologies, чтобы оценить допустимое количество компонентов, за которое может отвечать команда, предлагается смотреть именно на совокупную когнитивную нагрузку.

Статья рассматривает когнитивную нагрузку как основной фактор, который влияет на продуктивность отдельного разработчика. Она делится на две разновидности:

👉Intrinsic – нагрузка, неотделимая от самой задачи, вызванная ее реальной сложностью. Ее уменьшить практически никогда нельзя.
👉Extraneous – нагрузка, вызванная способом представления информации. Как раз ее можно и нужно уменьшать.

Примеры того, что вызывает extraneous cognitive load:

👉Слишком сильная вложенность кода
👉Слишком сильное дробление функций и классов
👉Распил проекта на слишком большое количество микросервисов с очень ограниченными областями ответственности
👉Языки программирования, в которых слишком много фичей
👉Слишком сильная завязка на магию конкретного фреймворка

Читать полностью…

kentbeck_7670/the-product-development-triathlon-6464e2763c46">3X Framework – Explore/Expand/Extract

Все вы знаете Кента Бека как автора XP, одного из подписавших Agile манифест и громкого сторонника TDD. Но помимо всего этого, у него много других классных статей и мыслей.

Одна из моих любимых – про фреймворк 3Х, который очень простым способом объясняет основные стадии жизни продукта и то, как они влияют на подходы к разработке:

1️⃣Explore. Этап прототипирования, когда вы только пытаетесь нащупать рабочую идею, которая получит отклик у пользователей. Правильная стратегия разработки на этом этапе – максимально снижать стоимость экспериментов, и запускать их как можно больше.
2️⃣Expand. Product/market fit нашелся, пошла фаза быстрого роста. В этот момент основной фокус разработки должен быть на поиске бутылочных горлышек в технологиях, процессах и команде, потому что именно они могут остановить рост.
3️⃣Extract. Проблемы роста решены, формула продукта в целом понятна. Теперь вы превращаете создаваемую им ценность в деньги. И тут фокус смещается на устойчивость, снижение костов разработки и поддержки, и вот все то, чем мы любим заниматься в бигтехе.

Какие ключевые мысли дает эта модель:

👉Каждая фаза требует очень разных майндсетов, процессов и технологий.
👉Фазы нельзя смешивать, а слишком ранний или поздний переход могут убить весь бизнес.
👉Менять людей и команды при переводе продукта между фазами, в целом, нормально. Какие-то люди отлично работают на этапе Explore, но вот решать проблемы роста им вообще не интересно.

Читать полностью…

Что делать, когда вас окружают идиоты

Мой рецепт – сразу же вспомнить про фундаментальную ошибку атрибуции:

Это склонность человека объяснять поведение других их индивидуальными особенностями, а своё поведение — ситуацией, внешними обстоятельствами.

В статье заходят немного с другой стороны, но с тем же самым результатом:

👉Поймите, что проблема, скорее всего. в вашем собственном восприятии реальности. Мысли вида "все тупые, а я молодец" – детская эгоистическая позиция, в которой вы не берете на себя ответственность за происходящее вокруг. Плюс это работает как бессознательная попытка самоутвердиться за счет других людей.
👉Чтобы понять мотивацию других людей, недостаточно просто наблюдать за их поведением. Если вам кажется, что кто-то делает дичь – попробуйте сначала поговорить с ним и с его коллегами, чтобы составить более взвешенное мнение.
👉Если идиотами кажутся решительно все, то еще один довольно очевидный вариант – надо вырвать себя из обыденности, отвлечься от работы и отдохнуть. Стресс только усиливает негативные эмоции.

Читать полностью…

Что вы думаете про открытые зарплаты

Я к идее открытых зарплат отношусь скорее негативно:

👉Я не вижу каких-то явных преимуществ от того, что я или кто-то еще будет знать точную зарплату своего коллеги. В лучшем случае, если она совпадает с твоей оценкой человека, ты просто проигнорируешь эту информацию. В худшем – почувствуешь ощущение тотальной несправедливости.
👉Это ощущение несправедливости может быть абсолютно необъективным. Ты можешь не видеть всех сторон деятельности своего коллеги, и не обладать полной картиной мира для оценки объективности оплаты его труда. При этом демотивация остается.
👉Эта политика довольно сильно связывает руки менеджеру – бывают ситуации, когда взять на себя "менеджерский долг" в виде слишком большой зарплаты нового сотрудника имеет смысл. Я бы точно не хотел терять такой инструмент.

Так вот, где-то в начале следующего года мы хотим записать выпуск Подлодки про открытые зарплаты. Хороший план выпуска всегда строится на разборе существующих мнений и острых вопросов – поэтому накидайте их в комментарии! А если у вас был собственный опыт жизни с открытыми зарплатами, то еще интереснее – расскажите, что сработало, а что нет.

Читать полностью…

Одна из самых классных моих покупок за этот год – планшет Remarkable Pro. Я его использую и для конспектов всяких лекций, и для индивидуальных брейнштормов, и для кучи других задач. Помимо ощущения настоящей бумаги, его главный плюс перед айпадом – это устройство, заточенное ровно под одну задачу, без этих ваших тиктоков и других социальных сетей.

Так вот, мы прямо сейчас стартуем новогодний стрим Подлодки, где не только будем делиться разными полезными штуками, но и разыграем этот самый планшет, так что подключайтесь!
🎄Стрим на YouTube

Читать полностью…

Дорофеев про прогнозирование сроков

Очень старый, но все еще бесконечно актуальный доклад Максима Дорофеева про то, как заниматься оценкой сроков в Scrum и Kanban: статистические методы, карты Шухарта и люди-снежинки с руками из жопы.

Читать полностью…

Как определять SLO

Если вы не знакомы с термином, то SLO расшифровывается как Service-Level Objectives. Это набор целей, которые вы ставите перед надежность вашего продукта. Так вот, держите по ссылке хороший подробный гайд, как с ними работать. Если кратко, то алгоритм такой:

1️⃣Определите самые важные пользовательские сценарии
2️⃣Определите SLI, service-level indicators, которые описывают надежность этих сценариев
3️⃣Выберите целевые показатели, в которых эти SLI должны находиться. Помните, что они должны быть реалистичными.
4️⃣Заложите бюджет на ошибки – проседание этих индикаторов, которое может быть более-менее нормально воспринято пользователями. Его можно расчитать, как процент измерений ваших SLI за какой-то промежуток времени, в который они не попадают в SLO.

Читать полностью…

Простая памятка про managing up

Ваш менеджер не должен переживать о чем-то в вашей зоне ответственности сильнее, чем вы.

Основных идей за этим правилом две:

👉Приоритеты у вас и у вашего менеджера должны быть одинаковыми, иначе вы довольно быстро столкнетесь с микроменеджментом и недоверием.
👉Чтобы эта схема не превратилась в безоговорочное принятие любых, даже бредовых приоритетов, важно управлять ожиданиями проактивно – пытаться понять истинные причины за хотелками менеджера, и приносить свои собственные решения, которые в них бьют.

Читать полностью…

Живая запись Бреслава и Ложечкина в Лондоне

Мы решили попробовать сделать классную штуку – организовать живую запись подкаста "Бреслав и Ложечкин" в Лондоне. Помимо самой записи обязательно будет интерактив с гостями и куча организованного нетворкинга.

Если вы живете в UK, то вам надо сделать две вещи:
👉Заполнить форму, чтобы мы могли понять интерес и выбрать площадку
👉Забронировать в календаре 18 марта
👉Отложить что-то около 20-40 фунтов на входной билет

Читать полностью…

Новые выпуски тимлидских подкастов

👉"Бреслав и Ложечкин" про карьерный рост в корпорациях: все про грейды, перформанс менеджмент и недостатки этих систем.
👉"Три тимлида заходят в бар" про внедрение изменений: какой поддержкой надо заручиться, как изменения продавать, поддерживать актуальными, и как их замять, если все пошло не по плану.
👉"КОДА КОДА" про финансовое планирование в разработке: как учитывать влияние различных технических решений на финансы организации
👉"Подлодка" про развитие продукта на этапе масштабирования: глубокий разговор с Аней Булдаковой про то, как принимать хорошие продуктовые решения

Читать полностью…

Виноваты процессы, а не люди

По словам Деминга в 94% проблем компании виновата система, и только в остальных 6% – люди.

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

Читать полностью…

Как сделать планирование менее вредным

👉Уменьшить количество целей и ожиданий от планирования. Обычно один процесс пытаются приспособить сразу под все – коммуникацию стратегии, сбор списка самых важных проектов, их декомпозицию и оценку, оценку хедкаунта. Чем меньшего вы будете пытаться добиться, тем больше шансы построить менее вредный процесс.
👉Не пытаться строить чисто bottom-up процесс. У большинства команд не хватает контекста про то, что важно всей компании, поэтому их решения будут крутиться вокруг локальных оптимизаций. Кроме того, у них не хватает понимания, чем занимаются соседние команды.
👉Не начинайте новых проектов во время планирования. Если вы пытаетесь все сделать одновременно, то вы сильно рискуете получить плохо продуманные планы запуска, потому что люди будут преследовать другую цель – успеть уложиться в сроки планирования, а не уменьшить риски запуска чего-то бесполезного.
👉Чтобы избежать микроменеджмента, задавайте понятные модели и ограничения. Например, очень полезно сделать явный приоритет между двумя на первый взгляд равными целями, или разложить направления работы по примерным процентам.
👉Как можно скорее убивайте идеи и проекты, которые не полетели. К новым планам тоже относитесь как к гипотезам, чтобы иметь возможность быстро их закрыть.
👉Всеми способами уменьшайте количество зависимостей между командами, особенно теми, которые занимаются самыми стратегически важными штуками.
👉Всеми способами старайтесь отвязать бюджетирование и оценку хедкаунта от планирования.

Читать полностью…

Геймификация на рабочем месте

Иногда в компаниях встречается практика выдавать сотрудникам что-то вроде внутренних очков за всякие общественно полезные действия – выступления на конференциях, написание статей, участие в гильдиях. Эти очки потом меняются на мерч, дополнительные выходные или показываются на лидерборде.

Когда я только стал тимлидом, я пробовал поиграть в геймификацию (pun intended), но подошел к этому еще более дурацким способом – собрал дэшборд, на котором выдавались очки за количество написанных тестов, решенных ворнингов от линтера и другие технические метрики. Сначала всем было, конечно, весело, но со временем люди стали грустить – позиция в этом лидерборде определялась не столько твоими личными заслугами, но изначальным состоянием проекта, которым тебя отправили заниматься. Как результат – люди, которые сидели на поддержке легаси проектов, стали еще более демотивированы.

Такой результат – не единственная проблема геймификации в рабочем окружении. Виталий Шароватов отлично раскладывает основные последствия:

👉Внешнее подкрепление может заменить собой внутреннюю мотивацию.
👉Соревновательный дух добавляет стресса, которого и так в работе много.
👉Геймификация обычно поощряет конкретные действия, а не результат – из-за чего люди сильно фреймятся и креативность падает.
👉Геймификация поощряет стремление к индивидуальному успеху, в то время как результаты обычно приносит сообщенная работа команды. Соревноваться надо не друг с другом, а против внешних конкурентов.

Читать полностью…

elliotgraebert/an-impact-based-level-system-for-engineering-organizations-2e0f9bee20e6">Грейды, основанные на импакте

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

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

Модель из статьи, как мне кажется, стоит на правильном пути. Вот ее основные принципы:

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

А сама линейка выглядит так (детальное описание каждого уровня есть в статье):

1️⃣Level 1 – Scoped Tasks
2️⃣Level 2 – Scoped Projects
3️⃣Level 3 – Unscoped Projects
4️⃣Level 4 – Team Force Multiplier
5️⃣Level 5 – Group Force Multiplier
6️⃣Level 6 – Company Force Multiplier

Читать полностью…