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

Как анализировать организацию работы в команде

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

1️⃣Собираем матрицу распределения работ – табличку, где по вертикали идут имена членов команды, по горизонтали – полный перечень функций и задач.
2️⃣В этой матрице отмечаем, кто какую из работ на самом деле выполняет, в том числе тип участия по RACI.
3️⃣Анализируем распределение и выполнение работ. Идем по каждой строке и проверяем, выполняется ли кем-то работа вообще, очевидно ли, кто должен ее выполнять в каждом случае, нет ли дублирования ролей, является ли количество исполнителей минимально достаточным, отвечает ли кто-то за конечный результат, согласована ли работа между всеми участниками, понятны ли критерии успеха, дает ли работа ожидаемый эффект.
4️⃣Анализируем каждый столбец: понятна ли роль участника команды, можно ли выделить и оценить его вклад в общее дело, ясны ли границы его зоны ответственности, соответствует ли нагрузка его компетенциям, соответствует ли объем работы его возможностям, и сбалансирована ли она относительно остальных коллег, нет ли избыточной зависимости от других участников, не страдает ли он от переключений контекста, отвечает ли за какой-то результат от начала до конца.

Честный опыт написания сложного проекта с агентами

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

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

Лучше всего пост подбивает вот эта цитата:

The takeaway for me is simple: AI is an incredible force multiplier for implementation, but it’s a dangerous substitute for design. It’s brilliant at giving you the right answer to a specific technical question, but it has no sense of history, taste, or how a human will actually feel using your API. If you rely on it for the “soul” of your software, you’ll just end up hitting a wall faster than you ever have before.

Как прикинуть окупаемость вашей команды

Команда из восьми инженеров где-то в Европе стоит около 1 миллиона евро в год – иначе говоря, 90000 евро в месяц и 4000 евро в день. Ожидания по окупаемости отличаются в зависимости от типа команды.

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

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

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

Кластеризуем компании, чтобы не ошибиться в выборе работы

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

Вот эти кластера:

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

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

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

Как менеджеры пытаются показать свою власть

Многие из этих антипаттернов проявляются неосознанно, поэтому проверьте себя на всякий случай:

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

Как качество агентского кода деградирует на дистанции

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

Для того, чтобы оценить качество результата, в бенчмарке смотрят на два показателя – количество лишнего или дублированного кода и нечто под названием structural erosion, что можно приблизительно представить как излишнюю сложность решения. И все довольно плохо. В 80% случаев сложность растет, в 90% случаев растет количество лишнего кода.

Что еще интересно – в коде, написанном человеком, эти метрики со временем остаются на одном уровне, а в агентском ухудшаются от итерации к итерации.

Аудит кодовой базы за несколько git команд

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

👉Посмотреть на топ самых часто изменяемых файлов. Если среди них есть те, за которые никто не хочет отвечать, это ваши точки отказа.
👉Посмотреть на коммитеров, ответственных за большую часть кода. Если кто-то один написал больше 60%, он ваш бас фактор. Другой важный сигнал – как много из изначальных авторов системы продолжают коммитить до сих пор, или ее поддерживают другие люди.
👉Какие файлы чаще всего попадают в коммиты с "bug" в названии. Хорошо сравнивать со списком файлов из первого шага.
👉Увеличивается ли количество коммитов, остается на плато или падает со временем. Периодические пики могут сигнализировать о кранчах перед релизами, а постепенный спад активности – на замедление команды и чей-то уход.
👉Насколько часто встречаются коммиты со словами "hotfix"/"revert". Это хороший прокси-показатель того, насколько много команда борется с пожарами.

Признаки того, что кодовая база вас тормозит

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

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

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

