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

Два вида сложных решений 1️⃣70/30, когда один из вариантов точно лучше другого 2️⃣49/51, когда решения примерно одинаковы Сложность в том, чтобы понять, с каким именно случаем вы столкнулись. Если решение надо принять срочно, а очевидного варианта нет, просто подбросьте монетку. Если решение не срочное, то можно дать ему настояться – и либо один из вариантов станет очевидно правильным, либо вернетесь к монетке.

Шаблон для подбора в команду Я в JetBrains недавно решал похожую проблему с наймом продакт-менеджеров – многие команды не могли четко сформулировать рекрутерам, кто конкретно им нужен, и это тащило за собой ворох негативных последствий. Мы договорились, что перед открытием новой позиции нанимающий менеджер должен заполнить небольшой hiring brief. Сначала идут вопросы про роль: 👉За какие продукты или фичи кандидат будет отвечать 👉Основные цели, которые перед ним будут стоять 👉Примеры конкретных задач 👉Уровень сеньорности по нашей линейке грейдов 👉Кого ему придется менеджерить Профиль идеального кандидата: 👉Тип опыта (B2C/B2B, corporate/startup, new product/scaling/mature) 👉Доменный опыт (например, геймдев) 👉Конкретные требования к техническому бэкграунду (он у нас нужен почти любому продакту, но уровень может различаться) 👉Конкретные компетенции с разбитием на must-have и nice-to-have 👉Важные для позиции личные качества (например, готовность к росту в пипл-менеджмент) С введением hiring brief стало сильно лучше – помимо улучшения качества кандидатов, приводимых рекрутерами, он очень помогает задизайнить вопросы и кейсы для интервью.

Не надо искать идеальных Вакансии часто закрываются долгими месяцами не из-за маленького потока кандидатов и не из-за каких-то уникальных требований – а просто потому, что нанимающий менеджер плохо представляет, кто именно нужен команде, и ищет абстрактного идеального сотрудника. Из-за этого возможен и другой эффект – человека в итоге наняли, а на испытательном сроке он не справился. В статье как раз про системный подход, который позволяет подходить к поиску кандидатов рациональнее: 1️⃣Сначала поймите, кого вы ищете. Подумайте, что важнее всего в этой конкретной роли по трем блокам – харды, софты, мотивация. Например, все три блока будут разными при найме на поддержку легаси-монолита и для разработки быстрых прототипов новых идей. Найм – инженерная задача с функциональными требованиями и ограничениями, и, чтобы получить оптимальное решение, их надо четко понимать. 2️⃣Относитесь к собеседованию не как к экзамену или способу померяться знаниями. Это способ понять, усилит ли человек команду. Например, для оценки хардов важно не столько знание конкретных фреймворков, сколько увидеть, как кандидат думает в незнакомой ситуации, диагностирует баги, насколько прагматичен при выборе решения. А для оценки мотивации хорошо бы понять, что человека драйвит и, например, как он относится к рутине. 3️⃣Чтобы это оценить, задавайте вопросы, которые побуждают кандидата разговаривать с вами, а не искать правильный ответ. В идеале – поведенческие, про то, как человек вел себя раньше в похожих ситуациях. 4️⃣Слушайте больше, чем говорите. Давайте кандидату время на тишину, спокойно подумать. Задавайте уточняющие вопросы, не останавливайтесь на поверхностных ответах. Слушайте интуицию – если что-то вас зацепило, то у этого есть какая-то причина, даже если ее пока не поняли. 5️⃣После интервью зафиксируйте все наблюдения, так как потом они очень быстро забудутся. Делайте заметки по всем кандидатам в единой системе – а в какой конкретно, не так важно. 6️⃣Следите за красными флагами, при которых даже продолжать не имеет смысла. Например, обесценивает какие-то роли или этапы процесса, или сваливает вину на других.

Месяц экспериментов с AI в компании на 700 человек Когда все время команды занято срочными дедлайнами и тушением пожаров, времени на то, чтобы "заточить пилу" совсем не остается. А для многих команд научиться вменяемо работать с AI может стать не просто заточкой пилы, а заменой пилочки для ногтей на лазерный меч. Так вот, в Monday провели интересный эксперимент – выделили целый месяц, в течение которого сместили фокус с продуктовых релизов на то, чтобы научиться использовать AI в своих ежедневных задачах. Вот как это работало: 👉Каждый день проводились лекции, тренинги и воркшопы от людей, которые уже научились получать пользу от AI в своих задачах 👉Раз в неделю команды проводили демо-сессии, где рассказывали, что они попробовали, что сработало, а что – нет 👉Запросы на покупку новых инструментов моментально одобрялись На результаты, конечно, стоит смотреть немного скептически, так как про них рассказывает топ-менеджер, а не люди на местах, но все равно интересно: 👉Доля AI-assisted PRs выросла с 50% до 90% 👉Команды показали 71 работающую демку того, как они используют AI в своей работе 👉Оценка на распил монолита уменьшилась с 408 до 21 человеко-недели (что ж они там такого автоматизировали-то)

