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

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

Как AI влияет на безопасность В продолжение вчерашней темы о том, что нас ждет темная эра софта. Исследователи из Veracode взяли 100 разных LLM, дали им много разных задач по генерации кода, а затем прогнали по результатам свой SAST сканер. Вот что получилось: 👉Только 55% решенных задач не содержали ни одной выявленной уязвимости. 👉Несмотря на то, что более новые модели лучше справляются с генерацией кода, уязвимостей в нем меньше не становится. 👉Не зависит количество найденных уязвимостей и от размера модели. 👉Результаты по Python, JavaScript, C# показали примерно одинаковые результаты, а вот с Java все намного хуже.

Запускаем новое исследование тимлидов Тимлиды в 2025 году стали страдать, кажется, еще сильнее, чем раньше. К постоянно сменяющим друг друга кризисам, мертвому рынку найма, некомпетентным топам и периодическим сокращениям добавилось повсеместное давление на внедрение AI даже там, где этого не требуется. Так вот, если вы руководите командами разработки, принимайте участие в новом исследовании тимлидов от DevCrowd. Это поможет вам сравнить свою роль с коллегами по индустрии, перенять полезные навыки и практики, узнать, как решаются похожие на ваши проблемы, ну и просто помочь собрать классные факты! Результаты будут в открытом доступе где-то в конце сентября. На заполнение уходит минут 10-15, так что можете заварить себе вкусный кофе, расслабиться, и поделиться своими мыслями. А если хотите посмотреть, как выглядели результаты в прошлом году – вам сюда.

Мы входим в эпоху быстрой моды На MBA программах всегда разбирается кейс того, как Zara создала новый рынок быстрой моды. Это стало возможным благодаря нескольким радикальным изменениям в цепочке поставок, которые позволили существенно сократить время на разработку и доставку до конечных точек нового товара. Мы стремительно приближаемся к аналогичной ситуации, но в мире разработки. Условный Lovable дает возможность очень быстро получать что-то рабочее, но довольно низкого качества, как бы это качество мы не измеряли. Многие из таких сервисов, уже получив пользователей, не проходят столкновения с реальностью – данные утекают, нагрузка не держится, пользовательский опыт разваливается. И мы получаем рынок софта, который плохо справляется со своими задачами, а разработчики которого, в попытке залатать дыры, делают его еще более сложным и хрупким, так как не умеют в инженерию и в дизайн систем. Короче, будущее выглядит не очень радостным!

Про stack ranking Вы наверное слышали про отвратительную практику, иногда встречающуюся в корпорациях – stack ranking. В чем суть – вы должны отсортировать всех своих сотрудников по перфомансу по бакетам по какой-то спущенной сверху эвристике. Например, в Microsoft долгое время в каждой команде всегда надо было выделять 10% худших сотрудников, даже если на деле все работали примерно одинаково. Обычно эта система влияет на распределение бонусов, а иногда служит и основой для сокращений. Так вот, в нашем втором канале "Тимлид не спит" Александр Орлов из Стратоплана разбирает кейс, в котором тимлид впервые столкнулся с такой системой и ему надо выбрать кого-то худшего в команде, в которой все молодцы.

Быстрые и долгие проекты Первый список вы, скорее всего, когда-то уже видели – это перечень амбициозных проектов, которые были сделаны удивительно быстро для своего масштаба. Например, Unix, написанный за три недели, JavaScript за 10 дней, или iPod, на весь цикл от идеи до продакшна которого ушло всего 290 дней. Второй список еще интереснее – он про проекты, на которые человечеству потребовалось очень много времени: детектор гравитационных волн, на который ушло почти 50 лет, доказательство теоремы Ферма, или продолжительные исследования того, как разные жизненные факторы влияют на здоровье сердца.

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

Никто ничего не читает Несмотря на истории из Amazon про writing culture, реальность и бигтеха, и компаний поменьше в том, что никто не читает больших документов. В самом лучшем случае часть людей прочитает по диагонали executive summary, но и на это расчитывать не стоит. Единственный способ добиться того, чтобы информация из документа осела – перевести его в презентацию, регулярно показывать ее разным группам людей, и в целом регулярно ссылаться на документ в других коммуникациях. Такое отношение к написанному тексту не только в нашей индустрии. Похожая ситуация в науке, где рецензенты не читают бумаги, и в финансах, где никто даже не пытается вчитаться в финансовые отчеты глубже, чем на уровне самых базовых метрик. А теперь мы в картину сломанной письменной культуры добавляем еще и AI. В итоге еще больше документов будут писаться людьми, не обладающими глубоким знанием темы, а затем суммаризироваться для более быстрого прочтения. И если где-то в этом процессе важная информация теряется или искажается – никто и не заметит.

