Свежая подборка тимлидских подкастов

Держите последний в этом году дайджест подкастов, и сохраняйте выпуски на длинные праздники!

👉Бреслав и Ложечкин про разработку внутренних платформ, организационные структуры и проблемы, связанные с ними.
👉Подлодка про рынки предсказаний, как публичные, так и внутрикорпоративные – как надежный способ прогнозировать будущее.
👉"Три тимлида заходят в бар" про кризисы в команде – что такое кризис, как понять, что он происходит, поддерживать команду и выходить из него.
👉Weekend Talk про поиск C-level позиций и текущее состояние рынка.
👉"Едим слона целиком" про то, от каких руководителей уходят команды, и как управлять своими негативными чертами личности.

Исследование про стратегию от Стратоплана и DevCrowd

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

Школа менеджмента Стратоплан совместно с DevCrowd проводят большое исследование о том, как управленцы в ИТ-компаниях — от IC и тимлидов до C-level — работают со стратегией: как её формулируют, кто вовлечён, с какими трудностями сталкиваются и как измеряют успех.

Зачем участвовать?

— В качестве благодарности за ваши 10 минут  — модули из курса «Стратегия» от Славы Панкратова, основанного на материалах Wharton University of Pensilvania и Oxford Executive Strategy Programme
— Поможет вам структурировать собственный взгляд на стратегию;
— Получите главные инсайты от Стратоплана и DevCrowd, на основании которых, возможно, вы поймете что не так «уже завтра»

📬 Принять участие в опросе: https://stratoplan-school.com/research/

🕒 Опрос займёт 7-10 минут — именно ваши ответы помогут внести вклад и понять реальную картину на рынке.

P.S. Обязательно делитесь опросом с коллегами — чем больше ответов, тем репрезентативнее будут результаты

Главный навык, определяющий сеньора

Если откинуть все громкие слова про лидерство, прозрачные коммуникации, архитектурные навыки, проактивность и прочее – то главное, что останется – умение снижать неопределенность.

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

Сеньоры умеют постепенно уменьшать риск неопределенного проекта, задавая правильные вопросы, находя на них ответы и постепенно декомпозируя его на понятные небольшие куски. Примеры таких вопросов:

👉Какую проблема мы на самом деле решаем?
👉Кто наш пользователь, и что у него болит?
👉Какие наши предположения могут быть ошибочными?
👉Что случится, если мы ошиблись, но все равно выпустим релиз?

Идея для новогоднего подарка, которая точно выделяется среди привычных гаджетов — Mind Tracker.
Это персональный тренер для мозга, который помогает снижать стресс, держать голову ясной и избегать выгорания.

Такой подарок подойдет тем, кто много работает головой: креаторам, IT-специалистам, предпринимателям и тем, кто заботится о себе. Mind Tracker определяет и показывает что происходит с мозгом, помогает улучшить качество жизни и управлять своим состоянием.

В приложении есть короткие тренировки c биологической обратной связью, которые помогут продуктивно работать, эффективно отдыхать и легко справляться со стрессом. Формат по 6-9 минут с фидбеком позволяет видеть реальный результат, а не действовать вслепую.

Сейчас на Mind Tracker доступна скидка по промокоду TEAMLEAD, поэтому это особенно удачный вариант подарка — себе или близким.

Дополнительно можно записаться на бесплатную вводную консультацию, где подробно рассказывают, как работает технология и как читать показатели в приложении — отличный старт для знакомства с нейротрекингом. Получить более подробную информацию об устройстве и попробовать его на себе можно по ссылке: https://clc.to/o7aPxg

И снова возвращаемся к вопросу promotion driven development в бигтехе.

Опыт работы по фреймворку Shape Up

Shape Up – довольно модный сейчас фреймворк организации командной работы. В чем суть:
👉Команда работает циклами по 6 недель сфокусированной продуктовой работы, после каждого из которых идут 2 недели на багфиксы, менее приоритетные задачи, техдолг и планирование следующей итерации.
👉До попадания в цикл разработки каждая идея проходит этап Shaping, на котором снимается достаточно рисков, чтобы над ней можно было начинать работать.
👉В цикл попадает очень ограниченное количество идей. Если не успевают сделать – режут скоуп.

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

We turned to the framework to create focus and discipline through process when what we really needed was clearer product direction.

Мне прямо очень сложно вспомнить, когда за любой проблемой с процессами на самом деле во весь рост не стояла бы проблема отсутствующей продуктовой стратегии🤷

