Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Обращусь с небольшой персональной просьбой. Если среди подписчиков есть менеджеры из Яндекса, близкие к Почте или к Яндекс 360, напишите мне пожалуйста (@etolstoy). Там дурацкая ситуация – 10 лет назад я сделпл родителям почтовые ящики на кастомном домене. Сейчас с ними какая-то проблема, надо получить доступ к админке, а для этого – подтвердить владение доменом. Подтвердить я могу, но поддержка внезапно перестала отвечать, и вот уже третью неделю держит упорное молчание. Буду очень благодарен кому-то, кто сможет изнутри подвигать это дело ❤️ Ну а чтобы пост был полезным, держите статью на выходные про ошибки, которые легко сделать начинающему менеджеру! Upd: Всем спасибо, помогли!

Публикуем новый кейс + разбор от эксперта канала! 👉 Кейс #10 Чек-лист для тимлида Интересует чек-лист для тимлида, в случае, если тимлид приходит новичком в существующую незнакомую ему команду, из которой ранее ушел тимлид. Ушел либо в другую компанию либо на повышение. 💬Разбор от эксперта Кейс разбирал: 👉 Александр Орлов @eagleson77, автор книги "Джедайские техники конструктивного общения", управляющий партнер Школы менеджмента Стратоплан А что вы бы добавили в чек-лист для тимлида? Делитесь в комментариях.

Технические собеседования поломаны Все мы проводим технические собеседования, и все мы в глубине души понимаем, насколько они несовершенны. На людей давит огромный стресс, время на поиск решения неоправданно ограничено, а решаемые задачи практически всегда оторваны от реальности. Если вы по какой-то причине уверены, что именно ваш процесс собеседования – полезный и объективный, расскажите, пожалуйста, о нем в комментариях!

Непопулярные мнения про продакт-менеджмент 👉За продукт отвечает не продакт-менеджер, а вся команда. Задача PMа – быть источником информации о нуждах пользователя, рынке и стратегии компании. А вот для генерации крутых идей, без которых результатов добиться сложно, нужны и инженеры, и дизайнеры, и остальные функции команды. 👉Умный продакт-менеджер – это плохо. У умных людей часто есть свое сильное мнение по любому вопросу, притом оно формируется довольно быстро на основе обрывочных фактов. Гораздо ценнее продакт, который вместо быстрой генерации кучи идей тратит время на общение с пользователями и получение большего количества информации об окружающем мире. 👉Конкретные артефакты продуктовой работы вообще не важны. Как именно вы пишете PRD, описываете стори и эпики не играет вообще никакой роли. Главное – последовательно шарить контекст с командой любым удобным всем способом, и постепенно уменьшать количество неопределенности. 👉Метрики важны гораздо меньше, чем умение понятно сформулировать, в чем заключается успех. Любая метрика будет не очень точной аппроксимацией смысла, поэтому слишком сильно привязываться к ним скорее вредно.

Новые выпуски подкастов про менеджмент 👉"Бреслав и Ложечкин" про доверие: как от него зависят качество и результаты команды, и что делать руководителю, чтобы его добиться. 👉"Три тимлида заходят в бар" про выход из тимлидства: очень важный выпуск про то, как не бояться перестать заниматься тем, что не приносит удовольствия, и как жить с последствиями этого решения. 👉Подлодка про страхи и проблемы в нашей индустрии: юбилейный выпуск с разбором самых частых страхов айтишников – сокращения, преобладание краткосрочной выгоды над смыслом, замена всех AI, падение уровня новых разработчиков. Кстати, мы давно не писали выпусков Подлодки на какие-то вот прямо чисто менеджерские темы. Накидайте в комментарии идей того, про что хотелось бы послушать!

Как тимлиду поддерживать свой технический уровень Если играть в "100 к 1", то самыми популярными ответами тут были бы: заниматься пет-проектами, брать задачи из глубины бэклога, от которых ничего не зависит, пилить внутренние инструменты и PoC. Главная проблема этих советов в том, что работа над ними никак не помогает вам справляться со своей основной работой – помогать команде достигать результатов и становиться со временем лучше. В статье предлагают посмотреть на вопрос немного с другой точки зрения. Чтобы поддерживать свои технические знания, вам надо не делать что-то своими руками, а изучать новое вместе со своей командой. Например, вы прочитали про какую-то новую технологию, которая потенциально может в будущем пригодиться в проекте. Вместо того, чтобы погрузиться в нее целиком самому, попробуйте следующий план: 👉Обсудите концепцию и идеи с командой 👉Подумайте, как совместить эксперименты с новой технологией с ближайшими планами команды 👉Спланируйте всю работу, помогайте команде с возникающими проблемами, смотрите на итоговый код и архитектуру, помогайте их улучшить своими советами 👉Обсудите результаты эксперимента вместе с командой и решите, насколько это технология действительно может помочь проекту В целом, мне нравится общая идея статьи. Глубокое погружение в контекст того, чем занимается команда, обсуждение с ними идей и архитектуры правда помогают поддерживать свою техническую мышцу. В реальности, конечно, все разбивается о то, что большинство задач, выполняемых командой, довольно стандартные, погружение в них многого вам не даст, а экспериментировать с интересными технологиями хорошо если пару раз в год получится.

