5 Уровней автономности сотрудника

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

Как сотруднику понять, с какими задачами идти к тимлиду, а какие решать самостоятельно?

Всё в той же статье HBR про «обезьяний менеджмент» выделяют 5 уровней автономности сотрудника.
Чем выше ваш уровень автономности, тем больше вам доверяют, тем интереснее задачи вы получаете и тем быстрее растёте карьерно.

1️⃣ Ждать указаний
— Вы не делаете ничего, пока менеджер не скажет конкретно, что и как делать.
— Инициатива и ответственность полностью на менеджере.

2️⃣ Спрашивать, как поступить
— У вас есть варианты решения, но вы ждёте, пока менеджер выберет один из них.
— Финальная ответственность на менеджере.

3️⃣ Консультироваться, затем действовать
— Вы самостоятельно придумываете решение, обсуждаете с менеджером и действуете, убедившись, что он не против.
— Ответственность уже ваша, менеджер только консультирует.

4️⃣ Действовать и сообщать о результате
— Вы самостоятельно принимаете решение, действуете, а менеджеру просто сообщаете, что именно сделали.
— Ответственность и инициатива полностью ваша, менеджер лишь информирован.

5️⃣ Действовать полностью автономно
— Вы полностью самостоятельны и берёте ответственность за задачи без обязательного уведомления менеджера.
— Обычно это область, где у вас максимальная экспертиза и полное доверие руководителя.

Пример:
Новая фича требует переделки архитектуры.

🔴 Уровень 1:
«Без тебя никак, скажи, что нам делать?»

🟠 Уровень 2:
«Есть два варианта, скажи, какой выбрать?»

⚪ Уровень 3:
«Подготовил пару решений, склоняюсь к первому. Хочу убедиться, что не упустил чего-то важного.»

🔵 Уровень 4:
«Мы обсудили и решили переделать архитектуру так-то и так-то. Работа уже идёт.»

🟢 Уровень 5:
«Переделали архитектуру, всё работает. Захочешь посмотреть — приходи.»

🛠️ Как применить модель на практике?

1. Обсудите с тимлидом текущий уровень автономности и комфортный для вас и команды следующий шаг.
2. Постепенно поднимайтесь: от «спрашивать, как поступить» до «действовать и сообщать» и далее.
3. Чем выше ваша автономность, тем больше свободы действий, интереснее задачи и заметнее вклад в общий результат.

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

Поделитесь в комментариях, на каком уровне чаще всего вы работаете сейчас?

———

📝Встреча с задачей📝

У меня есть боль: между встречами — разрывы по 30–60 минут, в которых вроде бы можно что-то сделать…
Но сил нет, фокус не включается, а к вечеру смотрю на список задач и думаю: «ну вот, снова ничего не успел».

Хотя список задач есть. Он даже приоритизирован. Но до него руки не доходят, пока задачи не становятся срочными. А если и доходят — уходит время на разогрев.

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

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

Инсайт этот не мой — наткнулся на пост Алексея Арефьева, автора канала @alexcouncil.

Суть простая:
Задачи — это тоже встречи. Только с собой.

Плюс — можно использовать цвета, чтобы понимать тип активности с первого взгляда:
🟢 регулярки, 🔴 разовые встречи, 🔵 задачи.

Я пока только начал пробовать — но кажется, это лучшее, что случалось с моим фокусом с начала года.

Давно читаю канал Алексея. Там еще и мемчики есть. Подписывайтесь 🙂

Почему люди не оправдывают наших ожиданий?

Когда коллега не делает задачу или делает её совсем не так, первая реакция обычно негативная:

«Ну понятно, опять ему всё равно. Не старается, наплевательски относится».

На самом деле причин гораздо больше. И чаще всего дело не в равнодушии.

Каждый может накосячить и сделать всё не так, не то, не вовремя или не того качества.
При этом у самого «накосячившего» может быть ощущение, что он всё сделал как договаривались.

Есть 4 основные причины, почему кто-то не оправдал наших ожиданий:

1️⃣ Не понял (или понял по-своему)
Вы вроде бы всё объяснили, но человек услышал что-то другое и начал делать не то.

Почему это происходит:

— Недостаточно чётко сформулировали задачу.
— Не убедились, что поняли друг друга.
— Коллега постеснялся переспросить.

📌 Как проверить: попросите пересказать задачу своими словами и убедитесь, что поняли друг друга одинаково.
(Кстати, это полезно и в случаях сложного фидбека.)

2️⃣ Не умеет

Человек отлично понял, что от него требуется, но не знает, как это делать.

Что пошло не так:

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

📌 Как проверить: просто спросите, решал ли он похожие задачи раньше и как именно собирается действовать.
© Ваш Капитан Очевидность.

3️⃣ Не может
Коллега понял и умеет делать задачу, но у него физически нет такой возможности.

Например:

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

📌 Как проверить: уточните, есть ли у него всё необходимое и не блокирует ли его кто-то другой.

