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

Задавайте больше вопросов Когда мы действительно пытаемся что-то понять, то строим в голове модель описываемого предмета. Единственный способ эту модель откалибровать – задавать вопросы, чем больше, тем лучше. Именно большое количество вопросов всегда было главным инструментом менеджера, которому надо было погрузиться в те части проекта, которые он не трогал руками сам. Теперь тот же самый навык становится супер-ценным в работе с агентами. Они всегда звучат очень уверенно, когда предлагают какие-то решения, но уже после нескольких вопросов вида "а точно ли у нас нигде такой класс уже не реализован?", или "правда ли что авторизация работает именно так?" выясняется, что на самом деле в половине случаев предположения агента не верны. Поэтому до тех пор, пока агентов не натренируют на то, чтобы очень явно говорить о том, в чем они не уверены, наш менеджерский навык задавания вопросов останется ценным!

Внедрение ИИ в компании стоит начинать не с выбора инструментов, а с понимания, где он действительно сэкономит время, как оценить эффект и какие задачи бизнеса должен решить.  Разберите эти вопросы с топовым экспертом из Яндекса и НИУ ВШЭ на бесплатной консультации при покупке любой программы ИИ-тренингов до конца ноября. Формат: 1 час с предварительным брифингом. Тему согласуем заранее. Что вас ждёт: ▪️ Обсудим ваши реальные задачи или типовые сценарии — подготовка к встречам, работа с документами, внедрение ИИ в команде. ▪️ Покажем, какие инструменты попробовать, как повысить личную эффективность, какие процессы автоматизировать и как проверить результат. ▪️ После встречи вы получите письменные артефакты — промты, рекомендации, чек-лист, роадмап или список шагов. Оставить заявку Реклама, ООО Яндекс, ИНН 7736207543, erid: 2VtzqviVCB7

The Power Broker – лучшая книга для менеджеров Я пару месяцев назад дочитал, кажется, САМУЮ БОЛЬШУЮ книгу в своей жизни – Power Broker. Это невероятно подробная биография Роберта Мозеса – человека, занимавшего довольно смешные должности вроде "главный за парки Лонг-Айленда", который при этом перестроил половину Нью-Йорка по своему чувству прекрасного, сломал об колено демократию, и подчинившего себе длинную череду мэров, губернаторов и президентов. Так вот, теперь эта книга первая в списке тех, которую я буду рекомендовать любым менеджерам. Она очень хорошо объясняет сразу несколько вещей: • Как вообще работает власть и как ее получить, когда у тебя нет никаких прямых рычагов. • Как добиваться результатов в проектах, которые все считают невыполнимыми. • Как использовать политические механизмы для пользы дела. • Как власть меняет и самого человека, и превращает благие намерения во что-то отвратительное и разрушительное. Чтобы вас заинтересовать, буквально несколько замечательных историй из книги: 👉Чтобы получить финансирование для строительства мостов (а Мозес ну очень любил строить мосты), он выпускал облигации. Облигации сопровождались большим количеством дополнительных условий, среди которых было и описание конкретных полномочий Мозеса. Купленная облигация по сути является подписанным контрактом, а сила контракта охраняется конституцией. Таким образом, после продажи пачки облигаций, формальное подчинение Мозеса мэру не значило ровным счетом ничего – никто не мог контролировать его решения. 👉Мозес был королем получения государственных грантов для своих проектов. Он получал их не потому, что занимался самыми полезными вещами (на самом деле многие из его инициатив, наоборот, активно вредили городу). Секрет был в другом – он всегда приходил за грантом с готовым просчитанным до мелочей проектом строительства, в то время как все остальные вбрасывали вялые неоформленные идеи. Короче говоря, побеждают не лучшие идеи, а наиболее готовые к реализации. 👉Мозес никогда не ждал формального одобрения полного бюджета для своих проектов. Вместо этого он начинал работать с доступным минимумом денег, закладывал базовую инфраструктуру, рассказывал прессе о том, как все будет прекрасно, и только потом шел запрашивать дополнительный бюджет. И ответственные за выделение денег были в тупике – если они бюджет не выделят, их распнут за то, что они заморозили перспективную стройку, результатов которой уже ждут все вокруг. Иначе говоря, чем больше людей и ресурсов уже включено в проект, тем политически сложнее его остановить. Готовьтесь к тому, что чтение может быть не самым простым – например, целая глава посвящена описанию опор одного из построенных Мозесом мостов. А другая рассказывает во всех деталях про зонирование Лонг-Айленда и то, кому из нефтяных баронов какой участок принадлежал. Тем не менее, читать это все равно невероятно интересно – автор, Роберт Каро, получил Пулицера за эту книгу во многом благодаря тому, насколько захватывающе он может писать о, казалось бы, очень скучных вещах. Короче говоря, я правда очень-очень рекомендую вам ее прочитать.

