TGINSIGHT CHAT
Teamlead Good Reads – ежедневные советы про менеджмент людей и команд
@leadgr
Бизнес и стартапыСамые интересные статьи, видео и новости, связанные с управлением людьми, командами, разработкой и продуктами. РКН: https://gosuslugi.ru/snet/67b4386d2a44e21839a0f87f Продуктовая папка: https://t.me/addlist/YvmnHCHUp700Nzky Реклама: @tanyasanovna
Последние посты
Стр. 17 из 85 · 1,018 постов
Опубликован 1 сент.
Про экзотические метрики Каждый продакт-менеджер гонится за тем, чтобы у его продукта была идеальная North Star метрика – показатель, который максимально отражает реальный успех, вдохновляет всю команду, и помогает выравнивать относительно него разные инициативы. Проблема в том, что на сложные вопросы очень редко можно получить простые ответы. А этот вопрос как раз из такой категории. У выбора NSM много стейкхолдеров, каждый из которых, пытаясь показаться умным, будет накидывать дополнительных ограничений. Кто-то будет придумывать сценарии, когда вашу метрику можно будет зачитить, кто-то будет придумывать якобы более отражающие реальную пользу ограничения. И в итоге вместо одного простого и понятного, хоть и не совершенного, индикатора, вы получите экзотическую метрику, которую почти невозможно посчитать, на которую сложно повлиять, и которой из-за этого на самом деле никто не пользуется. Я всегда к этому вопросу захожу немного с другой стороны. Мне кажется, что самое важное – это сформулировать простым языком смысл того, в чем заключается успех, и сделать так, чтобы вся команда это понимала. А затем, отталкиваясь от смысла, подобрать несколько простых релевантных метрик. Пока все понимают смысл того, что мы делаем, читить метрики бессмысленно. А то, что они не идеально отражают смысл – ну и пусть, все равно в итоге MRR всех рассудит!
Опубликован 29 авг.
Новые выпуски тимлидских подкастов 👉"Бреслав и Ложечкин" про то, как персональный бренд может иногда помочь прокачать карьеру, а иногда – быть уволенным 👉"Подлодка" про доверие к AI – откуда берутся галлюцинации и bias, и как с ними бороться 👉"Weekend Talks" с Виталием Шароватовым про его карьерный путь, помощь людям вокруг и важность тестирования 👉"КОДА КОДА" с Кириллом Мокевниным про A-players: кто это такие, надо ли их нанимать, и какую пользу бизнесу приносят 👉"Едим слона целиком" про способы управления командой и сохранения культуры в условиях очень быстрого роста
Опубликован 28 авг.
Как работать с социопатами Если вы когда-то встречали людей, для которых: 👉Должность – способ самоидентификации 👉Люди вокруг – ресурсы или препятствия 👉Рабочие отношения воспринимаются как игра в статус 👉Положение в иерархии определяет отношение к другим и способы общения То поздравляю, вы работали с социопатом. Если вы не можете избежать взаимодейсвия с ним, вот небольшая инструкция по выживанию: 1️⃣Не играйте с ним в иерархию. Ведите себя нейтрально – не реагируйте ни на лесть, ни на хамство. 2️⃣Фиксируйте все договоренности письменно, чтобы уменьшить возможности манипуляций фактами. 3️⃣Не оправдывайтесь перед ним, иначе он воспримет это как уязвимость и использует ее. 4️⃣Не вступайте в моральные дебаты. Сводите все общение к конкретной рабочей задаче. 5️⃣Не становитесь его другом, даже если он пытается подкатить. Дружба с социопатом всегда условная, и будет использована им как инструмент. 6️⃣Ищите союзников, с которыми можно поделиться своими наблюдениями, и которые смогут поддержать вас.
Опубликован 27 авг.
Заменять джунов на AI – тупейшая идея На волне популистских заявлений всех компаний, делающих что-то вокруг AI, последнее интервью СЕО AWS выглядит прямо хорошо: 👉Увольнять или не нанимать джунов, расчитывая, что их работу заменит AI – тупейшая идея. С одной стороны, у них маленькие зарплаты, а с другой – они же активнее и быстрее остальных учатся использовать AI в работе. 👉Индустрия должна продолжать нанимать выпускников и обучать их полноценной разработке и умению декомпозировать проблемы – иначе через десять лет никто не будет уметь работать. 👉Измерять успешность внедрения AI в компании, подсчитывая количество сгенерированных строк кода – глупость.
Опубликован 26 авг.
Как не превратиться в психотерапевтадля своей команды Хороший менеджер очень много разговаривает со своей командой и умеет хорошо слушать. И к нему приходят поговорить о своих проблемах и фрустрациях. Если не удерживать здоровые границы, вы можете превратиться в психотерапевта на полставки. А это – очень плохая идея. Во-первых, чтобы не навредить, вы должны обладать соответствующим образованием. Во-вторых, в отличие от терапевта, вы – заинтересованное лицо. Как бы вы ни старались, вы будете учитывать то, про что, и как сильно вам ноют, принимая решения по распределению задач и ответственности. Так вот, поговорим о том, как построить эти здоровые границы: 👉После того, как вы выслушали человека, постарайтесь развернуть разговор в сторону действий – обсудить, как можно исправить ситуацию, что человек может сделать сам, а чем вы, как менеджер, можете помочь. Вам нужно удерживать баланс между тем, чтобы сотрудник имел возможность спокойно пожаловаться, и тем, чтобы он понимал свою ответственность за решение проблемы. 👉При этом не переходите слишком быстро к обсуждению решений. Люди должны понимать, что вы их услышали и понимаете их чувства. 👉Не давайте гиперболизировать проблемы, но делайте это аккуратно. Напоминайте про другие точки зрения на проблему, делитесь своей перспективой. Ваша задача – откалибровать реакцию сотрудника так, чтобы она соответствовала реальному масштабу проблем.
Опубликован 25 авг.
Текущее состояние AI-assisted разработки Держите большой обзорный материал по всем последним исследованиям и опросам, связанным с тем, насколько на самом деле продуктивнее становятся разработчики при работе с AI. Часть из этих исследований я уже публиковал, но тут довольно удобно все собрали в одном месте. Что касается состояния, общее мнение индустрии сейчас такое – в ряде случаев использование AI может заметно улучшить продуктивность, но чудес и кратного повышения результативности ждать пока не стоит. 👉Адопшн AI очень большой и продолжает расти – разработчики всегда пытались сократить рутинную работу, и эти инструменты им помогают. 👉Трезвая оценка повышения продуктивности где-то в районе 20-30%, причем не во всех командах. 👉Все очень сильно варьируется от случая к случаю, например польза для новичков и для сеньоров будет очень разной. 👉С одной стороны, AI инструменты провоцируют over-confidence, а с другой – слепо доверять результатам их работы вообще нельзя. 👉Output != Outcome. Кода пишется больше, но скорость разработки может не измениться вообще, а то и упасть. Как с этим вообще жить: 👉Точно не стоит отчаиваться и клеймить весь AI бесполезным хайпом. Польза точно есть, но, как и у любого инструмента, есть границы применимости. 👉Если вы смотрите с точки зрения менеджера, то не стоит задирать планку ожиданий. Если кто-то в команде рассказывает про кратное повышение продуктивности, относитесь скептически. 👉С точки зрения инженера, будьте прагматичными. Экспериментируйте, выкидывайте то, что не работает, а полезные практики встраивайте в рутину. 👉Продолжайте вкладываться в ключевые инженерные навыки. Что точно стало понятно – как бы AI не эволюционировал дальше, гораздо эффективнее с ним работают опытные инженеры, которые умеют строить и поддерживать сложные системы.
Опубликован 22 авг.
Слышу много похожих рассказов от друзей, которые сейчас плотно работают с джунами. Расскажите, а как у вас?
Опубликован 21 авг.
Альтернатива командной работе Слаженной групповой работы можно добиться двумя способами: 👉За счет внутренней регламентации, когда правила вырабатываются и контролируются участниками группы, и команда едет сама. 👉За счет внешней регламентации, когда все условия игры задаются внешним руководителем, и группа едет за счет его пинков. Второй вариант не всегда плох – во многих ситуациях рабочей группы под управлением грамотного менеджера, хорошо настроившего процессы, будет достаточно. Но важно помнить, что группа с внешней координацией всегда будет уступать командной работе по эффективности – она ограничена управленческими способностями одного человека, в то время как группа заинтересованных профессионалов всегда будет умнее.
Опубликован 21 авг.
Собеседования глазами инженера Начнем с предлагаемых автором принципов хорошего собеседования. Интервью должны: 👉Дифференцировать кандидатов, помогая отличать опытного сеньора от волка с AI под рукой. 👉Быть прозрачными, отражая фактические должностные обязанности, а не синтетические задачи. 👉Смотреть в перспективе, отдавая предпочтение соискателям, которые хорошо впишутся в команду на годы вперед. 👉Экономить время обеих сторон. 👉Строиться на уважении к соискателю. 👉Помогать оценить наличие инженерного вкуса. Этим принципам отвечают не все из привычных форматов: ❌Лайвкодинг. Слабо показывает долгосрочную ценность сотрудника, не помогает дифференцировать кандидатов, слабо связан с повседневной работой. Да и по остальным принципам плоховато проходит – вкус не оценить, и многие кандидаты оценивают такой этап как неуважение к себе и своему времени. ❌Тестовые на дом. Проваливает пункты по экономии времени, дифференцированию и прозрачности. К такому собеседованию легко подготовиться с помощью AI. ℹ️Проектирование. Вариант получше, но все еще не идеальный. Код человека вы не увидите. ✅Разбор примеров работы или опенсорсных проектов. Тут все хорошо, но только если такие примеры у кандидата есть. ✅Код-ревью плохого кода – кандидат и собеседующий вместе разбирают подготовленный заранее проект. Очень уважительный ко времени кандидата вариант, плюс хорошо обеспечивает прозрачность и помогает оценить вкус.
Опубликован 19 авг.
И еще одно правило борьбы с плохо организованными встречами по принятию решений. Вам надо ответить всего на три вопроса: 1️⃣Какая информация нужна, чтобы принять решение? 2️⃣Есть ли у нас эта информация? 3️⃣Какое решение принимаем? При этом для ответа на первые два вопроса никаких встреч собирать не нужно.
Опубликован 18 авг.
Как бороться с лишними созвонами 👉По-максимуму переходить на асинхронные коммуникации вместо встреч. В первую очередь научиться работать с таск-трекером – обсуждать там все задачи, следить за прогрессом важных для вас задач, ставить отложенные напоминания. Второй полезный инструмент – запись коротких видео с объяснениями в Loom, которые можно посмотреть потом в любой момент. 👉Оптимизировать количество и формат встреч. Во-первых, избавиться от мало полезных – обсуждение статуса задач, созвоны уточнить что-то, дать апдейт по проекту. Во-вторых, сокращать длительность нужных встреч, и хорошо к ним готовиться – четко формулировать вопрос, который хотите решить, и заранее делиться повесткой. В-третьих, не звать всех подряд, исключать наблюдателей, включать только активных участников. 👉Не стесняться предлагать отменять чужие встречи, которые не проходят через эти правила, и предлагать другие форматы для них.
Опубликован 15 авг.
Результаты опроса Stack Overflow за 2025 Во вполне вероятной смерти Stack Overflow в ближайшие годы мне больше всего жаль будет потерять их ежегодные опросы, которые дают репрезентативный и очень полезный срез индустрии. Вот несколько интересных фактов за этот год: 🧑💻Про разработчиков: 👉Только четверть разработчиков счастливы на своей работе, но в прошлом году таких было еще меньше. 👉Больше всего на счастье влияют автономность, хорошая компенсация и решение реально важных проблем. 👉Основные причины по которым разработчики теряют интерес к инструментам: проблемы с приватностью, цена, наличие альтернатив получше. А вот отсутствие AI ни для кого не является проблемой. 💻Про технологии: 👉Самый быстрорастущий язык, ожидаемо, Python, причем на невероятные 7%. Среди баз данных быстрее всего растет Redis. 👉В списке самых любимых языков новичок – Gleam. Обязательно про него выпуск Подлодки скоро запишем! 🤖Про AI: 👉В прошлом году к AI относились на 10% позитивнее, чем в этом. Что контринтуитивно – профессиональные разработчики ценят AI больше, чем начинающие. 👉84% опрошенных используют AI в своей работе. 👉Чаще всего AI используют для поиска и генерации контента, а реже всего – для деплоя, мониторинга, планирования проекта. 👉AI агенты все еще не стали мейнстримом, только треть опрошенных их как-то использует. Из них 70% считают, что их продуктивность выросла.