4️⃣ Не хочет
Самая редкая причина, хотя именно её чаще всего подозревают.

Почему человек может не хотеть делать задачу:

— Она кажется ему бессмысленной.
— Он не видит в ней личной выгоды или интереса.
— У него есть скрытый конфликт или негатив к вам, команде или компании.

📌 Как проверить: откровенно обсудите мотивацию и ценность задачи для него. Но это отдельная большая тема, и одним разговором не решить.

Почему важно разбираться в причинах?

Если сразу списывать всё на равнодушие и лень, отношения будут портиться, а задачи так и не начнут выполняться лучше.

Если же начнёте разбираться, то:
✅ Чаще реальность станет совпадать с ожиданиями.
✅ Лучше поймёте мотивы и трудности коллег.
✅ Научитесь чётче ставить задачи, что сделает всю команду сильнее.

В следующий раз, когда кто-то не оправдает ваших ожиданий, попробуйте этот фреймворк:

1. Не понял?
2. Не умеет?
3. Не может?
4. Не хочет?

———

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

Давайте обсудим в комментариях:
Какие были у вас самые кринжовые ситуации неоправданных ожиданий? 😅

Technical Product Manager — редкий зверь

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

Артём руководит продуктовым офисом в Яндексе и делает платформу для разработчиков.
Его команда решает похожие задачи — только не с алфавитом, а с языками программирования, процессами разработки и внутренними инструментами.

Я читаю его канал @badtechproject, потому что он пишет про сложные вещи без буллшита. Вот несколько постов, которые особенно зацепили:

🛠 Про систем-дизайн на собесах

Артём вводит систем-дизайн как обязательную часть интервью для project-менеджеров. И это логично: если ты управляешь командой, неплохо бы понимать, как устроена система. В посте — разминка «спроектируй Twitter», советы и книга, которую стоит прочитать, даже если ты не инженер.

💬 Про "интервью наоборот"

Хороший чеклист «О чем спросить работодателя». Артём так же считает, что хорошее собеседование — это разговор двух взрослых людей, а не экзамен. И умение задавать вопросы — это навык, который повышает шансы получить сильную команду, а не просто оффер.

🔥 Про выгорание — в формате вредных советов

Очень жизненно. Я нашёл там пару пунктов, по которым проходил лично. Формат ироничный, но содержательный: как раз для тех, кто не любит душных лекций про баланс и ресурсное состояние.

Если вы project, product или тимлид и хотите:

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

подписывайтесь на @badtechproject. Канал — живой, честный и с пользой.

Disagree and Commit

Disclaimer: тема спорная, мнение непопулярное, призываю к срачу в комментах 🙂

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

Какие есть варианты поведения?

Вариант 1. Сделать «по кривому ТЗ», чтобы потом сказать: «Ну, я предупреждал»
На первый взгляд, выглядит логично: разработчик честно указал на проблему, а теперь просто делает работу как ему сказали.

Но на деле это превращается в психологическую игру по Эрику Берну — «А я же говорил»:

— Человек берёт задачу в работу без желания и делает минимально, без инициативы.

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

— Подсознательно он ждёт неудачи, чтобы потом показать, что был прав («Ну что, кто теперь виноват?»).

В краткосрочной перспективе человек получает чувство превосходства и подтверждение своей правоты («психологическое поглаживание»).

Но доверие в команде портится, коллеги начинают воспринимать его как токсичного и несговорчивого.

Вариант 2. Продолжать спорить, пока не достигнут полного согласия

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

Но это часто ведет в «ловушку консенсуса»:

— Обсуждения становятся бесконечными, никто не хочет брать ответственность за финальное решение.

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

Вариант 3. Disagree and Commit — не согласен, но обязуюсь сделать

Amazon и другие компании используют подход Disagree and Commit, чтобы избежать первых двух проблем.

Подход простой:

1. Пока решение не принято — нужно спорить, задавать неудобные вопросы, предлагать альтернативы.

2. Когда решение принято — вся команда действует так, словно это решение было общим и наилучшим, даже если кто-то с ним не согласен:

«Я не согласен, но понимаю, почему выбрали этот вариант. Сделаю задачу максимально хорошо, как если бы сам был её сторонником».

Обе части критично важны:

Нужно открыто высказываться, спорить и аргументировать до принятия решения.

После принятия — брать ответственность за общий результат.

Подход не заработает, если в команде нет доверия и открытости (см пост про 5 пороков команды).

Профит:

🧠 Принимаем сильные решения, иногда непопулярные. Избегаем ловушки консенсуса и посредственных решений.
⏱️ Двигаемся вперёд, команда не буксует. Экономим время. Нет откатов и «давайте ещё подумаем».
🤝 Повышаем доверие. Умеем спорить — и умеем поддержать общее решение.
🔁 И главное: а вдруг ты не прав? Решение группы может оказаться лучше твоего. Это нормально.

Когда этот подход не работает?

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

TL;DR:

— До принятия решения — спорим, аргументируем, ищем лучшее решение.

— После принятия — работаем как единая команда на общий результат.

— Не играем в «А я же говорил»: это портит отношения и разрушает доверие.

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

Закидывайте в комменты свои истории из разряда «а я же говорил» 🙂

🎭 Игры, в которые играют разработчики

В прошлом посте я привел пример игры «а я же говорил» — это одна из игр, описанных Эриком Берном в книге «Игры, в которые играют люди».

Когда читал, было странное чувство: как будто Берн писал не про абстрактную психотерапию, а про работу в команде разработчиков.

Это не игры ради веселья. Это поведенческие сценарии, в которых:
— есть знакомые роли (жертва, спасатель, агрессор),
— повторяются типовые ходы,
— а в финале всегда есть «выигрыш».

Что за «выигрыш»?
В русскоязычной литературе это называют «психологическим поглаживанием».
Мне больше нравится термин attention unit: единица внимания, подтверждающая наше существование.

В оригинале — strokes — единица социального/эмоционального признания:
“A stroke is a unit of recognition.”

Берн выбрал это слово, потому что исходно описывал физическое прикосновение (поглаживание) как форму признания младенца.
Отсюда и идея, что взрослые продолжают искать такие же «эмоциональные прикосновения» — в форме внимания, похвалы, критики, …

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

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

🧩 Распознавание этих игр и выход из них помогает в прокачке софт-скиллов:

— Рефлексия (заметить сценарий за собой)
— Эмпатия, эмоциональный интеллект (понять чувства под ролями, заметить игру со стороны)
— Ассертивность (выйти из позиции жертвы/героя)
— Фасилитация (увидеть и остановить игру)

Ниже — пример одной из самых частых игр в IT.

😩 Смотрите, как я страдаю

Сценарий:
Один человек делает всё сам. Не делится знаниями. Не просит помощи. Зашивается в задачах. Говорит: «так быстрее», «некому передать», «всё держится на мне».

Он не просит о помощи напрямую, а копит напряжение, чтобы потом предъявить. Иногда срывается на повышенных тонах, иногда — просто пассивно-агрессивно замолкает или уходит в обиду:

«Я тут один всё делаю!»
«Вы даже не замечаете, сколько я вкладываю!»
«Разгребать, конечно, как всегда всё мне!»

Выгода (поглаживание):

— Подтвердить, что он незаменим
— Получить сочувствие
— Манипулировать командой через вину

Как распознать:

— Никогда не просит о помощи — «сам всё сделаю»
— Делает больше, чем нужно, а потом обвиняет
— Может говорить: «Мне никто не помогает», хотя помощь предлагали
— Часто устал, но при этом демонстративно отказывается от отдыха

Как разорвать сценарий:

Коллегам и руководителю:
— Не подыгрывать чувству вины: «Я вижу, ты перегружен — но мы предлагали помощь»
— Сдвинуть в зону ответственности: «Что ты хочешь изменить?»
— Задать прямой вопрос: «Ты хочешь продолжать в этом ритме или распределим задачи?»

Игроку:
— Сказать: «Мне тяжело. Нужно перераспределить задачи»
— Написать доку, передать зону ответственности, уйти в отпуск
— Менторить коллег, делать задачи их руками

———

📚 У Берна десятки таких игр, некоторые пугающе узнаваемы. Книжка четко структурирована, одна игра занимает пару страниц. Поэтому читается легко и быстро. Рекомендасьон!

Если читали — напишите, какие еще наблюдали в работе?
Может быть, «Пни меня», «Теперь ты попался, сукин сын» или «Алкоголик»? 😄

Не становись тимлидом, не совершай ошибку

Обычно, когда разработчик становится тимлидом, про него говорят «вырос».

Но я не считаю это ростом. Мне больше нравится слово «переход».

Сейчас объясню, почему.

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

Почему никто не говорит про грейды тимлидов? Ведь бывают начинающие тимлиды, уверенные и бывалые.

Да-да, тимлид тоже бывает джун, а бывает сеньор.

❓ Как думаете, когда сеньор-разработчик «вырастает в тимлиды», каким тимлидом он становится?

Правильно, джуном.

Снова появляется гамма ощущений из детства джунства:

— 😰 Сталкиваешься с неизвестной тебе проблемой и даже не знаешь, куда копать. Только рядом нет сеньора, которого можно было бы спросить.

— 🚨 Боишься накосячить. Только теперь цена ошибки гораздо выше: раздрай в команде, увольнения, сорванные сроки по проекту.

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

Рост ли это?
Сомнительно.

Много ли от этого удовольствия?
Меньше, чем от разработки.

…

📌 Есть и другие неприятные моменты работы тимлидом:

— 😩 Постоянное нытьё. Когда ты внутри команды, это не заметно. Но у каждого есть свои проблемы, и ты как тимлид становишься той самой жилеткой. Ты будешь в контексте всего, что происходит у 9 человек. У тебя теперь в 9 раз больше личных и рабочих проблем. При этом ты не сможешь помочь всем и каждому. И от этого можно сойти с ума.