Ошибка периферийного примера Я принес новое когнитивное искажение в вашу копилку, чтобы вы могли эффективнее отбривать своих оппонентов в спорах. Суть в следующем: 👉Предмет спора можно отнести к категории, архетипичные примеры которой вызывают сильную эмоциональную реакцию. 👉Предмет спора при этом по факту находится где-то на периферии категории. 👉Так как предмет формально относится к категории, то эту эмоциональную реакцию автоматически распространяют и на него. Несколько примеров, чтобы было понятнее: 1️⃣Мартин Лютер Кинг сидел в тюрьме, а и значит он плохой человек. 2️⃣Генетическая инженерия это евгеника, а значит неэтична. 3️⃣Дублирование одной и той же функции в двух классах нарушает DRY, а значит – говнокод, и вредит системе. Не используйте такие аргументы, пожалуйста, и не давайте использовать другим.

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

Вы просто неправильно используете фреймворк Если вы попробовали внедрить модный подход, и у вас не получилось, то самой частой реакцией от его апологетов будет "ну вы просто использовали его неправильно". Да что уж там, я таким же был – ходил по конференциям, рассказывал, как мы в Авито прекрасно жили с OKR, а когда кто-нибудь рассказывал про свой неудачный опыт, то бросался объяснять, что он просто не разобрался, как правильно. Проблема тут не в том, что OKR не работают или вредны. Как и в случае большинства других подходов (ну кроме холократии конечно), есть много компаний, которым такой подход к целеполаганию полезен. Ошибка состоит в другом, и мне нравится, как автор статьи ее определяет:

I call this the “Precision Fallacy”: the belief that a more precise understanding or implementation would have worked, where the precision in question is undefined, or so intricate that it’s impossible to follow, and thus it’s an un-dis-provable excuse.

Нет ничего плохого в том, чтобы пробовать решения, которые сработали где-то еще, подкручивать их под ваши обстоятельства, и быстро выкидывать, если пользы нет. И что бы в этот момент вам ни говорили их сторонники, помните, что проблема скорее всего не в том, что вы сделали что-то не то, а в том, что конкретное решение не очень хорошо подходит конкретно вашим обстоятельствам.

Еще одна эвристика для боттлнека в code review Продолжаем обсуждать, как справляться с однозначно выросшим количеством кода, который нужно ревьюить. Как и в примере с Claude Code, в этой статье основная идея тоже крутится вокруг того, чтобы определять подмножество PR, которые можно не ревьюить. Для этого CI автоматически помечает часть PR как small-change при выполнении следующих условий: 👉Меньше 1000 строк. 👉Автоматическое ревью не нашло проблем с высоким приоритетом. 👉Автор PR слил хотя бы 10 других изменений, затрагивающих изменяемый модуль. Если PR трогает сразу несколько модулей, проверка опыта запускается для каждого. 👉Затрагивает не больше, чем N отдельных сервисов или приложений. Во фронтовой монорепе N=1, в бэкендной N=3. 👉Не затрагивает общие библиотеки. 👉Не затрагивает файлы, прописанные в отдельном конфиге, для которых обязательно ревью от человека. Вот с такой эвристикой 10% всех PR попадают под этот фильтр и мерджатся автоматически.

Как в Anthropic делают code review Ежемесячное количество PR в Claude Code выросло с с 2500 в мае до 30000 в сентябре. Еще раз, тысяча PR в день! Конечно, код такими темпами читать они не будут. Вместо этого вот как они подходят к code review: 1️⃣Локальные проверки, которые выполняет сам агент: прогон тестов, проверка дизайна на соответствие гайдлайнам, агентское ревью для поиска багов. 2️⃣AI ревью на PR. Один агент находит проблемы, другие их перепроверяют, а самые важные уходят на аппрув человеку. 3️⃣Автоматическое security ревью, которое может заблочить PR. 4️⃣Автоматические чеки – линтеры, куча тестов, тайпчеки и все в этом духе. 5️⃣Самое интересное – risk-based человеческое ревью. Тривиальные, либо закрытые фичефлагом изменения вообще его не требуют; средний риск ревьюит один человек; высокий риск - два человека. При этом это разделение касается только списка доверенных авторов. Например, изменения людей из других команд обязательно ревьюятся человеком. 6️⃣Все эти автоматические чеки прогоняются еще раз после того, как подходит очередь слить PR в мастер. Дальше фича обычно раскатывается на аудиторию постепенно. Если суммировать, то люди чаще всего подключаются к следующим решениям: 👉Надо ли вообще делать какую-то фичу, плюс разные решения по скоупу 👉Изменения в хай риск коде вроде биллинга 👉Архитектура, которая с большой вероятностью может быть повторена где-то еще 👉Ревью свидетельств того, что агент сделал работу – скриншоты, тесты, трейсы

