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

X, Y, Z — как найти подход ко всем У каждого поколения — свои ценности, ожидания и любимые способы коммуникации. Это не хорошо и не плохо, просто факт. Проблема начинается при попытках управлять всеми одинаково. Тогда одни перестают слышать задачи, другие теряют мотивацию, а третьи просто уходят — туда, где учитывают их особенности. Найти общий язык с межпоколенческой командой поможет бесплатный курс «Как работать с разными поколениями сотрудников» от Яндекс Практикума. Экспертизой поделятся управленцы с живым опытом от 13 лет из Т‑Банка, МТС, S7 Airlines. Чему вы научитесь ▪️Понимать, что на самом деле движет поколениями, — без стереотипов и обобщений. ▪️Писать вакансии, которые откликаются нужным кандидатам. ▪️Ставить задачи так, чтобы они выполнялись с первого раза. ▪️Выстраивать онбординг так, чтобы новички вливались в работу быстро и без стресса. ▪️Давать обратную связь, которую не боятся, а ждут — и после которой хочется расти. ▪️Экологично расставаться с сотрудниками, сохраняя HR-бренд и извлекая пользу из exit-интервью. А ещё вас ждут: практика на реальных кейсах, разбор ошибок и 20+ готовых инструментов для каждого этапа управленческого цикла. Учиться бесплатно Реклама, ООО Яндекс, ИНН 7736207543, erid: 2VtzqwE8XJe

Не давайте AI писать тексты за вас Любой текст, над которым вы работаете – это возможность подумать и отточить свои рассуждения по теме. Вы думаете над вопросом, анализируете, а на тот ли вопрос вы вообще отвечаете, улучшаете структуру и содержание своих мыслей. Чем-то это похоже на тренажерный зал – с каждым подходом на грани отказа вы становитесь чуть-чуть сильнее. Если вы аутсорсите написание текстов LLM, вы теряете возможность качественно подумать. Возвращаясь к аналогии с тренажеркой – вы просто попросили поднимать штангу за вас кого-то другого. Дополнительный минус – вы подрываете доверие окружающих к себе. Вместо аутентичных идей они видят безликую аппроксимацию того, что в среднем по палате хотят прочитать другие люди. Если вы пропустили, в феврале был еще один хороший пост на эту же тему.

Два важных вопроса для собеседования 1️⃣Кто отвечает за задачу? В собеседовании разработчика такой вопрос помогает понять, насколько он готов действовать проактивно, если получает неполные требования, соседняя команда задерживает свою часть работы, кто-то из коллег вовремя не отвечает или в других похожих ситуациях. И, что еще более важно, насколько он пытается подумать за рамками самой задачи – не только о том, как довести ее до релиза, но и как она будет жить после. В собеседовании тимлида такой же вопрос позволяет пощупать, превращает ли он себя в бутылочное горлышко или строит нормальную систему управления. 2️⃣Пишете ли вы unit тесты? Разговор про тесты с разработчиком позволяет понять его отношение к качеству, способу проектирования, отношению к изменениям и инженерной культуре в целом. Если задать такой вопрос тимлиду, то он может вывести на разговор про понимание инженерной реальности системы – ограничения, риски, последствия решений, долгосрочную устойчивость.

Как Intercom использует Claude Code Гипер-интересный тред про то, как в Intercom используют агентов для автоматизации разных процессов. Вот несколько идей: 👉Агентам дали доступ к продакшн админке, в которой есть штуки вроде контроля фичефлагов – но только на чтение. 👉Транскрипты всех сессий работы с агентом автоматически отправляются в LLM, чтобы собирать стату по частым ошибкам, недостающим скиллам и прочему. По итогу сразу же в бэклоге создаются таски на их решение. 👉Автоматически чинятся флаки тесты по заданной таксономии. 👉Автоматически обновляет список разрешенных пермишнов для агента на основе предыдущей истории их аппрува.

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

Инфраструктура растёт, и управлять ей вручную становится все сложнее: конфигурации расходятся, изменения занимают дни, а критичные знания остаются у отдельных специалистов. Приглашаем вас на бесплатный вебинар, где расскажем о преимуществах управления инфраструктурой через код, обсудим типичные ошибки при внедрении IaC и покажем подход на практике. Каждому участнику вебинара мы пришлём пошаговый план перехода к IaC. 📅 1 апреля, 11:00 по МСК 💻 Онлайн РЕГИСТРАЦИЯ И ПРОГРАММА

