#Пятничное

По традиции – развлекательный контент в пятницу вечером.

1. Old but gold, «Теория Жоп»

https://habr.com/ru/articles/593173/

Теория смешная и, одновременно, чудовищно жизненная.
Осторожно: при прочтении можно испытать серию вьетнамских флешбеков!

––

2. Как VK ускоряли работу приложения

https://www.youtube.com/watch?v=KDcOa_QbSQ0

Это – не реклама VK.
Это – история, которая может замотивировать работать над целью до тех пор, пока тебе не покажется, что стало «достаточно хорошо», а не до тех пор, пока у тебя не закончатся очевидные решения

Ребята начинают с пагинации и картинок, но позднее доходят до..алгоритмов сжатия, протоколов передачи данных и изменения сетевого стэка приложения

Если тебе было страшно внедрять новый фреймворк – посмотри это видео и больше не бойся 🙂

––

3. Как снимали «Матрицу»

https://habr.com/ru/companies/first/articles/724300/

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

– Подбор команды
– Костыли
– Бюджет
– Неочевидные решения

А можно – просто как развлекательный текст про продакшен крутого кино в 90-е/2000-е годы. В любом случае – по-моему, интересно!

О важном

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

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

Как приоритизировать:

1. Важное и срочное – сразу делать.
2. Важное и несрочное – делать или, как минимум, сразу планировать.
3. Неважное и срочное – делегировать или, хотя бы, фиксировать время, которое ты этому уделяешь.
4. Неважное и несрочное – честно признаться себе, что такие задачи – не более, чем развлечение. Выполнять только для собственного удовольствия или не выполнять совсем.

Мне – помогает, а тебе?

Давно нас не было на хабре!

Сегодня – про эффективный менеджмент! Или не очень эффективный..

https://habr.com/ru/articles/817617/

Лайки, репосты и комментарии – помогают 🙂

Loaded Question

Loaded question / нагруженный вопрос – вопрос, в который заложено твоё отношение к ситуации.

––

«Как дела у Васи?» – обычный вопрос
«Дела у Васи так себе, да?» – нагруженный вопрос

«Какой статус по проекту?» – обычный вопрос
«Проезжаем по срокам, да?» – нагруженный вопрос

––

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

1. Один раз на встрече хедов человек высокого уровня спросил:

– А что, Петю мы увольняем? (имя изменено)

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

2. В другой раз прозвучало

– Запуска без багов нам не ждать, верно?

Думаю, можно не комментировать, как это отразилось на отношении команды к QA и на уверенности QA в своей работе.
Запуск, кстати, всё равно случился с кучей багов – к тестированию особо серьёзно никто не отнёсся :)

––

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

Если, копаясь в деталях, ты обнаруживаешь настоящую, стопроцентную проблему, но команда этого не понимает – уже можно задать нагруженный вопрос или прямо сказать: «это – плохо!»

#ЧтоПочитать

Вечер пятницы и развлекательный контент:

1. «Стив Джобс», Уолтер Айзексон

Захватывающая история с пачкой инсайтов:

– Мировоззрение творческого человека vs профессионального менеджера
– Менеджмент мирного vs военного времени
– Как выглядит work-life balance топ-менеджера и существует ли он вообще?
– Насколько сильно переговоры влияют на карьеру, бизнес и жизнь людей?

А какие ты найдешь для себя?

2. «The Hard Thing About Hard Things», Ben Horowitz

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

3. «Чапаев и Пустота», Виктор Пелевин

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

Если ты, вдруг, не любишь Пелевина – это нормально. Просто надо читать его старые книги, а не новые :)

Про найм

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

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

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

– Адекватен, умеет говорить (hr-скрин)
– Умеет писать код (секция с кодом)
– Не думает три дня над простой задачей (все секции)
– Не предлагает трешовых архитектурных решений (архитектурная секция)

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

Всё, что ты знаешь после проведения стандартных секций: «передо мной – человек +- уровня X».

––

Если хочешь найти не просто «сотрудника +- уровня X», а человека, который:

– Супер-ориентирован на бизнес-результат ИЛИ
– Очень крут в выстраивании процессов ИЛИ
– Умеет быстро разбираться в сложных плоходокументированных технологиях ИЛИ
– Может за ночь из говна и палок построить космолёт,

Стандартные секции тебе не помогут.

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

––

Как это сделать?

1. Выписать для себя набор желаемых качеств
2. Попытаться за время беседы проверить их наличие

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