Последний этап превращения группы людей в команду Невероятный цикл историй про группу монтажников, проходящую через фазы forming-storming-norming-performing, подходит к концу. В этой части разбирается: 👉Как после фазы острого кризиса растет производительность 👉Как ускорение и успешное выполнение работы влияет на доверие людей друг к другу 👉Как выглядит настоящая командная работа А для тех, кто предпочитает смотреть видео – YouTube версия!

Тактики выживания в корпорации Держите плейлист на выходные из 15 коротких видео про разные аспекты выживания в корпорации. Я их еще не посмотрел, но за автора могу ручаться – я буквально недавно проходил его курс про product sense, и мне очень понравился и его опыт, и то, как он мыслит.

Как формулировать проблемы с помощью теории ограничений Мне очень нравится теория ограничений еще и тем, что многие инструменты из нее хорошо применимы в других контекстах. Например, дерево текущей реальности хорошо помогает системно проанализировать причинно следственные в любой сложной системе. В этой статье разбирают другой инструмент из ТОС – нежелательные явления. Это способ формулировки проблем, который помогает найти решение, приближающее к цели, мотивирует к действиям и о котором легко договориться. Правила формулировки НЖЯ: 👉НЖЯ — это проблема, которая регулярно повторяется 👉НЖЯ — это проблема, на которую мы можем повлиять 👉НЖЯ не субъективно 👉НЖЯ не является предполагаемой причиной 👉НЖЯ не содержит завуалированное решение 👉НЖЯ — не содержит обвинение 👉НЖЯ не требует пояснения, какой негативный эффект оказывает Примеры из статьи переформулировки довольно абстрактных проблем в НЖЯ: Не найти ответственных ➡️ Мы заметно срываем сроки по 70% задач Хаос в бизнес-процессах ➡️ До 80% разработки не попадает на прод Проблема с данными ➡️ Мы не можем использовать заметную часть данных

Как договариваться о росте хедкаунта Чтобы убедить менеджера выделить вам в команду больше людей, вам в первую очередь надо убедить его в том, что команда в своем текущем составе уже отлично справляется. Для этого вам надо выровняться по следующим вопросам: 👉Решаемая командой проблема важна 👉Все согласны с выбранным подходом к решению этой проблемы 👉Команда в своем текущем составе уже отлично справляется с разработкой этого решения 👉Как конкретно добавление новых людей повлияет на результаты решения проблемы: скорость, качество, что-то еще

Как доводить до успеха проекты в бигтехе В больших компаниях проект считается запущенным не в тот момент, когда он задеплоен на прод, или когда им начали пользоваться люди. Запущенным он считается тогда, когда топ-менеджмент в это поверит. Иначе говоря, если ваша система задеплоена, но СЕО очень не доволен результатом – это провал. Из этого следует, что ответственному за запуск проекта инженеру нужно думать не только о коде и об архитектуре, но и про следующие вещи: 👉Иметь четкое представление о том, какую пользу компания хочет получить от вашего проекта. Это могут быть как явные вещи, вроде денег и пользователей, так и менее явные, например, личная заинтересованность какого-то VP. 👉Поддерживать доверие к вам заинтересованных в проекте менеджеров. Ни у кого из них не будет технического контекста происходящего, поэтому во всем, что касается сроков и рисков, они будут полагаться на ваше суждение. Если доверие пропадет, шансы проекта на успех резко снизятся. 👉Оставлять себе достаточно свободного времени, чтобы иметь возможность быстро среагировать на неожиданные проблемы и сомнения каких-то соседних команд и стейкхолдеров. 👉Пытаться предугадать возможные будущие проблемы и заранее продумывать, как митигировать эти риски. Хороший способ делать это – регулярно задавать себе вопрос "Что мне могло бы помешать выпустить проект прямо сегодня?"

Как техдолг влияет на AI Лучше всего AI инструменты вроде Cursor работают на кодовых базах, которые разбиты на модули с понятными названиями и зоной ответственности. Иначе говоря, чем проще вам объяснить все взаимодействия и потоки данных в коде, тем проще генеративному AI будет с ними работать. Из этого проистекает довольно очевидная мысль, о которой я раньше не думал – чем больше у вас технического долга, тем меньше пользы вы будете получать от использования AI, а разница в скорости разработки в сравнении с новыми проектами вырастет еще сильнее.