Про проблемы с 1-1

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

При всем этом у 1-1 дофига недостатков:

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

Автор советует заменить регулярные 1-1 на:

👉Обсудить в чате -> Быстро ad hoc созвониться на 5 минут -> и только потом делать полноценный митинг. Большая часть вопросов таким образом решится гораздо быстрее.
👉Статус-чеки по проектам, которые включают в себя всех нужных участников.
👉Выделенное время под карьерные разговоры и обсуждение перфоманса.

Самые полезные вопросы на интервью от кандидата

На Reddit обсуждают список самых полезных вопросов, которые когда-либо слышали от кандидатов к компании в процессе собеседований.

Мне очень понравилась следующая мысль:

What I can say is that the candidates who impress me most in that section of the interview are ones that ask things that demonstrate they understand the role and the surrounding workflows. Things that show they are already picturing themselves in the role and looking for potential issues and blockers. And particularly I like questions that are hunting for potential red flags.

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

Расскажите, а какие самые ценные вопросы задавали вам?

Про книгу "Never Split the Difference"

Только что дочитал очень классную книгу про переговоры – Never Split the Difference. Автор, как часто водится у тренеров по переговорам, работал в силовых структурах и занимался освобождением заложников, после чего решил попробовать адаптировать используемые ими приемы к нашему с вами миру бизнеса и бытовых вопросов.

Какие идеи мне зашли:

👉Самая частая ошибка в переговорах – говорить о себе, своих интересах и своей позиции. Гораздо ценнее слушать вторую сторону, и всякими образами подталкивать их к тому, чтобы они побольше говорили, давали вам новую информацию, да и вообще чувствовали себя хозяином положения.
👉Хорошие инструменты, помогающие создать у второй стороны ощущение, что ее услышали, и продолжать говорить – зеркалирование и суммаризация.
👉Топовый прием – калибровочные вопросы. Вместо того, чтобы отвечать отказом на предложение, которое вам не подходит, лучше задавать открытые вопросы, которые подтолкнут вторую сторону к тому, чтобы принять вашу картину мира. Условно говоря, на слишком высокую цену стоит отвечать не предложением более низкой, а вопросом "Как я смогу себе позволить эту цену, если у меня есть только...?".

Книга уже окупилась – на днях сбил 100$ с цены за отель! Читается легко, кейсы полезные, рекомендую.

Работаем с лоу-перформерами

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

Первое, что стоит делать, когда вы столкнулись с лоу-перформером – проверить, что вы сами не накосячили, и ваши ожидания от перфоманса сотрудника ему известны и понятны.

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

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

Про качество AI продуктов

А сегодня смотрим классный разговор моих хороших друзей, Виталия Шароватова и Алексея Шаграева. Леша сейчас делает Lovi – продукт, помогающий подбирать косметику и skincare продукты. Конечно же, с помощью AI – и конечно же сталкивается с тем, с чем и другие похожие продукты – проверять качество становится сильно менее тривиально.

Вот какие подходы к QA у них работают:

👉Dark launch — выкатывают фичу в прод, но скрытно. Пользователь не видит, зато продукт уже работает с живыми данными.
👉Краудтестинг с помощью Толоки или MTurk, чтобы получать фидбэк от максимально разнообразных живых пользователей.
👉Black box testing – единственный способ оценивать функциональность недетерминированной системы.
👉Тестирование с помощью AI агентов на фермах девайсов помогает симулировать реальных пользователей и быстро прогонять разные exploratory сценарии.

Про карьеру в форме пирамиды

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

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

Что отделяет сеньоров от стаффов

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

Про многозадачность

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

👉Общий объем задач и время на их выполнение на самом деле растет. Чем сложнее задачи, тем дольше между ними переключаться, и тем больше потерь происходит. Ученые даже посчитали, что на потери переключений приходится до 40% времени, что очень дофига.
👉Меньше внимания уделяется отдельным задачам, и качество их проседает. А так как менеджер в основном работает с другими людьми, проседание качества получает цепной эффект.
👉Растет уровень стресса и тревожности.
👉Мозг меньше отдыхает, падает креативность, вы превращаетесь в машину по выполнению скучной рутины (которую как раз хорошо в будущем заменят AI).
👉Ухудшается рабочая память, падает способность к концентрации, и в итоге какие-то важные большие сложные задачи вы вообще перестаете быть способными выполнить.
👉И итог всего этого – хроническая усталость и выгорание.