Да, за мэтч по уникальным компетенциям можно простить промах на стандартной секции!

Getting Shit Done

Есть выражение (и даже методология) «getting things done» – про доведение дел до конца, управление задачами, проектами, и тд.

Сегодня мы про него говорить не будем.

Сегодня – про ключевой навык, отличающий крутого менеджера от обычного. Я называю его Getting Shit Done.

––

Почему не «Things?».

Раскидать и решить обычные «дела» (или «вещи») может любой менеджер, более-менее компетентный в предметной области и вооруженный ежедневником.

Самые большие неприятности, при возникновении которых зовут крутого менеджера – это никакие не things. Это именно Shit, в котором ты ничего не понимаешь, к которому не готов и готовым быть не можешь:

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

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

Крутой менеджер – ищет решение с учетом новых вводных, даже если эскалировать некуда. Что удивительно – проекты при этом часто выживают (хоть и сильно меняются).

––

Будь крутым менеджером! Как минимум, это весело :)

Тестирование в продакшене!

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

Лиды порой приобретают привычку говорить (и, что страшнее – думать!), что код работает как надо, если в тестовой среде не нашлось багов, прошли модульные и интеграционные тесты и тд. В идеальном мире – так оно и есть, но в реальном..если ты работаешь над большим приложением, которому много лет: этот подход не работает!

––

Почти всегда найдется:

– 10 конфигов, расходящихся в проде и в тестинге
– Паттерны использования приложения, до которых дошли странные юзеры и не дошли qa
– Блоки кода твоих коллег, которые включены в проде и выключены в тестовой среде
– Разница по нагрузке и данным, проходящих через разные окружения (моё уважение людям, которые льют в тестинг часть данных и нагрузки из прода! К сожалению, этот подход не устраняет остальные обозначенные проблемы).
– Банально невнимательный участник команды, который забыл проверить какой-нибудь сценарий на себе

Как следствие – вместо ожидаемого запуска на пользователей («всё ведь протестировано и работает – выкатим да включим») в день X происходит..получение 10 баг-репортов из прода и изменение графика поставки.

Решение: относиться к любому крупному изменению как к эксперименту

Даже если продуктовые метрики не должны прокраситься. Даже если это – «просто большой рефакторинг» (или оптимизация времени ответов бэкенда на 20%). Во многих случаях, выкатив сделанное на процент пользователей (или на всех сотрудников компании; или на город) ты, внезапно, соберешь пачку багрепортов, а иногда – увидишь прокрасившуюся в неожиданную сторону метрику :)

После эксперимента в проде – функционал и правда протестирован и готов к включению 🙂

#Пятничное

Время контента в пятницу вечером!

1. https://hbr.org/2008/02/getting-the-best-employee-idea

Old but gold: про ценность «маленьких» идей по улучшению продукта, приходящих от команды, а не от менеджмента.

И про то, что успех продукта и компании – не только в стратегических проектах :)

2. https://kinzhal.media/la-chaise/

Подписчики канала не узнают ничего нового для себя из этой статьи. Но она – не для вас!
Это – бесплатная инструкция, которую можно дать джуну или миддлу в своей команде и понадеяться на изменение подхода к работе :)

––

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

Поделись своими в комментариях!

––

upd: к своему ужасу узнал, что пост при добавлении двух картинок разрезается на три последовательных сообщения! Вот это я понимаю – пользовательский опыт. Удалять я их, конечно же, не буду :(

Не забудь подумать

Когда моя команда стала большой, у меня регулярно стали возникать недели, на 80-90% состоящие из встреч:

– Статусы по проектам
– 1х1-ы
– Встречи со стейкхолдерами
– Встречи с разборами проблем
– Обеды со смежниками
– ….

Всё, вроде, по делу.

Но есть две проблемы:

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

b. Качественно проводимые встречи сжигают энергию

Получается, если в день у тебя 10+ встреч – ты и на синках не можешь серьезно поразмышлять, и после них – тоже (энергии недостаточно!).

––

Осознав эту проблему, я пришел к практике, которой пользуюсь до сих пор:

Каждую неделю бронирую в календаре несколько часов времени для самостоятельной работы

Я использую их так:

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

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

––

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

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

Важно, чтобы это время было зарезервировано как полноценная встреча в рабочем календаре (можно сделать её закрытой). Иначе кто-нибудь его отберёт 🙂

О консервах в собственном соку

Рано или поздно растущий управленец оказывается в интересной позиции: руководитель перестаёт быть более экспертным в его домене.

Иногда это происходит на должности CTO/CPO/C*O.
Иногда – раньше.

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

Если тебе доводилось встречать компанию, в которой практики разработки/дизайна/etc устроены «как 10 лет назад», надежно законсервированы – скорее всего, C*O как раз наступил на эти грабли.

––

Что с этим делать?

1. Общаться с людьми из других компаний.

Если фидбека в компании получить негде – поищи снаружи :) Теперь это – часть твоей работы.

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

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