Сколько инженеров работают на двух работах сразу В Стэнфорде есть группа ученых, которые занимаются изучением продуктивности разработчиков. Самое крутое – это то, что у них есть доступ к приватным репозиториям 1000 разных компаний, с коммитами от 100к+ разработчиков. На его основе они находят много интересных инсайтов (например, можно вот этот доклад послушать или почитать эту бумагу). Но сегодня я принес два интересных факта: 👉9,5% всех инженеров – "призраки". Они делают где-то 10% коммитов в сравнении с медианным разработчиком. 👉4% инженеров работают на 2+ работах сразу. При этом продуктивность их работы почти в два раза ниже медианы. Я очень хочу вытащить ведущего рисерчера в подкаст и обсудить асе детали – предварительное согласие есть, где-то осенью будем пробовать!

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

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

Новые выпуски тимлидских подкастов Напоминаю, что на прогулке или в зале лучший способ совмещать приятное с полезным – включить на фоне хороший подкаст. Держите подборку вышедших в последнее время выпусков: 👉"Три тимлида заходят в бар" про work/life balance – действительно ли руководитель может своим примером влиять на команду, и как этого избегать. 👉"Бреслав и Ложечкин" про вред от бездумной data-driven культуры. 👉"КОДА КОДА" про андрагогику – науку про обучение взрослых, куда позвали Орлова и Панкратова из Стратоплана 👉Подлодка про то, как AI помогает небольшим командам и стартапам ускорять разработку в десятки раз Кстати, если вы вдруг знаете еще какие-то подкасты и блоги на YouTube, которые не попадают ко мне в подборки – поделитесь!

Абсурдность системы найма и роста джунов Я писал код почти всю сознательную жизнь. Началось все с толстенного зеленого тома "Библия Delphi", калькуляторов и симуляторов бомжей, потом пришла J2ME с деобфускацией и модами для мобильных игр, а в старших классах продолжилось С++ с простыми вирусами и кейлоггерами. Где-то тогда же я погрузился в прекрасный мир готовых PHP движков, и стал собирать на заказ бесконечные интернет-магазины, портфолио и визитки. Универ меня немного подвел – вместо ожидаемого технического хардкора я получил изучение бесконечных гостов и аппаратных методов защиты информации. Короче говоря, к третьему курсу, когда я задумался о поиске полноценной фуллтайм работы программистом, за плечами у меня был ворох какого-то очень странного опыта, довольно слабенький теоретический бэкграунд, и отсутствующее понимание того, что вообще такое промышленная разработка. Поэтому, мне кажется, что первую работу я получил ну очень легко – отозвался на первую попавшуюся вакансию в маленькую студию мобильной разработки, показал несколько пет-проектов под Android, и меня взяли без единого технического вопроса. Спустя два года работы в студии, в принципе, мало что поменялось – я собрал еще больше странного разношерстного опыта, но программистом все еще был объективно слабеньким. При поиске второй работы я нацелился уже на то, чтобы попасть в крупную продуктовую компанию. И тут, кажется, мне снова повезло. В 2013 году сам процесс собеседований был довольно лайтовый – с несколькими проектами в проде за плечами и довольно базовыми знаниями своего языка я попал в Rambler&Co на роль мидла, хотя на него тянул ну с очень большой натяжкой. Похожие истории были у многих моих знакомых – входить в IT и искать свои первые работы было действительно просто, если ты прилагал к этому хотя бы минимальные усилия. Индустрия тоже выглядела по-другому. Джунов готовы были нанимать, выделять им наставников, давать время и пространство для роста. Сейчас с каждым годом ситуация становится все абсурднее – планочка требований к мидлу поднимается, а воронка входа сужается, из-за чего приток новых специалистов становится все меньше. В статье довольно хорошо разбирается абсурдность получившейся системы. Она, правда, в основном про Россию, но похожая ситуация сейчас во всем мире.

Главные боли менеджеров в 2025 На Реддите менеджеры рассказывают про то, от чего у них больше всего пригорает в этом году: 1️⃣Топ-менеджмент и их одержимость AI, из-за которой планы меняются каждую неделю 2️⃣Неквалифицированные кандидаты, которые пытаются пройти собесы с помощью AI 3️⃣Рост требований к продуктивности, вызванный AI, и необходимость выполнять сразу много ролей 4️⃣AI-слоп везде: в коде, комментариях, имейлах А в комментариях давайте соберем срез по нашим подписчикам – что делает в этом году вашу работу максимально невыносимой?

Как HP купил Palm Замечательная история про то, как HP купил Palm за 1.2 миллиарда долларов, а спустя 49 дней убил всю линейку продуктов и, по сути, закрыл компанию. И все это случилось, пока CTO, пролоббировавший покупку, лежал в больнице и ничего с этим сделать не мог. Причины такие же, как и всегда – новый СЕО продал совету директоров свой вижн, нужно было быстро показать результаты и сильную руку, поэтому вместо рациональных решений не разобравшись рубил все с плеча.

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