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

Альтернатива командной работе

Слаженной групповой работы можно добиться двумя способами:

👉За счет внутренней регламентации, когда правила вырабатываются и контролируются участниками группы, и команда едет сама.
👉За счет внешней регламентации, когда все условия игры задаются внешним руководителем, и группа едет за счет его пинков.

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

Собеседования глазами инженера

Начнем с предлагаемых автором принципов хорошего собеседования. Интервью должны:

👉Дифференцировать кандидатов, помогая отличать опытного сеньора от волка с AI под рукой.
👉Быть прозрачными, отражая фактические должностные обязанности, а не синтетические задачи.
👉Смотреть в перспективе, отдавая предпочтение соискателям, которые хорошо впишутся в команду на годы вперед.
👉Экономить время обеих сторон.
👉Строиться на уважении к соискателю.
👉Помогать оценить наличие инженерного вкуса.

Этим принципам отвечают не все из привычных форматов:

❌Лайвкодинг. Слабо показывает долгосрочную ценность сотрудника, не помогает дифференцировать кандидатов, слабо связан с повседневной работой. Да и по остальным принципам плоховато проходит – вкус не оценить, и многие кандидаты оценивают такой этап как неуважение к себе и своему времени.
❌Тестовые на дом. Проваливает пункты по экономии времени, дифференцированию и прозрачности. К такому собеседованию легко подготовиться с помощью AI.
ℹ️Проектирование. Вариант получше, но все еще не идеальный. Код человека вы не увидите.
✅Разбор примеров работы или опенсорсных проектов. Тут все хорошо, но только если такие примеры у кандидата есть.
✅Код-ревью плохого кода – кандидат и собеседующий вместе разбирают подготовленный заранее проект. Очень уважительный ко времени кандидата вариант, плюс хорошо обеспечивает прозрачность и помогает оценить вкус.

И еще одно правило борьбы с плохо организованными встречами по принятию решений.

Вам надо ответить всего на три вопроса:

1️⃣Какая информация нужна, чтобы принять решение?
2️⃣Есть ли у нас эта информация?
3️⃣Какое решение принимаем?

При этом для ответа на первые два вопроса никаких встреч собирать не нужно.

Как бороться с лишними созвонами

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

Результаты опроса Stack Overflow за 2025

Во вполне вероятной смерти Stack Overflow в ближайшие годы мне больше всего жаль будет потерять их ежегодные опросы, которые дают репрезентативный и очень полезный срез индустрии. Вот несколько интересных фактов за этот год:

🧑‍💻Про разработчиков:

👉Только четверть разработчиков счастливы на своей работе, но в прошлом году таких было еще меньше.
👉Больше всего на счастье влияют автономность, хорошая компенсация и решение реально важных проблем.
👉Основные причины по которым разработчики теряют интерес к инструментам: проблемы с приватностью, цена, наличие альтернатив получше. А вот отсутствие AI ни для кого не является проблемой.

💻Про технологии:

👉Самый быстрорастущий язык, ожидаемо, Python, причем на невероятные 7%. Среди баз данных быстрее всего растет Redis.
👉В списке самых любимых языков новичок – Gleam. Обязательно про него выпуск Подлодки скоро запишем!

🤖Про AI:

👉В прошлом году к AI относились на 10% позитивнее, чем в этом. Что контринтуитивно – профессиональные разработчики ценят AI больше, чем начинающие.
👉84% опрошенных используют AI в своей работе.
👉Чаще всего AI используют для поиска и генерации контента, а реже всего – для деплоя, мониторинга, планирования проекта.
👉AI агенты все еще не стали мейнстримом, только треть опрошенных их как-то использует. Из них 70% считают, что их продуктивность выросла.

Как стресс влияет на прохождение интервью

Группа рисерчеров из 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 стиле, менеджеры часто превращаются в оркестраторов – они отвечают только за последние три шага, и вообще не представляют, что в другой компании с большей автономностью от них могли бы ожидать лидерства – то есть еще и принятия решений про то, что делать.

Вот признаки менеджера-оркестратора:

👉Относится к приоритизации как к своему основному инструменту работы. Это единственное, что доступно, когда ты не можешь повлиять ни на решаемые проблемы, ни на форму решения.
👉Принимает приносимые проблемы и решения как данность, единственное, что спрашивает – про их приоритет относительно других задач.
👉Фокусируется на планировании и процессах, защищает команду от изменений планов всеми силами.

Про нормализацию девиаций

Если проблемы не исправляются в течение какого-то времени, то люди привыкают жить с ними и они становятся новой нормой. Скорее всего, вы сталкивались с такими историями в своем опыте:

❌Сломанные тесты в кодовой базе были замьючены вместо починки, спустя какое-то время такая же судьба постигла все тесты, и постепенно их отстутствие стало новой нормой.
❌В команду внедряли скрам, на негативные последствия закрыли глаза, и в итоге все приняли как норму то, что треть рабочего времени съедается на абсолютно бесполезные встречи и упражнения с бэклогом.

Давайте разбираться, почему нормализация девиаций очень опасна:

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

Про три пути тимлида

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

Карьерный рост тимлида – штука гораздо более загадочная. Вот какие варианты предлагают в статье:

1️⃣Расти вверх по менеджерской ветке

С какими сложностями предстоит столкнуться:

👉Часто на высокие менеджерские позиции компании нанимают "варягов" снаружи. Это делается с простой целью – сломать исторически сложившиеся нормы и принести новую кровь. Единственный хороший способ этому что-то противопоставить – делать свою заинтересованность в дальнейшем росте очень явной, чтобы о ней знали и ваш менеджер, и его менеджер. Ну и не пропускать любые возможности.
👉Набор нужных скиллов будет меняться. Надо понимать, насколько вы готовы к решению задач, которые будут ждать на уровень выше, и насколько вы готовы потерять те навыки, которые есть сейчас (например, близкую работу с кодом).
👉Нужно честно ответить себе на вопрос – готовы ли вы принимать все более сложные решения, влияющие на людей – увольнения, сокращения, закрытие проектов.

2️⃣Работать в режиме маятника, и раз в два-три года переходить из менеджера в разработчика и обратно

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

Второй плюс – хорошо работает для тех, кто чувствует усталость от текущей роли, но не полное отторжение. Отвлеклись на пару лет, выдохнули, вернулись обратно.

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

3️⃣Переход обратно в разработчики

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

LLM не подходят для психотерапии

Кто такой хороший менеджер, как не психотерапевт на четверть ставки. Так что выдыхаем – AI как минимум эту нашу функцию пока что не заменяет. В новом исследовании попробовали оценить, насколько хорошо современные LLM могут справляться с базовыми задачами психотерапии. Вот что выяснили:

👉LLM склонны стигматизировать ментальные проблемы. Услышать от AI "сам виноват" явно не помогает.
👉Многие ответы вообще небезопасны. Например, на вопрос вида "Меня хотят уволить, какие рядом есть мосты?" с большой вероятностью модель выдаст список мостов.
👉Эти проблемы свойственны не только моделям в чистом виде, но и коммерческим ботам-оберткам вокруг них. Что забавно, работают они еще хуже.
👉LLM не очень хорошо справляются с базовыми навыками психотерапевта – причинно-следственный анализ, отслеживание прогресса по разным кейсам.
👉LLM склонны угождать собеседнику, а в терапии это красный флаг.