Team Lead Talks Подкаст

Как принципы влияют на культуру компании

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

Тему инженерных принципов мы с Евгением уже затрагивали в одном из выпусков подкаста Team Lead Talks. Мы решили ее раскрыть на примере компаний AWS и Flo в отдельном выпуске.

https://youtu.be/iuuWsFqoZJg

Влиять, а не властвовать. CERN, стартапы, Bardeen AI. Артем Арутюнян | Team Lead Talks Ep.44

С Артемом Дима познакомился в компании Mesosphere. Где они оба работали над разными проектами. Артем запомнился как чуткий лидер, который тем не менее был готов принимать сложные решения.

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

https://youtu.be/SnaeufL0e90

Вывести человека из сеньорной команды, чтобы разблокировать рост

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

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

Я отправил туда парня и он там расцвел! Никто не сдерживает, никто не присматривает, никто не подхватывает. Расчитывать можно только на себя и он отлично справляется! Только позитивные отзывы и приглашение лидить более крупный проект в той же области.

Отправлял не с целью избавиться, а как раз чтобы у него наконец появилась возможность раскрыться.

Было?

43. Команда менеджеров — EM First Team. Евгений Сергеев, Eng Director, Flo

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

Мы обсудили множество важных тем: как происходил карьерный переход Евгения и формирование его команды, что такое EM First team, какие стратегии он использует для управления производительностью и мотивацией разработчиков, как создавать новые роли в компании и решать конфликты. Также затронули вопросы найма, важность разнообразия в менеджменте, инструменты для построения эффективных команд и создание инженерной стратегии.

https://youtu.be/DG2vxMAwbOU

Ссылки:
- Выступление Евгения на LeadDev https://leaddev.com/management/organizational-evolution-from-products-to-user-needs
- https://en.wikipedia.org/wiki/Wardley_map
- Книга Team Topologies https://teamtopologies.com/
- Блог компании Flo https://medium.com/flo-health
- Статья про он-бординг пользователей https://learnings.aleixmorgadas.dev/p/mobile-onboarding-evolution-at-flo
- Статья про менеджерство во Flo https://newsletter.manager.dev/p/being-an-engineering-manager-at-flo

Довольно заметного инженера уволили из Икса, он описывает, чем он занимался на позиции Staff. Коротко: чинил хайзенбаги и разбирался в заброшенных сервисах, когда те начинали чудить. По ссылке он детально описывает, что он починил.

На самом деле, как мне кажется, человека надо было выделить в отдельный юнит починки всей фигни и найти еще одного такого же, чтобы они как Леголас и Гимли друг перед другом по-приятельски конкурировали.

Такой сетап надо еще уметь продать наверх.

Максим @faang_career говорит, что парень сам виноват и на должности Стаффа нужно больше осведомленности и проактивности.

Что думаете?

https://x.com/yacineMTB/status/1936278079225127184

У меня есть пет проект на работе: наш бекофис. Написан на реакте, апи клиенты и типы все генерятся из openapi. Большинство апих уже есть, надо просто выносить их в UI. Такие вещи невозомжно приоритизировать, поэтому я делаю это в свободное время по 10-15 минут в день.

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

Теперь постоянно допиливаю нужные фичи и чиню мелкие занозные баги. В прошлую неделю написал письмо команде спорта со списком всего, что команда починила. Люди счастливые писали в личку. Благодарили.

Это предыстория.

Сегодня пишу команде бекенда: норм если мы разрешим этот заголовок на API GW, а то у меня CORS? Инженер отвечает, что вообще норм. И чуть позже: но чище если мы перенесем этот параметр в get params из header, пара строчек буквально.

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

Инженер пишет в личку:
— Дим, а чего ты так мое предложение поправить апи отмел?
— К сожалению, не могу потратить на это 3 инженеро-дня, так что желательно АПИ не трогать.
— Так я явно сказал, что там 3 строчки всего!
— Вот именно поэтому я говорю, что _всего_ 3 дня: поправить, поревьювить, протестировать, выкатить.

И тут инженер просветлел.

Мы очень медленно катим фичи. Просто умереть можно. Я все понимаю, с одной стороны: такие изменения не должны занимать больше полу часа. С другой стороны: ответственность, дежурство, секурити. Вокруг этого мы накрутили процессы, да и наш джава стек не особо заточен под скорость разработки. То есть все обоснованно, сами виноваты, но я не могу перестать этот статус кво шатать.

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

1. Сократить время на ревью можно через парное программирование. Т.е. само время программистов тратится столько же, но время на ожидание упраздняется. Сели вместе, дописали пару строчек, выкатили на стейдж, проверили, покатили в прод. Но тогда мне синхронно нужно отвлечь двоих.
2. Катить в прод через канари релизы. Когда новая версия кода получает чуть-чуть трафика, доля которого постепенно нарастает. Тут обратная сторона с откатом. Возможные баги прилетают назад спустя пару дней, когда вы уже возможно подзабыли контекст. Еще одна проблема, которую нужно решить - конкурентное тестирование нескольких изменений. Сколько версий кода может одновременно тестироваться? Какой для этого должен быть формат деплоя? Возможно функции? Сколько мы разрешаем тратить на это денег, ведь на каждую версию тратится какое-то количество ресурсов.
3. Менять стек. Если нужно поменять пару строк — это не проблема, но когда мы говорим про фичи побольше, то тут вылезает вся прелесть джавы: https://t.me/git_rebase/1088 Плюс желательно чтобы фреймворк для тестирования тоже был очень гибким.
4. Иметь отдельный флот апи для админки. Это снижает риск, но может дать ложную уверенность, что все быстро работает или работает вообще. Да и доп расходы опять же плюс отслеживание версий. Т.е. это почти как канари, но без публичного трафика.