— 🤬 Люди косячат, и ты должен доносить им корректирующую обратную связь. Им неприятно. Тебе неприятно. А в какой-то момент ты должен будешь кого-то уволить. Может быть не в первый год, но этот момент точно наступит.

— 📑 Бюрократия и бесконечные отчёты. Даже в компаниях «без бюрократии», ты поймешь, что количество бумажной рутины выросло.

— 🎭 Окунание в корпоративные политические игры. Даже в «бирюзовых организациях» есть политика. Просто её сложнее будет увидеть.

— 📲 Встречи. Календарь превращается в сплошную портянку митингов.

— 💬 Контексты, контексты, контексты. Постоянное переключение между задачами, темами и людьми. Для разработчика это неприемлемо. Для тимлида — это норма.

— 🤥 Ответственность. Не всегда и не все ошибки команды можно и нужно предотвращать. Команде нужно давать возможность учиться на ошибках. Но отвечать за них всё равно тимлиду.

…

Потом потихоньку адаптируешься, начинаешь понимать, что происходит. Становишься тимлидом-мидлом.

Только удовольствие от работы почему-то не возвращается.

Когда ты был разработчиком, ты каждый день что-то созидал: утром не было какой-то фичи, ты её написал, и вечером она уже в проде. Ты — созидатель. Это даёт дофамин каждый день.

У каждого своё соотношение задач приятных и не очень.

🎯 Для меня лично, когда был разработчиком, соотношение задач было около 80% / 20% приятных / нейтральных или неприятных.
Если меньше — надо что-то менять.

Когда стал менеджером, понял, что минимально комфортное соотношение упало до 30% / 70 %.
Скажете — мало? А больше на рынке тупо нет. Везде работа тимлидом — это напряги, стресс и рутина.

Но менеджерский кайф есть. Он другой. Отложенный и трудно уловимый, но совершенно другого уровня.

Вот ты хочешь что-то поменять в процессах, решить какую-то боль.
Сначала потратишь не один день, чтобы придумать, как именно.
Потом будешь 2 недели преодолевать сопротивление изменениям в команде.
Потом месяц будешь наблюдать за тем, стало ли лучше.

И вот спустя 3 месяца тебе надо будет остановиться, посмотреть назад, увидеть «было/стало», и как следует от этого кайфануть.

В одиночестве.

И никому особо не похвастаешься: как было хреново, уже не помнят. Как хорошо стало — не видят: для команды это новая «нормальность» и в ней есть проблемы.

Готовы ли вы ждать месяцы ради такого призрачного кайфа?
Подумайте хорошенько, прежде чем идти в тимлиды.

Стратегия. Чеклист, как отличить плохую от хорошей.

Большинство «стратегий», которые я видел — это просто набор пафосных лозунгов:
— Увеличить вовлеченность
— Быть лидерами на рынке
— Повысить инновационность

Я и сам такое писал. И даже гордился.

Сейчас делаю очередной подход к составлению стратегии и на этот раз решил подойти к вопросу осознанно.

Прочитал книгу Ричарда Румельта Good Strategy / Bad Strategy и посмотрел модуль про стратегию от Стратоплана.

Теперь понимаю, что предыдущие мои стратегии — самые настоящие «Bad strategy».

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

🎯 Что такое настоящая стратегия?

По Румельту, стратегия — это не список целей. Это ответ на проблему. Она начинается с того, что:

📍 Определяет текущую точку А — где мы находимся и что за проблема перед нами.

🎯 Показывает точку Б — куда мы хотим прийти.

➡️ Рисует стрелочку — путь от А к Б.

И вот внутри этой стрелочки должны быть трудности.
Стратегия — это план, как эти трудности преодолеть.

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

Пример: стратегия Netflix

В 2007 году Netflix занимался доставкой DVD по почте. Компания поняла: оффлайн модель отмирает, нужно идти в онлайн.

Этот переход был невероятно сложным:

1. Пользователи не понимали, чем новый формат лучше DVD. Чтобы их переучить, Netflix сделал ставку на качество: HD-стриминг, понятный интерфейс и годный контент. А еще обеспечили UX одним кликом — сейчас на каждом пульте есть кнопка Netflix :)

2. HD стриминг требовал мощной инфраструктуры, а существующие CDN в 2007 году были дорогими и нестабильными. Тогда Netflix пошёл ва-банк и создал свою собственную CDN — Open Connect, с серверами прямо у провайдеров.

3. Студии не верили в стриминг, не хотели давать контент и требовали огромные роялти. Тогда Netflix сам стал студией — запустил оригинальные сериалы вроде House of Cards и раздавал их эксклюзивно через себя.

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

✅ Чеклист Good Strategy:

