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

Как правильно отдыхать

Отдых – это не награда за какие-то действия, это часть полноценной и насыщенной жизни.

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

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

Почему быстро выпускать новые фичи – это плохо

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

В чем заключается работа тимлида

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

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

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

Новые выпуски тимлидских подкастов

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

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

Поводов усиленно думать стало меньше

Помните алгоритм решения проблем имени Фейнмана?

1. Запишите задачу
2. Хорошо подумайте
3. Запишите решение

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

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

Про CapEx и OpEx

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

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

Координация стоит дорого

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

Если нырять в детали, то вот что важно понимать:

👉Координация между командами требует больше усилий, чем работа внутри своей команды, поэтому проше всего делать все локально, чтобы снизить издержки. Изоляция и дублирование работы отсюда и возникают.
👉Хотя время, затрачиваемое на митинги, кажется непродуктивным и отнимающим ресурсы от реальной работы, координация без них практически невозможна. Так что это не пустые потери, а цена за масштаб.
👉С ростом организации стоимость координации растет сильнее, и выливается в те же митинги и слои менеджмента. Можно смотреть на это как на организационный закон термодинамики – чтобы удержать систему от распада, надо вкладывать все больше усилий.
👉Что бы вам ни обещали на конференциях, нет серебряной пули, которвя решит проблему – волшебного фреймворка, инструмента или процесса.

Библиотека без кода

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

👉Подробная спецификация (высокоуровневые дизайн-принципы, требования по входу-выходу, обработке ошибок, описание логики работы и тестов для каждой функции)
👉Набор тестовых данных
👉Инструкция для агента

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

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

Зачем организациям оценка сроков

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

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

Если следовать этой модели, то вот несколько разумных правил поведения в ней:

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

Про доверие к исследованиям

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

На прошлой неделе произошел еще один скандал, который этот тезис подтверждает. В чем суть – есть исследование 2014 года под названием "The Impact of Corporate Sustainability on Organisational Processes and Performance". Его авторы заявляли, что компании, которые серьезно относятся к социальной ответственности, не только делают добро, но и зарабатывают больше денег для акционеров, причем таких сверхдоходов аж 40%, и это видно на горизонте 20 лет. Это исследование стало безумно популярным – 6000 ссылок, цитирование разными топ-менеджерами, финансистами и политиками. Но оказалось, что в нем есть ряд фатальных недостатков:

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

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

Как AI влияет на формирование навыков программирования

52 джуна разделили на две группы, каждая из которых решала одинаковую задачу, и после этого отвечала на тестовые вопросы по теме:

1️⃣Группа без доступа к AI. Они часто ошибались в задаче, но лучше справлялись с итоговым тестом. Получается, что в процессе работы они учились.
2️⃣Группа с доступом к AI. Эти лучше справлялись с прогарммированием, но по итогу ничего не поняли.

Какие дополнительные интересные выводы появились:

👉Хуже всего справились с заданиями те, кто делегировал AI и решение задачи, и дебаг, и не пытался вникнуть в суть решаемых проблем.
👉Участники, которые помимо генерации кода, использовали AI, чтобы понять, как и почему он работает, справлялись существенно лучше.

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

Почему разработчики выгорают, а фаундеры нет

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

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

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

Как LLM помогают мышлению

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

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

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

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

Тот самый проект на 100.000 строк, написанный полностью с помощью Claude Code (оригинал).

Как получать хорошие советы

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

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