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

Стратегический технический советник

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

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

Как разработчики на самом деле используют AI

Anthropic – создатели самых популярных моделей для работы с кодом, поделились детальной статистикой по тоиу, как именно разработчики используют AI.

Сначала чуть-чуть про методологию.

Взяли выборку в 500 000 сессий за начало апреля и прогнали их через privacy-preserving аналитику: модель анонимно определяла тему, язык, тип задачи классификацию всей беседы – либо как "автоматизацию" (AI делает работу) или "аугментацию" (AI + человек решают задачу вместе). Сравнивали два канала: обычный AI чат и AI агента Claude Code.

👉Чем агентнее инструмент, тем меньше человек участвует в самом процессе написания кода. 79% бесед с Claude Code относятся к классу "автоматизация" против 49% в чате. При этом полное делегирование задачи происходит в 44% сессий с агентом, и в 27% в чате.
👉В основном разрабатываются user-facing приложения, так что бэкендеров заменят последними. JavaScript и HTML лидируют в списке технологий. Для сравнения Java где-то в 10 раз менее популярна.
👉Агент в основном используется стартапами и в пет-проектах, в энтерпрайзах проникновение пока не очень большое.

Про радикальную прямоту

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

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

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

Ну и ждем новых кейсов от вас на разбор, закидывайте в бота @TeamleadDoNotSleepBot!

Как избежать атрофии навыков из-за AI

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

Признаки наличия проблемы:

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

Вот несколько практик, которые помогут не растерять знание проекта и домена при внедрении AI:

👉Все начинается с базовой гигиены. Вы всегда должны вчитываться в то, что генерирует AI. Особенно полезно выступать критиком, надевая на себя шапку того, кто пытается найти проблемы и уязвимости в коде.
👉Устраивайте AI-детокс и регулярно пишите какой-то код самостоятельно.
👉Встретившись с какой-то нетривиальной проблемой сначала попытайтесь решить ее сами, и только если ну вообще никак, используйте AI.
👉Команда должна знать и владеть всем кодом в проекте, не важно, написал ли его AI или человек.
👉Фиксируйте темы, за которыми чаще всего ходите за помощью к модели: повторяемость – сигнал закрыть пробел знаний.
👉Работайте с LLM в стиле парного программирования. Модель – пишет код, вы – направляете и рефакторите.

Как читят на собесах с помощью сервиса Interview Coder

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

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

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

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

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

Зачем менеджеру смотреть в бездну

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

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

Почему мы избегаем бездны? Признавать промахи – больно; принимать резкие карьерные решения – страшно; да и проще отложить на потом. Проблема в том, что за «потом» всегда приходится платить проценты: упущенные возможности, выгорание, стагнация.

👉 Выделяйте слоты для бездны. Заблокируйте в календаре день, когда всерьёз проверяете большие решения — иначе прокрастинация растянется на недели.
👉Найдите buddy. Собеседник помогает прорваться сквозь круговые мысли и задаёт неудобные вопросы, пока вы не доберётесь до сути.
👉Формулируйте свою бездну явно. «Если бы я ушёл из компании сегодня, что бы делал?» Когда вопрос лежит на бумаге, сложнее его проигнорировать.
👉Не смотрите в бездну слишком часто, иначе ваша жизнь превратится в один сплошной экзистенциальный кризис.

Забирает ли AI радость от работы

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

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

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

Качество разговоров и зрелость компании

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

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

Держите список вопросов для самодиагностики:

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

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

Почему важны точные формулировки

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

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

Про карьерный рост:

❌Сфокусируйся на возможностях прокачать лидерские навыки
✅В ближайшие полгода ты лидишь проект Х. С завтрашнего дня я сделаю официальный анонс и передам тебе все полномочия.

Про найм:

❌Вы сможете спокойно выбрать любую команду после принятия оффера
✅Открытые роли сейчас есть в командах X, Y и Z. В X вы не очень подходите по профилю. В Y как раз подходите идеально, но если вы не захотите пойти туда, давайте обсудим заранее.

Про повышение:

❌Думаю, в ближайшее время ты можешь расчитывать на повышение.
✅У нас два цикла повышения в ближайшие 12 месяцев. Вероятность в следующем цикле через 3 месяца невысока, а через 9 месяцев более реальна. Давайте обсудим, почему я так считаю, чтобы вы понимали логику.

Почему 10х инженеры – антипаттерн

Если вы запомните только одну мысль из этого поста, то пусть это будет следующее:

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

Но погнали по порядку:

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

Как выживать в токсичной команде

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

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

