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

Amazon переводит стрелки с AI на людей У Amazon за последнее время произошло несколько крупных падений, и как минимум в одном из них точно был замешан AI. Разработчик случайно оказался в продовом окружении вместо тестового, Kiro дернул команду не с теми флагами, и один из сервисов после этого лег. AWS во всех пресс-релизах после этого пытается всячески уйти от ассоциаций с AI, и говорит о том, что это человеческая ошибка – а в интернете на это смотрят как на попытку защищать AI. С моей точки зрения AWS все правильно делает. Проблема не в том, что AI дернул не ту команду, а в том, как выстроены процессы разработки и гардрейлы вокруг него. Как вообще разработчик случайно оказался в проде и смог что-то там поменять? Почему команда с такими сайд-эффектами была вызвана без одобрения? Все это выглядит, как провалы в тулинге, и вообще не важно, детерменистическая или вероятностная система там под капотом.

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

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

Я запускаю закрытый клуб про AI в разработке Так получилось, что я нахожусь практически в эпицентре того, что происходит с использованием AI в разработке – и благодаря моей основной работе в компании, которая делает девтулинг, и благодаря подкасту, и благодаря друзьям, которые горят этой темой. Но недавно я поймал себя на мысли, что я все равно испытываю жесточайший FOMO – индустрия меняется, а я за ней не успеваю. Если эта проблема горит у меня, то скорее всего таких людей очень много. А я люблю решать проблемы – поэтому я решил собрать Podlodka AI Engineers Club – закрытое сообщество опытных разработчиков, которые хотят вместе разбираться с тем, как использовать AI с пользой, и делать это системно, а не на ощупь. 👉Как это вообще работает. Каждую неделю – воркшопы и лайвкодинг с людьми, которые активно используют AI, и внедряют его в реальные продукты и компании. Разбор конкретных инженерных практик: как строить своих агентов, как работать по Spec-Driven Development, как собирать комбайн, превращающий таски в Jira в PRы, как масштабировать это и на небольшую команду, и на всю разработку в бигтехе. Между встречами – сеть закрытых чатов в Telegram, клубные созвоны, совместные эксперименты. 👉Кто уже в программе. Черновое расписание на март-апрель собрано. Среди экспертов – инженеры из компаний разного масштаба: Степан Гончаров (xAI), Роман Елизаров (Яндекс), Андрей Володин (Gracia AI), Андрей Бреслав (CodeSpeak), Денис Неклюдов (Google), Макс Страхов (Meta) и много других крутых ребят. 👉Как попасть. Клуб платный, вход через список ожидания с отбором – нам интересно сделать сообщество именно для опытных разработчиков. Мы набираем участников постепенно – нам важно сохранить атмосферу, в которой можно открыто делиться опытом и проблемами. Стартуем уже с понедельника! Отдельно подчеркну, что клуб делаем именно для инженеров – людей, которые большую часть своей карьеры писали код, решали технические задачи, принимали архитектурные решения, и жили с их последствиями. Я знаю, что на канал подписано довольно много технических менеджеров, и senior/staff/principal инженеров – вот этот анонс для вас! Подробности, расписание и заявка – на сайте. А если есть какие-то конкретные вопросы, пишите прямо мне в личку, @etolstoy!

Как правильно отдыхать Отдых – это не награда за какие-то действия, это часть полноценной и насыщенной жизни. У меня лично с этим тезисом очень сложно – мне очень сложно прямо отдыхать-отдыхать, и я обычно имитирую это переключением между разными видами деятельности. Условно говоря, чтобы отдохнуть от работы, занимаюсь какими-то подкастными делами, или сажусь пописать код. Если вместо этого я трачу время "бесполезно" – я быстро начинаю чувствовать очень изматывающее чувство вины. Никому не рекомендую, сказывается на мне не очень хорошо. Я очень активно пытаюсь бороться с таким восприятием отдыха, но прогресс пока ниже среднего. Так вот, держите хороший лонгрид про то, как отдыхать правильно: менеджерить усталость от работы, и находить активности, которые заряжают вас энергией.

Почему быстро выпускать новые фичи – это плохо Продолжаем тему пятничной статьи. Ограничением того, сколько новых фичей вы можете выпускать, могут быть не внутренние возможности компании, а конечный ресурс внимания ваших пользователей. Например, если вы делаете B2B продукт, то вне зависимости от того, с какой скоростью вы будет добавлять новые фичи, большинство клиентов будет адоптить в лучшем случае одну в течение нескольких месяцев. В итоге, ускоряя команду, вы на самом деле создаете невидимый бэклог фич, которые сделаны, но не используются, растягиваете time-to-value, ну и постепенно роняете качество. И вместе с этим я напоминаю, что вот уже сегодня начнется бесплатная большая конференция Стратоплана как раз про то, как AI меняет процессы разработки – поэтому, если сердце за происходящее у вас болит, обязательно заглядывайте!