1. Diagnosis — чётко названа реальная проблема
2. Guiding Policy — понятный принцип, как действуем
3. Coherent Action — шаги согласованы и усиливают друг друга
4. Focus — сделан выбор, на чём концентрируемся
5. Tackle the challenge — есть план, как преодолеем ключевые трудности. Не просто путь из А в Б, а план, как пройти через все узкие места по пути.

🧩 Чеклист Bad Strategy:

1. Dog’s Dinner Objectives — мешанина несвязанных хотелок
2. Blue-Sky Objectives — мечты без связи с реальностью
3. Fluff — пафосные слова вместо смысла
4. Failure to Face the Problem — игнор настоящей проблемы
5. Mistaking Goals for Strategy — цели выдают за стратегию
6. Template-Style Strategy — шаблон ради галочки
7. Avoiding the Hard Work — нет выбора, нет отказа, нет боли

Итог.

Теперь я дофига знаю о том, как должна выглядеть хорошая стратегия, поэтому свою еще не написал 😄

Сложно:
- найти настоящую проблему, а не просто её симптомы;
- сфокусироваться на одной вещи, отбросив всё лишнее;
- придумать руководящие политики, которые реально помогают сдвинуться с места;

…

В чем польза поста?

Если вы разработчик — теперь вы можете челленджить булшит-стратегии, которые выглядят как презентация для инвестора. Спрашивайте: «в чём проблема?», «как мы её решаем?», «что конкретно поменяется?»

Если вы менеджер — прям советую книжку Good Strategy / Bad Strategy.

Если уже читали, давайте обсудим в комментах.

Авито — топовая школа менеджмента

Короче, мы тут стали работодателем №1 для продактов по результатам исследования DevCrowd 🎉

DevCrowd несколько лет проводят опросы — их уже все видели и многие проходили. Например, я постил в этот канал опрос про тимлидов.

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

Ну и потому что там про денежки, конечно же 🙂

По итогам — я с результатами полностью согласен.
Авито действительно крутая школа для менеджеров.

Есть, где разгуляться:
— Тебе доверяют продукт, метрики. Можно не просто «пилить фичи», а формировать видение будущего и целенаправленно двигаться к нему
— Можно катить АБ-тесты на миллионы пользователей и быстро видеть статзначимые результаты
— У каждого продакта есть своя команда разработки
— Ну и просто приятно делать то, чем пользуются твои друзья и знакомые

Но и требования высокие. От продакта ожидают продуманности каждого шага, уверенности в принятии решений, и того самого видения.

В общем, результаты опроса приятные.
Потому что знаю, что это не заказуха, а реальные результаты реального опроса 800 продактов. 🧡

Гибкость vs прогнозируемость

Всегда хочется одновременно:
— Быстро реагировать на изменения.
— Чётко планировать спринты и попадать в срок.

Но это взаимоисключающие настройки:

1. Подкручиваешь гибкость — снижается прогнозируемость, больше шанс что у сырой задачи что-то вскроется в процессе и сроки поедут.
2. Тюнишь прогнозируемость — добавляешь пункты в Definition of Ready и начинаешь сопротивляться непроработанным задачам.

Когда-то давно у моей команды был максимально гибкий процесс: продакт приносил задачки прямо на планирование и мы весь понедельник с ними разобирались.

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

Как итог — накапливался снежный ком «доделок с прошлого спринта».

Минимальная глубина прогрумленности бэклога

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

Но встает вопрос: верхушка — это сколько?

Мы экспериментировали с разными вариантами и пришли к оптимальному значению — 2 спринта.

Почему именно 2?

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

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

Как измеряем 2 спринта

1. Берём задачи, проработанные не позднее 90 дней назад. Если задача более старая — скорее всего, что-то уже поменялось и её надо заново прорабатывать.
2. Считаем медианное velocity команды за последние 3 месяца.
3. Делим сумму оценок готовых задач на медианное velocity.

———

В итоге, можно сказать что наш ползунок «гибкость <—> прогнозируемость» стоит где-то посередине.
Что не идеально — в итоге гибкость ограничена по сути выбором из двух наборов задач.
А прогнозируемость гарантируем в пределах двух спринтов.

Но это не хорошо и не плохо — это наш выбор.
А у вас как?

Не все должны расти
…пост вдохновлён книгой Radical Candor.

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

Ну правильно, а иначе зачем мы здесь все собрались? Не деградировать же, как в твиттере. Расти, конечно!

Non progredi est regredi.
Не будешь расти — уволят и обязательно умрешь от голода под мостом. (мой вольный перевод)

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

Знакомьтесь: сеньор Дима
— 20 лет в профессии, последние 10 — в текущей компании
— Не ведёт блог, не выступает на конференциях, не продаёт курсы
— Просто работает работу. Стабильно и качественно. Не быстро и не медленно, средне. Но на него всегда можно положиться.
— Никогда не ноет. Вокруг него не возникает конфликтов.
— Не приходит с запросом х2 зп. Ему норм.
— Работает не больше 8 часов. Иногда справляется с задачами за 4 часа и тогда может больше времени провести с семьей. Об этом все знают и всех всё устраивает.