––

2. Хотя бы понемногу нанимать подчинённых-лидов извне

Практика «промоутить на управленческие позиции ребят из компании» – хорошая и имеет множество плюсов.

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

––

А что ещё ты делаешь, чтобы не консервировать себя и компанию?

Советы для M1. Планирование

Возвращаемся к ответам на вопросы.

Что бы ты сейчас посоветовал себе, когда только начинал быть лидом М1?

Полноценный ответ требует статьи на хабр, она выйдет позже 🙂
А пока – про одну из частых проблем M1: планирование.

––

У начинающих лидов часто возникает один из двух интуитивных подходов к планированию:

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

Например:
a. Синьор – сделает с такой же скоростью, как я.
b. Миддл – в два раза медленнее.
И т.д.

Внезапно, такие предсказания ломаются.

2. Спрошу у сотрудника, сколько времени у него уйдет на задачу. Если уровень невысокий – умножу на менеджерский коэффициент.

a. Синьор оценил задачу в три дня – добавлю денек на баги
b. Миддл оценил в три дня – умножу на два
c. Джун оценил в три дня – помоги мне бог, чтобы сошлось до конца месяца

И..такие предсказания тоже ломаются!

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

––

А что тогда делать с прогнозами?

Пользоваться историческими данными.

Во время планирования абстрагируйся от должности/внешней уверенности человека. Смотри на историю его работы с завершенными задачами:

– Если в предыдущих двух спринтах он закрывал задач на «5 сторипоинтов», не стоит ожидать, что в этом спринте он закроет 10, потому что «заказчикам очень нужно» или «ну я соберусь и затащу, честное слово!»

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

Тот же подход применим для ответа на вопрос: «сколько за итерацию сможет сделать команда?»

––

А как же рост эффективности? Люди что, не могут развиваться и учиться?

Могут. И в развитие команды нужно вкладывать своё время. Но:

Человек обучился и прокачался, если ты на данных видишь, что он стал делать больше / выше / лучше и т.д.

Планировать больше можно начинать только тогда, когда человек уже и так делает больше. Не наоборот!

О дедлайнах

Если кто-то должен что-то для тебя сделать, обязательно нужен дедлайн и ответственный.

– Запилите новый пуш? А когда? А кто лично сделает и проследит? Спасибо, записываем: Саша, до 19 июня

– Проведёте воспитательную беседу с андерперформером? А кто и когда? Спасибо, записываем: Андрей, завтра

– Прикинешь, сколько разработчиков тебе нужно на проект? Сколько времени тебе для этого нужно? Спасибо, записываю: Петя пришлёт оценку до конца недели

Зачем это нужно?

Во-первых, приоритизировать умеют не все. Твою «важную» задачу без дедлайна запросто могут задвинуть в пользу менее важных, но имеющих дедлайн. Ну а что – договорённость-то не нарушена :)

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

––

Когда в следующий раз договоришься о чём-то – обязательно проговори вслух и запиши ответственного и дедлайн. Иначе – можно было и не договариваться :)

Продуктивного понедельника и успешных переговоров!

О культуре дедлайнов

Иногда лиды, инженеры и менеджеры мысленно делят дедлайна на два типа:

1. Жесткие

Через неделю наш софт заблокируют в стране, если мы не поменяем X / завтра выйдет законопроект, требующий от нас Y / большой клиент расторгнет контракт, если не пофиксить баг Z…

Такой дедлайн ни в коем случае нельзя пропускать. Если кажется, что мы не попадём – мы напряжемся, порежем скоуп, поищем другие пути реализации и т.д.

2. Мягкие

«Мы прикинули, сколько времени нужно на проект и пообещали менеджменту выкатить его в следующем месяце»
«Я прикинул, сколько времени мне нужно на задачу, и пообещал руководителю закончить к понедельнику»

Такой дедлайн лучше не пропускать, но..никто ведь не умрет – если что, просто сдвинем

––