Что беспокоит разработчиков На прошлой неделе вышло сразу несколько интересных исследований, постепенно буду разбирать. Первое – State of Developers, от ребят, которые много лет делают исследования JS экосистемы. 👉Пять главных проблем, с которыми разработчики сталкивались за свою карьеру: плохой менеджмент, выгорание, проблемы с work/life balance, скука и боязнь потери работы. 👉Самый частый вид дискриминации – по возрасту, с ним сталкивались 13% опрошенных. 👉Ловите лайфхак – люди с должностью engineer получают в среднем на 65000$ больше, чем developers. 👉Среди рисков, связанных с AI, количество слоп-кода волнует больше людей, чем использование AI в военных целях😅 👉Самые частые проблемы со здоровьем – плохой сон, лишний вес, менталочка, больная спина и мигрень.

📞 Входящий звонок: VK JT Mobile Meetup 31 октября в Москве и 14 ноября в Санкт-Петербурге VK собирает опытных iOS- и Android-разработчиков. В Москве пройдут два параллельных трека — по iOS и Android. В Петербурге — общий трек для обеих платформ. Спикеры из ВКонтакте, Дзена, MAX, VK Tech и других команд VK разберут инженерные кейсы: расскажут о производительности, тестировании, архитектуре, импакт-анализе, ИИ и других задачах мобильной разработки. После докладов можно обсудить подходы с коллегами, поучаствовать в интерактивах и пообщаться на афтепати. Только офлайн. Количество мест ограничено. 👉 Регистрация

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

🚀 AI ускорил разработку. А что происходит с тимлидом? С 19 по 23 октября пройдёт новый сезон конференции Podlodka Teamlead Crew — «Системный подход к AI в работе тимлида». Участники будут разбираться, как руководителю превратить разрозненные AI-практики команды в работающие процессы, найти точки роста, сохранить эффективность — и при этом позаботиться о себе и коллегах. Участники сезона: 🧠 Узнают, как меняется мозг при постоянном использования ИИ, и как справляться с новой нагрузкой 👥 Увидят, как меняется матрица компетенций в команде, где код пишет AI 📊Подберут метрики эффективности AI и отделят реальные результаты от цифр, которым не стоит доверять 💬Вместе с тимлидом и психологом разберут кейсы на тему «Как жить с AI FOMO» — можно будет принести свою ситуацию и получить обратную связь. При этом в сезоне будут говорить не только об эмоциональной стороне работы с AI, но и о системных изменениях. Участники будут искать настоящие ограничения на пути от идеи до релиза и разбираться, что действительно стоит улучшать, а что не нужно ни ускорять, ни менять. 🎟Полная программа и билеты на сайте: https://podlodka.io/tlcrew

Синтетические митинги Если вам надо срочно показаться занятым и для тех, кто смотрит в календарь, и для тех, кто смотрит вам в монитор, держите конструктор синтетических митингов: 👉В календаре появляется встреча на нужный слот 👉На мониторе показывается UI стандартного митинга, с голосами, обсуждающими заданную тему – от All Hands до звонка с разбором инцидентов 👉Выводите звук от встречи прямо на динамики, и никто к вам в офисе не подойдет, так как все будут уверены, что вы заняты

Стартует новое исследование рынка тимлидов Как мы тут обсуждаем практически каждую неделю, этот год принес с собой гигантский шифт во всем перечисленном. Менеджеры снова должны быть более техническими и погруженными в детали происходящего, команды стали меньше, а объем работы - на порядок больше. Это точно происходит в заграничном бигтехе и стартапах, но вот насколько докатилось до России – вопрос. Так вот, ребята из DevCrowd делают ежегодные исследования того, что происходит с разными айтишными профессиями в русскоязычной среде. Одно из самых больших исследований – как раз про руководителей разработки – как меняются задачи, скоуп роли, проблемы, важные скиллы и зарплаты. Опрос анонимный, все результаты будут в открытом доступе где-то в середине декабря. Голосуйте, я потом обязательно сделаю разбор!

😎 Авито снова участвует в Рейтинге работодателей hh.ru! В прошлом году благодаря вашей поддержке мы вошли в топ-3 IT-компаний страны. Если вам откликается то, что мы делаем, проголосуйте за Авито и в этом году ❤️ Как поддержать компанию: — Перейдите на hh.ru и авторизуйтесь в личном кабинете. — Найдите Авито в списке компаний и оставьте свой голос. ✔️ Проголосовать за Авито Спасибо за поддержку! #РейтингРаботодателейРоссии