1️⃣ Включите режим «серой скалы» – нейтральное лицо, минимум эмоций. Не кормите троллей и не вступайте в бессмысленные конфликты.
2️⃣ Документируйте все. Если договорились о чем-то важном на митинге – зафиксируйте это письменно и отправьте коллегам. Это не паранойя, а разумная страховка.
3️⃣ Сократите личные разговоры до минимума. В токсичных командах любая ваша личная информация может легко превратиться в оружие против вас.
4️⃣ Развивайтесь за пределами компании. Общайтесь в профессиональных сообществах, ходите на конференции и митапы. Это поможет не потерять уверенность в своих силах и позволит легче уйти в лучшую команду, когда придёт время.
5️⃣ Создайте финансовую подушку. Когда появится возможность уйти – вы должны быть готовы сделать это без лишних переживаний.

Как упрощать сложные решения

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

2️⃣Основой для принятия решения должны быть его сильные стороны. Слабые – только повод для вето, если они критичны и не могут быть скомпенсированы.

3️⃣Сознательно двигайте и себя, и других в том, чтобы инвестировать в сильные стороны. Людям естественным образом хочится чинить слабые стороны, но это редко дает реально большую отдачу. К слабостям лучше относиться как к ограничениям, которые можно учитывать в дизайне, но устранять не обязательно.

4️⃣Не вводите слишком много критериев для принятия решения, используйте максимум три, которые реально влияют на исход.

AI для ведения тестовой документации

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

👉Закидываете макеты / скриншоты пользовательского сценария, добавляете весь контекст про профиль пользователя и его цели. Получаете первый черновик.
👉Проходитесь по черновику, выписываете все недостатки и пропущенные детали, закидываете в AI с просьбой доработать.
👉Когда по контенту все хорошо, закидываете в AI образец структуры и оформления, объясняете, какую мета-информацию вроде приоритетов надо добавить.
👉Экспортируете в нужный формат, который уже загружаете в тестохранилку или базу знаний.

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

Как внедрять AI в свою работу

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

1️⃣Уберите все барьеры, которые могут вам мешать быстро обратиться к AI. Запиньте вкладку в браузере, поставьте себе десктопное и мобильное приложение ChatGPT. Попробуйте хотя бы разово использовать AI для частых рутинных задач – отформатировать meeting notes, причесать задачу в трекере. Хинт: вместо того, чтобы просить AI "сделать хорошо", предложите ему сначала проинтервьюировать вас про ваши цели – так он соберет нужный контекст и сделает свою задачу лучше.
2️⃣Разберитесь с тем, где вы приносите больше всего ценности. Именно в этой области вам стоит пытаться применить AI – получив перфоманс буст тут, вы сильно поможете команде, а вот просто генерируя бесполезные тексты, о которых вас никто не просил – нет.
3️⃣Приучите себя документировать свою работу. Хорошая ментальная модель – представьте, что вам надо передать все свои знания новому сотруднику. Задокументировав цели, структуру и образ качественного результата, вы сможете передать эту же работу и AI.
4️⃣Если вы замечаете за собой, что регулярно закидывае просите AI выполнить одну и ту же задачу, или используете один и тот же промпт, подумайте, как это все можно автоматизировать. Может быть, ваш промпт можно обернуть в бота, который будет автоматически каждый день вытаскивать нужные ему данные и обрабатывать их. А самое простое, что можно тут сделать – в конце повторяющихся чатов просить AI превратить их в переиспользуемый шаблон.
5️⃣Делитесь с коллегами идеями, которые у вас заработали. Причем самое интересное – показывать не только результат, но и сам процесс проб и ошибок.

Как получать удовлетворение от работы

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

1️⃣Joy. То, что вы делаете, приносит радость настолько, что вы не хотите в течение дня заниматься чем угодно еще.
2️⃣Skill. Вы отлично шарите в том, что делаете. Вы гордитесь результатами своей работы, она выделяется для тех, с кем вы работаете.
3️⃣Need. То, что вы делаете, востребовано – либо в компании, либо для ваших пользователей. Если вы закрываете свою часть хорошо, это приводит к какому-то важному успеху.

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

👉Joy + Skill - Need. Вы кайфуете от работы, но ценности компании она не приносит. На краткосрочной дистанции такая работа может помочь перезарядиться, но в долгосроке вы либо ее потеряете, либо сами перестанете видеть смысл.
👉Joy + Need - Skill. Вы тратите кучу времени на то, что более опытный человек сделал бы гораздо быстрее. Опять же, общая продуктивность страдает.
👉Skill + Need - Joy. А это классическое выгорание. Вы работаете весь день, чувствуете внешнее давление из-за важности работы, но удовольствия ноль.

Ваши сильные стороны – они же и слабые

People are package deals; you take the good with the confused. In most cases, strengths and weaknesses are two sides of the same coin.

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

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

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

Как вы используете AI

На прошлой неделе HBR опубликовали исследование того, в каких сценариях люди используют AI в 2025 году, и как их паттерны поведения изменились за год.

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

👉Структуризация сырого набора мыслей в понятные концепции или документы.
👉Deep Research каких-то тем, в которых я не очень разбираюсь, но хочу быстро вкатиться.
👉Чат с большими документами, которые нет времени внимательно читать.