Скорость разработки никогда не была проблемой Все СЕО на интервью в модных подкастах рассказывают про свои команды так, как будто их бэклог уже был полон хороших идей, и единственное, что их ограничивало – это скорость разработки программистами. Помню веселую байку из Авито, уже почти десятилетней давности. Весь менеджмент беспокоило, что ценных новых фичей появляется мало, доля рынка не растет, а конкуренты поджимают. Ругали, конечно же, неэффективную разработку – поэтому провелся большой реорг, всех пересобрали в автономные продуктовые команды, научили скраму и дейликам, и подкрутили архитектуру под такой сетап. Все стало очень эджайл, прозрачно, и понятно – но ситуация сильно не изменилась. Зато стало видно, что проблема была не в том, с какой скоростью задачи перемалываются, а в том, что продуктовые бэклоги были забиты какой-то фигней. Вот и сейчас мы видим похожую историю. В подавляющем большинстве случаев внедрение AI не сильно изменит картину: 👉У людей внутри организации мало хороших идей, и много плохих. Вообще то, что идеи запиливать было долго и дорого, наоборот, могло вас спасать от некомпетентности. 👉У большинства ваших сотрудников нет особой мотивации быть суперпродуктивными и выкладываться на благо компании. Как и любые разумные люди, они работают 9-5, и идут домой к семье и своим делам. 👉Для нормальных людей польза от AI не в том, чтобы быть 10х эффективнее, закрывая продуктовый бэклог, а в том, чтобы тратить меньше своей ценной энергии. 👉Те несколько людей, которые действительно хотели свернуть горы, вместо этого сидят и ревьюят AI слоп, который нагенерировали все остальные, и постепенно выгорают. 👉И на фоне всего этого ваш финансовый директор постепенно начинает задавать вопросы про то, как так получилось, что все инженеры теперь стоят на несколько тысяч долларов дороже из-за токенов, которые они прожигают.

AI не уменьшает количество работы, а делает ее более интенсивной In an eight-month study of how generative AI changed work habits at a U.S.-based technology company with about 200 employees, we found that employees worked at a faster pace, took on a broader scope of tasks, and extended work into more hours of the day, often without being asked to do so. Несколько мыслей по этому поводу: 👉От переключения контекстов во время работы с агентами удержать себя очень сложно. Во-первых, тебе действительно нечего делать, пока он думает над задачами. Во-вторых, ты одновременно находишься в состоянии потока, но и в голову загружено сильно меньше контекста, чем при ручной разработке – поэтому есть ощущение, что ты можешь горы свернуть. В-третьих, фидбэк луп о том, что ты на самом деле сильно вымотался, довольно долгий, поэтому по рукам тебя ничего не бьет, и ты не учишься на ошибках. 👉Когда человек хочет добиться промо, либо успешно пройти испытательный срок, он часто выбирает стратегию в лоб – перерабатывать, за счет этого закрыть больше задач, и показать свою ценность. Проблема в инфляции перфоманса. Твоя повышенная эффективность быстро становится планкой базовых ожиданий от тебя, и снизить темп уже не получается. Так вот, если в похожем режиме начинает работать половина компании, все еще хуже – такие ожидания закрепятся в рамках всей системы грейдов и промо. 👉Тебя постоянно не покидает ощущение, что задача ну вот почти-почти доделана, и до идеального результата осталась всего одна итерация работы с агентом. Это с одной стороны мешает оставить задачу незавершенной, и вернуться к ней на другой день, а с другой – дополнительно подталкивает тебя побыстрее взяться за параллельную задачу. Мы, конечно, справимся с этими проблемами – но нужно будет многим практикам учиться заново. Вот бы сейчас кто-то новые Джедайские техники про это написал...

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

Как сделать программиста счастливее 1️⃣Status – ощущение профессиональной значимости. На него влияют публичное признание вклада, конструктивная обратная связь, вовлечение в принятие важных решений, как технических, так и продуктовых. 2️⃣Certainty – предсказуемость и ясность. С этим помогают понятные цели, хотя бы на краткосрок, наличие смысла за задачами, логичные объяснения причин изменений, доверие к решениям менеджера. 3️⃣Autonomy – контроль над своей работой. Важно иметь возможность самому планировать и свою работу, и то, как она будет делаться, без микроменеджмента, контроля и советов под руку. 4️⃣Relatedness – чувство принадлежности и безопасности. Этот пункт про команду, которой ты доверяешь, с которой разделяешь общие цели, и вместе с которой тебе кайф работать. 5️⃣Fairness – ощущение справедливости. Больше всего его рушит чувство несоответствия между твоими усилиями и вознаграждением. Поэтому работать над этим менеджеру надо, устанавливая понятные правила игры для всех, компенсируя похожим образом похожие результаты, и оставаясь последовательным (см пункт про ясность и предсказуемость).

Что такое Context Graph Разбираем новый модный термин Context Graph. В чем идея – организации в целом довольно неплохо справляются с тем, чтобы записывать результаты своих решений. Отсюда берутся все те тысячи тикетов в вашей системе и разные документы, лежащие в папках на гугл диске. Но в большинстве случаев, записываются только результаты решений, а не их контекст – как и почему они были приняты. Поэтому, когда спустя какое-то время никто не может объяснить, почему вообще так было сделано. Проблема-то не новая, даже в канале я постил очень много материалов про то, как вести разнообразные decision records – для архитектуры, процессов, решений по людям. Но в реальной жизни поддерживать и ответственно вести их очень дорого, особенно если речь идет о кроссфункциональных процессах. Какие-то обсуждения ведутся в комментариях к тикету, какие-то – в комментариях к документу с контрактом, какие-то в тредах в Slack – и никто не будет соединять все кусочки этой информации. Вот тут в игру и вступает контекстный граф. Это автоматическая система трекинга того, как, почему и кем принимаются организационные решения, когда и какие исключения из них были приняты, каким образом были выданы аппрувы. Короче говоря, поиск релевантного контекста во всем огромном массиве организационных переписок и документов. Пока это скорее идея, которая очень интересна большому количеству стартапов. В реальности я еще не видел, чтобы оно работало хорошо. Инфраструктура для чего-то похожего точно есть у Gleam, которым мы пользуемся на работе, но релевантность там пока оставляет желать лучшего – да и UX удобный точно еще надо будет придумывать.

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