Нам надо двигаться быстрее
Эту фразу можно услышать практически в каждой компании, кого из топ-менеджеров вы бы ни спросили. С вопросом "а куда именно нам надо двигаться", или, еще хуже, "а зачем нам двигаться быстро", так легко они уже не справляются.
Конечно, рыночек часто мотивирует компании ускоряться. При этом не стоит путать реальную нужду со следующими похожими на нее вещами:
👉Ностальгия. Когда-то компания была маленькой, двигалась и менялась быстро. Но рост всегда несет за собой сложность и неповоротливость, и вернуться в прошлое при всем желании не получится.
👉Хаотичность. Быстрая и интенсивная работа сама по себе не всегда несет за собой пользу для бизнеса.
👉Героические усилия. В компаниях, живущих от пожара до пожара, частым элементом культуры становится поощрение тех, кто, превозмогая все, решает очередную проблему. Это ведет не только к выгоранию, но и к тому, что компании разучиваются работать над долгосрочными проектами.
Когда от вас требуют двигаться быстрее, задайте следующие вопросы:
👉Зачем? Откуда вообще берется это требование, чем оно продиктовано, как согласовано со стратегией компании.
👉Какого типа скорость нужна? Идет ли речь о скорости поставки ценности или скорости адаптации к внешним изменениям на рынке?
👉В каких конкретно областях бизнеса надо двигаться быстро? Ускориться одновременно везде нельзя, да и не имеет смысла.
👉Что мы готовы заплатить за скорость? Ускорение не дается бесплатно, нужно чем-то пожертвовать. Например, качеством.
👉Какая поддержка будет оказана? Для того, чтобы команда работала быстрее, нужно, чтобы ее вход и выход были так же оптимизированы – грамотный менеджмент, понятные требования, налаженная автоматизация.
Эту фразу можно услышать практически в каждой компании, кого из топ-менеджеров вы бы ни спросили. С вопросом "а куда именно нам надо двигаться", или, еще хуже, "а зачем нам двигаться быстро", так легко они уже не справляются.
Конечно, рыночек часто мотивирует компании ускоряться. При этом не стоит путать реальную нужду со следующими похожими на нее вещами:
👉Ностальгия. Когда-то компания была маленькой, двигалась и менялась быстро. Но рост всегда несет за собой сложность и неповоротливость, и вернуться в прошлое при всем желании не получится.
👉Хаотичность. Быстрая и интенсивная работа сама по себе не всегда несет за собой пользу для бизнеса.
👉Героические усилия. В компаниях, живущих от пожара до пожара, частым элементом культуры становится поощрение тех, кто, превозмогая все, решает очередную проблему. Это ведет не только к выгоранию, но и к тому, что компании разучиваются работать над долгосрочными проектами.
Когда от вас требуют двигаться быстрее, задайте следующие вопросы:
👉Зачем? Откуда вообще берется это требование, чем оно продиктовано, как согласовано со стратегией компании.
👉Какого типа скорость нужна? Идет ли речь о скорости поставки ценности или скорости адаптации к внешним изменениям на рынке?
👉В каких конкретно областях бизнеса надо двигаться быстро? Ускориться одновременно везде нельзя, да и не имеет смысла.
👉Что мы готовы заплатить за скорость? Ускорение не дается бесплатно, нужно чем-то пожертвовать. Например, качеством.
👉Какая поддержка будет оказана? Для того, чтобы команда работала быстрее, нужно, чтобы ее вход и выход были так же оптимизированы – грамотный менеджмент, понятные требования, налаженная автоматизация.
NOBL
Speed Traps in Organizations — NOBL
Leaders naturally want to move fast—but watch out for these common speedbumps
Метод Монте-Карло для прогнозирования сроков
За последний месяц мне нужно было построить сразу несколько финансовых моделей и моделей роста на основе довольно ограниченных объективных данных о размере рынка и конверсиях. Получить хоть какое-то представление о возможных разбросах значений очень помог метод Монте-Карло. И вот как раз наткнулся на статью, где подробно разбирается, как его использовать в Google Sheet, и применять для прогнозирования сроков выполнения задач и приоритизации бэклога.
За последний месяц мне нужно было построить сразу несколько финансовых моделей и моделей роста на основе довольно ограниченных объективных данных о размере рынка и конверсиях. Получить хоть какое-то представление о возможных разбросах значений очень помог метод Монте-Карло. И вот как раз наткнулся на статью, где подробно разбирается, как его использовать в Google Sheet, и применять для прогнозирования сроков выполнения задач и приоритизации бэклога.
Может ли тимлид не быть программистом
Все похоливарили на прошлой неделе, давайте и мы не будем отрываться. На Хабре завирусилась статья, автор которой настаивает на том, что тимлиды, которые не пишут код, не обладают технической квалификацией и не могут справляться со своими задачами. Доводы такие:
👉Вы не можете нанять инженера, так как вы не в состоянии оценить его квалификацию.
👉Вы не можете поставить задачу инженеру, так как вы не можете её сформулировать.
👉Вы не можете оценить качество выполнения поставленной задачи, потому что вы не понимаете её суть.
👉Вы не можете оценить адекватность сроков выполнения задачи, так как не можете оценить её трудоёмкость.
👉Вы не можете выступать в роли арбитра в спорах между инженерами, так как не понимаете суть этих споров, и не обладаете авторитетом среди технарей.
👉Вы не можете обучать нанятых вами инженеров, так как вам нечем с ними поделиться.
👉Вы не можете выявлять технических лидеров в команде, чтобы делегировать им полномочия развития тех или иных направлений.
👉Вы не можете обеспечить "отказоустойчивость" вашей команды, так как не можете оценить реальный вклад в работу инженеров. Вы не понимаете, кого нужно удерживать, а с кем можно спокойно попрощаться. Вы не можете адекватно оценить риски ухода того или иного инженера. И, как следствие, вы не можете вовремя минимизировать эти риски.
На мой взгляд – полная ерунда. А вы что думаете?
Все похоливарили на прошлой неделе, давайте и мы не будем отрываться. На Хабре завирусилась статья, автор которой настаивает на том, что тимлиды, которые не пишут код, не обладают технической квалификацией и не могут справляться со своими задачами. Доводы такие:
👉Вы не можете нанять инженера, так как вы не в состоянии оценить его квалификацию.
👉Вы не можете поставить задачу инженеру, так как вы не можете её сформулировать.
👉Вы не можете оценить качество выполнения поставленной задачи, потому что вы не понимаете её суть.
👉Вы не можете оценить адекватность сроков выполнения задачи, так как не можете оценить её трудоёмкость.
👉Вы не можете выступать в роли арбитра в спорах между инженерами, так как не понимаете суть этих споров, и не обладаете авторитетом среди технарей.
👉Вы не можете обучать нанятых вами инженеров, так как вам нечем с ними поделиться.
👉Вы не можете выявлять технических лидеров в команде, чтобы делегировать им полномочия развития тех или иных направлений.
👉Вы не можете обеспечить "отказоустойчивость" вашей команды, так как не можете оценить реальный вклад в работу инженеров. Вы не понимаете, кого нужно удерживать, а с кем можно спокойно попрощаться. Вы не можете адекватно оценить риски ухода того или иного инженера. И, как следствие, вы не можете вовремя минимизировать эти риски.
На мой взгляд – полная ерунда. А вы что думаете?
Хабр
Почему секретарша является самым дорогим ресурсом в команде?
Недавно наткнулся на пост , который поразил меня до глубины души: тимлид - это САМЫЙ ДОРОГОЙ ресурс команды. И когда тимлид садится писать код, вместо того, чтобы решать свои прямые задачи, он...
Определение ожиданий методом компаса или карты
Людям и командам разной зрелости нужен разный подход к определению ожиданий. Иногда полезно сравнивать их с определением направления движения с помощью компаса или с помощью карты.
🧭Компас – вы задаете только направление движения, но не даете никаких дополнительных ограничений, оставляя сотруднику максимум автономности для принятия собственных решений.
🗺️Карта – вы определяете не только направление, но и маршрут, причем в разной степени детализации. Можно задать только несколько ограничений, а можно описать весь маршрут с точностью до каждого поворота.
Людям и командам разной зрелости нужен разный подход к определению ожиданий. Иногда полезно сравнивать их с определением направления движения с помощью компаса или с помощью карты.
🧭Компас – вы задаете только направление движения, но не даете никаких дополнительных ограничений, оставляя сотруднику максимум автономности для принятия собственных решений.
🗺️Карта – вы определяете не только направление, но и маршрут, причем в разной степени детализации. Можно задать только несколько ограничений, а можно описать весь маршрут с точностью до каждого поворота.
Как пройти через массовое сокращение команды
Представьте – вы несколько лет строили замечательную команду, которая показывает отличные результаты. Однажды к вам приходит СЕО и говорит, что вам надо сократить 80% всех ее участников, причем на принятие и проведение решения выдается только один день.
В Reddit-треде куча советов про то, как менеджеру пройти через это. Вот некоторые из них:
👉Обновить собственное резюме, так как есть огромная вероятность, что на этом сокращения не остановятся. Особенно стоит подумать о том, остаетесь ди вы ценны, как менеджер, при значительно уменьшившемся размере команды.
👉Разобраться с зоной ответственности команды. Если ушла большая часть людей, их работу надо либо перестать делать, либо переложить на оставшихся. У менеджмента не должно быть ожиданий того, что оставшиеся 20% команды будут делать тот же объем работы.
👉Обязательно как можно раньше встретьтесь лично со всеми, кто остался в команде, обсудите происходящее и то, как поменяется их работа.
👉Изначально настройте себя на то, что сокращение – это не переговоры, а уже принятое бизнесовое решение. Лучший способ провести разговор с увольняемыми – придерживаться одного и того же сценария, оставаясь при этом человечным, и давая им возможность запроцессить информацию.
👉Постарайтесь сохранить личный контакт с увольняемыми. Вы можете помочь им с рекомендациями, отточкой навыков прохождения собеседования или написания резюме.
Представьте – вы несколько лет строили замечательную команду, которая показывает отличные результаты. Однажды к вам приходит СЕО и говорит, что вам надо сократить 80% всех ее участников, причем на принятие и проведение решения выдается только один день.
В Reddit-треде куча советов про то, как менеджеру пройти через это. Вот некоторые из них:
👉Обновить собственное резюме, так как есть огромная вероятность, что на этом сокращения не остановятся. Особенно стоит подумать о том, остаетесь ди вы ценны, как менеджер, при значительно уменьшившемся размере команды.
👉Разобраться с зоной ответственности команды. Если ушла большая часть людей, их работу надо либо перестать делать, либо переложить на оставшихся. У менеджмента не должно быть ожиданий того, что оставшиеся 20% команды будут делать тот же объем работы.
👉Обязательно как можно раньше встретьтесь лично со всеми, кто остался в команде, обсудите происходящее и то, как поменяется их работа.
👉Изначально настройте себя на то, что сокращение – это не переговоры, а уже принятое бизнесовое решение. Лучший способ провести разговор с увольняемыми – придерживаться одного и того же сценария, оставаясь при этом человечным, и давая им возможность запроцессить информацию.
👉Постарайтесь сохранить личный контакт с увольняемыми. Вы можете помочь им с рекомендациями, отточкой навыков прохождения собеседования или написания резюме.
Reddit
From the managers community on Reddit
Explore this post and more from the managers community
Когда парное программирование приносит больше всего пользы
В задачах с высокой степенью определенности:
👉Программист, отвечающий за задачу, недостаточно сильный, чтобы быстро с ней справиться. Такое может происходить, например, с джунами. Добавление к нему в пару опытного разработчика поможет и с задачей быстрее справиться, и подкачать навыки джуна.
👉Программист сильный, но недостаточно знаком с кодовой базой. В таком случае парное программирование существенно ускоряет получение контекста.
В задачах с высокой степенью неопределенности скилл и знание кодовой базы уже не настолько критичны, и в целом парное программирование тут полезно почти всегда. Вот почему:
👉Помогает избегать туннельного видения. Часто первое, с чего программист начинает решать неопределенную задачу – написание прототипа. В итоге первоначальная реализация прототипа может сильно ограничить возможные способы решения задачи и создать белые пятна. Второй взгляд сильно помогает с этим бороться.
👉Ускоряет фидбэк луп обсуждения и проверки идей.
👉Помогает побороть психологические блокеры, мешающие приступить к непонятной задаче, и перестать прокрастинировать.
В задачах с высокой степенью определенности:
👉Программист, отвечающий за задачу, недостаточно сильный, чтобы быстро с ней справиться. Такое может происходить, например, с джунами. Добавление к нему в пару опытного разработчика поможет и с задачей быстрее справиться, и подкачать навыки джуна.
👉Программист сильный, но недостаточно знаком с кодовой базой. В таком случае парное программирование существенно ускоряет получение контекста.
В задачах с высокой степенью неопределенности скилл и знание кодовой базы уже не настолько критичны, и в целом парное программирование тут полезно почти всегда. Вот почему:
👉Помогает избегать туннельного видения. Часто первое, с чего программист начинает решать неопределенную задачу – написание прототипа. В итоге первоначальная реализация прототипа может сильно ограничить возможные способы решения задачи и создать белые пятна. Второй взгляд сильно помогает с этим бороться.
👉Ускоряет фидбэк луп обсуждения и проверки идей.
👉Помогает побороть психологические блокеры, мешающие приступить к непонятной задаче, и перестать прокрастинировать.
DEV Community
Thoughts on Pair Programming
I am currently leading a team of four very talented engineers, and we started practicing pair...
Про эффект IKEA
Эффект IKEA – когнитивное искажение, суть которого в том, что люди гораздо более сильнее эмоционально привязаны к вещам, к созданию которых они приложили руку. Одно из исследований даже померяло степень этой привязанности – исследуемые были готовы заплатить на 63% больше за мебель, которую они собирали сами.
Это когнитивное искажение относится не только к мебели и к успеху бизнеса IKEA. Как показывает статья, оно распространяется и на изменения в организациях. Если вы хотите, чтобы оно сработало в вашу пользу:
👉Всегда объясняйте причину внедрения какого-то изменения, и проверяйте, что все участники действительно согласны с решаемой проблемой.
👉Вместо того, чтобы спускать на команду готовое решение, начинайте с драфтов, готовых где-то на 20%.
👉Не просто вовлекайте людей в работу, а делегируйте им проработку конкретных кусков.
👉Давайте людям достаточно времени подумать над вашими предложениями и дать фидбэк.
👉Не бойтесь того, что совместная работа с большим уровнем вовлеченности замедлит вас. На старте вы действительно притормозите, зато отыграете все потери на этапе внедрения изменения.
Эффект IKEA – когнитивное искажение, суть которого в том, что люди гораздо более сильнее эмоционально привязаны к вещам, к созданию которых они приложили руку. Одно из исследований даже померяло степень этой привязанности – исследуемые были готовы заплатить на 63% больше за мебель, которую они собирали сами.
Это когнитивное искажение относится не только к мебели и к успеху бизнеса IKEA. Как показывает статья, оно распространяется и на изменения в организациях. Если вы хотите, чтобы оно сработало в вашу пользу:
👉Всегда объясняйте причину внедрения какого-то изменения, и проверяйте, что все участники действительно согласны с решаемой проблемой.
👉Вместо того, чтобы спускать на команду готовое решение, начинайте с драфтов, готовых где-то на 20%.
👉Не просто вовлекайте людей в работу, а делегируйте им проработку конкретных кусков.
👉Давайте людям достаточно времени подумать над вашими предложениями и дать фидбэк.
👉Не бойтесь того, что совместная работа с большим уровнем вовлеченности замедлит вас. На старте вы действительно притормозите, зато отыграете все потери на этапе внедрения изменения.
Jeremy Brown
The IKEA Effect and How I Screwed Up!
Learn about the IKEA Effect's role in organizational change from my firsthand account of its misapplication. I also share lessons on communication, co-creation, and the power of early involvement for successful change initiatives.
Умер Даниэль Канеман
Вспоминая когнитивные искажения, нельзя не вспомнить главного их популяризатора, поведенческого экономиста Даниэля Канемана. На прошлой неделе он умер 💔
Если вы по какой-то совсем непонятной причине еще не читали "Thinking Fast and Slow", обязательно запланируйте себе. Лично мне эта книга дала, наверное, самый значимый буст в понимании и себя, и других людей.
Вспоминая когнитивные искажения, нельзя не вспомнить главного их популяризатора, поведенческого экономиста Даниэля Канемана. На прошлой неделе он умер 💔
Если вы по какой-то совсем непонятной причине еще не читали "Thinking Fast and Slow", обязательно запланируйте себе. Лично мне эта книга дала, наверное, самый значимый буст в понимании и себя, и других людей.
Как показывать свое признание другим людям
В статье много советов как для менеджеров, так и для индивидуальных контрибьюторов. Я выбрал несколько, которые мне понравились:
👉Используя чье-то предложение, или обсуждая чью-то идею на митинге, всегда старайтесь органично упомянуть ее автора.
👉Если кто-то пропустил важную командную встречу или вечернюю посиделку, пришлите ему фотографию, видео или сообщение про то, что его не хватало, и по нему скучали.
👉Если вы знаете карьерные цели своих сотрудников (а вам хорошо бы их знать), старайтесь почаще подкидывать им релевантные возможности – выступить перед нужными людьми, подключиться к проекту, который их разовьет, делегировать подходящую задачу.
👉На митингах старайтесь давать явную возможность высказаться самым тихим и молчаливым участникам.
В статье много советов как для менеджеров, так и для индивидуальных контрибьюторов. Я выбрал несколько, которые мне понравились:
👉Используя чье-то предложение, или обсуждая чью-то идею на митинге, всегда старайтесь органично упомянуть ее автора.
👉Если кто-то пропустил важную командную встречу или вечернюю посиделку, пришлите ему фотографию, видео или сообщение про то, что его не хватало, и по нему скучали.
👉Если вы знаете карьерные цели своих сотрудников (а вам хорошо бы их знать), старайтесь почаще подкидывать им релевантные возможности – выступить перед нужными людьми, подключиться к проекту, который их разовьет, делегировать подходящую задачу.
👉На митингах старайтесь давать явную возможность высказаться самым тихим и молчаливым участникам.
Harvard Business Review
Simple Ways to Show Appreciation at Work
Appreciation, like trust, is relationship-based — each interaction we have with someone either strengthens or weakens that invisible connection. The more we feel appreciated, the stronger those bonds become, and the more tension they can withstand when something…
Как выполнять решения, с которыми ты не согласен
Представьте, что вы были частью группы, принимающей важное решение, касающееся вашей команды. Например, про закрытие проекта, которым вы занимались. Вы высказали аргументы в защиту своей позиции, яростно спорили с альтернативами, но в итоге было принято решение, с которым вы в корне не согласны. Дальше спорить бессмысленно, остается принять его и исполнить. И вот дальше начинается самое сложное – теперь это решение надо объяснить команде.
Некоторые менеджеры в таких случаях напускают на сеья притворный энтузиазм и начинают подыскивать аргументы, в которые не верят сами. Другие встают в позицию "я прав, а все вокруг мудаки" и ищут поддержки в команде, настраивая ее против всех. Оба подхода – фиговые. Вместо этого попробуйте практиковать "disagree and commit". Будьте прозрачны, объективно объясните аргументы обеих сторон, скажите, что не согласны, что принятое решение правильное, но при этом исполнить его все равно нужно, потому что время дебатов закончилось и вечно буксовать не получится.
Вот еще несколько советов из статьи:
👉Дайте членам команды выговориться на 1-1. Не стоит пытаться переубеждать их, просто поддержите.
👉Максимально избегайте выстраивания ментальности "мы против них", выливая свои фрустрации на команду.
👉Не откладывайте рассказ о неприятных для команды новостях, как бы этого ни хотелось.
👉Будьте последовательны и консистентны, рассказывайте всем одну и ту же честную версию событий.
Еще в статье мне понравился заключительный блок про то, как объявлять письменно о таких больших спорных решениях:
👉Только факты, никаких эмоций.
👉Осветите следующее: кто принимал решение, какие проблемы решались, что именно было решено, на кого влияет решение, когда оно вступает в силу, какие следующие шаги.
👉Если какие-то детали, например, конкретный план действий еще не определены, напишите об этом явно.
👉Запланируйте Q&A сессию, где все смогут задать свои вопросы.
Представьте, что вы были частью группы, принимающей важное решение, касающееся вашей команды. Например, про закрытие проекта, которым вы занимались. Вы высказали аргументы в защиту своей позиции, яростно спорили с альтернативами, но в итоге было принято решение, с которым вы в корне не согласны. Дальше спорить бессмысленно, остается принять его и исполнить. И вот дальше начинается самое сложное – теперь это решение надо объяснить команде.
Некоторые менеджеры в таких случаях напускают на сеья притворный энтузиазм и начинают подыскивать аргументы, в которые не верят сами. Другие встают в позицию "я прав, а все вокруг мудаки" и ищут поддержки в команде, настраивая ее против всех. Оба подхода – фиговые. Вместо этого попробуйте практиковать "disagree and commit". Будьте прозрачны, объективно объясните аргументы обеих сторон, скажите, что не согласны, что принятое решение правильное, но при этом исполнить его все равно нужно, потому что время дебатов закончилось и вечно буксовать не получится.
Вот еще несколько советов из статьи:
👉Дайте членам команды выговориться на 1-1. Не стоит пытаться переубеждать их, просто поддержите.
👉Максимально избегайте выстраивания ментальности "мы против них", выливая свои фрустрации на команду.
👉Не откладывайте рассказ о неприятных для команды новостях, как бы этого ни хотелось.
👉Будьте последовательны и консистентны, рассказывайте всем одну и ту же честную версию событий.
Еще в статье мне понравился заключительный блок про то, как объявлять письменно о таких больших спорных решениях:
👉Только факты, никаких эмоций.
👉Осветите следующее: кто принимал решение, какие проблемы решались, что именно было решено, на кого влияет решение, когда оно вступает в силу, какие следующие шаги.
👉Если какие-то детали, например, конкретный план действий еще не определены, напишите об этом явно.
👉Запланируйте Q&A сессию, где все смогут задать свои вопросы.
Péter Szász
How To Represent Decisions You Disagree With
How to stand in front of your team representing a decision you didn't agree with? How to keep your integrity and support the team going through the change? What approaches are useful and what's better avoided in turbulent times?
Ошибки во внедрении OKR
Несколько лет назад я писал статью про то, как мы в Авито работали с OKR. В частности, рассказывал про потенциальные проблемы, с которыми вы можете столкнуться. Сегодняшний материал из заголовка натолкнул меня на мысль о том, что многие из довольно очевидных проблем меня вообще обошли стороной благодаря тому, что у компании уже была очень сильная data-культура. Люди хотели и умели считать деньги и влияние на них продуктовых метрик.
Но если бы такой культуры и сильной аналитической системы на тот момент не было, скорее всего, OKR бы провалились. Вот какие фейлы выделяет автор статьи:
👉OKR навешиваются поверх delivery-first подходов с роадмапами и дедлайнами.
👉Команды не вовлечены в работу с данными, а просто получают какие-то сигналы от аналитиков, работающих как черные ящики.
👉Лидеры компании не готовы к неопределенности, поэтому пытаются сохранить контроль над сроками.
👉Больше времени тратится не на работу с данными, а на подбор подходящих key results.
👉OKR уровня компании и уровня команд не связаны друг с другом из-за того, что финансовые и продуктовые метники плохо провязаны.
👉OKR навешиваются на функциональные группы вместо кросс-функциональных команд, из-за чего постоянно происходят конфликты приоритетов.
👉OKR выставляются на год, но меняются каждые три месяца.
Несколько лет назад я писал статью про то, как мы в Авито работали с OKR. В частности, рассказывал про потенциальные проблемы, с которыми вы можете столкнуться. Сегодняшний материал из заголовка натолкнул меня на мысль о том, что многие из довольно очевидных проблем меня вообще обошли стороной благодаря тому, что у компании уже была очень сильная data-культура. Люди хотели и умели считать деньги и влияние на них продуктовых метрик.
Но если бы такой культуры и сильной аналитической системы на тот момент не было, скорее всего, OKR бы провалились. Вот какие фейлы выделяет автор статьи:
👉OKR навешиваются поверх delivery-first подходов с роадмапами и дедлайнами.
👉Команды не вовлечены в работу с данными, а просто получают какие-то сигналы от аналитиков, работающих как черные ящики.
👉Лидеры компании не готовы к неопределенности, поэтому пытаются сохранить контроль над сроками.
👉Больше времени тратится не на работу с данными, а на подбор подходящих key results.
👉OKR уровня компании и уровня команд не связаны друг с другом из-за того, что финансовые и продуктовые метники плохо провязаны.
👉OKR навешиваются на функциональные группы вместо кросс-функциональных команд, из-за чего постоянно происходят конфликты приоритетов.
👉OKR выставляются на год, но меняются каждые три месяца.
Product Discovery Group
Our Half-Baked Adoption of OKRs — Product Discovery Group
Many companies adopt the Objectives and Key Results (OKRs) framework. They create goals but struggle to achieve them. Only some of this failure can be blamed on the goals themselves. Part of this failure can be attributed to a lack of an analytic culture…
В чем различия между менторством, коучингом и спонсорством
👉Менторство – это процесс передачи опыта от одного человека другому. Чаще всего менторство работает лучше, если вы не находитесь в отношениях "начальник-сотрудник".
Менторство хорошо описывается следующей фразой: "Я сталкивался с похожей ситуацией, вот как я поступил... Мне кажется, тебе стоит...".
👉Коучинг – это помощь человеку в достижении его целей. В отличие от менторства фокус не на развитии навыков, а на правильном применении уже существующих.
Коучинг можно описать так: "Чего ты пытаешься достичь? Что тебе мешает? Пробовал ли ты делать...? Как прошло? Что ты сделаешь по-другому в следующий раз?"
👉Спонсорство – это помощь человеку, уже владеющему всеми нужными навыками и компетенциями, продвинуться внутри организации. Его используют, если кто-то явно способен на большее, но почему-то оказался забдокирован и не может получить нужные возможности самостоятельно.
Спонсорство звучит примерно так: "Этот проект звучит как то, в чем отлично разбирается Вася. Давайте предложим лидить этот проект ему".
👉Менторство – это процесс передачи опыта от одного человека другому. Чаще всего менторство работает лучше, если вы не находитесь в отношениях "начальник-сотрудник".
Менторство хорошо описывается следующей фразой: "Я сталкивался с похожей ситуацией, вот как я поступил... Мне кажется, тебе стоит...".
👉Коучинг – это помощь человеку в достижении его целей. В отличие от менторства фокус не на развитии навыков, а на правильном применении уже существующих.
Коучинг можно описать так: "Чего ты пытаешься достичь? Что тебе мешает? Пробовал ли ты делать...? Как прошло? Что ты сделаешь по-другому в следующий раз?"
👉Спонсорство – это помощь человеку, уже владеющему всеми нужными навыками и компетенциями, продвинуться внутри организации. Его используют, если кто-то явно способен на большее, но почему-то оказался забдокирован и не может получить нужные возможности самостоятельно.
Спонсорство звучит примерно так: "Этот проект звучит как то, в чем отлично разбирается Вася. Давайте предложим лидить этот проект ему".
Может ли мобильщик вырасти до СТО
С одной стороны, не мне задавать такой вопрос. Моя карьера выглядит следующим образом:
👉Начал как Android и iOS разработчик
👉Стал тимлидом iOS команды, а затем – руководителем всей мобильной разработки
👉Потом каким-то образом стал руководить большим платформенным департаментом, где кроме мобилки были и фронтенд, и бэкенд, и тестирование, и много чего еще
👉Сгорел, стал продакт-менеджером, ушел делать Котлин
👉Невероятным образом стал руководить всем проектом и командой Kotlin, включая всю разработку
При этом я очень много раз замечал, что в обычной продуктовой компании мобильному разработчику гораздо проще упереться в стеклянный потолок, чем условному бэкендеру. В целом, тут нет ничего удивительного – чаще всего самые сложные инженерные задачи находятся все-таки не на клиенте, и возможностей для роста как по лесенке индивидульного контрибьютора, так и менеджера, бэкенд предоставляет существенно больше.
Илья Царев, с которым мы много пересекались в мою бытность мобильщиком, сейчас вырос до целого Director of Engineering в Яндексе. По ссылке в заголовке – его статья с неплохим разбором отличий между разными уровнями руководителей, ожиданиями от них, и рекомендациями по карьерному росту.
С одной стороны, не мне задавать такой вопрос. Моя карьера выглядит следующим образом:
👉Начал как Android и iOS разработчик
👉Стал тимлидом iOS команды, а затем – руководителем всей мобильной разработки
👉Потом каким-то образом стал руководить большим платформенным департаментом, где кроме мобилки были и фронтенд, и бэкенд, и тестирование, и много чего еще
👉Сгорел, стал продакт-менеджером, ушел делать Котлин
👉Невероятным образом стал руководить всем проектом и командой Kotlin, включая всю разработку
При этом я очень много раз замечал, что в обычной продуктовой компании мобильному разработчику гораздо проще упереться в стеклянный потолок, чем условному бэкендеру. В целом, тут нет ничего удивительного – чаще всего самые сложные инженерные задачи находятся все-таки не на клиенте, и возможностей для роста как по лесенке индивидульного контрибьютора, так и менеджера, бэкенд предоставляет существенно больше.
Илья Царев, с которым мы много пересекались в мою бытность мобильщиком, сейчас вырос до целого Director of Engineering в Яндексе. По ссылке в заголовке – его статья с неплохим разбором отличий между разными уровнями руководителей, ожиданиями от них, и рекомендациями по карьерному росту.
Как подталкивать всех к командной работе
На уровне своей команды:
👉Определять корректные ожидания от людей, которые ориентированы на командный успех, а не на индивидуальный
👉Давать частый фидбэк про то, что работает, а что нет
👉Самому быть ролевой моделью для команды
На уровне всей компании:
👉Выстраивать хорошие личные отношения с людьми из других департаментов
👉Наблюдать за тем, какие проблемы и хотелки есть у коллег из других департаментов и помогать им с ними
👉Иметь общее планирование
Как самому стать лучшим командным игроком:
👉Найти какую-то групповую активность за пределами основной работы
👉Фокусироваться на эмпатии, помощи другим и командных целях
👉Решать проблемы, которые мешают всей команде, но за которые никто не хочет браться
На уровне своей команды:
👉Определять корректные ожидания от людей, которые ориентированы на командный успех, а не на индивидуальный
👉Давать частый фидбэк про то, что работает, а что нет
👉Самому быть ролевой моделью для команды
На уровне всей компании:
👉Выстраивать хорошие личные отношения с людьми из других департаментов
👉Наблюдать за тем, какие проблемы и хотелки есть у коллег из других департаментов и помогать им с ними
👉Иметь общее планирование
Как самому стать лучшим командным игроком:
👉Найти какую-то групповую активность за пределами основной работы
👉Фокусироваться на эмпатии, помощи другим и командных целях
👉Решать проблемы, которые мешают всей команде, но за которые никто не хочет браться
Eng-Leadership
Great teams build great software
Better the teamwork, better the culture -> codebase -> product and happier are the customers!
Про использование LLM в ваших продуктах
В этому году, кажется, продакты и топ-менеджмент любой компании 80% своего ресурса тратят на то, чтобы понять, где конкретно их бизнесу могут помочь LLM. В посте – довольно неплохая подборка эвристик, которые могут вам помочь в такого рода рассуждениях.
👉LLM предсказывают наиболее резонные ответы на любые промпты.
👉Вы не сможете оценить, насколько точно был дан каждый конкретный ответ.
👉Вы можете в среднем оценивать точность модели и какого-то определенного набора промптов.
👉Точность ответов можно увеличить, используя модели большего размера, но они буду дороже и медленнее.
👉Даже самые быстрые LLM недостаточно быстры для многих задач.
👉Даже самые дорогие LLM не слишком дороги для большинства В2В задач. Даже самые дешевые LLM недостаточно дешевы для большинства консьюмерских задач.
👉Перфоманс моделей продолжит улучшаться в будущем, но скорость его улучшения будет довольно быстро падать.
👉Учитывая приведенные выше ограничения, вам надо либо смириться с неточностью ответов модели, либо комбинировать их с ручными человеческими проверками.
В этому году, кажется, продакты и топ-менеджмент любой компании 80% своего ресурса тратят на то, чтобы понять, где конкретно их бизнесу могут помочь LLM. В посте – довольно неплохая подборка эвристик, которые могут вам помочь в такого рода рассуждениях.
👉LLM предсказывают наиболее резонные ответы на любые промпты.
👉Вы не сможете оценить, насколько точно был дан каждый конкретный ответ.
👉Вы можете в среднем оценивать точность модели и какого-то определенного набора промптов.
👉Точность ответов можно увеличить, используя модели большего размера, но они буду дороже и медленнее.
👉Даже самые быстрые LLM недостаточно быстры для многих задач.
👉Даже самые дорогие LLM не слишком дороги для большинства В2В задач. Даже самые дешевые LLM недостаточно дешевы для большинства консьюмерских задач.
👉Перфоманс моделей продолжит улучшаться в будущем, но скорость его улучшения будет довольно быстро падать.
👉Учитывая приведенные выше ограничения, вам надо либо смириться с неточностью ответов модели, либо комбинировать их с ручными человеческими проверками.
Lethain
Notes on how to use LLMs in your product.
Pretty much every company I know is looking for a way to benefit from Large Language Models. Even if their executives don’t see much applicability, their investors likely do, so they’re staring at the blank page nervously trying to come up with an idea. It’s…
Подборка книг для менеджеров
Чтение книг – самый доступный для менеджера способ получения новых знаний. Помимо, конечно, регулярного утреннего чтения этого канала. Если ваши списки к прочтению пустые, посмотрите на подборку книг в посте, она, в целом, достаточно неплохая.
👉Turn the Ship Around: про выстраивание команды, которая не будет зависеть от вас
👉No Rules Rules: про инженерную культуру Netflix с отсутствием бюрократии
👉Extreme Ownership: про то, что вы представляете свою компанию, и в любых проблемах, кроме вас, винить некого
👉High Output Management: как менеджеру выбирать точку приложения усилий
👉From Worst to First: как делать себя и команду более бизнес-ориентированными
👉The Making of a Manager: про то, как стать менеджером
👉The Manager's Path: про путь от инженера до VP
👉5 Dysfunctions of a Team: как превращать сломанные команды в рабочие
👉The Ride of a Lifetime: про длиннющий путь СЕО Disney
👉Dare to Lead: как лидеру не бояться быть открытым и уязвимым
Кстати, я в свое время тоже регулярно писал отчеты о прочитанных книгах, среди которых было и много менеджерских. Если хотите прям заполнить свой бэклог на максимум, то можете вот тут эти обзоры почитать!
Чтение книг – самый доступный для менеджера способ получения новых знаний. Помимо, конечно, регулярного утреннего чтения этого канала. Если ваши списки к прочтению пустые, посмотрите на подборку книг в посте, она, в целом, достаточно неплохая.
👉Turn the Ship Around: про выстраивание команды, которая не будет зависеть от вас
👉No Rules Rules: про инженерную культуру Netflix с отсутствием бюрократии
👉Extreme Ownership: про то, что вы представляете свою компанию, и в любых проблемах, кроме вас, винить некого
👉High Output Management: как менеджеру выбирать точку приложения усилий
👉From Worst to First: как делать себя и команду более бизнес-ориентированными
👉The Making of a Manager: про то, как стать менеджером
👉The Manager's Path: про путь от инженера до VP
👉5 Dysfunctions of a Team: как превращать сломанные команды в рабочие
👉The Ride of a Lifetime: про длиннющий путь СЕО Disney
👉Dare to Lead: как лидеру не бояться быть открытым и уязвимым
Кстати, я в свое время тоже регулярно писал отчеты о прочитанных книгах, среди которых было и много менеджерских. Если хотите прям заполнить свой бэклог на максимум, то можете вот тут эти обзоры почитать!
Как писать статус-репорты
Когда вы отвечаете за какой-то важный и долгий проект, хорошим способом держать всех заинтересованных в курсе того, что происходит – писать регулярные сообщения о его прогрессе куда-то в видимый всем канал. Это даже не столько инструмент вовлечения стейкхолдеров, потому что с действительно важными разумнее общаться лично, а политический инструмент, который уменьшает вероятность того, что про ваш проект начнут разговаривать как про непрозрачный бесполезный долгострой.
Автор статьи рассказывает про набор советов, которыми он руководствуется при написании таких отчетов. Некоторые мне кажутся странненькими, но вот те, которые точно утащу себе:
👉Регулярность переоценена. Вместо того, чтобы публиковать отчет по строгому расписанию, лучше делать перерывы разной продолжительности – иногда неделю, иногда три. Так будет создаваться ощущение, что у вас действительно появилась новая и интересная информация, и вероятность прочтения отчета повышается.
👉Если для вас такой режим подходит, то попробуйте headline driven development. Заранее запланируйте, когда будете писать следующий отчет, и к этому моменту постарайтесь сделать что-то весомое в проекте.
👉Всегда любой отчет начинайте с TL;DR в одно предложение и с короткого напоминания целей проекта. Во-первых, список читателей мог поменяться. Во-вторых, это для вас ваш проект – центр мира, а остальные люди его могут не держать в голове. В-третьих, любые новости проще воспринимать в общем контексте.
👉Все любят приятные сюрпризы. Можете заранее прикинуть, что может быть таким сюрпризом, и целенаправленно подготовить его для включения в отчет.
👉Если в проекте произошли какие-то изменения, особенно те, которые противоречат опубликованным вами ранее отчетам, обязательно в явном виде про них напишите. Неявные изменения могут легко привести к поломанным ожиданиям, а те к политическим проблемам.
👉Держите в голове три основных вопроса, которые могут быть у вашей аудитории, и постарайтесь на них ответить.
👉Если в проекте случились какие-то проблемы или появились новые риски – о них тоже стоит ясно рассказать. При этом обязательно упомяните, что вы будете с ними делать.
Когда вы отвечаете за какой-то важный и долгий проект, хорошим способом держать всех заинтересованных в курсе того, что происходит – писать регулярные сообщения о его прогрессе куда-то в видимый всем канал. Это даже не столько инструмент вовлечения стейкхолдеров, потому что с действительно важными разумнее общаться лично, а политический инструмент, который уменьшает вероятность того, что про ваш проект начнут разговаривать как про непрозрачный бесполезный долгострой.
Автор статьи рассказывает про набор советов, которыми он руководствуется при написании таких отчетов. Некоторые мне кажутся странненькими, но вот те, которые точно утащу себе:
👉Регулярность переоценена. Вместо того, чтобы публиковать отчет по строгому расписанию, лучше делать перерывы разной продолжительности – иногда неделю, иногда три. Так будет создаваться ощущение, что у вас действительно появилась новая и интересная информация, и вероятность прочтения отчета повышается.
👉Если для вас такой режим подходит, то попробуйте headline driven development. Заранее запланируйте, когда будете писать следующий отчет, и к этому моменту постарайтесь сделать что-то весомое в проекте.
👉Всегда любой отчет начинайте с TL;DR в одно предложение и с короткого напоминания целей проекта. Во-первых, список читателей мог поменяться. Во-вторых, это для вас ваш проект – центр мира, а остальные люди его могут не держать в голове. В-третьих, любые новости проще воспринимать в общем контексте.
👉Все любят приятные сюрпризы. Можете заранее прикинуть, что может быть таким сюрпризом, и целенаправленно подготовить его для включения в отчет.
👉Если в проекте произошли какие-то изменения, особенно те, которые противоречат опубликованным вами ранее отчетам, обязательно в явном виде про них напишите. Неявные изменения могут легко привести к поломанным ожиданиям, а те к политическим проблемам.
👉Держите в голове три основных вопроса, которые могут быть у вашей аудитории, и постарайтесь на них ответить.
👉Если в проекте случились какие-то проблемы или появились новые риски – о них тоже стоит ясно рассказать. При этом обязательно упомяните, что вы будете с ними делать.
Как делать дата-проекты
Офигенный выпуск подкаста от ребят из Yandex Cloud про то, как вообще разрабатываются дата-проекты с руководителем соответствующей платформы из Альфы. Из интересных лично мне тем в выпуске поговорили про:
👉Метрики качества данных и их полноты
👉Определение ответственных за тот или иной кусок данных
👉Из каких кусочков состоит роль руководителя в платформе данных
👉Что там происходит на рынке специалистов по работе с данными
Офигенный выпуск подкаста от ребят из Yandex Cloud про то, как вообще разрабатываются дата-проекты с руководителем соответствующей платформы из Альфы. Из интересных лично мне тем в выпуске поговорили про:
👉Метрики качества данных и их полноты
👉Определение ответственных за тот или иной кусок данных
👉Из каких кусочков состоит роль руководителя в платформе данных
👉Что там происходит на рынке специалистов по работе с данными
Признаки того, что менеджер все продолбает
За последние шесть лет среднее количество прямых сотрудников у менеджера выросло почти в три раза. Это привело сразу к нескольким неприятным последствиям:
👉Менеджеры считают, что они отвечают за где-то на 50% больше вещей, чем им позволяет загруженность.
👉Все та же половина менеджеров сильно страдает от стресса и вымотанности, и не может уделять достаточно внимания персонализированной работе со своей командой.
👉У сотрудников таких менеджеров шансов стать топ-перформерами в два раза меньше, чем у других. А шанс того, что они уволятся, наоборот, в три раза выше.
В статье выделяют четыре признака того, что менеджер будет склонен к тому, чтобы зафейлить свою команду:
👉Менеджер не понимает своих сильных и слабых сторон. Это проявляется в оборонительной позиции при получении конструктивного фидбэка, отказе от делегирования, постоянном поиске поддержки от руководства в решениях, которые должны приниматься самостоятельно.
👉Команда не проявляет эмпатию к менеджеру. Это проявляется в их недоверии к его навыкам, нежеланию приспосабливаться к его стилю менеджмента и попытках переложить всю ответственность за результат на его плечи.
👉Сотрудники не получают видимой пользы от взаимодействий со своим менеджером.
👉Работа членов команды не выровнена с целями. Это проявляется в несоответствии амбициозности задач и уровня конкретных сотрудников, большом проценте времени, который уходит на неявные цели, и слишком частое изменение направления работы.
За последние шесть лет среднее количество прямых сотрудников у менеджера выросло почти в три раза. Это привело сразу к нескольким неприятным последствиям:
👉Менеджеры считают, что они отвечают за где-то на 50% больше вещей, чем им позволяет загруженность.
👉Все та же половина менеджеров сильно страдает от стресса и вымотанности, и не может уделять достаточно внимания персонализированной работе со своей командой.
👉У сотрудников таких менеджеров шансов стать топ-перформерами в два раза меньше, чем у других. А шанс того, что они уволятся, наоборот, в три раза выше.
В статье выделяют четыре признака того, что менеджер будет склонен к тому, чтобы зафейлить свою команду:
👉Менеджер не понимает своих сильных и слабых сторон. Это проявляется в оборонительной позиции при получении конструктивного фидбэка, отказе от делегирования, постоянном поиске поддержки от руководства в решениях, которые должны приниматься самостоятельно.
👉Команда не проявляет эмпатию к менеджеру. Это проявляется в их недоверии к его навыкам, нежеланию приспосабливаться к его стилю менеджмента и попытках переложить всю ответственность за результат на его плечи.
👉Сотрудники не получают видимой пользы от взаимодействий со своим менеджером.
👉Работа членов команды не выровнена с целями. Это проявляется в несоответствии амбициозности задач и уровня конкретных сотрудников, большом проценте времени, который уходит на неявные цели, и слишком частое изменение направления работы.
Что делать, когда сотрудник не воспринимает обратную связь
Представьте, что у вас есть сотрудник, на которого вам принесли обратную связь. Она довольно негативная. Люди жалуются, что ваш сотрудник пассивно-агрессивный и ведет себя снисходительно. Когда вы пытаетесь донести эту обратную связь, сотрудник отказывается ее признавать и встает в защитную позицию.
Вот, что советуют в таких ситуациях:
👉Вообще говоря, такой фидбэк выглядит довольно абстрактным. Перед тем, как приходить с ним к сотруднику, нужно собрать конкретные кейсы того, где и что пошло не так. Хороший менеджер закапываетсы в детали, а не просто передает жалобы.
👉Давая такой фидбэк, постарайтесь деперсонализировать его. Не называйте человека пассивно-агрессивным. Вместо этого лучше сказать что-то вроде "твои действия в этой ситуации были восприняты как пассивно-агрессивные".
👉Проявите эмпатию, и попробуйте покопать, какие конкретно эмоции в человеке вызывает эта обратная связь, и откуда именно эти эмоции берутся.
В комментах к треду на Реддите, конечно, какие-то очень кровожадные люди собрались. Каждый второй комментарий про то, что человеку надо написать PIP, а потом уволить. Как страшно жить то, а.
Представьте, что у вас есть сотрудник, на которого вам принесли обратную связь. Она довольно негативная. Люди жалуются, что ваш сотрудник пассивно-агрессивный и ведет себя снисходительно. Когда вы пытаетесь донести эту обратную связь, сотрудник отказывается ее признавать и встает в защитную позицию.
Вот, что советуют в таких ситуациях:
👉Вообще говоря, такой фидбэк выглядит довольно абстрактным. Перед тем, как приходить с ним к сотруднику, нужно собрать конкретные кейсы того, где и что пошло не так. Хороший менеджер закапываетсы в детали, а не просто передает жалобы.
👉Давая такой фидбэк, постарайтесь деперсонализировать его. Не называйте человека пассивно-агрессивным. Вместо этого лучше сказать что-то вроде "твои действия в этой ситуации были восприняты как пассивно-агрессивные".
👉Проявите эмпатию, и попробуйте покопать, какие конкретно эмоции в человеке вызывает эта обратная связь, и откуда именно эти эмоции берутся.
В комментах к треду на Реддите, конечно, какие-то очень кровожадные люди собрались. Каждый второй комментарий про то, что человеку надо написать PIP, а потом уволить. Как страшно жить то, а.
Новые выпуски тимлидских подкастов
Тут вышло сразу два интересных выпуска, которые не стоит пропускать:
👉"Бреслав и Ложечкин" про карьерный рост руководителя: в чем отличия ролей линейного руководителя и менеджера менеджеров, как подготовиться к переходу между ними, какие бывают типичные ошибки и ловушки.
👉"Три тимлида заходят в бар", новый подкаст от Насти Абрашитовой, Жени Антонова и Виктора Корейши. Первый выпуск – про сложные разговоры с подчиненными. Как сказать человеку, что от него попахивает, надо ли помогать бороться с зависимостями и как побеждать в кондиционерных войнах.
Тут вышло сразу два интересных выпуска, которые не стоит пропускать:
👉"Бреслав и Ложечкин" про карьерный рост руководителя: в чем отличия ролей линейного руководителя и менеджера менеджеров, как подготовиться к переходу между ними, какие бывают типичные ошибки и ловушки.
👉"Три тимлида заходят в бар", новый подкаст от Насти Абрашитовой, Жени Антонова и Виктора Корейши. Первый выпуск – про сложные разговоры с подчиненными. Как сказать человеку, что от него попахивает, надо ли помогать бороться с зависимостями и как побеждать в кондиционерных войнах.