Про культуру встреч The goal of an exceptional meeting culture is to allow for people to constructively decline meetings by fully understanding the consequences of their action. Митинги, особенно регулярные, имеют свойство постепенно разрастаться из-за того, что не приглашенные туда изначально люди чувствуют FOMO. В итоге на встречи ходят не потому, что их надо посетить, а потому, что страшно пропускать. Чтобы это сломать, нужно сделать так, чтобы безопасным дефолтным выбором было отклонить встречу. Вот каких изменений это требует: 👉В описании митинга должна быть агенда встречи с примерной оценкой, сколько времени на какую тему вы хотите потратить 👉Если на встрече планируется принять решения, напишите об этом явно 👉Модератор встречи должен следить за тем, что вы придерживаетесь запланированной агенды, и ей в итоге можно верить 👉Любые отклонения от запланированных тем тормозятся и откладываются на другие обсуждения 👉Участники приходят только тогда, когда сильно заинтересованы в теме, готовятся к участию, и активно участвуют в обсуждениях 👉Те, кто отклоняет встречу, готовы к тому, что решения принимаются без них 👉Ведутся подробные meeting minutes

Новые выпуски тимлидских подкастов За месяц с последнего дайджеста подкастов вышло много новых интересных выпусков. Сохраняем в подборки и слушаем – можно даже параллельно с очередным бесполезным митингом! 👉"Бреслав и Ложечкин" про то, может ли руководитель проявлять свои эмоции, и где провести грань 👉"Три тимлида заходят в бар" про то, как ужерживать в команде самых ценных и важных специалистов на высоких грейдах 👉"КОДА КОДА" про то, как тимлиду управлять собственной энергией и мотивацией 👉Подлодка про то, как AI помогает в рабочих и личных задачах за пределами разработки (например, в поиске работы и подготовке к интервью) 👉"Едим слона целиком" про то, что такое стресс в менеджерской работе, и как с ним справляться

Как в AWS подходят к оценке продуктивности разработки Инженеры AWS, занимающиеся оптимизацией инфры и процессов разработки, искали способ получить оценку влияния своих изменений, хоть как-то приближенную к реальному миру. Считать только velocity – опасно, так как из уравнения исключается качество. Считать сэкономленное время в отдельных задачах – бесполезно, не дает общей картины, и не обязательно ведет к системному улучшению. Вместо этого они взяли фреймворк Cost-to-Serve (CTS), который до этого использовался Amazon, чтобы оценивать эффективность цепочки доставки физических товаров. В чем суть: 👉CTS измеряет общую стоимость доставки unit of software. Юнит – какой-то конечный результат работы, который команда считает достаточно ценным, чтобы разработать, проверить качество, доставить до пользователей и поддерживать его. Этот юнит различается для разных команд, потому что, например, регулярность релизов мобильных приложений накладывает свои ограничения. 👉CTS расчитывается как (стоимость разработки + стоимость разработческой инфры) / количество поставленных юнитов. 👉Так как результат метрики – деньги, она хорошо привязывается к любым другим финансовым показателям, и дает хорошее представление о ценности платформенных улучшений.

Разница между оркестрацией и лидерством Продуктовую работу услрвно можно разбить на шесть шагов: 1️⃣Problem Discovery: выбираем, какие проблемы существуют 2️⃣Problem Selection: выравниваемся со стейкхолдерами на тему того, какие из проблем самые важные 3️⃣Solution Discovery: ищем возможные решения для выбранной проблемы 4️⃣Solution Selection: выравниваемся со стейкхолдерами про то, какой подход к решению выберем 5️⃣Execution: запиливаем решение 6️⃣Ongoing Revision: постоянно выравниваем команду и стейкхолдеров про план действий Так вот, в организациях, управляемых в top-down стиле, менеджеры часто превращаются в оркестраторов – они отвечают только за последние три шага, и вообще не представляют, что в другой компании с большей автономностью от них могли бы ожидать лидерства – то есть еще и принятия решений про то, что делать. Вот признаки менеджера-оркестратора: 👉Относится к приоритизации как к своему основному инструменту работы. Это единственное, что доступно, когда ты не можешь повлиять ни на решаемые проблемы, ни на форму решения. 👉Принимает приносимые проблемы и решения как данность, единственное, что спрашивает – про их приоритет относительно других задач. 👉Фокусируется на планировании и процессах, защищает команду от изменений планов всеми силами.