Дима — не топ-перформер и не Rock Star
Назовём его Rock-Solid 🗿

Rock Star vs Rock-Solid

Rock Star 🌟

— Хочет новых задач, технологий и челленджей
— Готов работать много и напряжённо
— Хочет быстрого карьерного роста
— Получает от текущего места всё что может за 1-2-3 года и уходит искать новые вызовы

Rock-Solid 🗿

— Глубоко знает свою работу и технологии
— Стабильно выдаёт предсказуемый результат
— Не гонится за хайпом и модой
— Работает долго (5–10+ лет)

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

Многие даже осознанно «нанимают только звёзд», тем самым загоняя себя в ловушку.

Когда в команде 8 человек, и 7 из них — Rock-star с запросом на постоянный рост — это беда. Через полгода половина разбежится.
Потому что невозможно всем одновременно дать челленджевые задачи и карьерный рост.

———

⚠️ Почему мы недооцениваем Rock-Solid?

1. Культ роста в IT. Все хотят нанимать только «амбициозных» и «с горящими глазами».

2. Недостаточная видимость. Rock Star — всегда на виду. Рефакторинг всего легаси, презентации новой архитектуры, внедрение новых технологий. Rock-Solid тихо чинит прод, фиксит баги, онбордит новичков. Его ценность становится очевидной только тогда, когда он уходит.

3. Неправильные метрики.
Performance Review обычно поощряет тех, кто делает задачи выше своего грейда. А где метрика «стабильно держит критичный сервис уже 5 лет»? Где награда за то, что благодаря его экспертизе мы избежали 10 архитектурных ошибок?

4. Единственный карьерный трек: Junior -> Middle -> Senior -> Manager. А что если человек не хочет становиться менеджером?

Что делать руководителю?
Концепция из Radical Candor: ваша задача — не заставить всех расти вверх, а помочь каждому двигаться по его траектории.

Для Rock-Solid:
— Признавайте их ценность публично
— Создавайте возможности для менторства и обучения других
— Платите справедливо за экспертизу, а не только за «потенциал»
— Давайте интересные задачи в рамках их зоны комфорта
Для Rock Star:
— Обеспечивайте челленджи и новые проекты
— Готовьте к следующей роли
— Будьте готовы к их уходу через 2-3 года

Идеальный баланс:
— 20–30% Rock Star
— 70–80% Rock-Solid

Да-да, большая часть команды должна состоять из стабильных экспертов!
Это контринтуитивно для индустрии, помешанной на «hiring only A-players».

Итог

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

И это нормально.
Более того — это необходимо для здоровой команды.

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

А если вы — Rock Solid, — скиньте своему менеджеру этот пост. И не стесняйтесь своего выбора. Наша индустрия держится на таких, как вы.

Performance Review: the good, the bad, the ugly

Я уже когда-то писал пост про перфревью. А потом еще один про калибровки. Тогда впервые проходил процесс, и казалось что цель — справедливость для всех и каждого.

Сейчас заканчивается мой седьмой цикл перфревью.

Первые два я прошел как тимлид. Тогда для меня главным было, чтобы все мои инженеры получили справедливые (по моему мнению, конечно же) оценки. Всё остальное было вторично.

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

Сейчас первый цикл прохожу как руководитель кластера.

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

Вот к чему пришел.

1. Основная цель — управляемость компании как системы

В Бауманке у нас был курс ТАУ — Теории Автоматического Управления.

Управление – это такая организация технологического процесса, которая обеспечивает достижение поставленной цели.

Применительно к компании:
1. Сотрудники или команды — элементы системы, объекты управления
2. У каждого элемента есть вход, куда подаются сигналы — цели / KPI
3. И выход, откуда берется результат работы

Система преобразует сигнал с выхода «проделанная работа» и подаёт его на вход как сигнал «оценка перформанса».

Сигнал «оценка перформанса» влияет на выполнение следующей «работы».

Высокая оценка — сигнал развиваться дальше в том же направлении. Низкая — сигнал скорректировать курс.

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

Без нее система либо уйдет вразнос, либо затухнет. С ней — стремится к заданным параметрам.

Что до справедливости.. Это вторичный продукт. Абсолютной справедливости не существует, потому что это она субъективна и у каждого своя.

Звучит бездушно, но на больших числах по-другому не работает.

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

2. Защита от ошибок и выравнивание стандартов

Если у вас классные люди и классный руководитель — можно жить и без ревью.

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

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

Система заставляет руководителя регулярно думать об этих вещах, даже если ему не хочется или некогда.

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

Перформанс ревью — это система-уравнитель.

3. Защита от инфляции грейдов и хаоса при ротациях

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

Если убрать перформанс ревью и калибровки — то будет очень обычная ситуация «что-то Вася загрустил, дадим ка ему повышение».

Когда все знают, что промо — это не «руководитель захотел», а часть системы, у людей появляется ощущение прозрачности.
Хотя это не всегда делает систему справедливой.