В апреле-мае основной упор на несколько треков – spec-driven development, harness engineering и внедрение AI в компании. Спикеры очень классные – например, на этой неделе один из инженеров Cursor будет рассказывать, как они живут с огромной кодовой базой, которую им написал AI еще предыдущего поколения. Потом через неделю лиды платформенных команд российского и зарубежного бигтеха не под запись будут рассказывать всю правду про то, как у них внедряется AI. А еще через неделю закопаемся в тему исполняемых спецификаций и разных методов верификации агентского кода, благодаря которым AI можно подпускать к высоконагруженным mission critical системам.

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

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

Подробности, расписание и заявка – на сайте. А если есть какие-то конкретные вопросы, пишите прямо в личку @etolstoy!

Как поменяется работа Junior инженера

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

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

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

Не давайте AI писать тексты за вас

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

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

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

Если вы пропустили, в феврале был еще один хороший пост на эту же тему.

Два важных вопроса для собеседования

1️⃣Кто отвечает за задачу?

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

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

2️⃣Пишете ли вы unit тесты?

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

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

Как Intercom использует Claude Code

Гипер-интересный тред про то, как в Intercom используют агентов для автоматизации разных процессов. Вот несколько идей:

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

Советы по техническим интервью в эпоху LLM

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

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

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

Каждому участнику вебинара мы пришлём пошаговый план перехода к IaC.

📅 1 апреля, 11:00 по МСК
💻 Онлайн

РЕГИСТРАЦИЯ И ПРОГРАММА

Как Cursor влияет на скорость и качество разработки

Исследователи взяли все репозитории с GitHub, в которых файл .cursorrules появился уже после создания проекта, и сравнили их состояние до и после его появления. Вот какие выводы получились:

👉После адопшна Cursor количество новых строк кода выросло в 3-5 раз, но уже спустя два месяца этот эффект проходит.
👉Одновременно с этим растет устойчивое накопление техдолга: статанализ находит на 30% больше проблем, а когнитивная сложность выросла на 40%.

Оптимизировать надо не скорость написания кода

Держите отличную статью, которую можете аккуратно закинуть своему СТО, когда он предложит внедрять метрики оценки количества AI-generated PR, или еще каким-то образом будет пушить ускорение разработки фичей.

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

Когда менеджер должен вмешиваться

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

👉Команда должна иметь возможность совершать ошибки и учиться на них. Выбрать такие ошибки поможет эвристика "Below/above the waterline" – если какая-то ошибка может сильно навредить и потопить ваш корабль, стоит вмешаться, иначе – нет.
👉Нужно различать ошибки и вкусовщину. В случае вкусовщины не нужно сильно давить своим мнением, оно не важнее других людей в команде.
👉Вмешиваться стоит в следующих случаях – команда столкнулась с большой неопределенностью, которую вы можете уменьшить; или они вошли в дедлок по вопросу, который не имеет одного верного ответа, например, по выбору архитектуры.
👉При оценке необходимости вмешательства всегда учитывайте сеньорность человека в контексте конкретной задачи. Иногда в одной и той же задаче джуну помощь может быть не нужна, а вот сеньору – вполне.
👉Хорошее вмешательство организовано таким образом, чтобы в будущем команда чему-то от него научилась, и в похожей ситуации справилась бы сама.

Скилл для подготовки к интервью

Наткнулся на рекомендацию скилла для отработки всех этапов по поиску работы:

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

Как понятно объяснять свои мысли

👉Bottom line up front. Когда вас просят что-то объяснить, основной вывод должен быть в первой же фразе, и только потом идти дополнительный контекст. А многие поступают наоборот – вместо прямого ответа пытаются подробно воспроизвести рассуждения, которые к нему приводят.
👉Just in time context. Не нужно пытаться сходу вывалить весь возможный контекст. Давайте его ровно столько, сколько нужно, чтобы собеседник мог решить свою текущую проблему. А чем глубже вы понимаете какую-то тему, тем сложнее удержаться от того, чтобы погрузить в нее человека.
👉The top-down bridge. Когда вы насыпаете кому-то контекст, отталкивайтесь от того, что они сейчас знают, и постепенно углубляйтесь в детали, отстраиваясь от этого.