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

AI фейки на собеседованиях Буквально недавно к нам собеседовался русскоязычный продакт, который в начале разговора подключил к звонку Otter.ai (это такой сервис автоматической расшифровки звонков). Он очень бодро отвечал на все behavioral вопросы, а порой даже слишком бодро, подкрепляя свои истории кейсами других людей (а вы знаете, что с такой же проблемой сталкивался и Джобс...). Явно прокололся он в тот момент, когда пытался выговорить незнакомые ему сложные слова на английском языке. Короче говоря, наша гипотеза в том, что он автоматически расшифровывал наши вопросы, отправлял их LLM вместе с кастомными промптами, и весело зачитывал ответы. Так вот, такой читинг – это еще цветочки. Держите дикую историю про то, как в один и тот же стартап собеседовались два польских программиста с идеальными техническими знаниями и небольшими желтыми флагами на скрининге и интервью с нанимающим менеджером. Только на последнем этапе стало понятно, что это – полностью AI-генерированные фейки, начиная от аватара на видео, заканчивая всем LinkedIn профилем.

Способы принятия решений в команде Если в понедельник мы обсуждали довольно абстрактную модель принятия решений, то теперь держите максимально прикладные методы: 👉Голосование точками. Тут все стандартно, помогает быстро выбрать один ответ из множества, и при этом учесть мнение каждого. 👉Степень поддержки. Каждый участник оценивает решение по x-балльной шкале. Решение принято, только если средний уровннь поддержки больше нужного уровня. 👉Метод NUF. Взвешенная оценка – новизна (new), полезность (useful), осуществимость (feasible). Решение можно принимать как по общей оценке, так и выбрав один или несколько приоритетных критериев. 👉Игра в покер. Похоже на предыдущие методы, но проводится в закрытую. Все так же, как в planning poker – все выкладывают карты, вскрываются, затем владельцы минимальной и максимальной оценок спорят. 👉Метод парных сравнений. Выбираются критерии, каждое решение сравнивается с каждым, победитель получает +1 балл. Наилучшим становится тот вариант, который победил во всех парах. А вообще, я наконец-то в отпуске, так что на этой и следующей неделе ежедневных статей не обещаю!

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

Треугольник принятия решений Я периодически делюсь статьями про разные практики документирования принимаемых в команде решений. Классический пример – Architecture Decision Records, документы, которые сохраняют весь контекст когда-то принятых решений про дизайн проекта. Так вот, вне зависимости, какое именно решение вы документируете, у него можно выделить три ключевых компонента: 👉Желаемое будущее, в которое вы хотите прийти. 👉Действие, которое должно привести вас в это будущее. 👉Триггер – событие, которое вызвало необходимость принятия решения. Если использовать эти компоненты как вершины треугольника, мы получаем отличную ментальную модель, в которой его стороны становятся дополнительными аспектами принятия решения: 👉Критерии: ограничения, которые влияют на то, в какое будущее мы хотим прийти, и желаемые критерии успеха. 👉Сценарии: все возможные варианты будущего, к которым может привести выбранное действие. 👉Анализ: сбор информации, который помогает перейти от триггера к непосредственному действию. После того, как решение принято и исполнено, с помощью этой же модели удобно сравнивать ожидание и реальность (картинка как раз про это). Если модель заинтересовала, то в статье есть очень подробный пример продуктового решения, разложенного по этой модели.

Принципы Principal инженеров Amazon Случайно наткнулся на страницу со списком культурных и инженерных установок, которых придерживаются Principal инженеры в Amazon: 👉Задавать инженерную планку своим собственным примером. 👉Не бояться выходить за рамки привычных концепций и подходов. 👉Прислушиваться к остальным, давать место быть услышанными даже новичкам. 👉Подходить ко всем проблемам с прагматизмом. 👉Упрощать любую проблему до ее базовых принципов, делать сложное ясным. 👉Быть гибкими, подстраиваться под нужды команды, проекта и продукта. 👉Уважать то, что написано и сделано до вас. 👉Постоянно учиться и помогать становиться лучше другим. 👉Не просто деливерить результаты, а оказывать заметное влияние на компанию через команды и продукты.

Новые выпуски менеджерских подкастов 👉"Три тимлида заходят в бар" про техлидов – как и зачем искать техническое лидерство, и должен ли техлид быть инженером, разбирающимся во всех технических нюансах проекта. 👉"Бреслав и Ложечкин" продолжают говорить про дайверсити – в этот раз про стереотипы, предвзятость, и то, как с ней бороться. 👉"Frontend Weekend" с Евгением Россинским, СТО Иви, про то, как не выгореть, работая техническим директором 15 лет в одной компании. Кстати, я понял еще одну суперсилу подкастов. В условиях полной удаленки они неплохо компенсируют мне отсутствие полурабочих разговоров на кухне, которых иногда очень не хватает. Так что если вы в такой же ситуации – попробуйте завести парасоциальные отношения с кем-то из подкастеров!