Как Cursor влияет на скорость и качество разработки Исследователи взяли все репозитории с GitHub, в которых файл .cursorrules появился уже после создания проекта, и сравнили их состояние до и после его появления. Вот какие выводы получились: 👉После адопшна Cursor количество новых строк кода выросло в 3-5 раз, но уже спустя два месяца этот эффект проходит. 👉Одновременно с этим растет устойчивое накопление техдолга: статанализ находит на 30% больше проблем, а когнитивная сложность выросла на 40%.

Оптимизировать надо не скорость написания кода Держите отличную статью, которую можете аккуратно закинуть своему СТО, когда он предложит внедрять метрики оценки количества AI-generated PR, или еще каким-то образом будет пушить ускорение разработки фичей. Вообще, Голдратт уже все объяснил десятки лет назад, но эффективные менеджеры либо его не читают, либо думают, что именно их случай – особенный.

Когда менеджер должен вмешиваться Задача хорошего менеджера построить команду так, чтобы она могла работать и без него. Совсем не вмешиваться в работу команды часто может быть неразумно – но можно нащупать грань. 👉Команда должна иметь возможность совершать ошибки и учиться на них. Выбрать такие ошибки поможет эвристика "Below/above the waterline" – если какая-то ошибка может сильно навредить и потопить ваш корабль, стоит вмешаться, иначе – нет. 👉Нужно различать ошибки и вкусовщину. В случае вкусовщины не нужно сильно давить своим мнением, оно не важнее других людей в команде. 👉Вмешиваться стоит в следующих случаях – команда столкнулась с большой неопределенностью, которую вы можете уменьшить; или они вошли в дедлок по вопросу, который не имеет одного верного ответа, например, по выбору архитектуры. 👉При оценке необходимости вмешательства всегда учитывайте сеньорность человека в контексте конкретной задачи. Иногда в одной и той же задаче джуну помощь может быть не нужна, а вот сеньору – вполне. 👉Хорошее вмешательство организовано таким образом, чтобы в будущем команда чему-то от него научилась, и в похожей ситуации справилась бы сама.

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

Как понятно объяснять свои мысли 👉Bottom line up front. Когда вас просят что-то объяснить, основной вывод должен быть в первой же фразе, и только потом идти дополнительный контекст. А многие поступают наоборот – вместо прямого ответа пытаются подробно воспроизвести рассуждения, которые к нему приводят. 👉Just in time context. Не нужно пытаться сходу вывалить весь возможный контекст. Давайте его ровно столько, сколько нужно, чтобы собеседник мог решить свою текущую проблему. А чем глубже вы понимаете какую-то тему, тем сложнее удержаться от того, чтобы погрузить в нее человека. 👉The top-down bridge. Когда вы насыпаете кому-то контекст, отталкивайтесь от того, что они сейчас знают, и постепенно углубляйтесь в детали, отстраиваясь от этого.

Про продуктивность и энтропию С ростом размера и сложности программ растет и их энтропия – уровень неопределенности и непредсказуемости поведения. Чем продуктивнее разработчик, тем больше изменений в систему он вносит, и тем быстрее растет энтропия. На AI все смотрят как на волшебную таблетку продуктивности – и такой подход может привести к очень быстрому и про том неявному росту энтропии. Вот несколько интересных мыслей из статьи: 👉Чем раньше принято какое-то решение по дизайну системы, тем сложнее его изменить в будущем. Оно задает ограничения и воркэраунды, которые приходится делать при разработке новых фичей. Чем больше фичей вы будете генерировать, тем сложнее станет отказываться от таких ранних легаси решений, тем больше неочевидных путей и решений в вашем коде будет появляться. 👉У разных команд в организации могут быть конфликтующие цели с точки зрения архитектуры. Например, платформенные команды стремятся сделать архитектуру стабильной и развивающейся по понятному набору правил, и в то же время продуктовые команды хотят move fast and break things, потому что поджимают квартальные OKR. Обычно такие конфликты заставляли людей сесть в одной комнате и договориться. AI ускоряет цикл разработки, и гораздо чаще будут случаться ситуации, когда вместо договоренности все будут тянуть систему в разных направлениях, увеличивая энтропию. 👉Обратная связь о многих решениях прилетает не сразу. Например, качество принимаемых архитектурных решений может быть видно только спустя месяцы или годы. То же самое и с запутанным кодом – обратную связь в виде инцидентов вы можете получить, только когда распутывать его станет уже слишком сложно и дорого. Ну и напоследок прекрасная цитата: AI will require us to hold on to good software engineering principles even tighter. Those who understand this will build systems that grow and last. The ones chasing unbounded productivity gains won’t know why they failed.