Итог

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

Но альтернатива — хаос, в котором компания обречена, потому что не может повернуть руль.

Если ты сотрудник — не воспринимай оценку как вердикт. Это не суд, это сигнал.

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

Два подхода к обучению: Principles-first vs Application-first
Disclaimer: этот пост — реклама библиотеки кейсов от Карьерного Цеха.

В книге The Culture Map Эрин Мейер меня зацепило описание 2 подходов к обучению:

📌 Principles-first (от принципов к практике):
Сначала глубоко разбираешься в теории, понимаешь фундаментальные принципы, и только после этого идёшь применять их на практике.
Так обучают в традиционной российской школе и вузах:

«Разберусь в сути, остальное приложится».

Плюсы подхода:
➕ Позволяет глубоко понять и систематизировать знания.
➕ Даёт фундамент для самостоятельного принятия решений.

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

📌 Application-first (от практики к принципам):
Обучение сразу идёт через конкретные примеры и ситуации, на основе которых затем выводятся общие принципы.
Так учатся маленькие дети: моя дочь изучает мир не через принципы, а через множество конкретных ситуаций.

«Разберусь на примерах — а потом пойму почему».

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

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

Минусы:
➖ Меньше глубины, если не уделять внимание обобщению.
➖ Без должного анализа может превратиться в «делай по шаблону».

Какой подход лучше?
Они разные. Лучше работает комбинация:
1. Application-first для быстрого старта, насмотренности и уверенности.
2. Principles-first для систематизации знаний и осознанности решений.

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

Внутри библиотеки:
🎥 Видеоразборы реальных продуктовых задач.
📌 Конкретные кейсы с подробными комментариями.
🎧 Удобный формат: можно смотреть видео, а можно слушать как подкаст по дороге на работу.

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

Цена для моих подписчиков: 7 дней доступа за 1₽, затем 1800₽ вместо 2000₽ в месяц по промокоду PRDEVELOPER

👉 Оформить подписку

Реклама. ИП Федоров Е.П.
ИНН 532008901966

Как научиться не перебивать

У меня есть проблема. Если у тебя её нет, — ты либо святой человек, либо врёшь (возможно сам себе).

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

Кому я вру. Я перебиваю не потому что «хочу как лучше», а потому что импульсивен, ставлю собственное мнение выше мнения других, и не умею вовремя остановиться.

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

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

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

1. Правило трёх секунд
Самый простой и самый трудный совет.

Прежде чем сказать что-то — пауза на 3 секунды.

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

Но обычно происходит такое:

— Человек продолжает говорить. Значит, мысль не закончена. Хорошо, что ты не вклинился.
— Ты даёшь себе время подумать, а не просто реагировать на последнюю фразу.

Дискомфортная тишина — не враг. Это пространство, в котором люди думают.

2. Записывать, а не перебивать

Почему я перебиваю чаще всего? Потому что боюсь забыть мысль. Она кажется важной, критически важной прямо сейчас. И я боюсь её потерять.

Теперь у меня рядом блокнот (или приложение с заметками), и я просто пишу туда то, что хотел сказать.
А когда человек договорит — выбираю:
это всё ещё важно?
если да — нужно ли это говорить прямо сейчас?

Почти всегда оказывается, что половина моих мыслей уже озвучена другими, а другая половина уже не кажется такой важной через 5 минут. 80% «перебивок» просто растворяются.

3. Признать проблему вслух
Я начал прямо говорить:

«Если я вдруг перебью — скажи мне об этом. Я над этим работаю».
Эта фраза меняет тон разговора.

Во-первых, ты берешь на себя ответственность, а не сваливаешь на культуру / Zoom / задержки.

Во-вторых, люди чувствуют, что ты хочешь слушать, а не доминировать.

Итог

Если тебе правда важно, что человек говорит — дай ему место.

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

P.S.
До сих пор иногда перебиваю.
Но теперь слышу это и учусь останавливаться.
Иногда даже успеваю.

Если есть ещё способы — напишите в комменты, поделитесь опытом.


Upd Из комментариев:

...пункт 0: научиться хотеть слушать и услышать.

Желание перебивать пропадает, когда ты приходишь не рассказать, а выслушать.

Если менять свою позицию с «сейчас я всех научу» на позицию «я хочу услышать разные варианты и выбрать лучший», то дальше сильно легче становится не перебивать.

Авито и ВШЭ запускают магистратуру для продактов

Когда я учился в Бауманке, традиционные программы давали скорее базу и тренировали навык быстро сориентироваться в куче материала, чтобы сдать сессию.

Были крутые преподы, которые на собственном энтузиазме делали полезные и современные курсы. Это было супер ценно, но таких было буквально единицы.

У сегодняшних студентов в этом плане есть из чего выбрать. Авито уже несколько лет сотрудничает с топовыми вузами страны. Уже есть программа по аналитике и Data Science в Физтехе, курс для инженеров в ИТМО.