Состояние нашей индустрии в 2026 Хороший срез основных трендов в разработке на сегодня: 👉Все меняется очень быстро – мы и раньше привыкли к довольно быстрому темпу смены технологий, но ничего даже близкого к текущей скорости еще не было. 👉Никто не пишет код руками (тут подтверждаю, я в последнее время интервьюировал десятки инженеров по всему миру, и руками хорошо если 5% работы делаются). 👉Большинство одновременно работает с несколькими агентами в параллель, и учатся справляться с когнитивным перегрузом из-за этого. 👉Количество PR за авторством агентов точно стало больше, чем человеческих. Это касается и всего GitHub, и ситуации в отдельных компаниях. 👉Скиллы стали стандартным используемым примитивом и внутри компаний, и в сообществе. 👉IDE очень-очень быстро умирают. 👉Довольно значимая часть агентских задач инициируются из Slack. 👉Все вокруг экспериментируют с разными видами автономных фабрик. 👉Большие миграции с одной технологии на другую занимают недели и месяцы, а не годы. 👉Токенмаксинг уходит в прошлое, все начинают следить за тратами на AI и искать пути сэкономить. 👉Проектная работа постепенно превращается в задачи на одного или максимум двух человек, но никак не на большую команду. 👉Инженерные специализации пропадают. Например, уменьшается спрос на iOS/Android/Frontend, но растет спрос на более универсальных инженеров.

Новые выпуски тимлидских подкастов 👉"Бреслав и Ложечкин" про то, что такое сложность и откуда она берется 👉Подлодка про AI в математике с обсуждением того, насколько сильно в сообществе математиков сейчас повторяется то, что мы уже видели среди программистов 👉КОДА КОДА про то, как читать в эпоху AI и фильтровать входящую информацию

20 лет назад ВКонтакте выглядел совсем иначе. Да и сама задача развития большой соцплатформы сегодня уже не сводится к тому, чтобы просто добавлять новые функции. За привычными для пользователя сценариями стоит довольно сложная технологическая система, которую требуется обновлять. Например, команда ВКонтакте сейчас переводит часть сервисов на Go, меняет работу с базами данных и отдельные компоненты инфраструктуры — при этом сам продукт продолжает работать без остановки. Интересно, что такие изменения в итоге заметны и в обычных пользовательских сценариях. Например, обновлённая статистика для авторов теперь работает быстрее и хранит данные за всё время, а не только за последние три месяца. О том, что происходит с ВКонтакте «под капотом» и зачем большой платформе меняться, поговорили с техническим директором ВКонтакте Юрием Кочаряном в новом выпуске подкаста «Потом доделаю». Посмотреть выпуск можно здесь.

«Нива» на Avito.Tech.Conf? Что? Да! Идеальное воплощение слогана конфы: «Для тех, кто действительно управляет сложным» 🚀 Но это не главное! В эту субботу Avito.Tech.Conf собрала более 1000 CTO, технических директоров и руководителей разработки из разных IT-компаний. На докладах и воркшопах, говорят, были полные залы. Как и в зонах активностей — тимлид-«техосмотр», 1–1, управленческий покер и «тихий аукцион» с редкими вещами. А еще было то, чего ни у кого никогда на конфах не было, — IT-погребок с закрутками! Кстати, кто был, с вас лайк! А если вас не было или вы пропустили конференцию — смотрите доклады онлайн: – на YouTube – в VK Очень ждем Avito.Tech.Conf в следующем году 🤝

Где стафф инженеру брать идеи проектов Классическое ожидание от staff-level инженера – это умение самому найти идеи, стоящие того, чтобы их реализовать. Какие-то идеи могут следствием наблюдаемых в компании проблем, какие-то – запросами пользователей, а какие-то – реакцией на то, что происходит на рынке. 👉Идеи можно брать из сигналов, производимых обслуживаемой системой: инциденты и постмортемы на них, стоимость каких-то кусков инфраструктуры, сопутствующая стоимость вашей собственной работы, происходящая из-за каких-то проблем в DX. 👉Идеи можно брать от ваших пользователей, если вы делаете внутреннюю платформу – конечно, помня о классическом уроке из продакт-менеджмента про то, что фиче-реквесты не стоит воспринимать буквально: надо регулярно разговаривать с пользователями, интервьюировать их про проблемы, смотреть за тем, пытаются ли они решать с помощью ваших инструментов юзкейсы, для которых они и не бвли предназначены. 👉Очевидно важный источник сигналов – ваша организация: OKR, общая стратегия, проблемы, о которых регулярно вспоминает ваш менеджер, любые миграции между техническими стеками и платформами, которые имеют свойство никогда не заканчиваться. 👉Сигналы от индустрии: сравнивать ваши системы с SOTA того, что есть на рынке.