Качество разговоров и зрелость компании

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

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

Держите список вопросов для самодиагностики:

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

Последний вопрос мой любимый, конечно – захотелось завести дневничок эмоций и помаппить туда встречи, на которые я походил за последние недели.

Забирает ли AI радость от работы

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

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

Так вот, для таких разработчиков AI хоть и повышает механическую продуктивность, но при этом забирает из работы всю радость, ничем ее не заменяя. Что с этим делать пока не очень понятно, так что пока что просто ноем вместе с автором статьи и продолжаем нажимать Tab-Tab-Tab.

Зачем менеджеру смотреть в бездну

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

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

Почему мы избегаем бездны? Признавать промахи – больно; принимать резкие карьерные решения – страшно; да и проще отложить на потом. Проблема в том, что за «потом» всегда приходится платить проценты: упущенные возможности, выгорание, стагнация.

👉 Выделяйте слоты для бездны. Заблокируйте в календаре день, когда всерьёз проверяете большие решения — иначе прокрастинация растянется на недели.
👉Найдите buddy. Собеседник помогает прорваться сквозь круговые мысли и задаёт неудобные вопросы, пока вы не доберётесь до сути.
👉Формулируйте свою бездну явно. «Если бы я ушёл из компании сегодня, что бы делал?» Когда вопрос лежит на бумаге, сложнее его проигнорировать.
👉Не смотрите в бездну слишком часто, иначе ваша жизнь превратится в один сплошной экзистенциальный кризис.

Как читят на собесах с помощью сервиса Interview Coder

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

В статье – история развития сервиса Interview Coder, и его создателя, который разочаровался в многоступенчатых интервью в бигтехе и решил поменять правила игры.

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

Сервис платный, но есть уже и опенсорсные аналоги – и со временем их будет появляться все больше.

Короче говоря, добро пожаловать старые добрые походы на собеседования в офис, и попытки случайно не встретить там знакомых, чтобы не спалиться, что ты ищешь работу!

Как избежать атрофии навыков из-за AI

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

Признаки наличия проблемы:

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

Вот несколько практик, которые помогут не растерять знание проекта и домена при внедрении AI:

👉Все начинается с базовой гигиены. Вы всегда должны вчитываться в то, что генерирует AI. Особенно полезно выступать критиком, надевая на себя шапку того, кто пытается найти проблемы и уязвимости в коде.
👉Устраивайте AI-детокс и регулярно пишите какой-то код самостоятельно.
👉Встретившись с какой-то нетривиальной проблемой сначала попытайтесь решить ее сами, и только если ну вообще никак, используйте AI.
👉Команда должна знать и владеть всем кодом в проекте, не важно, написал ли его AI или человек.
👉Фиксируйте темы, за которыми чаще всего ходите за помощью к модели: повторяемость – сигнал закрыть пробел знаний.
👉Работайте с LLM в стиле парного программирования. Модель – пишет код, вы – направляете и рефакторите.

Кстати, если вы пропустили, в нашем канале с кейсами разбираемся, как быть с токсичным сотрудником, который в каждом действии команды и руководителя видит травлю.

Ну и ждем новых кейсов от вас на разбор, закидывайте в бота @TeamleadDoNotSleepBot!

Про радикальную прямоту

Radical Candor – очень хорошая книга для начинающих менеджеров. Я ее упоминал в своей мега-подборке книг, и, если вы ее еще не прочитали, то в статье по ссылке довольно хорошее саммари.

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

Стратегический технический советник

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

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

Frontend + Летний митап + Суббота = Я.Субботник по разработке интерфейсов 💛

7 июня в Москве Яндекс Go проводит Я.Субботник по разработке интерфейсов. В программе 4 доклада и воркшоп:

👉 Артемий Карпов расскажет, как команда выстраивает взаимодействие между разработкой и тестированием при написании автотестов и улучшении семантики приложения
👉 Миша Колосовский покажет, как сделать статические схемы интерактивными и причем тут SVG
👉 Давид Давыдов объяснит, что мы сделали с серверным API и как пришли к одной строчке кода вместо сотни
👉 Серёжа Алейников поделится опытом портирования нативного BDUI в вебе

На воркшопе участники в командах будут исправлять некорректные интерфейсы, стараясь учесть требования дизайнеров, бэкенд-разработчиков и тестировщиков. Вместе обсудим варианты решений, а коллеги из Яндекса помогут найти самое оптимальное.

Регистрируйтесь и зовите друзей!

Мероприятие бесплатное. Количество мест в офлайне ограничено — пожалуйста, дождитесь нашего подтверждения.

Реклама. ООО «Яндекс.Такси» ИНН 7704340310

AI код сразу же становится легаси

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

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

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

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

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

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

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

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

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

Был момент, когда я реально думал: “Ну не дано мне быть тимлидом”.
Команда есть, задачи есть, а ощущения уверенности — нет.
Каждый день — бесконечный чат, куча ручной координации, всё держится на мне, и никакой опоры.

Я пытался: внедрял процессы, проводил ретро, делал one-on-one, читал статьи.
А потом снова выгорал. Потому что не было системы. Потому что на каждом уровне роста я залипал — и не понимал, что происходит.

И только когда я увидел, что у управления есть этапы, что есть точки, где почти все проваливаются — стало легче.
Появилась карта. Появились ориентиры.
И главное — чёткий план действий!


Меня зовут Павел Чертков.
Я — руководитель разработки с 10-летним опытом, работаю с тимлидами, руководителями и теми, кто только начинает этот путь.

И 20 мая в 19:00(мск) я проведу открытый урок

«Эволюция руководителя: как преодолеть потолок в развитии и выйти на новый уровень».

Вы сейчас в похожей точке:
— тащите команду на себе,
— не чувствуете роста,
— устали от хаоса и микроконтроля —

Я приглашаю вас на открытый урок «Эволюция руководителя».

Будем разбирать,
— почему “быть идеальным” мешает расти,
— что блокирует ваш переход на новый уровень,
— и как выстроить систему управления, которая работает.

📌 Это открытый урок в преддверии большого курса «Тимлид 360».
👉 Вот ссылка на участие

Если чувствуете, что застряли — это не тупик. Это следующая ступень.
Пора двигаться дальше.


Реклама. Самозанятый Чертков, ИНН 420549309401, erid:2SDnjeEZAX7

КРОК запустил второй сезон онлайн-стримов про people-менеджмент для тимлидов и вообще всех, кто работает с людьми ⚡️

Вас ждет

📌 5 встреч в прямом эфире
🎙 Спикеры из КРОК, Яндекс, Ozon, HeadHunter, Dodo Engineering, K2 Cloud, Контур и red_mad_robot

Ведущий — Иван Пластун, директор по трансформации департамента инфраструктурных решений и сервисов КРОК.

Разберемся, что действительно помогает руководителю управлять командой, налаживать процессы и не терять себя в круговороте задач. Спойлер: это не про отсутствие ошибок и суперсилу «держать все под контролем» 😁

Старт 5 июня в 19:00. Зарегистрироваться и узнать про все выпуски можно по ссылке 🔗

Реклама ЗАО «КРОК Инкорпорейтед», ИНН 7701004101. Erid: 2W5zFHRbcFS

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

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

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

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

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

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

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

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

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

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