Голосуем в исследовании тимлидов
Большой опрос руководителей разработки закрывается уже вот прямо на днях. Если вы еще не успели его пройти, самое время! А пока несколько фактов, которые видны уже по сырым данным:
👉Тимлиды постепенно уходят с полной удаленки, процент снизился с 44% до 35%. Основные причины возврата в офис – желание сменить обстановку, проведение встреч с командой и возможность быстрого решения вопросов.
👉Самым сложным в работе за последний год был слишком большой завал разными задачами и чересчур масштабные цели.
👉Треть тимлидов не получает поддержки от своих компаний в вопросах обучения – нет внутренних курсов, не оплачиваются внешние.
🔗Опрос можно пройти вот тут, результатами поделюсь в канале
Большой опрос руководителей разработки закрывается уже вот прямо на днях. Если вы еще не успели его пройти, самое время! А пока несколько фактов, которые видны уже по сырым данным:
👉Тимлиды постепенно уходят с полной удаленки, процент снизился с 44% до 35%. Основные причины возврата в офис – желание сменить обстановку, проведение встреч с командой и возможность быстрого решения вопросов.
👉Самым сложным в работе за последний год был слишком большой завал разными задачами и чересчур масштабные цели.
👉Треть тимлидов не получает поддержки от своих компаний в вопросах обучения – нет внутренних курсов, не оплачиваются внешние.
🔗Опрос можно пройти вот тут, результатами поделюсь в канале
survey.alchemer.eu
Исследование рынка руководителей разработки, 2024
Исследование рынка руководителей разработки, 2024.
Подкасты про переговоры
Навык переговоров, наверное, один из трех самых важных софт-скиллов для тимлида. Уговорить соседнюю команду о приоритизировать важную вам штуку, убедить члена команды не отчаиваться из-за работы, ушедшей в стол, договориться со своим менеджером о повышении зарплаты – переговоры приходится применять практически каждый день.
Держите два наших недавних подкаста, которые помогут вам узнать и попробовать новые тактики:
👉Выпуск Подлодки про зарплатные переговоры с Ильей Синельниковым
👉Выпуск Бреслава и Ложечкина про сложные переговоры со всякими топ-менеджерами
Навык переговоров, наверное, один из трех самых важных софт-скиллов для тимлида. Уговорить соседнюю команду о приоритизировать важную вам штуку, убедить члена команды не отчаиваться из-за работы, ушедшей в стол, договориться со своим менеджером о повышении зарплаты – переговоры приходится применять практически каждый день.
Держите два наших недавних подкаста, которые помогут вам узнать и попробовать новые тактики:
👉Выпуск Подлодки про зарплатные переговоры с Ильей Синельниковым
👉Выпуск Бреслава и Ложечкина про сложные переговоры со всякими топ-менеджерами
YouTube
Учимся договариваться о деньгах | Офферы, Зарплаты, Повышение | Podlodka Podcast #383
На протяжении всей карьеры нам постоянно приходится вести переговоры о деньгах — при принятии оффера, обсуждении профессионального роста со своим тимлидом, или назначении стоимости за фриланс и консалтинг услуги. Переговоры — это искусство; понимая их суть…
Pioneers – Settlers – Town Planners
Все модели в какой-то момент начинают врать, потому что они по определению представляют собой только карту реальности. Но при этом некоторые модели бывают полезны. Та, что описывается в статье, на мой взгляд как раз одна из них. В чем суть – и отдельных людей, и команды можно условно разбить на три категории, и использовать это разделение, чтобы правильнее распределять их между работой разного типа.
👉Pioneers. Инноваторы, которые любят работать в условиях неопределенности, пилить кучу прототипов, исследовать новые идеи.
👉Settlers. Практики, которые умеют брать прототипы и продуктизировать их, доводя до пользователей в надежном виде.
👉Town Planners. Те, кто умеет оптимизировать уже существующие рабочие системы, делая их более надежными, стабильными и дешевыми.
Все модели в какой-то момент начинают врать, потому что они по определению представляют собой только карту реальности. Но при этом некоторые модели бывают полезны. Та, что описывается в статье, на мой взгляд как раз одна из них. В чем суть – и отдельных людей, и команды можно условно разбить на три категории, и использовать это разделение, чтобы правильнее распределять их между работой разного типа.
👉Pioneers. Инноваторы, которые любят работать в условиях неопределенности, пилить кучу прототипов, исследовать новые идеи.
👉Settlers. Практики, которые умеют брать прототипы и продуктизировать их, доводя до пользователей в надежном виде.
👉Town Planners. Те, кто умеет оптимизировать уже существующие рабочие системы, делая их более надежными, стабильными и дешевыми.
Claus Höfele
Explorers, Villagers, and Town Planners ✍🏻 Drawn to Leadership
Startups require different skills (aptitude) and mindsets (attitude) than corporations. Simon Wardley identified three essential mindsets necessary for success: Explorers, Villagers, and Town Planners (formerly called Pioneers, Settlers, and Town Planners).…
Три важных софт-скилла при найме
👉Кандидату не пофиг на работу. На интервью это можно проверить следующим образом:
- Поговорить про проблемы на прошлом рабочем месте и то, как они решались. Тут важно смотреть на проактивную позицию кандидата и то, как он сам участвовал в решении того, что его беспокоило.
- Поспрашивать, как его фичи влияли на продукт. Скорее всего, если ему было не пофиг на то, что он делает, он понимает, какую пользу принес.
- Узнайте, как он влиял на бэклог команды. Проактивные люди и фичи сами предлагают, и техдолгом бэклог наполняют.
👉Самонаводимость – кандидат может сам решать задачи с высокой степенью неопределенности, доуточняя все детали и подключая помощь, где необходимо. Как проверить на интервью:
- Спросить про задачи с самыми туманными требованиями
- Узнать, как часто взаимодействовал с людьми за пределами команды
- Попросить рассказать про самую продолжительную задачу и понять, как он контролировал ее
👉Внутренний локус контроля – отсутствие тенденции сваливать вину за проблемы на других людей и обстоятельства. Как проверить:
- Спросить про самый большой провал и то, что к нему привело
- Поговорить про выстраивание отношений с другими людьми и кейсы, где это не получилось
👉Кандидату не пофиг на работу. На интервью это можно проверить следующим образом:
- Поговорить про проблемы на прошлом рабочем месте и то, как они решались. Тут важно смотреть на проактивную позицию кандидата и то, как он сам участвовал в решении того, что его беспокоило.
- Поспрашивать, как его фичи влияли на продукт. Скорее всего, если ему было не пофиг на то, что он делает, он понимает, какую пользу принес.
- Узнайте, как он влиял на бэклог команды. Проактивные люди и фичи сами предлагают, и техдолгом бэклог наполняют.
👉Самонаводимость – кандидат может сам решать задачи с высокой степенью неопределенности, доуточняя все детали и подключая помощь, где необходимо. Как проверить на интервью:
- Спросить про задачи с самыми туманными требованиями
- Узнать, как часто взаимодействовал с людьми за пределами команды
- Попросить рассказать про самую продолжительную задачу и понять, как он контролировал ее
👉Внутренний локус контроля – отсутствие тенденции сваливать вину за проблемы на других людей и обстоятельства. Как проверить:
- Спросить про самый большой провал и то, что к нему привело
- Поговорить про выстраивание отношений с другими людьми и кейсы, где это не получилось
Хабр
Как увидеть три важнейших софт-скилла, чтобы нанять лучшего инженера
Чтобы нанять хорошего инженера, недостаточно проверить только его харды. В статье я расскажу о трех софт-скиллах, которые я обязательно проверяю у каждого кандидата. Если вы начнете проверять эти три...
Про скип-левел встречи
Небольшое напоминание про то, что в ваших интересах организовать как скип-левел встречи вверх, с менеджером вашего менеджера, так и вниз, с подчиненными ваших подчиненных.
Зачем нужны скип-левелы вверх:
👉Можете получить ценный разговор про стратегию
👉Получите представление о том, как воспринимается ваша работа
👉Вы можете сравнить ответы на ваши вопросы вашего прямого менеджера и менеджера над ним
Зачем нужны скип-левелы вниз:
👉Вы можете заметить начинающие таланты
👉Вы можете сравнить то, что говорит про климат в команде менеджер, и то, что считают сами члены команды
А самая главная ценность в таких встречах – возможность начать строить доверительные отношения не только с теми людьми, с кем вы постоянно работаете.
Небольшое напоминание про то, что в ваших интересах организовать как скип-левел встречи вверх, с менеджером вашего менеджера, так и вниз, с подчиненными ваших подчиненных.
Зачем нужны скип-левелы вверх:
👉Можете получить ценный разговор про стратегию
👉Получите представление о том, как воспринимается ваша работа
👉Вы можете сравнить ответы на ваши вопросы вашего прямого менеджера и менеджера над ним
Зачем нужны скип-левелы вниз:
👉Вы можете заметить начинающие таланты
👉Вы можете сравнить то, что говорит про климат в команде менеджер, и то, что считают сами члены команды
А самая главная ценность в таких встречах – возможность начать строить доверительные отношения не только с теми людьми, с кем вы постоянно работаете.
Threadreaderapp
Thread by @mipsytipsy on Thread Reader App
@mipsytipsy: 🌼Skip levels 🌸Are an 🌻Organizational 🌷Necessity If you don't have a 1x1 with your boss's boss, and/or each of your direct reports' reports, at least 2-4 times a year...why not? Skip levels are e2e healt...…
У Виталика в канале отличная подборка исследований про social loafing, эффект, при котором в больших группах люди прикладывают меньше усилий к своей работе. Берите себе на вооружение, это очень полезное знание, чтобы останавливать неразумных менеджеров, пытающихся сделать странное.
Forwarded from Sharovatov (Vitaly Sharovatov)
Кратко про social loafing (эффект, когда в группе люди прикладывают меньше сил к труду по сравнению с тем же трудом в одиночку):
основными причинами этого эффекта являются:
- излишне крупные группы
- ощущение несправедливости, возникающее от того, что люди видят, что кто-то “мало усилий прикладывает”
- “неинтересные задачи”
это что ж получается такое удивительное — людям внезапно становится скучно и неинтересно если увеличивать команды до дурных размеров а потом реальные проблемы по-барски эдак декомпозировать и раскидывать между людьми (продакт умнее пусть придумывает чо делать а тимлид умнее пусть и придумывает как делать)
кто бы мог подумать?
Рефы:
- https://journals.sagepub.com/doi/10.1177/0146167284101011
- https://psycnet.apa.org/doiLanding?doi=10.1037/0022-3514.37.6.822
- https://www.researchgate.net/publication/228608182_Social_Loafing_A_Field_Investigation
- https://journals.sagepub.com/doi/10.1177/0022002183014003009
- https://journals.sagepub.com/doi/10.1177/001872679504800603
основными причинами этого эффекта являются:
- излишне крупные группы
- ощущение несправедливости, возникающее от того, что люди видят, что кто-то “мало усилий прикладывает”
- “неинтересные задачи”
это что ж получается такое удивительное — людям внезапно становится скучно и неинтересно если увеличивать команды до дурных размеров а потом реальные проблемы по-барски эдак декомпозировать и раскидывать между людьми (продакт умнее пусть придумывает чо делать а тимлид умнее пусть и придумывает как делать)
кто бы мог подумать?
Рефы:
- https://journals.sagepub.com/doi/10.1177/0146167284101011
- https://psycnet.apa.org/doiLanding?doi=10.1037/0022-3514.37.6.822
- https://www.researchgate.net/publication/228608182_Social_Loafing_A_Field_Investigation
- https://journals.sagepub.com/doi/10.1177/0022002183014003009
- https://journals.sagepub.com/doi/10.1177/001872679504800603
Wikipedia
Social loafing
the phenomenon of a person exerting less effort to achieve a goal when they work in a group than when working alone
Please open Telegram to view this post
VIEW IN TELEGRAM
Еще про перегрузку менеджеров
В продолжение вчерашнего поста даввйте поговорим о том, а откуда конкретно берется эта менеджерская загруженность:
👉Растущее количество "работы вокруг работы" – бесконечные митинги, необходимость приспасабливаться к новым процессам и меняющейся оргструктуре.
👉Помимо растущей административки, от менеджеров требуют глубокого погружения в детали. Само по себе это не плохо, но создает огромную дополнительную нагрузку.
👉Из-за страха сокращений и проблемного поиска работы никто не обозначает предыдущие пункты как проблемы, и все просто молча принимают правила игры.
👉Разумная и значимая перестройка процессов или другая оптимизация работы требует времени, а его как раз нет из-за всего предыдущего. Освободить его, уменьшив количество WIP, не получается из-за все того же страха быть сокращенным.
👉Резкие изменения на рынке происходят все чаще, из-за этого растет количество той самой административки, увеличивается количество фокусов, и во все большее количество контекстов нужно быть глубоко погруженным.
👉Это все накладывается на и так тяжелые последние годы – сначала пандемия, потом война.
В посте, помимо разбора этих проблем, есть и советы, что делать. Никаких волшебных таблеток, конечно, нет. Нужно переставать заниматься процессами, которые не приносят пользы, уменьшать WIP, говорить вслух о проблемах организации, и явно определять приоритеты работы.
В продолжение вчерашнего поста даввйте поговорим о том, а откуда конкретно берется эта менеджерская загруженность:
👉Растущее количество "работы вокруг работы" – бесконечные митинги, необходимость приспасабливаться к новым процессам и меняющейся оргструктуре.
👉Помимо растущей административки, от менеджеров требуют глубокого погружения в детали. Само по себе это не плохо, но создает огромную дополнительную нагрузку.
👉Из-за страха сокращений и проблемного поиска работы никто не обозначает предыдущие пункты как проблемы, и все просто молча принимают правила игры.
👉Разумная и значимая перестройка процессов или другая оптимизация работы требует времени, а его как раз нет из-за всего предыдущего. Освободить его, уменьшив количество WIP, не получается из-за все того же страха быть сокращенным.
👉Резкие изменения на рынке происходят все чаще, из-за этого растет количество той самой административки, увеличивается количество фокусов, и во все большее количество контекстов нужно быть глубоко погруженным.
👉Это все накладывается на и так тяжелые последние годы – сначала пандемия, потом война.
В посте, помимо разбора этих проблем, есть и советы, что делать. Никаких волшебных таблеток, конечно, нет. Нужно переставать заниматься процессами, которые не приносят пользы, уменьшать WIP, говорить вслух о проблемах организации, и явно определять приоритеты работы.
The Beautiful Mess
TBM 303: The Current Tech Puzzle (With Diverse Takes)
Managers are bumping up against many dependencies, duplicative administrative tasks, an onslaught of mind-numbing meetings, constant calls to detail tradeoffs, shifting strategies, and a call to focus more on performance management. To quote a manager friend:…
20% на техдолг не работают
👉Вместо единого бэклога появляются два – продуктовый и технический. И в технический постепенно начинает попадать все, что не фичи – решение багов, автоматизация рутины, обновления библиотек и решение проблем безопасности. А тот факт, что эти задачи приносят ценность пользователям, начинает игнорироваться.
👉Перенос задач в технический бэклог без определения их business value приводит к тому, что они воспринимаются менеджментом как низкоприоритетные, и легко могут вытесняться важными продуктовыми задачами.
👉Так как время выделяется не на решение конкретной проблемы, а на широкий зонтик задач, очень легко размыть фокус, броситься одновременно исправлять много вещей, и не получить значимого прогресса нигде.
👉Как только организация выделяет под "технические задачи" 20% времени, становится очень легко начать их откладывать. Если раньше вы одновременно с реализацией какой-то фичи могли поправить связанную с ней техническую проблему, то теперь гораздо чаще будете встречать сопротивление этому со словами "сделаете в выделенные 20% времени".
👉20% времени – на самом деле не очень много. Если вашей системе требуется действительно серьезная переработка, она может растянуться на годы.
👉Вместо единого бэклога появляются два – продуктовый и технический. И в технический постепенно начинает попадать все, что не фичи – решение багов, автоматизация рутины, обновления библиотек и решение проблем безопасности. А тот факт, что эти задачи приносят ценность пользователям, начинает игнорироваться.
👉Перенос задач в технический бэклог без определения их business value приводит к тому, что они воспринимаются менеджментом как низкоприоритетные, и легко могут вытесняться важными продуктовыми задачами.
👉Так как время выделяется не на решение конкретной проблемы, а на широкий зонтик задач, очень легко размыть фокус, броситься одновременно исправлять много вещей, и не получить значимого прогресса нигде.
👉Как только организация выделяет под "технические задачи" 20% времени, становится очень легко начать их откладывать. Если раньше вы одновременно с реализацией какой-то фичи могли поправить связанную с ней техническую проблему, то теперь гораздо чаще будете встречать сопротивление этому со словами "сделаете в выделенные 20% времени".
👉20% времени – на самом деле не очень много. Если вашей системе требуется действительно серьезная переработка, она может растянуться на годы.
Substack
"20% for tech debt" doesn't work
5 traps will stop your technical vision from happening
Подборка вопросов для референс чека
Сбор рекомендаций на кандидата при найме – потенциально самый ценный этап всего процесса. Результаты прохождения собеседования, все-таки, довольно синтетические, и имеют мало общего с тем, как кандидат будет вести себя в реальности. А вот конкретные примеры от тех, кто с ним работал – другое дело.
По ссылке – хорошая подборка вопросов, которые стоит задавать при сборе рекомендаций. Вот некоторые из них:
👉Были ли какие-то области, в которых вас удивило, что кандидат был не так хорош, как вы ожидали? А где он наоборот был выше ожиданий?
👉Есть ли разница в том, как кандидата опишут его руководитель, коллега и подчиненный? В чем она?
👉Что из того, что кандидат делал, часто оставалось незамеченным или недооцененным?
👉Расскажите про случай, когда кандидат поменял свое мнение о чем-то. С какого на какое мнение он поменял, что это вызвало?
Расскажите в комментариях, какие вопросы обычно задаете вы!
Сбор рекомендаций на кандидата при найме – потенциально самый ценный этап всего процесса. Результаты прохождения собеседования, все-таки, довольно синтетические, и имеют мало общего с тем, как кандидат будет вести себя в реальности. А вот конкретные примеры от тех, кто с ним работал – другое дело.
По ссылке – хорошая подборка вопросов, которые стоит задавать при сборе рекомендаций. Вот некоторые из них:
👉Были ли какие-то области, в которых вас удивило, что кандидат был не так хорош, как вы ожидали? А где он наоборот был выше ожиданий?
👉Есть ли разница в том, как кандидата опишут его руководитель, коллега и подчиненный? В чем она?
👉Что из того, что кандидат делал, часто оставалось незамеченным или недооцененным?
👉Расскажите про случай, когда кандидат поменял свое мнение о чем-то. С какого на какое мнение он поменял, что это вызвало?
Расскажите в комментариях, какие вопросы обычно задаете вы!
Threadreaderapp
Thread by @jasonfried on Thread Reader App
@jasonfried: Questions I ask when checking references When hiring for key positions, speaking with references is important. For us, it's typically the last step in the hiring process. A phase for the final-finalists...…
Инструкция по организации онбординга
Я уже как-то делился подкастом про онбординг, который мы записывали с Женей Антоновым. Теперь его классную инструкцию про то, как максимально сгладить первые рабочие недели новичка, можно прочитать и в виде статьи. Рекомендую!
Для затравки, некоторые тезисы:
👉Онбординг должен погружать новичка не только в процессы и технологии, но и в социум – совместные обеды, чаты с мемами, традиции.
👉Пишите две инструкции – для новичка, в которой перечислено все, что ему надо сделать в первые дни, и для себя, как тимлида – чтобы ваш замыленный глаз не пропустил каких-то важных шагов.
👉Попросите успешно заонбордившегося сотрудника дополнить инструкцию. Так она будет оставаться актуальной и покрывать все эдж кейсы.
👉Четкие ожидания, проговоренные с сотрудником на старте его работы, и на которые у него есть возможность повлиять – залог успеха испытательного срока.
Я уже как-то делился подкастом про онбординг, который мы записывали с Женей Антоновым. Теперь его классную инструкцию про то, как максимально сгладить первые рабочие недели новичка, можно прочитать и в виде статьи. Рекомендую!
Для затравки, некоторые тезисы:
👉Онбординг должен погружать новичка не только в процессы и технологии, но и в социум – совместные обеды, чаты с мемами, традиции.
👉Пишите две инструкции – для новичка, в которой перечислено все, что ему надо сделать в первые дни, и для себя, как тимлида – чтобы ваш замыленный глаз не пропустил каких-то важных шагов.
👉Попросите успешно заонбордившегося сотрудника дополнить инструкцию. Так она будет оставаться актуальной и покрывать все эдж кейсы.
👉Четкие ожидания, проговоренные с сотрудником на старте его работы, и на которые у него есть возможность повлиять – залог успеха испытательного срока.
Хабр
Система онбординга комфорт-класса
Привет! Я Евгений Антонов, ведущий технический менеджер проектов в Yandex Infrastructure. В ИТ‑индустрии за 17 лет успел поадминистрировать, поразрабатывать и поруководить. Работал...
Почему советы часто не работают
Нет ничего более раздражающего, чем люди, раздающие направо и налево советы про то, как сделать что-то лучше, удивляются, когда их советам не следуют, говорят что-то вроде "я всегда прав" или "ну я же говорил", и считают окружающих недальновидными дурачками. Как и в других случаях, когда в дело вступает фундаментальная ошибка атрибуции, полезно понимать, что может на самом двигать другими людьми, поведение которых вас не устраивает:
👉Чтобы понять ваш совет, надо обладать вашим жизненным опытом, без него он неполный.
👉Люди могут просто не понимать ваш совет, особенно если он идет вразрез с их оценкой реальности.
👉В целом они согласны с вашим советом, но по какой-то причине в глубине души им кажется, что он не сработает. Например, потому что требует слишком много нестандартных усилий, а результат не гарантирован.
👉То, что сработало для вас, вообще не обязательно сработает и для других.
👉Людям может не хватать понимания контекста, чтобы оценить и принять совет.
👉У проблемы, на решение которой направлен ваш совет, и у того, почему ему не следуют, может быть один руткоз.
Нет ничего более раздражающего, чем люди, раздающие направо и налево советы про то, как сделать что-то лучше, удивляются, когда их советам не следуют, говорят что-то вроде "я всегда прав" или "ну я же говорил", и считают окружающих недальновидными дурачками. Как и в других случаях, когда в дело вступает фундаментальная ошибка атрибуции, полезно понимать, что может на самом двигать другими людьми, поведение которых вас не устраивает:
👉Чтобы понять ваш совет, надо обладать вашим жизненным опытом, без него он неполный.
👉Люди могут просто не понимать ваш совет, особенно если он идет вразрез с их оценкой реальности.
👉В целом они согласны с вашим советом, но по какой-то причине в глубине души им кажется, что он не сработает. Например, потому что требует слишком много нестандартных усилий, а результат не гарантирован.
👉То, что сработало для вас, вообще не обязательно сработает и для других.
👉Людям может не хватать понимания контекста, чтобы оценить и принять совет.
👉У проблемы, на решение которой направлен ваш совет, и у того, почему ему не следуют, может быть один руткоз.
Substack
Why doesn't advice work?
(or at least work better)
Как работать с кандидатами после того, как они приняли оффер
По-хорошему найм не заканчивается в тот момент, когда кандидат ответил радостным "да" на ваше письмо про зарплату, печеньки и дружный коллектив. В вашем интересе сделать так, чтобы человек вышел на работу, уже подняв какой-то минимальный контекст, и будучи заряженным новыми идеями. Я довольно часто после успешного найма отправляю новичку список релевантных статей и видео, которые позволят ему получше узнать продукт, над которым придется работать, и разобраться с принятыми в команде процессами. В статье советуют еще несколько неплохих практик:
👉Попросить людей, принимавших участие в интервью, поздравить кандидата с оффером, ну и в целом написать что-то позитивное. Почта, LinkedIn, все работает.
👉Созвониться с новичком, либо написать ему письмо про то, что сейчас происходит в команде – цели, планы, основные челленджи. Ваша цель тут не загрузить его работой до того, как он начал получать зарплату, а скорее заинтересовать будущими задачами, дать ему время покрутить какие-то идеи в голове, и уже заранее почувствовать себя частью чего-то нового и классного.
👉Если у вас планируются какие-то тимбилдинги, то подумайте над тем, чтобы добавить туда и таких новичков.
По-хорошему найм не заканчивается в тот момент, когда кандидат ответил радостным "да" на ваше письмо про зарплату, печеньки и дружный коллектив. В вашем интересе сделать так, чтобы человек вышел на работу, уже подняв какой-то минимальный контекст, и будучи заряженным новыми идеями. Я довольно часто после успешного найма отправляю новичку список релевантных статей и видео, которые позволят ему получше узнать продукт, над которым придется работать, и разобраться с принятыми в команде процессами. В статье советуют еще несколько неплохих практик:
👉Попросить людей, принимавших участие в интервью, поздравить кандидата с оффером, ну и в целом написать что-то позитивное. Почта, LinkedIn, все работает.
👉Созвониться с новичком, либо написать ему письмо про то, что сейчас происходит в команде – цели, планы, основные челленджи. Ваша цель тут не загрузить его работой до того, как он начал получать зарплату, а скорее заинтересовать будущими задачами, дать ему время покрутить какие-то идеи в голове, и уже заранее почувствовать себя частью чего-то нового и классного.
👉Если у вас планируются какие-то тимбилдинги, то подумайте над тем, чтобы добавить туда и таких новичков.
David Gomes
Keeping Candidates Engaged After the Offer Has Been Accepted
This is the seventh blog post of a series titled Hiring for Engineering Managers. I plan to write a few posts on this topic since I'm incredibly passionate about how to hire for, and grow software engineering teams.
Congratulations! The candidate has signed…
Congratulations! The candidate has signed…
Что происходит с рынком джунов в России
Я не очень сильно доверяю зарплатной статистике Хабра, но картина все равно интересная:
👉2024 год не стал хуже в сравнении с 2023. Конкуренция за вакансии стажеров и джунов осталась на том же уровне, где-то 80 откликов на каждую.
👉Больше всего джуновых вакансий среди бэкендеров. За ними идут, понятное дело, фронтендеры, и, удивительно, системные аналитики. Близких моему сердцу мобильных разработчиков нет даже в топ-10.
👉Зарплаты за год чуть-чуть подросли, примерно на 7%.
👉Джунов часто берут на удаленку, доля таких вакансий – 60%.
Я не очень сильно доверяю зарплатной статистике Хабра, но картина все равно интересная:
👉2024 год не стал хуже в сравнении с 2023. Конкуренция за вакансии стажеров и джунов осталась на том же уровне, где-то 80 откликов на каждую.
👉Больше всего джуновых вакансий среди бэкендеров. За ними идут, понятное дело, фронтендеры, и, удивительно, системные аналитики. Близких моему сердцу мобильных разработчиков нет даже в топ-10.
👉Зарплаты за год чуть-чуть подросли, примерно на 7%.
👉Джунов часто берут на удаленку, доля таких вакансий – 60%.
Хабр
Джуны в IT: зарплаты в компаниях, вакансии и отклики
Мы на Хабр Карьере помогаем IT-специалистам зарабатывать больше, а компаниям — быть в курсе трендов на рынке найма. Собрали новое исследование зарплат, на этот раз изучили зарплатные возможности для...
Как быть одновременно поддерживающим и требовательным
Такие качества руководителя как "требовательный" и "поддерживающий" ощущаются практически антонимами. На самом деле, это не всегда так, и хороший лидер может быть одновременно и тем, и другим. В статье приводится хороший пример из практики Instacart, когда один и тот же инвестор в разные моменты кризиса включал разные режимы, неизменно подталкивая команду к лучшим результатам.
Такие качества руководителя как "требовательный" и "поддерживающий" ощущаются практически антонимами. На самом деле, это не всегда так, и хороший лидер может быть одновременно и тем, и другим. В статье приводится хороший пример из практики Instacart, когда один и тот же инвестор в разные моменты кризиса включал разные режимы, неизменно подталкивая команду к лучшим результатам.
Новые выпуски тимлидских подкастов
Лучше регулярных походов в спортзал только регулярные походы туда под хорошие подкасты. И я вам принес сразу пачку новых тимлидских выпусков:
👉Подлодка про корпоративное обучение: как строить внутренние и внешние программы обучения, оценивать пользу от них и откуда брать экспертов.
👉Бреслав и Ложечкин про переговоры с топами: как тимлидам защищать результаты своей работы, получать ресурсы и поддержку.
👉Три тимлида заходят в бар про оценку руководителей: как понять, хороший ли ты тиилид, или просто с командой повезло.
👉КОДА КОДА про конструктивные коммуникации и конфликты: про ошибки в общении, манипуляции и работу с эмоциями.
Лучше регулярных походов в спортзал только регулярные походы туда под хорошие подкасты. И я вам принес сразу пачку новых тимлидских выпусков:
👉Подлодка про корпоративное обучение: как строить внутренние и внешние программы обучения, оценивать пользу от них и откуда брать экспертов.
👉Бреслав и Ложечкин про переговоры с топами: как тимлидам защищать результаты своей работы, получать ресурсы и поддержку.
👉Три тимлида заходят в бар про оценку руководителей: как понять, хороший ли ты тиилид, или просто с командой повезло.
👉КОДА КОДА про конструктивные коммуникации и конфликты: про ошибки в общении, манипуляции и работу с эмоциями.
Тимлид не спит: команда двачеров
Спустя пару недель работы тимлидом в новой команде, вы понимаете, что попали в команду двачеров, которые обмениваются в закрытом чате мемами за гранью рабочей этики. Что делать – оставить все как есть, или выбрать душный, но этичный путь?
К чему все это – в нашем новом проекте "Тимлид не спит" мы запустили разбор первого кейса! Работает все так:
👉Сегодня собираем ответы подписчиков (не в этом канале, а вот тут)
👉Завтра публикуем разбор кейса несколькими экспертами
👉Подписчики выбирают самый лучший вариант разбора. Участвуют и эксперты, и ответы из комментариев!
Пока планируем разбирать по два таких кейса в неделю, так что подписывайтесь, делитесь своими идеями, голосуйте за лучших!
Спустя пару недель работы тимлидом в новой команде, вы понимаете, что попали в команду двачеров, которые обмениваются в закрытом чате мемами за гранью рабочей этики. Что делать – оставить все как есть, или выбрать душный, но этичный путь?
К чему все это – в нашем новом проекте "Тимлид не спит" мы запустили разбор первого кейса! Работает все так:
👉Сегодня собираем ответы подписчиков (не в этом канале, а вот тут)
👉Завтра публикуем разбор кейса несколькими экспертами
👉Подписчики выбирают самый лучший вариант разбора. Участвуют и эксперты, и ответы из комментариев!
Пока планируем разбирать по два таких кейса в неделю, так что подписывайтесь, делитесь своими идеями, голосуйте за лучших!
Telegram
Тимлид не спит: разбор менеджерских болей, вопросов и кейсов
Самые крутые эксперты в менеджменте разбирают вопросы, проблемы и кейсы, с которыми сталкиваются реальные тимлиды!
Предложить кейс – @TeamleadDoNotSleepBot
Стать экспертом – https://forms.gle/8iZrsoqpjpTN5yuw6
Реклама в канале – @tanyasanovna
Предложить кейс – @TeamleadDoNotSleepBot
Стать экспертом – https://forms.gle/8iZrsoqpjpTN5yuw6
Реклама в канале – @tanyasanovna
Как задизайнить департамент разработки
Автор статьи предлагает довольно прямолинейный подход к структурированию большой инженерной команды:
1️⃣Определить UX домены в рамках продукта. Например, онбординг или конверсия в платящего пользователя.
2️⃣Выделить общие продуктовые домены, которые требуются для работы нескольких доменов из пункта выше.
3️⃣Один слой инженерной организации будет отвечать за UX домены, второй – за общие продуктовые, а третий – за инфру.
Разберемся в этой классификации чуть-чуть подробнее.
👉Пример UX домена – онбординг. Пользователь взаимодействует с разными страницами и фичами, находясь в одной конкретной роли. Некоторые из фичей относятся только к этому домену – например, авторизация. Какие-то, вроде личного кабинета, могут относиться сразу к нескольким UX доменам.
👉К общим продуктовым доменам могут относиться штуки вроде биллинга. Они нужны для разных UX доменов, но в то же время детали их реализации не должны вылезать вне домена.
В статье эта схема разбирается детальнее, так что, если вам стало интересно, и хотите побольше закопаться в то, как правильно выделить домены и как распределять инженеров между этими слоями, читайте!
Автор статьи предлагает довольно прямолинейный подход к структурированию большой инженерной команды:
1️⃣Определить UX домены в рамках продукта. Например, онбординг или конверсия в платящего пользователя.
2️⃣Выделить общие продуктовые домены, которые требуются для работы нескольких доменов из пункта выше.
3️⃣Один слой инженерной организации будет отвечать за UX домены, второй – за общие продуктовые, а третий – за инфру.
Разберемся в этой классификации чуть-чуть подробнее.
👉Пример UX домена – онбординг. Пользователь взаимодействует с разными страницами и фичами, находясь в одной конкретной роли. Некоторые из фичей относятся только к этому домену – например, авторизация. Какие-то, вроде личного кабинета, могут относиться сразу к нескольким UX доменам.
👉К общим продуктовым доменам могут относиться штуки вроде биллинга. Они нужны для разных UX доменов, но в то же время детали их реализации не должны вылезать вне домена.
В статье эта схема разбирается детальнее, так что, если вам стало интересно, и хотите побольше закопаться в то, как правильно выделить домены и как распределять инженеров между этими слоями, читайте!