Уточняйте свои просьбы
Не все сотрудники готовы переспрашивать менеджера о деталях, когда он просит с чем-то помочь. Как результат, чтобы ответить на какой-то вопрос своего менеджера или кого-то из топов, человек может потратить в несколько раз больше времени и сил, чем на самом деле необходимо. Например, на просьбу сообщить какие-то данные вместо быстрого ответа можно начать готовить красивую презентацию, которая будет вообще излишней.
Поэтому, если вы просите кого-то о помощи, будьте конкретными:
👉Уточните время, которое стоит потратить на вопрос. Например: "Если займет больше 15 минут, то забей".
👉Уточните приоритет относительно других задач. Например: "Не стоит откладывать другие важные задачи из-за этой. Но если за две недели не успеешь заняться, скажи мне, пожалуйста".
👉Уточните, просите ли вы рассказать о существующем знании или узнать что-то новое.
👉Уточните, как конкретно вы планируете использовать полученную информацию, чтобы было легче сопоставить результат и затрачиваемые усилия.
Не все сотрудники готовы переспрашивать менеджера о деталях, когда он просит с чем-то помочь. Как результат, чтобы ответить на какой-то вопрос своего менеджера или кого-то из топов, человек может потратить в несколько раз больше времени и сил, чем на самом деле необходимо. Например, на просьбу сообщить какие-то данные вместо быстрого ответа можно начать готовить красивую презентацию, которая будет вообще излишней.
Поэтому, если вы просите кого-то о помощи, будьте конкретными:
👉Уточните время, которое стоит потратить на вопрос. Например: "Если займет больше 15 минут, то забей".
👉Уточните приоритет относительно других задач. Например: "Не стоит откладывать другие важные задачи из-за этой. Но если за две недели не успеешь заняться, скажи мне, пожалуйста".
👉Уточните, просите ли вы рассказать о существующем знании или узнать что-то новое.
👉Уточните, как конкретно вы планируете использовать полученную информацию, чтобы было легче сопоставить результат и затрачиваемые усилия.
Staysaasy
Your Small Imprecise Ask Is a Big Waste of Their Time
When managers and leaders don't specify the expected time investment of an ask, the time that is invested is almost never what was intended.
Приемы по внедрению изменений в процессы
👉Если все в команде понимают решаемую проблему, и нужно выровняться по конкретным улучшениям, подойдет Improvement Kata. Это простой подход к проведению процессных экспериментов и оценке их влияния на результат. Основной плюс – удобная визуализация происходящего.
👉Если общего понимания проблемы нет, и ее сначала нужно продать, лучше всего начать с разговоров с отдельными людьми, и, только получив согласие от всех вовлеченных, делать презентацию на группу. Такой подход называется японским термином Nemawashi.
👉Если количество людей, которых надо убедить в изменении, слишком большое – лучше всего описывать его в виде документа. Как варианты: A3 problem solving или RFC.
👉Если все в команде понимают решаемую проблему, и нужно выровняться по конкретным улучшениям, подойдет Improvement Kata. Это простой подход к проведению процессных экспериментов и оценке их влияния на результат. Основной плюс – удобная визуализация происходящего.
👉Если общего понимания проблемы нет, и ее сначала нужно продать, лучше всего начать с разговоров с отдельными людьми, и, только получив согласие от всех вовлеченных, делать презентацию на группу. Такой подход называется японским термином Nemawashi.
👉Если количество людей, которых надо убедить в изменении, слишком большое – лучше всего описывать его в виде документа. Как варианты: A3 problem solving или RFC.
Medium
Engineering Leadership Tactics: Building Alignment
How to find buy-in as an Engineering Manager?
Оптимальное количество людей у менеджера
Количество людей, которое вы можете успешно менеджерить, зависит от кучи факторов: сеньорности менеджера и сотрудников, вашей собственной вовлеченности в разработку, да и вообще типа работы, за который отвечает команда.
В статье предлагается простая шкала, по которой можно определить оптимальное количество людей для конкретной ситуации.
Количество людей, которое вы можете успешно менеджерить, зависит от кучи факторов: сеньорности менеджера и сотрудников, вашей собственной вовлеченности в разработку, да и вообще типа работы, за который отвечает команда.
В статье предлагается простая шкала, по которой можно определить оптимальное количество людей для конкретной ситуации.
Когнитивные искажения в программировании
Серия из трех постов про частые когнитивные искажения, которые особенно заметны в работе программистов. Вот несколько примеров:
👉Феномен Баадера-Майнхоф: если вы думаете о чем-то, то начинаете замечать упоминания этого на каждом шагу.
👉Предпочтение нулевого риска: вместо выбора решения с наибольшей эффективностью в целом, вы выбираете то, которое сводит к нулю какой-то один из факторов.
👉Искажение восприятия сделанного выбора: вы ищете оправдания и рационализацию выбору, который уже успели сделать.
Серия из трех постов про частые когнитивные искажения, которые особенно заметны в работе программистов. Вот несколько примеров:
👉Феномен Баадера-Майнхоф: если вы думаете о чем-то, то начинаете замечать упоминания этого на каждом шагу.
👉Предпочтение нулевого риска: вместо выбора решения с наибольшей эффективностью в целом, вы выбираете то, которое сводит к нулю какой-то один из факторов.
👉Искажение восприятия сделанного выбора: вы ищете оправдания и рационализацию выбору, который уже успели сделать.
Хабр
Когнитивные искажения в программировании
Всем привет! Сегодня мы поговорим о такой интересной и забавной вещи, как когнитивные искажения . Что это? Зачем это? Как с этим бороться или, быть может, их даже можно использовать? Для начала...
Инструкция по быстрому бенчмаркингу зарплат в команде
Конец года – традиционное время пересмотра вилок зарплат. В статье разбирается, как с помощью нескольких скриптов и табличек быстро собрать актуальный срез зарплат, оценить его распределение по перцентилям и сравнить с зарплатами людей в вашей команде.
Конец года – традиционное время пересмотра вилок зарплат. В статье разбирается, как с помощью нескольких скриптов и табличек быстро собрать актуальный срез зарплат, оценить его распределение по перцентилям и сравнить с зарплатами людей в вашей команде.
State of Developer Ecosystem
Подъехали результаты большого ежегодного исследования разработчиков от JetBrains.
👉77% разработчиков используют ChatGPT, а 46% – CoPilot. Самый частый сценарий – задавать вопросы общего характера про программирование.
👉Выгорание за свою карьеру переживали 73% разработчиков.
👉Для 58% первым шагом к обучению программированию было формальное образование. На втором месте – книги, но уже только 10%.
👉Только у 63% разработчиков в проекте есть юнит тесты.
👉Среди языков программирования единственным растущим остался Rust.
👉Три самых высокооплачиваемых языка: Scala, Go, Kotlin.
👉Новые языки чаще всего учат просто ради интереса, для работы над личными проектами и чтобы следить за трендами.
Подъехали результаты большого ежегодного исследования разработчиков от JetBrains.
👉77% разработчиков используют ChatGPT, а 46% – CoPilot. Самый частый сценарий – задавать вопросы общего характера про программирование.
👉Выгорание за свою карьеру переживали 73% разработчиков.
👉Для 58% первым шагом к обучению программированию было формальное образование. На втором месте – книги, но уже только 10%.
👉Только у 63% разработчиков в проекте есть юнит тесты.
👉Среди языков программирования единственным растущим остался Rust.
👉Три самых высокооплачиваемых языка: Scala, Go, Kotlin.
👉Новые языки чаще всего учат просто ради интереса, для работы над личными проектами и чтобы следить за трендами.
JetBrains: Developer Tools for Professionals and Teams
The State of Developer Ecosystem in 2023 Infographic
Learn about the latest trends in tools, technologies, AI, and programming languages.
Прямо сейчас три команды Авито находятся в поиске опытных тимлидов разработки:
➡️ Тимлид разработки в команду инфраструктуры поиска
➡️ Тимлид разработки в команду внутренних проектов (Legal Tech)
➡️ Тимлид разработки в команду Support Systems
Здесь вы сможете реализовать свои идеи в проекте с многомиллионной аудиторией и талантливой командой.
Зарплата достойная (обсуждается на собеседовании), а ещё:
– мощное железо, дополнительные мониторы и всё, что нужно для продуктивной работы;
– личный бюджет на обучение, который можно тратить на книги, курсы и конференции;
– ДМС со стоматологией с первого дня;
– прозрачная система премий;
– удалёнка и крутой офис в 2-х минутах от метро «Белорусская»;
– терапевт и массажист, которые принимают в офисе.
Откликайтесь на вакансии и присоединяйтесь к одной из команд!
➡️ Тимлид разработки в команду инфраструктуры поиска
➡️ Тимлид разработки в команду внутренних проектов (Legal Tech)
➡️ Тимлид разработки в команду Support Systems
Здесь вы сможете реализовать свои идеи в проекте с многомиллионной аудиторией и талантливой командой.
Зарплата достойная (обсуждается на собеседовании), а ещё:
– мощное железо, дополнительные мониторы и всё, что нужно для продуктивной работы;
– личный бюджет на обучение, который можно тратить на книги, курсы и конференции;
– ДМС со стоматологией с первого дня;
– прозрачная система премий;
– удалёнка и крутой офис в 2-х минутах от метро «Белорусская»;
– терапевт и массажист, которые принимают в офисе.
Откликайтесь на вакансии и присоединяйтесь к одной из команд!
Как строить доверие
Никаких секретных способов быстро заслужить доверие команды нет. Нужно быть хорошим менеджером, на которого можно положиться, и со временем доверие придет. При этом есть некоторые гигиенические вещи, без которых доверия точно не заслужить:
👉Действуйте одинаково в похожих ситуациях. Менеджер, реакцию которого невозможно заранее предсказать, точно не создаст фундамента для доверительного общения.
👉Ясно и открыто рассказывайте про происходящее в компании и любые изменения, которые могут затронуть людей. Если что-то рассказывать нельзя, то не уклоняйтесь от ответов, а ясно объясняйте, почему информацией сейчас делиться нельзя.
👉Будьте надежными, и отвечайте за свои слова.
👉Как можно реже прибегайте к режиму авторитарного управления.
👉Давайте как можно больше фидбэка, причем с уклоном в позитивный.
👉Открыто признавайте заслуги других, а провалы берите на себя.
👉Делегируйте людям в команде не только скучную для вас работу, но и те задачи, которые вам самому кажутся интересными.
Никаких секретных способов быстро заслужить доверие команды нет. Нужно быть хорошим менеджером, на которого можно положиться, и со временем доверие придет. При этом есть некоторые гигиенические вещи, без которых доверия точно не заслужить:
👉Действуйте одинаково в похожих ситуациях. Менеджер, реакцию которого невозможно заранее предсказать, точно не создаст фундамента для доверительного общения.
👉Ясно и открыто рассказывайте про происходящее в компании и любые изменения, которые могут затронуть людей. Если что-то рассказывать нельзя, то не уклоняйтесь от ответов, а ясно объясняйте, почему информацией сейчас делиться нельзя.
👉Будьте надежными, и отвечайте за свои слова.
👉Как можно реже прибегайте к режиму авторитарного управления.
👉Давайте как можно больше фидбэка, причем с уклоном в позитивный.
👉Открыто признавайте заслуги других, а провалы берите на себя.
👉Делегируйте людям в команде не только скучную для вас работу, но и те задачи, которые вам самому кажутся интересными.
jacobian.org
How to Build Trust - Jacob Kaplan-Moss
What are the major management behaviors that can help build trust? Management books often cover the importance of trust, but abstractly. There’s precious little writing about the nuts and bolts, the day-to-day tasks of trust-building. That’s the gap I’d like…
Опрос про Роадмап Тимлида
Я тут недавно посчитал, сколько лет прошло с момента первого запуска Роадмапа Тимлида. Оказывается, целых пять! Изначально я вписался в этот проект с очень корыстной целью – собрать базу знаний, с помощью которой смогу помогать развитию тимлидов, которыми руковожу сам. Так и получилось, за прошедшую пятилетку Роадмап помог мне бесчетное количество раз.
Если вы тоже пользовались Роадмапом для решения каких-то своих задач, то, пожалуйста, пройдите наш небольшой опрос. Нам со Стасом будет очень приятно узнать, каким компаниям мы смогли помочь, а заодно набрать идей по дальнейшему улучшению проекта.
👉Ссылка на опрос
Я тут недавно посчитал, сколько лет прошло с момента первого запуска Роадмапа Тимлида. Оказывается, целых пять! Изначально я вписался в этот проект с очень корыстной целью – собрать базу знаний, с помощью которой смогу помогать развитию тимлидов, которыми руковожу сам. Так и получилось, за прошедшую пятилетку Роадмап помог мне бесчетное количество раз.
Если вы тоже пользовались Роадмапом для решения каких-то своих задач, то, пожалуйста, пройдите наш небольшой опрос. Нам со Стасом будет очень приятно узнать, каким компаниям мы смогли помочь, а заодно набрать идей по дальнейшему улучшению проекта.
👉Ссылка на опрос
Как избегать накопления техдолга
У причин появления в проекте большого количества техдолга всегда есть два наивных объяснения: неосознанные разработчики или глупый и жадный менеджмент. Но в подавляющем большинстве случаев настоящие причины не настолько полярны.
Типичная история – менеджер просит команду побыстрее сделать фичу, на что тимлид соглашается, не озвучивая при этом риски, либо считая их очевидными, либо просто не желая быть негативным. В этой ситуации, конечно, виноваты оба участника: и менеджер не проговорил, какая вообще ценность от задачи, и в чем причины спешки, и тимлид не задал вопросов.
Чтобы избежать такого паттерна накопления техдолга, попробуйте следующие шаги:
👉Вместо прямых указаний или просьб сделать фичу задавать вопросы вида "Можем ли мы сделать Х за время У?". Это дает команде возможность сделать выбор вместо того, чтоьы пойти по простому пути и следовать указанию.
👉Еще лучше использовать открытый вопрос. Например, "Что нам придется убрать из скоупа, чтобы сделать Х?" или "Как вы оцениваете риски фичи Х по 10-балльной шкале?"
👉Еще лучше – делать команду достаточно автономной и передавать ей ответственность за результат, чтобы продакту достаточно было рассказать о фактах и дать команде самой решить, что самое ценное для пользователя они могут сделать.
👉Поощряйте привычки команды, которые заставляют ее регулярно задумываться о стоимости и смысле изменений, или уделять внимание инженерной культуре. Например, учитывать в приоритизации cost of delay.
👉Поощряйте не только релизы фичей, но и невидимую работу по решению техдолга и улучшению процессов.
У причин появления в проекте большого количества техдолга всегда есть два наивных объяснения: неосознанные разработчики или глупый и жадный менеджмент. Но в подавляющем большинстве случаев настоящие причины не настолько полярны.
Типичная история – менеджер просит команду побыстрее сделать фичу, на что тимлид соглашается, не озвучивая при этом риски, либо считая их очевидными, либо просто не желая быть негативным. В этой ситуации, конечно, виноваты оба участника: и менеджер не проговорил, какая вообще ценность от задачи, и в чем причины спешки, и тимлид не задал вопросов.
Чтобы избежать такого паттерна накопления техдолга, попробуйте следующие шаги:
👉Вместо прямых указаний или просьб сделать фичу задавать вопросы вида "Можем ли мы сделать Х за время У?". Это дает команде возможность сделать выбор вместо того, чтоьы пойти по простому пути и следовать указанию.
👉Еще лучше использовать открытый вопрос. Например, "Что нам придется убрать из скоупа, чтобы сделать Х?" или "Как вы оцениваете риски фичи Х по 10-балльной шкале?"
👉Еще лучше – делать команду достаточно автономной и передавать ей ответственность за результат, чтобы продакту достаточно было рассказать о фактах и дать команде самой решить, что самое ценное для пользователя они могут сделать.
👉Поощряйте привычки команды, которые заставляют ее регулярно задумываться о стоимости и смысле изменений, или уделять внимание инженерной культуре. Например, учитывать в приоритизации cost of delay.
👉Поощряйте не только релизы фичей, но и невидимую работу по решению техдолга и улучшению процессов.
Benji's Blog
Supporting Sustainability - Benji's Blog
what about from the management side? I often hear from engineering and product managers that they're unaware, or learn too late, that folks were accumulating debt. It becomes visible when teams are no longer able to achieve goals.