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

Что общего у рынка труда журналистов и программистов Традиционная журналистика уже достаточно давно умерла. В 2008 году в результате финансового кризиса из прессы ушли рекламодатели, и кучу штатных журналистов уволили. Они пошли во фриланс – и обнаружили, что на пару десятков заказов в месяц отзывается десятки кандидатов в день. При этом университеты продолжали выпускать новых журналистов, профессия годы до этого была на хайпе. Рынок работодателя сразу же создал несколько довольно знакомых нам явлений. Для начала, вокруг отбора кандидатов появилось много ритуальных бессмысленных действий. Это привело к тому, что получение заказа стало отдельным искусством, и работу стали получать не лучшие авторы, а те, кто лучше всего умел под эти требования адаптироваться. Ну и, конечно же, появились волчьи сообщества, которые учили журналистов получше продавать свои питчи и проходить гейткипинг. Что происходило с журналистами дальше: 👉Мидлы вымерли. На рынке остались начинающие фрилансеры, работающие за копейки, и завездные опытные журналисты. 👉Выжившие ушли от гейткиперов. Самые сильные авторы перестали пытаться пробиться к редакторам в издания, и стали независимыми – открыли рассылки, сделали подкасты, сколотили собственный бренд. Гейткипер при этом, конечно, остался – но теперь это не редактор-человек, а алгоритм ленты в соцсетях. 👉Сместился дефицит. Раньше им было место в журнале, теперь – доверие читателя к конкретному имени. Что из этого можно перенести на рынок программистов – вопрос хороший, и упирается он в то, конечен ли спрос на программистов, или нет (парадокс Джевонса и вот это все). Пока все показывает на то, что на самом деле спрос конечен – люди не начинают ставить себе больше приложений на телефон, а компании не то, чтобы успешно диверсифицировали свою продуктовую линейку и запускали кучу новых успешных продуктов.

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

Почему автономные фабрики софта не работают Последние полгода из каждого угла говорят про то, что вот-вот агентская разработка эволюционирует до того момента, когда людей можно будет полностью убрать из этого процесса, заменив все полностью автономными фабриками. А если у вас это не получается, то skill issue. На самом деле все немного не так. 👉Модели становятся лучше только в вопросах выполнения одной конкретной задачи, но не в том, чтобы поддерживать кодовую базу в долгую. Поэтому спустя достаточно быстрое время такого развития, проект станет неподдерживаемым ни вами, ни моделью. 👉Так происходит из-за текущих механизмов reinforcement learning – определить правильное поведение и награду на горизонте атомарных задач легко, а вот на уровень выше уже очень сложно. За плохие архитектурные решения модели никак не наказываются.

Про comprehension debt На прошлой неделе в посте про оргдизайн я вспоминал замечательную книгу Team Topologies. Одна из мыслей, которые мне очень запали в душу – это то, что зону ответственности команды надо проектировать с учетом ее ограниченной когнитивной емкости, а не просто закидывать в нее ответственность за все рядом лежащие компоненты. Когнитивная емкость – это способность команды переварить когнитивную нагрузку. К такой нагрузке относится все, что команда должна понимать, чтобы самостоятельно безопасно обслуживать и менять свой продукт: бизнесовые правила, доменный язык, архитектура, устройство инфраструктуры и пайплайнов, интеграции с другими сервисами, особенности пользователей. Когнитивная нагрузка появляется от двух видов сложности: 👉Intrinsic, неотъемлимая сложность предметной области. Как код ни упрощай, биллинг всегда будет сложным. 👉Extraneous, случайная сложность. Плохо организованный ручной пайплайн деплоя, много разных форматов конфигурации, лишние слои абстракции. Так вот, агентская разработка, при всем ее великолепии, очень сильно влияет на когнитивную нагрузку. Во-первых, очень просто резко вырастить случайную сложность. Агенты любят оверинжинирить, писать обработчики для тридцати эдж кейсов, и городить те самые слои абстракций. Если не выстраивать правильную инженерную дисциплину, то уже этого хватит, чтобы когнитивная емкость переполнилась. Во-вторых, разработка фичей ускоряется, и у эффективных менеджеров появляется соблазн закинуть в зону ответственности каждой команды побольше всего, или, наоборот, оставить зону ответственности такой же, а количество голов, думающих над ней, сократить. И тогда даже без учета выросшей случайной сложности, даже неотъемлимая сложность перестает помещаться в головах. Так мы и получаем comprehension debt – головы разработчиков уже перегружены, их емкости не хватает, чтобы вместить туда что-то новое, и знание о том, как работает продукт, постепенно ускользает. Спустя короткое время, команда уже не может безопасно менять свою систему – количество инцидентов растет, а способность их предсказать падает. С таким долгом можно бороться инструментальными способами, упрощая для человека понимание того, как работает система – ну условно показывать простые диаграммы вместо полотен кода. Но важно помнить, что, как информацию не сжимай, количество концепций, которые мы в голове можем держать – ограничено. И лучшее, что вы, как менеджер, можете в такой ситуации сделать – это удерживать количество компонентов, за которые отвечает команда, в пределах ее когнитивной емкости. Еще про comprehension debt хорошо пишет у себя в канале Владимир Балун. Он руководил разработкой системы трейсинга с трафиком 11GB/s в Яндексе, поэтому набил руку на сложных системах, и знает, о чем говорит. Поэтому можете почитать его пост, а заодно подписаться на его канал, где он рассказывает о своем опыте программирования, разработке сложных высоконагруженных систем и просто делится своими мыслями о разработке.