Capable и capability Capable - can already do the “work” Capability - has potential to be capable to do the “work” В статье хорошо разбирается разница между двумя состояниями людей – Вася может быть способен выполнять задачу уже сейчас, а Маша – пока еще не уметь, но иметь потенциал развить эту способность. Так вот, основные мысли: 👉Развитие потенциала требует индивидуального менеджмента, а не командного – то есть нужно учитывать личные мотивацию и цели каждого человека. 👉Индивидуальный подход к обучению – пререквизит к тому, чтобы команда становилась более способной со временем. У разных людей разные роли, способности их должны дополнять друг друга. 👉Задача хорошего менеджера – глубоко понимать особенности каждого человека, и помогать раскрыть его потенциал с их учетом и с учетом потребностей бизнеса.

Открытое собеседование на СТО Роль СТО сильно зависит от размера, структуры и культуры компании. Собеседования тоже довольно сильно отличаются от компании к компании, но при этом общее ядро выделить точно можно. Ведущие подкаста "Бреслав и Ложечкин" уже завтра проводят открытое собеседование СТО – Саша будет собеседовать Андрея. Помимо самого собеседования будет детальный анализ всех вопросов и ответов вместе с экспертом, который отвечает за Executive Search. Короче говоря, если вы посматриваете на роль СТО как на возможный майлстоун в вашей карьере, обязательно подключайтесь! Собес пройдет в Телеграм-канале по ссылке в заголовке.

Как AI повлиял на качество кода в 2024 GitClear выпустили свой ежегодный отчет, в котором они анализируют 25 больших опенсорсных репозиториев на 200М строк кода. Так вот, в сравнении с 2023 годом, количество блоков кода, в которых дублируется 5+ строк, выросло в 3 раза (а если сравнивать с 2021, то вообще в 6!). При этом рефакторить код стали на 40% реже, а копипастить – на 17% чаще. Сам репорт читайте аккуратно, GitClear очевидно довольно предвзяты, так как их задача – продать инструмент контроля за качеством кодовой базы. Но сами данные интересные – если даже в крупном опенсорсе с хорошей инженерной культурой качество кода падает, что говорить про обычный энтерпрайз.

DEI – хорошая идея, плохая реализация 👉Хороший менеджер оценивает людей не только по их текущим результатам, но и по потенциалу. Компания – это система, которая может как раскрывать этот потенциал, так и убивать его. 👉Задача компании – зарабатывать деньги. Этому помогают ценности и культура. DEI (diversity, equity, inclusion) – инструмент, который может помочь с реализацией некоторых ценностей, но он не должен подменять ни их, ни цель существования бизнеса. 👉Инклюзивная культура помогает строить хай-перфоманс команды за счет того, что расширяет как воронку кандидатов в целом, так и воронку тех, кому окружение не мешает добиваться крутых результатов. А чем больше перформящих людей, тем выше планочка поднимается для всех. 👉Пример того, почему это важно – после скандала в Uber процент женщин в SRE команде упал с 25% до 3%. А это означает кучу упущенных возможностей получить крутых сотрудников. 👉Разумные DEI инициативы направлены на то, чтобы уменьшить когнитивные искажения, которые мешают какой-то группе людей нормально работать и расти в компании. 👉При этом на самом деле большинство DEI кампаний бессмысленные – вместо того, чтобы объяснять, чем бизнесу важна инклюзивность, и решать конкретные точечные проблемы, они навязывают карго-культы и заворачивают их в обертку пустых ценностей.

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

Meetily – локальный генератор заметок со встреч Я давно уже хотел настроить себе пайплайн записи встреч, их расшифровки, суммаризации и складывания куда-то в Obsidian. Все это, конечно, только на локальных моделях, чтобы данные никуда не утекали. Так вот, только я сел настраивать пайплайн, как наткнулся на готовый опенсорсный проект – Meetily. Что он уже умеет: 👉Подключаться к аудиосессии и захватывать ее 👉Транскрибировать встречи с помощью whisper.cpp, причем сразу с разметкой спикеров 👉Использовать разные локальные модели для суммаризации Забираю себе потестировать, вы тоже потом расскажите! Демку можно посмотреть вот тут.