90% фичей, выпускаемых обычной продуктовой компанией, не подпираются внешними, объективными дедлайнами. Внешний дедлайн – это форс-мажор.

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

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

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

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

––

Что с этим делать?

Устранять «не-жесткие» дедлайны как концепцию в культуре команды.

Дедлайн есть дедлайн. Двигать его нельзя. Как только мы договорились о дедлайне, он стал жёстким. Проехать за дедлайн – форс-мажор; если он приближается, нужно эскалировать и обсуждать.

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

Важная дополнительная установка: в рабочей неделе по умолчанию – 40 часов. Она, с одной стороны, неизбежно приведет к срыву первых 5-10 дедлайнов, с другой – поможет не убить команду + научит людей быть эффективнее, а не тупо больше работать.

––

Совсем без профакапленных сроков и овертаймов на дистанции обойтись невозможно. Но увеличить вероятность успеха – в твоих руках 🙂

Как договариваться с менеджерами высокого уровня

Порой топам что-то нужно от тебя: узнать планы команды на квартал / понять статус проблемы или проекта и т.д;

Иногда – тебе что-то нужно от больших начальников: получить ресурс / заставить других их подчинённых что-то сделать / получить одобрение на смену курса / …

Как вести эти разговоры эффективно?

––

При общении в переписке

1. Если задаёшь вопрос:

Вся нужная для ответа инфа и явно сформулированный вопрос должны находиться в одном сообщении.

2. Если отвечаешь на вопрос:

В начале – как можно более ёмкий ответ, за ним – все нужные детали. Обязательно в одном сообщении.

––

Не допускай долгой переписки! К решению нужно прийти за единицы сообщений. На уточняющие вопросы отвечай со всеми деталями в одном сообщении + сразу возвращайся к исходному вопросу;


Если договариваешься на встрече

Всю нужную для принятия решения информацию нужно принести в максимально разжёванном виде.

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

Ответ или решение нужно обязательно получить на той же встрече.

––

Почему так? Топы вообще не держат контекст и не умеют читать?

Да.

(Шутка)

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

Что из этого следует?

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

Заводить разговор: «помнишь, мы позавчера начали обсуждать X? Так вот..» – бесполезно. Нет, собеседник не помнит и да – тебе придётся начинать сначала. Короче, контекст между транзакциями обычно не сохраняется.

Так что работай над формулировками и договаривайся быстро :)

Decision-review

У разрабов в бигтехе часто обязательной является практика код-ревью.

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

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

А есть ли аналогичный механизм у руководителей для своих задач?

––

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

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

––

А какой выход? Управленческие решения – это же не код, на ревью не отправишь..

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

– Я хочу сделать X. Вот такая мотивация, вот такой эффект ожидаю. Чего думаете?
– Не, смотри, у тебя вот эти люди могут разбежаться от такого. Я делал – вот что вышло. <и другой поток обратной связи…>

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

––

P.S.

Тут тред для небольших вопросов – мы время от времени публично их разбираем в канале

Здесь можно записаться и лично детально пообсуждать свои кейсы

А здесь – можно поискать уже вышедший совет на нужную тему

О метриках для лидов любого уровня:

1. Самый осмысленный и ценный результат – это измеримый результат

Мы сделаем сервис надёжным и отказоустойчивым

– буллшит, оставь для своей избирательной компании.

В прошлом году у нас было два часа даунтайма. В этом году мы не допустим даунтайма более, чем на 15 минут

– хорошая цель.

Я классно развиваю специалистов

– буллшит, расскажешь на дне открытых дверей для школьников (студентам уже нужно посложнее).

Джун в моей команде за полгода растёт до миддла; миддлы имеют стабильный перформанс не ниже X; миддлы за два года превращатся в синьоров; людей из моей команды пытаются переманить конкуренты в среднем на X2 зп и + 2 грейда

– крутые показатели.

––

2. Если умные люди регулярно думают про метрику, она меняется в желаемую сторону

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

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

При регулярном повторении начинает происходить магия

––

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

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

1 квартал: 5 секунд -> 2 секунды
2 квартал: 2 секунды -> 1 секунда
3 квартал: 1 секунда -> 0.8 секунд
4 квартал: 0.8 секунд -> 0.75
…

Стоп!
Может быть, 1 секунда – это уже хорошо? Правда ли 1 -> 0.8 – это лучшее, что можно было сделать за 3 квартал? Может быть, где-то рядом есть другая метрика, теперь уже с бОльшим value, за которую мы не взялись?

––

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