“Зачем мы придерживаемся политики bar raising при найме? Какие задачи бизнеса это решает?” Команды, сформированные из синьоров, стоят дороже, но способны решать задачи качественнее и быстрее. А еще в таких командах меньше риски.
Примеры. Senior developer реализует фичу за час, вместо дня. Код такой, что потом другой команде не придется тратить время и называть его некрасивыми словами. Продакт лежит с ковидом, но команда понимает как и что делать и не теряет velocity.
“Также интересно было бы узнать каким образом эта планка измеряется“ По текущей команде - ежегодно на performance review по 4 шкалам. По кандидатам - эмпирически на собеседовании, на review в конце испыта по 4 шкалам.
Лидер обязательно собеседует людей в свою команду. Он хорошо знает своих direct reports, так что обычно способен понять, как среди них будет выглядеть кандидат. Хотя ошибка выжившего возможна из-за тех, кого не взяли по эмпирической оценке, а они-то на самом деле огого!
“Как долго вы собираетесь это продолжать?” Пока это будет целесообразно экономически. Как только это перестанет быть целесообразно экономически - тут же прекратим.
“Придерживаетесь ли вы принципов меритократии при этом?” Я лично принципов меритократии придерживаюсь, даже когда с ребенком Lego собираю. Во Flo скиллы и желания самого человека помогают найти ему оптимальное место.
“Есть ли оценки как скоро вы скорее всего не сможете больше поддерживать постоянный подъём планки? Какой план после этого?” Мы вот буквально намедни вышли на рынок труда в Европе, и кажется на горизонте нескольких лет новый план не нужен.
Также спрашивали про книжки, что почитать, чтобы сразу синьором стать. Универсальный ответ - определите свои слабые стороны (хоть сами, хоть прости-господи с коучем) и прокачивайте их. Я сейчас качаю прогнозирование, у меня в читалке Тетлок, Сильвер, Талер.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Больше всего вопросов вызывает рекрутинг, так что тред сегодня будет про него.
Не путаю ли я bar raising с наемом синьоров? Нет, не путаю. Если долго нанимать сотрудников выше среднего уровня в команду, средний уровень в команде поднимется до senior. Даже если никого не увольнять.
Таким образом, чтобы кандидат оказался выше среднего, он как минимум должен быть синьором. И уже затем его можно сравнивать со средним и понимать - этот конкретный senior bar raiser сейчас для команды или нет.
Про команду тред. Мы все очень разные. Объединяет всего пара вещей: 1. Каждый непременно в чем-то талантлив 2. Среди нас нет “пассажиров”
(по меткому выражению нашего СТО Романа)
Для меня это а⃫д⃫ добавляет работы как для people-менеджера. Раздавать задачки как в армии не работает, с каждым продактом свой ритм, свои аргументы, свой подход в общем. Но это и великолепно, потому что любая задача встретит свежий (иногда недобрый) взгляд.
Общаемся мы в основном языком ОКР.
*тупая шутка про то, что это одновременно и методология, и диагноз*
Продуктивные конфликты — лучший способ узнать что-то новое и разрешить настоящие противоречия. (трэд)
Пока у вас есть только довольные клиенты, пока в команде все хорошо, а у стейкхолдеров нет к вам вопросов — все ок.
Вот только все это лишь слабые свидетельства в пользу того, что все действительно идет как надо.
О чем-то важном в таком режиме вы рискуете не узнать никогда.
К сожалению, общество с малых лет приучает нас «жить дружно», поощряет идти на компромиссы, избегать конфликтов. Маркирует конфликтное поведение в целом как нежелательное — развивает в нас конфликтофобию.
Трэд про коммуникацию, которой все постоянно занимаются, не смотря на то что она практически невозможна.
Менеджер продукта — профессиональный коммуникатор.
Систему знаний о продукте невозможно создать без коммуникации с другими людьми; система знаний не нужна, если ее составляющие невозможно в процессе коммуникации передать другим людям.
Качественная коммуникация со всеми кто работает с продуктом (клиенты, команда, стейкхолдеры и т.д.) — ответственность менеджера.
Главное что мы должны понимать — успех коммуникации случается вопреки множеству предпосылок (то есть это практически чудо).
Ок, сегодня будет тема попроще — как могут вредить метрики ;)
Самая простая ошибка: «после не значит вследствие». Сделали что-то в продукте — изменилась метрика — засчитали себе win. Подкрутили еще — метрика просела — lose. Можно ли на этом основании делать какие-то выводы? Кажется, что «да», а на самом деле «пока не понятно».
В самой первой главе в Симулятора (@oleg_gpio) есть пара хороших задач про понимание, где причинно-следственная связь, а где только возможная корреляция. По мне так очень недооцененное знание, особенно в приложении к работе с метриками.