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

Большое исследование продактов Раз в год команда DevCrowd делает срез текущего рынка продакт-менеджеров, чтобы оценить, а как вообще поменялась их работа, навыки, инструментарий и зарплаты. Так вот, новый опрос уже запущен – проходите сами и пересылайте своим продактам! Напомню, что сам я этими исследованиями уже не занимаюсь, но при этом супер рекомендую в них участвовать: 👉У команды нет какой-то повестки, которую им важно продвигать (уровня "ААА, рынок умирает, приходите к нам за консультациями!"), поэтому результаты довольно чистые. 👉Обычно в исследовании участвует 1000+ респондентов собранных как из публичных каналов, так и путем ручного обхода больших и маленьких компаний – так что срез получается довольно репрезентативный. 👉Опросы проводятся уже много лет, поэтому можно делать самое интересное – отслеживать, как самые важные сигналы меняются год к году! 👉Все результаты открыты для всех без всяких регистраций. Этот опрос откроют уже в мае! 🔗Пройти опрос

Как работают инженерные менеджеры в разных компаниях Держите несколько хороших разборов того, в чем заключается работа engineering manager'ов в разных компаниях, и как они влияют на бизнес: 👉Amazon 👉Meta 👉Roots 👉Flo

Чем отличаются менеджер, директор и VP Наткнулся на лучшее описание различных менеджерских уровней, которое я встречал. 👉Менеджеру платят за то, чтобы он достигал результатов, получая помощь по необходимости. 👉Директору платят за то, чтобы результаты достигались вообще без какого-то контроля. 👉VP платят за то, чтобы они придумывали планы, основанные на понимании бизнеса. Главное отличие VP от директора в том, что даже если предложенный им план был зааппрувлен всеми, идеально выполнен, но результатов нет – это его провал. Соответственно, хороший VP никогда не должен подписываться под планами, в которые сам не верит – лучше столкнуться с политическими последствиями своего несогласия, чем навредить бизнесу в том домене, за который ты отвечаешь.

На что влияют скиллы разработчика при работе с AI Мартин Фаулер за последние месяцы успел много поработать с AI агентами, и на основе этого опыта выделил несколько самых частых проблем, в которых индивидуальные навыки разработчика все еще решают: 👉Неправильный диагноз того, почему код не работает, из-за чего дебаг становится бесконечным. 👉Вместо того, чтобы идти маленькими итеративными шагами, агенты часто стремятся написать слишком много кода сразу. 👉Вместо поиска корневой проблемы агент лечит симптомы костылями. 👉Задача может быть реализована таким образом, что общий developer experience неоправданно усложнится. 👉Агент может неверно понять функциональные требования, и начать решать вообще не ту задачу. 👉Тесты, которыми покрывается код, могут быть избыточными. 👉Код может получаться слишком сложным. Все эти проблемы закрываются довольно банальными способами – нужно очень внимательно следить за работой агента в процессе, ревьюить результаты, и применять олдскульные практики обеспечения качества всей кодовой базы.

Почему учить других – хороший способ учиться самому 1️⃣ Когда вы объясняете кому-то новую тему, вам приходится глубоко в ней разобраться. Если вы не можете ясно изложить материал, значит, вы сами еще недостаточно его поняли. 2️⃣ Чтобы доступно объяснить что-то другим людям, вам приходится упрощать информацию, искать понятные примеры и аналогии. В этом процессе вы и сами лучше понимаете суть изучаемого материала. 3️⃣ Когда вы только-только изучили что-то новое, вы еще помните, что это такое – не понимать материал. Это помогает вам предвидеть возможные вопросы, объяснять тему более доступно, и уметь так же объяснять ее и в будущем. 4️⃣ Необходимость обучить теме кого-то еще хорошо так пинает разобраться в теме глубже, и не откладывать это на последний момент.

Что вынуждает топ-перформеров увольняться 👉Отсутствие ясного вижна у компании. Топ-перформеры готовы сами находить новые челленджи и двигать компанию вперед, но для этого им важно понимать общен направление. 👉Добавление новых задач без отказа от старых. По себе знаю, насколько просто попасть в ловушку бездумного накидывания задач в своих самых сильных людей. А за перегрузкой будет следовать либо выгорание, либо провал каких-то из проектов. 👉Скидывание части ваших задачс когда вы передаете их не с целью развития навыков, а просто для того, чтобы освободить собственное время. 👉Обещать отдать контроль, но на деле постоянно микроменеджерить и забирать его на себя. Помимо того, что вы забираете возможность развития, вы таким образом показываете отсутствие доверия. 👉Предполагать, что вы знаете, что их мотивирует. Когда какой-то человек с радостью берет на себя новые сложные задачи, легко сделать вывод о том, что его основная мотивация лежит в интеллектуальных челленджах. На самом деле ситуация может быть вообще другой, и, не понимая всех причин, вы будете принимать плохие решения.