Если у вас есть свободный час времени, подключайтесь на традиционный новогодний стрим подкаста Подлодка – будем подводить итоги года, рассказывать про наши главные открытия, самые полезные книги и всякое такое. А главное – разыграем среди зрителей Switch 2!

👉Начинаем через 10 минут

Подборка лучших постов за 2025 год

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

🤝Управление людьми и командой
Кто виноват в плохой передаче знаний при увольнении
Про принадлежность к группе
Непопулярные мнения про организацию команд
Никогда не используйте DISC
Сколько инженеров работают на двух работах сразу
Советы по управлению большими проектами

❤️Культура
Важность благодарности для менеджера
Избегайте нытиков
Почему 10х инженеры – антипаттерн
Принципы СТО Amazon
Менеджмент через последствия
Почему бигтех такой медленный

🤖AI
Карьера вайб-кодера – это тупик
Заменять джунов на AI – тупейшая идея
AI код сразу же становится легаси
AI фейки на собеседованиях
Почему сеньоры теперь особенно ценны

↗️Карьера менеджера
Как прокачаться в менеджменте за год
Топ-5 красных флагов при поиске работы
Как понять, что компания тебе не подходит
Про карьеру в форме пирамиды
Как начинать работу в новой компании
Как получать удовлетворение от работы

Ну и вообще, с наступающим, держитесь там, и продолжайте ставить лайки к статьям и вести холивары в комментариях!

Помогают ли дэйлики

Держите результаты интересного рисерче по одной из наших любимых холиварных тем:

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

Я пробежался по другим бумагам, прямо хорошего мета-анализа нет, но нет и каких-то опровергающих исследований. Так что, коллеги, встречаемся в понедельник в 9 утра на 15 минутный созвон!

Главные уязвимости агентских приложений

Вот только недавно я жаловался на то, что в OWASP как-то совсем ничего нет про зарождающиеся классы уязвимостей AI приложений – и вот под это дело они опубликовали отдельный рейтинг.

1️⃣Подмена цели – атакующий манипулирует тем, какие задачи преследует агент, или тем, как он принимает решения.
2️⃣Эксплойты тулов – агент оперирует в изначально установленных пользователем рамках, но использует один из предоставленных ему тулов не так, как предполагалось – например, для удаления ценной информации, вызова дорогого API, выборочной передачи приватной информации.
3️⃣Абьюз систем IAM – здесь много всего, начиная от использования привилегий агента в злонамеренных целях, заканчивая кражей учетных данных.
4️⃣Уязвимости цепочек поставок – тоже большой класс уязвимостей, к которому можно отнести как дырки, заложенные в веса моделей или логику агентов, так и взлом через установку агентом скомпрометированных библиотек в ваши приложения.
5️⃣Выполнение небезопасного кода – то самое, что в первую очередь приходит на ум. Агент пишет код, вы его исполняете, а где-то в нем оказывается написана логика по выдаче рутового доступа к вашему серверу кому-то со стороны.

Как менять поведение систем

Донелла Медоуз – автор очень известной книги про системное мышление "Thinking in Systems". Есди вы ее не читали, то вот это ставшее уже классическим эссе про то, какие рычаги для изменения поведения систем существуют, даст довольно хорошее представление о материале.

Фальшивые догмы

Некоторые правила разработки менеджеры слепо повторяют друг за другом, хотя, если задуматься, они имеют мало смысла. Вот несколько примеров:

👉Не переизобретайте колесо и берите готовые библиотеки. На самом деле, это трейд-офф, на другой стороне которого – ценность хорошего понимания кода, и безопасность от supply chain атак.
👉Каждый PR кто-то должен заревьюить. Цена обязательных ревью очень высокая, поэтому, хоть они и поднимают качество кодовой базы, не нужно доводить это правило до абсолюта и ревьюить тривиальные вещи.
👉Все современные команды должны работать короткими спринтами. Не всегда тот факт, что вы работаете по спринтам, делает вас гибкими. Более того, не вся разработка должна быть гибкой.
👉Каждая фича должна быть за флагом. Точно нет, так как огромное количество флагов усложняет даже самый тривиальный код, а ценность от них есть не всегда.

Полезные правила работы с календарем