Подкасты на выходные

Возвращаемся к нашей нерегулярной рубрике "Что послушать про тимлидство на выходных":

👉"Бреслав и Ложечкин" про вайбкодинг: область применимости, польза и последствия, влияние на будущее языков программирования и джунов в индустрии.
👉"КОДА КОДА" про проектный менеджмент как профессию: чем занимаются, как делится ответственность с продактом и тимлидом, что ожидает в будущем.
👉"Три тимлида заходят в бар" про succession planning: как вырастить себе замену, которая подменит тебя в отпуске или когда ты пойдешь на повышение.
👉Weekend Talks с Романом Ивлиевым, бессменным директором TeamleadConf, про переосмысление карьеры после 25 лет в IT, боли тимлида и отказ от консалтинга.

Про экономику вайбкодинга

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

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

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

Как нанимать джунов с учетом AI

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

👉Умение формулировать понятный промпт и верифицировать результаты AI.
👉Умение смотреть на код критически, задавая вопросы "почему здесь так, а не иначе?"
👉Понимание границ применимости AI и всех ограничений, включая приватность и этику.

Такие навыки превращают джуниора в полезного члена команды, а не в бездумную прослойку между AI и ментором. Что можно сделать, чтобы прийти к этой картине:

1️⃣Сменить подход к найму – вместо оценки знания алгоритмов смотреть на то, как кандидат задаёт вопросы модели и исправляет её промахи.
2️⃣Организовывать работу через трио сеньор + джуниор + AI. Пусть опытный разработчик показывает ход мысли, новичок – задает вопросы и озвучивает сомнения, ассистент – генерирует код. Знания передаются быстрее, ошибки ловятся раньше.
3️⃣Чередуйте задачи с AI и без него. Хотя бы раз в спринт давайте новичку задачу, решить которую надо целиком вручную, чтобы не атрофировались навыки вроде дебага.
4️⃣ Добавьте в свой онбординг гайд по AI, в том числе какие данные можно загружать в модель, какие – категорически нельзя.
5️⃣Пересмотрите свои критерии перфоманса для джунов. Оценивайте не просто закрытые задачи, а способность объяснить решение, быстро найти и починить баг, предложить улучшение после отклика ассистента.

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

Architecture Decision Records

Как вы знаете, ADR – документ, который описывает важные технические решения, весь нужный контекст вокруг из принятия и последствия. По ссылке – большая подборка шаблонов, рекомендаций по работе с ними и даже специализированных тулов вроде adr-tools. А самое интересное – публичные гайдлайны конкретных компаний:

👉Amazon
👉GitHub
👉RedHat

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

Как хвастаться своей работой

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

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

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

Советы по созданию линеек грейдов

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

Но если вы уверены, что вам нужно описание карьерных уровней, вот набор советов от человека, который первым выложил карьерный фреймворк своей компании в открытый доступ:

👉Не давайте HR составлять описания уровней, получится фигня. Определять требуемый уровень экспертизы для разных уровней вообще не их работа.
👉Детали важны. Если ваше описание уровней похоже на гороскоп, оно будет только вредить. Субъективных штук вроде "high impact", "large systems" не избежать, но вы можете постараться минимизировать количество таких абстрактных терминов, и дать хоть какую-то шкалу для их оценки.
👉Хороший способ объяснить смысл и логику за табличкой – сопроводить ее подробным блог-постом.
👉Постарайтесь не превращать эту табличку в чек-лист компетенций, который гарантирует промо на следующий уровень по его заполнению. Промо – функция не только навыков человека, но и текущих потребностей компании.
👉Будьте честными – не для каждой профессии можно подготовить линейку от самых низких уровней до VP.