Рефлексия тимлида

Онбординг человека и AI-агента подозрительно похож Чем больше я работаю с AI-агентами, тем сильнее их проблемы напоминают мне онбординг нового разработчика. Писать код агент умеет. Сложности начинаются, когда нужно понять, как запустить проект, почему здесь сделано именно так и какие договорённости приняты в команде. С человеком у нас для этого давно есть универсальное решение — другие люди: — Спроси Петю. — Тут есть нюанс, я расскажу. — Это нигде не написано, но мы так не делаем. С агентом такой подход не работает. И сразу становится видно, сколько знаний о системе хранится не в документации или коде, а в головах команды. GitHub в статье Onboarding your AI peer programmer прямо сравнивает настройку Copilot coding agent с онбордингом нового разработчика. OpenAI в материале Harness engineering пишут, что информация, которую агент не может найти во время работы, для него фактически не существует. Если что-то обсудили в чате или на созвоне и нигде не зафиксировали, агент об этом не узнает. Например, команда обсудила архитектурное решение в Mattermost или Telegram и пошла дальше. Через несколько месяцев о нём не будет знать ни агент, ни новый разработчик, который придёт в проект. Поэтому OpenAI начали хранить в репозитории не только код, но и знания о системе: описание архитектуры, принятые решения, планы, правила и технический долг. При этом сама проблема далеко не новая. Ещё в исследовании IBM Moving into a New Software Project Landscape отмечалось, насколько важно новичку разобраться в структуре проекта и иметь возможность проверить, правильно ли он её понял. Дайте новому человеку — или агенту — репозиторий и посмотрите, сможет ли он без Пети понять: — как запустить проект; — как прогнать тесты; — где искать нужный код; — какие договорённости приняты в команде. AI может оказаться неплохим тестом на качество инженерной среды. Если для этого всё-таки нужен Петя, значит, важный контекст остался за пределами репозитория. Слишком большая часть знаний о системе всё ещё живёт в головах старожилов. И у подготовки проекта к работе с AI есть хороший побочный эффект: следующему человеку тоже будет проще в него войти.

Наверное, все уже видели недавнее заявление Сбера о том, что они планируют сократить 20% «неэффективных сотрудников». Но говорить хочу не о Сбере. Меня куда больше интересует сам термин — а как вообще понять и померить эффективность сотрудника? Мы любим мерить всё цифрами: KPI, закрытые задачи, скорость. Но я уверен, эффективность — это НЕ только про количество тикетов в таск-трекере.

Про отдых В какой-то момент понял, что отдых — это не награда за работу. Это часть работы. Когда даёшь себе время выдохнуть, не потому что «устал», а потому что хочешь сохранить ясность. Паузы — это не слабость. Это способ не потерять себя в процессе. Пошел думать , что делать с моими 40+ днями не отгулянного отпуска.

О радости писать код В последнее время мы в команде много работаем с AI — LLM, RAG, MCP, агенты и всё вокруг этого. Ничего «великого», просто прикладные, продуктовые штуки. Но мысль не об этом. Спустя время я снова сам пишу код. Прототипы, PoC, эксперименты. И какое же это классное чувство! Когда не получается — ищешь, разбираешься, учишься. Когда находит решение — всё оживает. Когда видишь, как оно работает — хочется улучшать, допиливать, пробовать дальше. Поймал себя на мысли: я не ошибся, выбрав эту профессию. Столько лет прошло, а писать код всё ещё чертовски приятно.

Засела в голове фраза: От личности руководителя зависит больше, чем от его менеджерских навыков. И я до сих пор не могу понять — согласен я с этим или нет. С одной стороны — хочется сказать, что на 100% да. Мне действительно важно понимать, кто мой руководитель: какие у него взгляды, чего он хочет, что может. Мне нужно совпасть с ним по ценностям, чтобы нормально работать и развиваться. Но с другой — достаточно ли просто быть хорошим человеком? Можно ведь говорить правильно, вдохновлять… и при этом не уметь управлять: устраивать микроменеджмент и орать на команду. И вот я думаю: личность решает? Или всё-таки скиллы тоже важны? А может, одно без другого просто не работает?.. Как вы считаете? Что для вас важнее в руководителе?

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

Как выбирают CTO? Разбираем в прямом эфире. Подкаст «Бреслав и Ложечкин» вместе с Подлодкой, Яндексом и South HUB приглашает заглянуть за кулисы собеседования на топ-уровне. Мы проведём Mock interview — формат, который помогает кандидатам понять, что действительно важно при устройстве в крупную компанию. В этот раз зрители cмогут не только наблюдать за ходом собеседования, но и разбирать его вместе с экспертами. Мы обсудим, какие вопросы задают CTO и что от него хотят услышать в ответ, какие моменты делают кандидата сильнее, а где он теряет позиции. А после — вместе с экспертом по Executive Search разберём интервью и покажем, как можно было ответить иначе. Встреча будет полезна, если вы: — CTO и хотите понять, что ждут от вас в бизнесе; — CEO и задумываетесь, как находить сотрудников на технические роли; — планируете расти в IT и мечтаете о позиции C-level. 🎙 В эфире: Андрей Бреслав — кандидат на роль CTO Александр Ложечкин — CIO, интервьюер Тамара Амбарцумян (Яндекс) — модератор и эксперт по Executive Search 📅 4 марта, 14:30-15:30 по Московскому времени 📍 Прямой эфир в Telegram-канале South HUB

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

