Кейс «Затягивание сроков?» — разбор
Да, я тоже немного подзатянул с разбором: неделя была ударная, времени — впритык. Но кейс слишком хороший, чтобы его пропустить.
Итак, это история не про то чтобы сравнить двух мидлов и вывести кто лучше, а кто идёт на улицу, это история про калибровку ожиданий, уровни (грейды) и то, как система переваривает сильных.
Я бы разложил кейс на два вопроса:
— что делать с новичком?
— что делать со «старичком»
1️⃣ Что делать с новичком
Новичок делает задачи примерно в 2 раза быстрее человека того же грейда. Это факт.
Тут легко сделать неправильный вывод «старичок слабее». Надо проверить гипотезы.
Гипотеза А: мы недооценили новичка на входе
Вполне нормальная ситуация. Интервью это всё-таки шумный инструмент, плюс первый месяц часто идёт на «дофамине новой работы».
Если тренд устойчивый, то через некоторое время (и если ваша система мотивации в компании это позволяет) просто поднимаем новичку уровень и компенсацию.
Чтобы подкрепить тренд даём новичку задачи уровнем выше / с неопределённостью и ответственностью — и смотрим, держит ли он качество, коммуникацию и решения, а не только скорость.
Гипотеза Б: сравнение «нечестное»
Новичок мог получать более «чистые» задачи (ещё очень часто их называют «задачи на испытательный срок» для вкатывания), а старичок тащит то, что не видно: кучу контекстов, согласований, тушение пожаров, сложных стейкхолдеров и легаси в конце концов.
Тут путают output (видимый результат) и impact (реальная польза для продукта/команды).
Тут надо честно взглянуть на наборы задач и постараться выровнять их. То есть догрузить новичка и снять задачи со старичка.
Вне зависимости от того какую гипотезу вы считаете более правдоподной важно ещё и проговорить риски бездействия.
Если оставить всё как есть, то с высокой вероятностью «система откатит новичка до среднего», то есть локальная эффективность потонет в системных ограничениях. А сам новичок либо замедлится, либо выгорит и/или уйдёт туда, где среда поддерживает темп.
Сам факт того что такое случилось — это сигнал о том что нужно включать прозрачность, но не про людей, а про ожидания:
— то есть что значит «мидл» в этой уникальной роли,
— какие артефакты считаются стандартом,
— что должно появиться, чтобы уровень стал выше.
И это ваша работа.
2️⃣ Что делать со «старичком»?
Допустим что все же вы склонны к варианту, что «старичок» заскучал, расслабился, привык. Увольнять? Почти никогда такие увольнения не бывают верным решением — особенно если роль уникальная и человек носит критичный контекст.
Но и делать вид, что ничего не произошло, тоже нельзя. Нужно соотнести ожидания от уровня с фактической работой.
Важно: «мы планировали повысить» ≠ «обязаны повысить».
Повышение — это подтверждение соответствия ожиданиям следующего уровня, а не награда за стаж или уникальность.
Что тут надо сделать:
— выровнять уровень задач у новичка и старичка и посмотреть как летит хотя бы 2–4 недели (а вдруг потянет)
— зафиксировать стандарт артефактов для роли (то есть скорее всего расширить его и явно объяснить «старичку» что у нас поменялись требования)
— разгрузить старичка от шума, когда он был один в роли и все потоки коммуникации шли в него.
— сделать индивидуальный план развития старичка с конкретными ожиданиями
— пересмотреть (если вообще есть) модель компетенций для этой роли (часто это сигнал что она описана плохо)
— если политика позволяет — иногда можно подтянуть компенсацию без изменения формального уровня
Главный вывод тут такой, что приход сильного новичка привел вас к ситуации, когда можно поменять систему и/или признать ошибку найма, или не делать ничего и пустить на самотёк... В общем поймите вы будете подтягивать систему под сильного или сильного под систему?
Да, я тоже немного подзатянул с разбором: неделя была ударная, времени — впритык. Но кейс слишком хороший, чтобы его пропустить.
Итак, это история не про то чтобы сравнить двух мидлов и вывести кто лучше, а кто идёт на улицу, это история про калибровку ожиданий, уровни (грейды) и то, как система переваривает сильных.
Я бы разложил кейс на два вопроса:
— что делать с новичком?
— что делать со «старичком»
1️⃣ Что делать с новичком
Новичок делает задачи примерно в 2 раза быстрее человека того же грейда. Это факт.
Тут легко сделать неправильный вывод «старичок слабее». Надо проверить гипотезы.
Гипотеза А: мы недооценили новичка на входе
Вполне нормальная ситуация. Интервью это всё-таки шумный инструмент, плюс первый месяц часто идёт на «дофамине новой работы».
Если тренд устойчивый, то через некоторое время (и если ваша система мотивации в компании это позволяет) просто поднимаем новичку уровень и компенсацию.
Чтобы подкрепить тренд даём новичку задачи уровнем выше / с неопределённостью и ответственностью — и смотрим, держит ли он качество, коммуникацию и решения, а не только скорость.
Гипотеза Б: сравнение «нечестное»
Новичок мог получать более «чистые» задачи (ещё очень часто их называют «задачи на испытательный срок» для вкатывания), а старичок тащит то, что не видно: кучу контекстов, согласований, тушение пожаров, сложных стейкхолдеров и легаси в конце концов.
Тут путают output (видимый результат) и impact (реальная польза для продукта/команды).
Тут надо честно взглянуть на наборы задач и постараться выровнять их. То есть догрузить новичка и снять задачи со старичка.
Вне зависимости от того какую гипотезу вы считаете более правдоподной важно ещё и проговорить риски бездействия.
Если оставить всё как есть, то с высокой вероятностью «система откатит новичка до среднего», то есть локальная эффективность потонет в системных ограничениях. А сам новичок либо замедлится, либо выгорит и/или уйдёт туда, где среда поддерживает темп.
Сам факт того что такое случилось — это сигнал о том что нужно включать прозрачность, но не про людей, а про ожидания:
— то есть что значит «мидл» в этой уникальной роли,
— какие артефакты считаются стандартом,
— что должно появиться, чтобы уровень стал выше.
И это ваша работа.
2️⃣ Что делать со «старичком»?
Допустим что все же вы склонны к варианту, что «старичок» заскучал, расслабился, привык. Увольнять? Почти никогда такие увольнения не бывают верным решением — особенно если роль уникальная и человек носит критичный контекст.
Но и делать вид, что ничего не произошло, тоже нельзя. Нужно соотнести ожидания от уровня с фактической работой.
Важно: «мы планировали повысить» ≠ «обязаны повысить».
Повышение — это подтверждение соответствия ожиданиям следующего уровня, а не награда за стаж или уникальность.
Что тут надо сделать:
— выровнять уровень задач у новичка и старичка и посмотреть как летит хотя бы 2–4 недели (а вдруг потянет)
— зафиксировать стандарт артефактов для роли (то есть скорее всего расширить его и явно объяснить «старичку» что у нас поменялись требования)
— разгрузить старичка от шума, когда он был один в роли и все потоки коммуникации шли в него.
— сделать индивидуальный план развития старичка с конкретными ожиданиями
— пересмотреть (если вообще есть) модель компетенций для этой роли (часто это сигнал что она описана плохо)
— если политика позволяет — иногда можно подтянуть компенсацию без изменения формального уровня
Главный вывод тут такой, что приход сильного новичка привел вас к ситуации, когда можно поменять систему и/или признать ошибку найма, или не делать ничего и пустить на самотёк... В общем поймите вы будете подтягивать систему под сильного или сильного под систему?