AI внушает ложную уверенность Можете добавлять себе еще одно исследование в копилку когнитивных искажений, которые появляются при взаимодействии людей из AI. В этот раз сделали следующее – выдали группам испытуемых доступ к довольно слабенькой гугловой модели, и задавали им вопросы из категорий, в которых модели часто ошибаются – например, про визуальные детали из фильмов. Наблюдения вот такие: 👉Доступ к AI снижает вероятность ответа на вопрос "я не знаю" с 44% до 3%. 👉Точность ответов при этом упала с 27% до 9%, а вот уверенность в ответе, наоборот, выросла в 2.5 раза, с 30% до 76%. При этом часть участников были готовы ответить правильно до консультации с AI, а потом поменяли свой ответ. 👉Добавление денежной мотивации почти не помогло, готовность признать незнание поднялась только до 8%, а точность до 16%.

Как строятся современные базы знаний Команда Cerebras рассказала, как они построили свою автоматически обновляемую внутреннюю базу знаний, которую одновременно используют и люди, и агенты. Вот интересное: 👉База знаний строится поверх всех источников, в которых уже накапливается ценная информация – Slack, кодовая база, документы, Jira, Confluence и куча чего еще. 👉Самые полезные сведения лежат в Slack, так как в глубине тредов принимается куча важных решений. Вытаскивать ее оттуда тоже очень сложно, потому что мусорных обсуждений тоже много. В итоге сработала комбинация из полнотекстового поиска, эмбеддингов, механизма устаревания фактов, реранкинга более редких токенов. 👉Для поиска по коду используется опенсорсный фреймворк CocoIndex, который умеет пересчитывать индекс для каждого коммита инкрементально. 👉В базе знаний есть механизм плагинов, чтобы каждая команда могла добавить свой кастомный источник. 👉Помимо непосредсвенно поиска информации, сделали отдельный тул who_knows, который сразу выдает имена людей, релевантных поисковому запросу. 👉Информация агрегируется по проектам, чтобы сделать результаты поиска более релевантными.

Тревожит FOMO — страх что-то упустить? Чувствуете, что упускаете ИИ-волну и не знаете, что с этим делать? Вокруг ИИ-агенты, вайбкодинг... А у вас бизнес, рутина и ... По-честному... Даже некогда сесть и разобраться... В Битрикс24 есть все для того, чтобы начать использовать новые фишки ИИ в числе первых. Это ИИ-сервис для бизнеса, где нейросети встроены прямо в рабочие процессы. Пока все платят в долларах за подписки и жонглируют десятками приложений — уже тысячи компаний в России автоматизируют бизнес с Битрикс24. Что внутри? • База для любого бизнеса: CRM, задачи, мессенджер • Нейросети и агенты: помогают с задачами, ищут информацию, пишут тексты и т.д. • Вайбкодинг для всех: с подсказками и в привычном интерфейсе Подключите ИИ к своему бизнесу уже сегодня.