Настольная книга СТО стартапа Держите золото – бесплатную книгу с описанием кучи концепций, практик и процессов, которые нужны любому техническому руководителю. 👉Менеджмент людей: коучинг, деревья компетенций, continuous improvement, обучение менеджеров. 👉Жизненный цикл сотрудника: найм, онбординг, перфоманс менеджмент. 👉Управление технической командой: общая культура, техдолг, developer experience. 👉Технологии: архитектура, SDLC, DevOps, инцидент-менеджмент.

Мои топ-5 кандидатов: 1️⃣ "Отсутствие бюрократии" 2️⃣ "У нас скрам с элементами вотерфолла" 3️⃣ "Мы стремимся в бирюзу" 4️⃣ "Мы тут делом занимаемся, а не процессами" 5️⃣ "Фаундеры очень вовлечены в процесс разработки"

Важность – Решаемость – Запущенность Чаще всего, выбирая точки приложения усилий, менеджеры сортируют возможные задачи по степени их срочности. Иногда вмешивается матрица Эйзенхауэра, и, помимо срочности, появляется компонент важности. Держите чуть более глубокий фреймворк, который помогает ответить на вопрос "Будет ли мое участие как менеджера полезным?" 👉Решаемость (tractability) – насколько вообще выбранную проблему можно решить в разумное время. 👉Запущенность (neglectedness) – насколько уровень выделяемых ресурсов на проблему соответствует тому, который нужен, чтобы реально ее решить. 👉Важность (importance) – ну тут все по классике. Так вот, при оценке всех проблем по этим критериям, вы можете увидеть довольно важные вещи. Самыми интересными выглядят вот эти два кластера: 👉Важные, но нерешаемые проблемы. В такие места вам имеет смысл погрузиться и попробовать понять, нельзя ли пересмотреть саму проблему или текущий подход к ее решению. В статье как раз приводится хороший пример с распилом монолита. 👉Важные, решаемые, но при этом запущенные проблемы. Сюда попадает знакомый многим длинный хвост проектов, которыми занимается по полчеловека, и которые в итоге годами не двигаются вперед.

Интервью на СТО Недавно я анонсировал открытое интервью на позицию СТО, где Александр Ложечкин собеседовал Андрея Бреслава. Так вот, все прошло классно, и, если вы опоздали на лайв, обязательно посмотрите запись на Youtube!

Большой анализ зарплат по всему миру Держите офигенный разбор того, как платят сеньорам по всему миру. Из интересных наблюдений: 👉Почти во всех ключевых регионах можно выделить несколько сегментов компаний с разными медианами и распределениями зарплат. Чаще всего одним из сегментов является международный бигтех, а другим – локальные компании. 👉Рынок вытягивают вверх в основном компании с HQ в США. 👉На локальном рынке США компенсация супер-сильно зависит от штата, вот тут можно посмотреть распределение. 👉Чем больше общая компенсация, тем большую часть в ней занимают опционы. Но при этом самые большие пакеты – в хедж-фондах, где никаких опционов нет, зато премии в кэше составляют до 200% от базовой зарплаты. 👉Приложил к картинкам классную оценку того, как изменение цены акций компании повлияло на компенсационный пакет разработчиков. В случае Nvidia за три года он вырос на 45%, а в менее успешных компаниях упал на треть.

Как техническому менеджеру не терять свои навыки 1️⃣Периодически проходитесь и по всем этапам пользовательского пути, и по этапам стандартного процесса разработки в вашей команде, выписываете все проблемы, составляете friction log. 2️⃣Почти во всех командах львиная доля времени уходит на различную операционку – закрытие мелких багов, инфраструктурные задачи, решение инцидентов. Регулярный глубокий анализ всего, что происходит в этих областях, и поиск возможностей их оптимизировать – как помогут команде, так и дадут менеджеру больше контекста о происходящем. 3️⃣Участвуйте в той же ротации дежурных по инцидентам, что и вся команда. Вы сможете буквально на кончиках пальцев понимать, где в вашей системе самые проблемные места, насколько хорошо все документировано, и чем весь процесс можно сделать лучше. 4️⃣Возьмите на себя подготовку различных документов – и техдокументации, и пострмортемов, и ADR. 5️⃣Попробуйте периодически брать "engineerication" (engineer+vacation) – несколько дней или недель непрерывного времени, когда вы занимаетесь только инженерными задачами. Это особенно хорошо работает, когда нужно быстро погрузиться в новый домен.