Иногда люди уходят из команды — это естественный процесс. Порой бывает очень жаль терять опытного сотрудника, но в такие моменты важно посмотреть на ситуацию с другой стороны. Подумать о том, как много этот человек успел сделать для команды, насколько она стала «взрослее» и профессиональнее благодаря ему. Вспомнить всё то, что вы успели дать друг другу. Если человек смог вырасти в вашей команде и стать более профессиональным, это и ваша заслуга тоже. Но если вы не можете предложить ему интересные задачи или конкурентоспособную зарплату, лучшее, что можно сделать для него и для компании — помочь перейти в другую команду. Это будет проявлением уважения к его развитию и карьере. Такой подход позволит сохранить хорошие отношения и продолжить сотрудничество в будущем, возможно, на новом уровне. А компании сохранить ценного сотрудника.

Как заставить другого стать более ответственным? Никак. Ответственность невозможно дать. Её можно только взять. С "лидерством" такая же история: • Создание лидеров начинается с поиска людей, которые хотят стать лидерами и готовы к ответственности. • Лидерство не может быть передано, его нужно взять самостоятельно. • Ответственность должна быть осознанной и добровольной, а не навязанной. Поэтому к назначению фича-лидеров, о которых я писал в посте выше, нужно подходить с осторожностью. Если человек не хочет "драйвить" эту активность, лучше обойтись без лидера вовсе, чем кого-то просто назначить. Иначе вы потратите ещё больше своих ресурсов и времени, и сроки точно сдвинутся. Важно понимать, что каждый член команды имеет право на свою зону ответственности и уровень вовлечённости. Навязывание лидерства или чрезмерной ответственности может привести к демотивации и снижению эффективности Вместо этого стоит поощрять тех, кто проявляет инициативу и готов брать на себя ответственность добровольно. Это поможет создать более здоровую атмосферу в коллективе и повысить общую продуктивность.

"Рабочие группы" У меня на работе команда, которая поделена на 2 полноценные кроссфункциональные фича-тимы. И было два момента, которые меня волновали. 1. В командах начали накапливаться уникальные знания. Это было осознанным решением в отношении «бизнес» задач, но в технических задачах я этого не хотел. Однако это начало происходить. 2. На ретроспективах стали появляться стикеры о том, что коммуникация между командами ухудшается. Конечно, у нас есть общий технический долг и большие «технические эпики» — задачи, которые делают нашу систему лучше и соответствуют общему вектору развития внутри банка. Эти задачи невозможно выполнить за один спринт. Примеры таких задач: переезд в новый кубер-кластер, обновление всех микросервисов на Spring Boot 3, переход на общий keycloak и т. д. Можно было бы просто поручить такую задачу одной из фича-тим, которая лучше знает эту область. Это быстрое решение в моменте, которое позволяет быстро закрыть задачу, но способствует дальнейшему росту экспертизы только в этой команде. Поэтому для таких задач я практикую создание динамических рабочих групп — «мини-команд» из 2-4 человек из разных фича-тим. Зачем? - дополнительная точка синхронизации между фича-тимами; - обмен знаниями между командами и людьми; - общее участие всей команды в развитии нашей системы; - поддержание политики коллективной ответственности за код (collective code ownership policy) В каждой такой группе мы назначаем «фича-лидера». Это помогает развивать софт-скилы и лидерские качества у сотрудника. А мне это помогает меньше погружаться в детали, но при этом понимать статус активности.

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

Привет. Я решил создать этот канал весной, но примерно в то же время забросил его. Собирался написать интересный и полезный пост, но меня одолевали мысли: «Это никому не интересно», «Это и так очевидно», «Какая-то ерунда». Так прошёл почти год, и я практически забыл об этом канале. Один мой знакомый напомнил мне о нём. А другой знакомый напомнил, что главное здесь — мои мысли для самого себя. Чтобы эти мысли не терялись, и я мог к ним вернуться и по-рефлексировать.

Рефлексия тимлида pinned «Привет! Меня зовут Вдовин Дима, и я работаю Engineering Manager в Райффайзен Банке. За свою карьеру я много лет посвятил разработке и программированию (14 лет), но теперь я открываю для себя новый и увлекательный мир управления и создания команд. Для чего…»

📺 #посмотреть Я тимлид, и у меня ломка. Что делать? / Антон Огородников (Магнит) - "Ломка" - это чувство, когда менеджер начинает отставать от индустрии и хочет вернуться к инженерным задачам - Антон считает, что причина это в том, что отсутствуют артефакты работы менеджера. - В докладе есть несколько советов, как с этим справляться - Предлагается научиться получать удовольствие от своей работы и научиться получать удовольствие от управления командой. - Визуализация эффекта работы тимлита может помочь ему увидеть, насколько эффективна его команда. - Играющий тренер может работать в команде до 5 человек, но в больших командах он становится просто хорошим тим-лидом.

Привет! Меня зовут Вдовин Дима, и я работаю Engineering Manager в Райффайзен Банке. За свою карьеру я много лет посвятил разработке и программированию (14 лет), но теперь я открываю для себя новый и увлекательный мир управления и создания команд. Для чего мне этот канал? 1. Записывать свои мысли и решения, связанные с управлением и развитием команд. Это поможет мне анализировать свой опыт и учиться на своих ошибках. 2. Спустя время возвращаться к своим записям и анализировать, как бы я поступил в той или иной ситуации сейчас, изменились ли мои мысли и развиваюсь ли я как менеджер. 3. Публиковать полезные материалы для обучения и развития. Буду рад, если этот канал станет бедет полезным и для других. 🙌

Channel name was changed to «Рефлексия тимлида»

Channel photo updated

Channel created