❤️ В Яндексе завершилась мастерская «Диапазон» — трёхмесячная образовательная программа для 45 руководителей из Яндекса и других IT-компаний. Тема — профессиональная репутация и усиление влияния внутри компании и во внешних комьюнити через развитие профессиональной репутации. Не в смысле «как начать вести канал» или «как стать заметнее в соцсетях». На уровне senior и C-level репутация — это рабочий управленческий инструмент. От неё зависит, чью позицию слышат, кому доверяют сложные задачи, кого зовут в важные проекты, партнёрства и профессиональные дискуссии.

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

В программе выступили HR-директор Яндекса Дарья Золотухина, предприниматель Денис Кутергин, инвестор и сооснователь Okko Екатерина Лапшина, Нина Зверева и другие практики. Сам факт такого проекта — интересный сигнал от Яндекса: компания инвестирует не только в развитие навыков сотрудников, но и в формирование сильного экспертного комьюнити — внутри компании и на рынке. Часть материалов мастерской открывают для внешней аудитории. ➡️ 28 июля в 19:00 пройдёт онлайн-лекция Александра Ложечкина | CIO Райффайзен Банка и Наталии Губаревой | Head of R&D в HR-маркетинге Яндекса: «Я как продукт и я как герой: как системно строить репутацию эксперта». Обсудят продуктовый подход к собственной карьере, профессиональное позиционирование и сторителлинг, который помогает доносить экспертизу без «самопиара ради самопиара». После регистрации можно получить промпт для самостоятельного аудита себя как профессионального продукта. 📍 Регистрация: https://events.yandex.ru/events/diapazon_online

Интервью в Weekend Talk Я, кстати, совсем забыл рассказать две личных новости. Во-первых, я ушел из JetBrains, поработав там последний год как VP по продукту. Во-вторых, я решил выдохнуть от работы в корпорациях, и вышел работать в стартап CodeSpeak, где мы думаем над тем, как помочь людям продолжать разрабатывать поддерживаемые системы и не терять понимание того, как они работают. Вообще, уже за первый месяц видно, насколько сильно работа в стартапе отличается от всего, к чему я привык – это касается и скорости принятия решений, и дефолтного уровня уверенности в них, и очень частой смены фокуса внимания. И, главное, того, насколько сильно нужно погружаться в сам продукт – это то, чего мне сильно не хватало последние много лет. Так вот, я недавно сходил в гости в подкаст Weekend Talk, где рассказал Андрею Смирнову про оба эти изменения, а заодно много разных баек про жизнь в Шотландии, автоматизацию работы AI клуба, в котором, в отличие от конференций Podlodka Crew, я изначально решил не пытаться нанимать большой команды, и про свои мысли про будущее роли тимлида.

Про организационный дизайн для директора Продолжаем серию заметок про то, какие навыки важны для директора. Вот тут можно почитать про развитие руководителей под собой и про принятие решений в условиях неопределенности. Задача руководителя разработки – управлять системой, составляющими которой являются как люди, так и технические компоненты. Умные люди называют такие системы "социотехническими". Про ограничения, которые на всю систему накладывает ее техническая часть, в целом всем всегда интуитивно понятно – именно поэтому мы столько времени тратим на разговоры про трейдоффы разных подходов к архитектуре. Человеческая часть, на мой взгляд, имеет гораздо более определяющее значение. Оргдизайн – это главный инструмент, который есть у директора, чтобы менять ее контуры и возможности. У меня нет какой-то единой стройной теории того, как работать с оргдизайном, но есть несколько отдельных советов и наблюдений. 👉Начну сразу с козырей, и порекомендую книгу Team Topologies. В ней довольно много лишнего, но первая часть – золото, потому что дает хороший набор строительных блоков, из которых можно дизайнить свою организацию, их интерфейсов для работы друг с другом, и ограничений, от которых стоит отстраиваться. Сильно помогает рассуждать про оргдизайн гораздо глубже, чем просто рисуя рандомные квадратики на доске в Miro. 👉Оргдизайн – это всегда политический вопрос. Размер команды, скоуп, зона ответственности, да даже название – все это напрямую влияет на статус людей, их власть и даже на зарплату. Поэтому про оргдизайн нельзя думать чисто рационально – люди будут сопротивляться, когда у них что-то забирают, или когда кому-то другому дают новую область ответственности. При любой реструктуризации обязательно заранее продумывайте, как она повлияет на всех, кого затронет, проговорите с ними лично, придумайте противовесы. 👉Команду важно вовликать в дизайн ее собственной структуры, но при этом продолжать держать в голове предыдущий пункт. Задача директора – отделять рациональные возражения от политических, и работать с ними по-разному. 👉Для нормальной работы с оргдизайном важны базовые представления о психологии групп и групповой динамике. Самый банальный пример – как только вы разводите людей по двум разным группам, вы строите забор между ними, и провоцируете разделение на "свой-чужой". Если для успеха важного проекта этим людям нужно работать сообща, то такое решение может быть не самым лучшим. 👉Нужно понимать, как организованы потоки работы и доставки ценности – где проходит критический путь, где на нем возникают передачи задач от одной команде к другой, где бутылочные горлышки, где вся система спотыкается. 👉У вас никогда не будет идеального оргдизайна. Меняется внешний мир, меняются цели, меняются внутренние компоненты системы, и ее нужно постоянно донастраивать. А для этого вам нужна собственная система сигналов о том, что происходит на ее входах, выходах, внутренних взаимодействиях.