А теперь, — полноценная магистратура для продактов в НИУ ВШЭ, той самой Вышке!

Чем это круто?

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

2. Программа создана совместно с действующими продактами, аналитиками, UX-исследователями и экспертами Авито. Никакой устаревшей информации.

3. Студенты могут попасть в Avito Product Bootcamp — 9 месяцев работы с реальными задачами, командой и зарплатой.

Если бы такая магистратура существовала в моё время — возможно, моя карьера сложилась бы быстрее и проще 🙂

Авито финансирует 30 из 42 мест, так что шансы попасть весьма высокие.

Документы можно подать до 8 августа.

Исследование тимлидов

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

А пока поделюсь интересностями прошлого года.

В прошлом опросе приняло участие 659 человек, из которых:
- 70.1% – тимлид
- 21.4% – менеджер менеджеров
- 8.5% – директор

📌 Топ-3 обязанности руководителей любого уровня:
1️⃣ Собеседования,
2️⃣ Развитие людей в команде
3️⃣ Оценка их перфоманса.

📌 Топ-3 навыка на прокачку:
1️⃣ Стратегическое видение,
2️⃣ Коммуникации,
3️⃣ Самоорганизация

📌 — Каждый четвертый тимлид столкнулся в прошедшем году с чрезмерным объемом работы.

📌 — При этом только 6.7% тимлидов активно собеседуются. Остальные не планировали менять работу в ближайший год

📌 — Большинство тимлидов тратит не более 30% рабочего времени на написание кода.

📌 — Медианная зарплата тимлида в 24 году — 400к рублей. Интересно будет посмотреть на результат 25 года.

Подробнее, с инфографикой и цифрами — Ссылка на результаты 2024.

———

P.S. там есть вопрос про медиа, которые вы читаете. Ну вы знаете, что отметить 🙂

Пройти опрос

Промо в бигтехах

Немного философский пост о том, как устроено повышение в корпорациях — от человека, который уже полгода работает «в шапочке» следующего грейда, но все еще не получил промо.

И да, я понимаю, почему так, и сейчас буду вам объяснять, что это нормально.

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

———

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

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

Проще всего объяснить это как промо за успехи на текущем грейде.

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

Или так: Вася — хороший мидл, но что-то заскучал. Повысим его до сеньора.

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

Побочные эффекты

Проблема такого подхода в том, что у сотрудника появляется мотивация и склонность «натягивать» проявления компетенций.

Помню, как пришел тимлидом в Авито, и старательно выискивал проявления TUL’a (руководителя юнита). Вот я цели на год составил — галочку поставил. Сейчас хихикаю, понимаю что это было как раз натягивание.

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

Роль руководителя и почему объяснение может ранить

Задача руководителя — объяснить, как матрицу для грейда Х трактуют те, кто проводит перформанс-ревью для этого грейда. И из-за того, что сотрудник склонен «натягивать», это объяснение от руководителя может считываться как обесценивание.

«Да, цели на год есть, но они чисто операционные. А где твоя персональная техническая повестка? Куда ты ведёшь юнит с точки зрения техландшафта?»

пу-пу-пу.. в матрице-то написано просто «составляет цели на год». А тут оказывается какая-то повестка требуется и техландшафт.

И таких вещей много, а матрица достаточно компактная.
Получается, нужно выпускать дополнительный «поясняющий» документ к матрице?

Слишком сложно, да и читать его никто не будет, скорее всего. Потому что людям некогда читать инструкции. Им нужно чтобы инструмент был очевидным и самодокументируемым.

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

Редкость проявлений на высоких грейдах

От сеньоров требуются проекты на квартал или полгода. Понятно, что такие проекты появляются не часто.

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

Условно, средний тимлид М2 в Авито нанимает одного-двух инженеров в год. Таким образом, техлиду М1 скорее всего потребуется год, чтобы показать, что он умеет самостоятельно нанимать, и поставить галочку в матрице тимлидов.

Средний TUL М4 нанимает тимлида раз в 2 года. Таким образом, тимлиду в шапочке aTUL нужно 2 года, чтобы закрыть компетенцию М4.

Средний кластерлид М6 нанимает TUL’a раз в 3 года. .. Ну вы поняли.

Чем выше грейд — тем больше долгоиграющих компетенций надо закрыть.

А справедливо ли это?

Выглядит как несправедливость: человек сидит «в шапочке» грейда Х+1, делает работу Х+1, но получает зарплату грейда Х. Но если это повышение нужно самому сотруднику — считаю, что это ок.

А вот если это компания приходит к сотруднику и говорит «нам надо чтобы ты работал работу грейда Х+1» — справедливо сразу дать за это компенсацию.

Проблема в том, что обычно процесс одинаковый для всех. Давайте обсудим в комментах.

P.S. Не говорю, что это идеальная система и всем срочно надо так же делать в любом стартапе. Это способ обеспечить управляемость системы, как в посте про Performance Review.
Добро пожаловать в мир корпоративных процессов и правил :)