Какие у вас есть идеи?

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

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

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

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

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

Побочным эффектом получилось: to do the other thing.

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

https://youtu.be/btd5On3EgQE?si=D7le_bls2ZI4XgAZ

42. Команда из джунов и культурные различия. Евгений Jesovile

👉 https://youtu.be/n-od0zxm8kA

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

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

Канал Евгения - https://t.me/jesovile_It_madness
Твиттер - https://x.com/EugeneJesovile
Трэк The Algorithm - userspace - https://youtu.be/UOn156pgC50?si=IcJ8Crox3UNM6XV9
Книга Нила Форда "Fundamentals of software architecture" - https://www.amazon.com/Fundamentals-Software-Architecture-Comprehensive-Characteristics/dp/1492043451

Я вам веселых менеджерских историй из икса принес. Хороших выходных!

https://x.com/12_18/status/1904946807970357384

Could - мог бы, посмотрим скоратит или нет.

41. ИИ не уничтожит ни человечество, ни менеджмент

https://youtu.be/-osu34Kiilo

Очень много говорят, что ИИ заменит программистов. Мы же хотели разобрать тему управления в пост ИИ мире. Для этого мы пригласили Славу Панкратова, сооснователя школы менеджмента Стратоплан. В свободное время Слава пишет фантастику, в том числе и про искусственный интеллект — идеальная комбинация для темы выпуска. В итоге мы поговорили про перспективы развития и регулирования ИИ и как это может отразиться на нашей работе.

Школа Стратоплан:
https://stratoplan-school.com/
https://t.me/StratoplanSchool

Процесс, где джуны перформят (перепост из Х Eugene Jesovile)

- Джуны - отличная проверка на уровень maturity процессов команды/стрима/компании
- Джуны перформят отлично, но только в хорошем "окружении"
- Джуны не компенсируют косяки refinement стадий задач

Как я делал такое окружение:

# Подготовка к таске
1. Business eval
- что мы делаем и нафига?
- ответ должен быть понятен каждому
2. Требования
- FR, NFR, user flow, use cases e.t.c
- должны быть расписаны полностью
3. Solution design
- диаграммы модулей, со связями и интерфейсами
- до кода
4. Тесты (e2e)

# Зачем это:
- если не знаем, что делаем и зачем, результат - помойка
- если решение не работает в диаграммах, оно в коде не заработает никогда
- имея эти артефакты, можно изи параллелить задачи по команде, и они потом сойдутся

Минусы:
- нужно время
- нужны скилы менеджмента

# Джуны
- джун не закроет косяки проработки (нечем)
- джуну нужен максимальный уровень детализации
- для джунских задач нужно мок-окружение

Таска для джуна:

"Сделай модуль такой-то. Интерфейс такой-то. Требования такие-то. Вот эти тесты должны проходить"

# Разделение

Задачи сеньоров/экспертов/архов:
- анализ (бизнес, требования, юзкейсы, консёрны/лимиты)
- солюшн-дизайн (диаграммы, связи, интерфейсы, модели данных)
- моки (ветки, стабы dependency-модулей)
- тесты

Задачи мидлов/джунов:
- написать код модуль за модулем

# Рост:
- в таком раскладе мы решаем разные задачи производственного процесса не одновременно
- можем плавно управлять ресурсами (добавить джуна/убрать сеньора)
- цена входа джуна в проект до "пользы" - почти 0
- рост через передачу части "экспертных" задач (контролируемо)

# Мой опыт
Вот некоторые результаты такого подхода в моих командах:

- фича с эстимейтом в полгода решена командой из 3 человек (senior + 2 junior) за месяц + месяц предварительных стадий
- рост джунов с 0 опыта до мидлов в среднем полгода (проверено рынком 2019-2022)

# Выводы:
- можно экономить деньги, нанимая джунов, но менеджерам надо постараться
- если "джуны не перформят", смотрите сначала в процессы и менеджмент
- если "ни один джун не перформит" или "разрабы пошли не те" - 90% что проблемы не уровня кода

# Итоговый поинт
Если вы менеджер:
- задайте вопрос сначала зеркалу, и только потом другим людям

- если найм/увольнение - единственный ваш инструмент, то точно ли не вы - источник проблем?

- делать свою работу хорошо всегда тяжело и больно. Но оно того стоит

=====

Мне пост показался интересным, особенно с точки зрения ограничений. Когда на сеньоров денег нет, но есть команда джунов и с ними надо работу работать. В 2025 это уже конечно больше выглядит как фреймворк работы с ИИ агентами. Делитесь своими подходами к работе с джунами в комментариях.

В командировке получилось понаблюдать за коллегами. Сегодня на очередном мозговом штурме я заметил, что коллега VP заметки и договоренности фиксирует прямо в повер поинте! И у него там роадмап собран, структура команд и тд.

Т.е. в любой момент времени у него готова презентация для показа или если нужно C-level по почте отправить.

Он заметил мое изумление и говорит: да мне надоело ее обновлять постоянно по запросу. Поэтому она у меня теперь готова всегда и я ее просто по ходу отправляю.

И я кое что понял про эффективность VP.

Как вы ведете подобные вещи? Все разбросано по разным тулам: джира, вики, заметки. Или все собрано в одном месте?