Что сейчас чувствуют люди в IT Я за последние пару недель провел пару десятков продуктовых интервью с разработчиками, на которых, помимо прочего, спрашивал, как вообще они себя ощущают в меняющейся индустрии, и что происходит с их инженерной идентичностью. То, что я услышал, почти полностью совпадает и с результатами опроса из заголовка: 👉Половина чувствует себя заряженными – им кажется, что они могут сделать гораздо больше классного, чем раньше. Вторая половина находится в разной степени стресса, разочарования и выгорания. 👉Говоря про выгорание – оно свойственно и первой группе. 56% опрошенных говорят о сильном градусе выгорания, тогда как в прошлом году их было 44%. 👉Одновременно с этим падает оптимизм относительно карьеры в нашей индустрии. Что интересно – больше половины опрошенных теперь активно отговаривают других идти работать в IT. 👉Все оценивают свою продуктивность как повысившуюся, а вот качество результатов стало хуже. 👉Самый сильно коррелирующий с выгоранием фактор – эффективность менеджера. Так что засучиваем рукава!

Как руководить, когда люди выдыхаются, а KPI растут? Бизнес требует более высоких результатов, планы увеличиваются, а команда уже работает на пределе возможностей. Знакомая ситуация? Поставить команду перед фактом — верный путь к выгоранию и потере доверия сотрудников. В то же время руководитель не может просто отказаться от новых KPI — нужно грамотно обосновать ограничения руководству, и это отдельный вызов. 📌 23 июля в 20:00 по мск спикер лаборатории коммуникации Софт Скиллз Лаб проведет открытый вебинар, где разберет, как балансировать между требованиями бизнеса и ограниченным ресурсом команды. Вы узнаете: ▫️ Как обсуждать с сотрудниками повышение KPI и растущую нагрузку? ▫️ Что делать, если подчиненные говорят, что и так работают на пределе? ▫️ Как защищать интересы команды перед бизнесом, сохраняя доверие топ-менеджмента? 🎙 Спикер — Михаил Ромашов, руководитель курса «Осознанные коммуникации», владелец продукта в SberCIB, преподаватель НИУ ВШЭ и Сколково, соавтор книги «Эффективный конфликт». Встреча пройдет в Zoom, где вы сможете задать свои вопросы и разобрать сложные рабочие кейсы. 👉🏻 Запустите бота, чтобы получить ссылку на конференцию

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

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

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

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

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

🧭 Корпоративный университет — большой проект, нужны команда, платформа, программы, бюджет. Но сначала стоит разобраться, зачем компании вообще нужна система обучения. 16 июля в 17:00 Нетология проведёт бесплатный вебинар «Как создать корпоративный университет с нуля: этапы и бюджет». Елена Степанова, бизнес-стратег, ментор Сколково и кандидат экономических наук, разберёт, когда компании действительно нужен свой университет, как выбрать формат обучения, связать его с показателями бизнеса и заранее оценить расходы. Присоединяйтесь — будет полезно собственникам, директорам по персоналу, руководителям обучения и операционным директорам. Вшей, пожалуйста, ссылкив название вебинара и в слово "Присоединяйтесь" Реклама. ООО “Нетология” ОГРН 1207700135884 Erid: 2VSb5xRGR2r

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

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