👉Решайте конфликты между накладывающимися друг на друга встречами максимально рано. Чем раньше вы отклоните один из них, тем удобнее будет для всех его участников.
👉Используйте цветовое кодирование для митингов разного типа. Например, их можно делить по требуемому уровню фокуса, формату, решаемой проблеме, роли или еще чему-то, что имеет смысл именно для вас.
👉Используйте эту категоризацию для бюджетирования времени – например, на уровне одной недели можно поставить ограничение на количество собеседований.
👉Бронируйте слот на обед.
👉Делайте события в календаре редактируемыми всеми участниками по умолчанию, так их будет проще переносить.
👉Если у вас есть и личный, и рабочий календарь, слоты в которых пересекаются, используйте Reclaim для их автоматической синхронизации.
👉Забронируйте первый день после отпуска под то, чтобы снова въехать в контекст и разобрать все накопившееся, иначе встречи не дадут этого сделать.

Почему нанимать джунов стало выгоднее

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

Джун – это ставка с определенным уровнем риска. Вы нанимаете неопытного человека, вкладываете в него время и ресурсы кого-то опытного из команды, и не можете быть на 100% уверены, что по итогу эти вложения оправдаются.

Красная линия на графике – профит от джуна. Первое время он отрицательный, и, если вам повезет, когда-то выйдет в плюс. Сократить эту отрицательную область можно с помощью правильного онбординга и обучения, которые будут помогать быстрее приносить пользу, поддерживая достаточный уровень качества. Так вот, AI как раз с этой частью отлично помогает – если вы еще не использовали тот же Claude Code для онбординга в незнакомый код, обязательно попробуйте.

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

Реорг на вайбе

У реоргов есть несколько очень частых проблемы:

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

Как думать про компенсацию

Мне нравится, как автор сформулировал цель процесса компенсации:

Создать самую талантливую и мотивированную команду, которую только позволит вам ваш бюджет.

Это значит, что следующие вещи не являются самоцелями:

❌Сделать сотрудников счастливыми
❌Сохранить команду любой ценой
❌Сэкономить на ФОТ
❌Платить на уровне рынка, или на уровне какой-то конкретной компании
❌Соответствовать ожиданиям сотрудников
❌Платить всем одинаково

Если подумать над целью более рационально, то вам важно обязательно соблюдать следующее:

👉Платить самым ценным членам команды на уровне, на котором им будет сложно найти на рынке другую работу
👉Не допускать нечестной компенсации, использовать понятные и прозрачные зарплатные уровни
👉Быть готовым объяснить любое свое зарплатное решение
👉Максимизировать выравнивание интересов людей и компании через equity и performance-based бонусы

Как разные роли используют AI

Сценарии использования AI инструментов довольно сильно отличаются в зависимости от роли человека:

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

Тимлидов спросить забыли, но мы ведь понимаем, что в основном для написания перфоманс ревью!

Про мораль корпораций

На этой неделе весь Reddit обсуждает анонимный пост от сотрудника какого-то крупного приложения доставки еды, в котором рассказано про какие-то совсем неэтичные практики:

👉Фича priority delivery, которая на самом деле не влияет ни на что, кроме флажка, отправляемого на сервер.
👉A/B тесты с замедлением скорости доставки неприоритетных заказов.
👉Автоматическое определение курьеров, которые готовы браться за заказы любой стоимости, и занижение им оплаты.
👉Чаевые, которые целиком уходят в карман платформы.

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

Очень подробно про это рассказано в вышедшей в прошлом году книге Careless People, в которой бывший топ-менеджер Meta делится байками про то, как Цукерберг и компания принимают решения и разруливают происходящий по их вине геноцид (и даже не один). Если вот эта история про доставку еды показалась вам нереалистичной, очень советую прочитать!

Так вот, расскажите в комментариях, сталкивались ли вы с тем, что ваша компания принимает решения, которые идут вразрез с вашей этикой? Как действовали?

Законы разработки софта

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

👉Закон Каннингема – Самый лучший способ получить полезный и правильный ответ в интернете – не спрашивать, как правильно, а запостить неправильный ответ.
👉Закон Стерджена – 90% чего угодно это мусор (ну получается как минимум один пост в две недели в нашем канале должен быть годным).
👉Закон Хайрума – от любого, пусть даже незадокументированного поведения вашего API, кто-то будет зависеть. Про этот закон мы пару лет назад классно поговорили в выпуске Подлодки про дизайн API.
👉Эффект Рингельмана – чем сильнее растет группа, тем сильнее снижается продуктивность отдельных ее участников.