Самые интересные статьи, видео и новости, связанные с управлением людьми, командами, разработкой и продуктами. Размещение рекламы: @tanyasanovna Папка лучших продуктовых каналов: https://t.me/addlist/YvmnHCHUp700Nzky
Пример Manager's Readme
Я уже выкладывал в канале несколько материалов про то, что такое Manager's Readme. Если концепция заинтересует, посмотрите на них в поиске. Если кратко – это небольшой документ, в котором описываются ваши основные менеджерские принципы и ожидания от своей команды. Он особенно хорош, когда вы только вкатываетесь в новую команду, и не выстроены неявные модели ожиданий и рутина.
В статье по ссылке из заголовка тимлид небольшой команды показывает свой readme в сыром виде. Мне нравится там следующее:
👉Явно прописаны основные ожидания от роли самого менеджера.
👉Очень простыми словами объясняется, зачем нужны 1-1, и они не смешаны с проектными синками.
Что мне не очень нравится:
👉Документ получился сборной солянкой. Например, там зачем-то описывается в деталях роль "лидера фичи", или рабочее расписание. Кажется, этому место где-то в других артефактах.
Чего ожидать от девелопер адвоката
Роль девелопер адвоката еще более загадочная, чем роль тимлида – мало кто может сформулировать, чем они должны заниматься. James Ward, довольно известный чувак в этой области, который сейчас работает в Google, попробовал сформулировать ожидания от роли в терминах набора артефактов, которые должны получаться на выходе любого проекта:
👉Семплы кода
👉Блог посты
👉Презентация или видео с лайвкодингом
👉Hands-on воркшоп
👉Сообщения в социальных сетях с широкими охватами
👉Фидбэк по продукту
👉Улучшение отношений с коммьюнити и партнерами
Анализ различных видов премий
Делюсь отличным постом из канала Виталия Шароватова, в котором он приводит выдержки из длинного исследования всех возможных типов премирования и их влияния на командную работу. А заодно прикладывает список литературы для тех, кто хочет в вопрос премий закопаться подробнее.
Книги, которые вы прочитали в этом году
У меня выдался очень ненасыщенный год на менеджерскую литературу, всего несколько книг, которые готов порекомендовать:
👉Radical Candor – про то, как давать открытый и честный фидбэк в моменте, а не тянуть с ним вечность.
👉The Culture Map – про особенности работы с людьми разных культур.
👉Team Topologies (ее еще не дочитал, но пока нравится) – про осознанный подход к организационному дизайну.
Расскажите, а что в этом гожу прочитали вы? Что понравилось, а что – не очень?
Как СТО развалить компанию
Представьте, что вас наняли как СТО в компанию, которую по какой-то причине вы хотите разрушить. За явный саботаж вас, конечно, уволят, поэтому нужно действовать в социально-приемлемых рамках. Вот мои любимые советы из статьи:
👉Внедрите сложный процесс приемки изменений, оправдывая его требованиями безопасности и комплаенса.
👉Требуйте вносить все задачи в трекер, а после этого проводить через ревью и приоритизацию группой не меньше 5 человек.
👉Чтобы избежать вендор-лока, настаивайте на том, чтобы реализовывать все самим вместо покупки готовых решений.
👉Поддерживайте коллективное владение кодом.
👉Наймите архитекторов и требуйте прохождения архитектурного ревью для всех изменений.
👉Привяжите зарплату к должности, а должность к размеру команды.
👉Отправляйте хай-перформеров на R&D проекты без четкой судьбы и целей.
В статье советов еще больше. Накидайте в комменты других полезных тактик незаметного развала компании.
Кому и зачем надо становиться менеджером
Очень классный мотивационный пост про то, почему стоит выбирать менеджерский карьерный трек помимо чуть большей в среднем по больнице зарплаты. Мне запали следующие мысли:
👉Задача менеджера – не принимать все решения, а делать так, чтобы они принимались.
👉Иерархия в компаниях существует для координации изменений в отдельных подсистемах и их постепенных улучшений. Менеджеры обеспечивают наличие в системе цикла обратной связи, благодаря которому эти улучшения и происходят, а систему получается выровнять вокруг общей цели.
👉Для некоторых людей потребность менторить других и передавать им свои знания – биологический императив. Это не обязательное требование, чтобы быть менеджером, но хорошая причина.
👉Другая хорошая причина – насмотреться на плохих менеджеров, понимать, как делать не надо, и хотеть помочь другим не страдать от тех же проблем.
👉Для хорошего инженера работа менеджером в течение пары лет – отличный опыт, чтобы вырасти в стаффа.
👉Опыт работы менеджером сильно помогает вам улучшить навыки взаимодействия с людьми, которые требуются и в личной жизни: вы учитесь управлять собой, понимать свои чувства и чувства других людей, устанавливать границы, говорить о неудобных вещах.
Тест для сборки инструкции к менеджеру
В конце года принято ретроспективно смотреть на все проекты, процессы и коммуникации. Ребята из SETTERS Media запустили тест-конструктор инструкции к себе как к менеджеру.
Как работает:
👉 Отвечаете на десять вопросов про свой стиль постановки целей, делегирования и коммуникаций
👉 Рассказываете о своих увлечениях и грузите фотку, чтобы вас ни с кем не спутали
На выходе получаете красиво сверстанную пдф, в которой подсвечены ваши основные менеджерские черты. Можно (и даже нужно) пошэрить файл с командой, потому что подтянуть коммуникации = подтянуть вообще все процессы. Пробуйте и рефлексируйте перед Новым годом!
Реклама. ООО "СЕТТЕРС МЕДИА"
Как в Google работает code review
Интересный разбор особенностей code review в Google – от гайдлайнов и до разбора Critique, внутреннего инструмента для ревью. Среди заметных фич:
👉Использование AI для того, чтобы в одну кнопку применить предложения из комментария.
👉Автоматическая генерация комментов-саджестов для ревьюеров кода на основе работы статических анализаторов.
👉Есть специальные дэшборды, которые показывают, какие ревью на ком зависли.
👉Если PR содержит и стилистический рефакторинг, и изменения бизнес-логики, Critique отфильтровывает только значимый код.
Как деливерить быстрее
Набор принципов, некоторые из которых показались мне интересными:
👉Protect momentum. Чем чаще вы что-то релизите, тем выше получается держать уровень мотивации и энергии в команде. Длинные циклы разработки приводят к выгоранию и потере контакта с пользователем.
👉Beware of prioritization. Бессмысленно тратить много времени на приоритизацию, когда все, что действительно важно – это какую задачу делать прямо сейчас, а какую – следующей.
👉Only doers can plan what you work on. Как только за планирование начинают отвечать оторванные от разработки люди, появляется искуственное раздувание сроков разработчиками, которые не хотят промахиваться в оценках. А работа занимает все выделенное на нее время.
👉There is no quality vs speed tradeoff. Плохое качество кода замедлит вам работу в будущем. Любой компромисс такого рода – в долгую вреден. При достаточном уровне культуры разработки и скиллов инженеров можно достичь обеих целей.
Навигаторы как замена архитектурным комитетам и командам
Про проблемы, вызываемые в компании наличием централизованной функции архитекторов, в канале мы обсуждали уже много раз (как минимум вот). При этом польза от них тоже есть, как минимум в том, чтобы любые технические вопросы не эскалировались до СТО. Один из вариантов замены – навигаторы.
👉На каждую большую бизнесовую область выделяется один человек навигатор. Им может быть только тот, кто активно контрибьютит в связанную кодовую базу.
👉Зоны ответственности навигаторов не пересекаются.
👉Навигатор целиком отвечает за принятие крупных технических решений в его области.
👉Если решение сталкивается с бизнесовыми или пипл-менеджерскими ограничениями, навигатор должен сам договориться с ответственными людьми.
👉Навигаторы отчитываются перед СТО за все принятые решения.
👉Если пара навигаторов не может договориться, вопрос эскалируется до СТО.
Как убедить всех замедлить разработку
Представьте (а, может, вам и представлять не надо), что с каждым месяцем вы все медленнее и медленнее деливерите фичи из-за накопившегося технического долга и других проблем, а бизнес при этом пушит, чтобы вы ускорялись. Любое ускорение в такой ситуации приводит только к тому, что вы создаете еще больше технического долга, башня которого в ближайшем будущем обрушится на вашу голову.
Единственное разумное решение в такой ситуации – замедлить разработку еще сильнее, исправить накопившиеся проблемы, и потом вступить в игру с новой силой. Проблема в том, что такой подход так просто не продать, особенно в период утраты доверия к команде. Держите советы из статьи, как все-таки достичь желаемого:
👉Оцените все, что от вас требуют сделать, в финансовых метриках, хотя бы очень приблизительно.
👉Выберите самые импактящие вещи, которые заблокированы существующими проблемами. Используйте их для обоснования.
👉Продумайте стратегию отдачи техдолга, которая уменьшает возможные риски и позволяет заинтересованным прозрачно видеть прогресс.
👉Быстро проверьте свои основные предположения до того, как продавать план. Например, точно ли вы сможете переписать какой-то компонент системы в обозначенное время.
👉Заранее продумайте, какие трейдоффы возможны, и используйте их как аргумент в переговорах.
👉Включите свою работу в продуктовый роадмап, сделайте ее видимой, чтобы всем было очевидно, что она связана с болями пользователя.
👉Выбирайте стратегию, которая сможет показать хоть какие-то ранние результаты.
Обязательные знания для тимлида
Сегодня вечером пишем выпуск Подлодки, в котором будем вместе с Виталием Шароватовым разбираться, что должен знать настоящий тимлид. Чтобы выпуск получился более живым, мы хотим собрать побольше мнений сообщества.
Расскажите в комментариях, что, по вашему, входит в комплект обязательных знаний для тимлида!
Как запрашивать фидбэк на свою работу
Типичная история – вы работаете над какой-то идеей, запрашиваете у коллег фидбэк, и вместо чего-то полезного получаете поток обратной связи про несущественные аспекты и косметику. Чтобы этого избежать, надо заранее проговаривать, фидбэк какого типа вы ожидаете. Вот одна из моделей:
👉Работа завершена на 5%: "Согласны ли вы с проблемой, которую я решаю?"
👉Работа завершена на 30%: "На правильном ли пути я нахожусь с моим решением проблемы?"
👉Работа завершена на 60%: "Является ли решение разумным, достигнем ли мы с ним наших целей?"
👉Работа завершена на 90%: "Пропустил ли я что-нибудь?"
👉Работа завершена на 100%: "Что в следующий раз надо сделать по-другому?"
Бреслав и Ложечкин про обратную связь
Вышел новый эпизод дочернего проекта Подлодки – подкаста для менеджеров "Бреслав и Ложечкин". В этот раз разговор идет про обратную связь: когда и кому она нужна, сколько времени на нее тратить и с какими подводными камнями можно столкнуться.
Как построить найм студентов
Один из способов расширить воронку найма – посмотреть в сторону найма студентов, которые пока нигде поработать не успели. С одной стороны, нужно построить непростой процесс обучения и отфильтровывания тех из студентов, кто не готов вкладываться, а с другой вы можете получить отлично обучаемых людей, которые готовы будут быстро вникнуть именно в ваш технический стек.
Ребята из МойОфис рассказывают, как запускали два потока студенческих стажировок и с какими сложностями столкнулись. По цифрам результат такой:
👉50 собеседований на входе воронки, 5 наймов спустя 3 месяца.
👉4 из 5 нанятых остались в компании после испытательного срока.
Инцидент-менеджмент и recency bias
Хорошее напоминание о том, что сам факт того, что произошел какой-то инцидент, не должен вести к тому, чтобы работы по предотвращению подобных проблем в будущем автоматически становились самыми приоритетными. Если действовать так, то велика вероятность, что решение недавних проблем будет вытеснять решение предотвращение более опасных инцидентов.
Выпуски Подлодки про управление командами
Мы недавно провели опрос слушателей нашего подкаста и помимо прочего выяснили, что тимлиды – один из самых крупных сегментов наших слушателей! По этому поводу держите подборку релевантных выпусков за последний год!
👉Онбординг с Евгением Антоновым про то, как построить простой и качественный процесс ввода в работу новых людей в вашей команде.
👉Организация стажировок со Стасом Цыгановым про то, как расширить воронку найма за счет кандидатов вообще без опыта работы, и как построить их отбор и обучение.
👉Письменная культура с Александром Ложечкиным про то, как развивать скилл написания полезных и понятных текстов и как эта кудьтура выстроена в Microsoft и Amazon.
👉Делегирование с Евгением Котом про самый важный навык любого руководителя.
👉Холакратия с Андреем Кузнецовым про то, как в Точке построена организация команд и процессы их работы.
👉Engineering Director с Евгением Котом про то, что меняется, когда от руководства командой вы переходите к руководству большим департаментом.
Если вам понравились эти или другие выпуски – напишите нам что-то хорошее в отзывах в Apple Podcasts, или прямо в чатике подкаста!
Процессный долг
Начнем новый год с эссе про то, что организации страдают не только от технического долга, но и от процессного. Он бывает разных типов. Например, у стартапов процессный долг – следствие быстрого роста. К нему можно отнести отсутствие адекватного онбординга, работу, построенную только на неформальных коммуникациях, отсутствие стандартизации в процессах. У кровавого энтерпрайза тоже есть свой процессный долг, но выглядит он немного по-другому – переизбыток бюрократии, митинги на 50 человек, информационные колодцы.
Пока кушаете салатик, подумайте, какой процессный долг есть в вашей команде, откуда он появился, чем он помог вам в то время, и когда от него пора избавляться.
🔥 Энтузиасты от комьюнити проектных менеджеров снова проводят исследование рынка, которое стало уже ежегодным!
Цель: выяснить зарплаты руководителей проектов и факторы, от которых они зависят, по выборке больше 1500 респондентов до 20 января 2024 года
Прошлогодний рекорд не побит - 564 чел 💪 Давайте поднажмем в этом году 🚀
Ссылка на опрос (~5 минут)
Тестовая неделя как способ найма
Linear делятся своим опытом добавления в процесс найма тестовой недели, в течение которой кандидат работает в их компании. Цели понятные – дать возможность и команде, и кандидату посмотреть на то, как он будет работать с реальными задачами, и сработаются ли они вообще.
Неделя оплачивается. Кандидату дают доступ ко всем необходимым инструментам и ставят четкую задачу. Например, реализовать фичу, которая поможет триажить входящие тикеты. Через эту систему проходят все нанятые люди, включая топ-менеджеров. Говорят, что ретеншн-рейт команды на протяжении 4 лет составил 96%.
Выпуск Подлодки про то, кто такой engineering director
Руководить другими менеджерами – совсем не то же самое, чем линейными сотрудниками. Записали выпуск Подлодки с Евгением Котом про то, в чем заключаются основные особенности работы инжиниринг директором от обычной менеджерской роли, и поговорили, какие знания и навыки будут обязательными.
Гайд по переходу к асинхронным коммуникациям
Все знают, что даже 3 встречи способны сделать полностью бесполезным рабочий день у разработчика. Но не все пытаются с этим что-то сделать. Держите довольно подробный гайд по тому, как подготовить команду к переходу на асинхронный режим взаимодействия, какие конкретные изменения надо сделать, и как постепенно менять культуру.
Почему вы увольнялись с менеджерской работы
Я увольнялся с менеджерских позиций два раза. Первый раз был в 2016 году в Rambler&Co. У нас одним днем сменился весь менеджмент технического подразделения на каких-то очень эффективных ребят из Инновы. Первое, что они сделали – собрали всю нашу команду и начали рассказывать про Scrum и другие великие изменения, которые планируют внедрить. На любые разумные вопросы про эти изменения отвечали чем-то типа "Да я уже пять успешных бизнесов построил, когда сделаешь столько же, вопросы и задавай". После этой встречи мы завели встречи для всего iOS отдела, на которых совместно стали готовиться к интервью. Спустя пару месяцев уволился и я, и процентов 70 всей команды. Мораль, которую я для себя вынес – даже если вас нанимают ради внедрения изменений, не стоит врываться с ними с порога без внятной стратегии их исполнения.
Второй раз был уже из Авито. В какой-то момент количество скучных менеджерских задач на монй позиции стало перевешивать интересные. В частности, смешно получилось с перфоманс ревью. Еще в 2017 году я начал его внедрять в компании. Со временем он эволюционировал, превращаясь во все более сложную машину. Два года спустя, сидя поздно вечером на калибровке, на которой мы несколько часов до хрипоты спорили о том, кто из двух незнакомых мне инженеров заслуживает +0.05 к оценке, я понял, что это совсем не то, на что я хочу тратить свою жизнь.
А теперь ваша очередь! Расскажите в комментариях, почему вы увольнялись с менеджерской работы.
Пан или пропал?
Представьте, вам предлагают проект с горящими сроками и очень небольшим бюджетом. Но где-то на горизонте маячит огромная прибыль.
Готовы выполнить проект? Отлично. Вопрос один: как?
Андрей Волков, тимлид из «Nitka Technologies», решил поделиться своим опытом о нескольких таких проектах в эфире «Экстремальные проекты: как выжить самому и не угробить команду?», который будет 14 декабря в 19:00.
✅ Андрей расскажет о:
• Своём опыте работы над проектом, который имел очень большой скоуп работ, сильно ограниченные сроки и мог потенциально сэкономить компании несколько миллионов долларов.
• Флоу данного проекта, мои ошибки и чему научился в итоге.
• Топ–10 моментов, которые я рекомендую проверить перед началом проекта.
Будет минимум теории и максимум практической пользы для тимлидов и управленцев, которые хотят эффективно оценивать проекты и ресурсы команды.
👉 Записывайтесь сейчас и получите бесплатный чек-лист «Трекинг здоровья команды»!Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Универсальное правило для продуктивной работы
Держи голову свободной! Тебе никогда не придёт в голову гениальная идея, если она всегда забита операционными мелкими задачами. Помнишь, как ты придумывал что-то перед сном или в отпуске? А сколько из этих идей моментально забывались?
🍅Помодоро или регулярных медитаций не хватает, это лишь кратковременная фокусировка на чём-то. Надо создать систему, в которой абсолютно все твои мысли и задачи будут учтены. Так ты избавишь голову от каждодневного хлама и начнёшь кратно увеличишь скорость роста как себя, так и всей компании.
О том, как система тайм-менеджмента может помочь достичь такого состояния расскажут на вебинаре 16 декабря в 20:30 по мск. Участие бесплатное, надо лишь зарегистрироваться в боте
🫥 Привлечь 18 тысяч новых клиентов с помощью аналитики: кейс Skyeng
Skyeng — EdTech-компания с целой экосистемой сервисов для изучения иностранных языков. В 2022 году они решили усилить аналитическое направление, построив новое корпоративное хранилище данных и сменив инструменты для аналитики.
Новое хранилище построено на сервисах платформы данных Yandex Cloud, покрывающей полный цикл работы с данными в облаке. Ядром DWH стал Yandex Managed Service for Greenplum® , для оперативного доступа к данным используется Yandex Managed Service for ClickHouse®, а для визуализации — Yandex DataLens.
Переход на сервисы Yandex Cloud позволил Skyeng сократить расходы на аналитику данных на 10% и ускорить тестирование маркетинговых гипотез. Это помогло компании за год увеличить продажи на 26%, а число клиентов — на 12%.
Как сервисы Yandex Cloud помогают Skyeng развиваться, читайте по ссылке.
Производительность определяется не личностью разработчика, а случайными факторами
Интересное исследование за 1995 год. 500 разработчиков выполняли на протяжении времени набор одинаковых задач, оценивая свои трудозатраты на разные этапы работы над ними. На выходе получились интересные данные:
👉В рамках отдельных заданий есть огромная разница между некоторыми программистами – лучший может быть производительнее худшего аж в 55 раз.
👉Если отбросить эти выбросы, то разница между 25 и 75 перцентилем очень небольшая.
👉Все интереснее, когда анализируется производительность каждого разработчика в рамках всех задач. У 90% разработчиков очень большой разброс времени выполнения разных заданий. Фактически 482 из 494 программистов закончили хотя бы одно задание быстрее среднего, а 415 — медленнее.
Короче, еще одно подтверждение того, что бессмысленно сравнивать перфоманс разработчиков друг с другом, когда они работают над разными задачами, и что вместо фиксации на скорости разработки лучше уменьшать ее неопределенность.
Новые возможности в новом году
Выбрать подарок для сотрудников — дело непростое. Нужно учесть интересы разных специалистов — от разработчиков до креаторов. Поэтому команда Яндекс Практикума создала подарочные сертификаты на 5 000, 10 000 и 15 000 ₽ для обучения востребованным навыкам. Например, работе с Excel или SQL, вёрстке на HTML и CSS или контент-маркетингу.
В чём плюсы:
→ Сотрудники освоят новые навыки, которые помогут в решении бизнес-задач компании.
→ Работают со всеми курсами направлений — программирование, аналитика, менеджмент, маркетинг и дизайн.
→ Подарок без проблем с логистикой: не нужно тратить силы на организацию доставки, особенно если команда распределённая.
→ Сертификаты будут действовать в течение всего года.
Хочу подарить сертификат
Пост для всех, кто любит новогодние подарки с пользой
Грейд клуб от Яндекс Практикума запустил адвент-календарь для руководителей цифровых команд.
Грейд Клуб — сообщество для нетворкинга цифровых лидеров и площадка для поиска решений о том, как драйвить рост IT-команд.
На протяжении трех недель пользователи будут получать классные подарки от клуба и его партнеров. А их собралось внушительное количество: Эйч, МИФ, Ясно, Кинжал и топовые эксперты индустрии.
Внутри вас ждут:
🎁Полезные фичи для мессенджеров
🎁Билеты на отраслевые конференции
🎁Гайды по эффективному лидерству и другие полезные подарки.
Переходите в бот адвент-календаря, чтобы не пропустить подарки!
ООО Яндекс. ИНН 7736207543
Как избегать накопления техдолга
У причин появления в проекте большого количества техдолга всегда есть два наивных объяснения: неосознанные разработчики или глупый и жадный менеджмент. Но в подавляющем большинстве случаев настоящие причины не настолько полярны.
Типичная история – менеджер просит команду побыстрее сделать фичу, на что тимлид соглашается, не озвучивая при этом риски, либо считая их очевидными, либо просто не желая быть негативным. В этой ситуации, конечно, виноваты оба участника: и менеджер не проговорил, какая вообще ценность от задачи, и в чем причины спешки, и тимлид не задал вопросов.
Чтобы избежать такого паттерна накопления техдолга, попробуйте следующие шаги:
👉Вместо прямых указаний или просьб сделать фичу задавать вопросы вида "Можем ли мы сделать Х за время У?". Это дает команде возможность сделать выбор вместо того, чтоьы пойти по простому пути и следовать указанию.
👉Еще лучше использовать открытый вопрос. Например, "Что нам придется убрать из скоупа, чтобы сделать Х?" или "Как вы оцениваете риски фичи Х по 10-балльной шкале?"
👉Еще лучше – делать команду достаточно автономной и передавать ей ответственность за результат, чтобы продакту достаточно было рассказать о фактах и дать команде самой решить, что самое ценное для пользователя они могут сделать.
👉Поощряйте привычки команды, которые заставляют ее регулярно задумываться о стоимости и смысле изменений, или уделять внимание инженерной культуре. Например, учитывать в приоритизации cost of delay.
👉Поощряйте не только релизы фичей, но и невидимую работу по решению техдолга и улучшению процессов.