Тимлид или техлид

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

На самом деле, в здоровой команде тимлид (Engineering Manager) и техлид (Tech Lead) это две части одного целого. Типа инь-янь.

Го разбираться.

▫️Тимлид (Engineering Manager)

В фокусе - люди и процессы. Его задача создать среду, в которой инженеры могут максимально эффективно работать и расти, по сути отвечая на вопрос: «Как мы работаем?».

У него может быть много 1-1, встречи с HR по найму, встречи с продактами по планированию на квартал (год) вперед, либо например планирование спринта с командой. Также могут быть даже собесы на разные позиции, обсуждение бюджетов команды или Performance Review.

По таскам в том числе могут быть: найм, онбординг и увольнение, развитие и мотивация команды, решение «человеческих» проблем (выгорание, конфликты, низкая вовлеченность). Также устранение блокеров, выбивание ресурсов, взаимодействие с другими командами и коммуникация со стейкхолдерами.

▫️Техлид (Tech Lead)

Здесь в фокусе качество продукта. Его задача - обеспечить техническое совершенство, надежность и масштабируемость того, что делает команда. Он отвечает на вопрос: «Что и как мы делаем?».

Если у тимлида больше менеджерский работы, то у техлида среди встреч может быть: обсуждение архитектуры новой фичи с командой (System Design), сессия парного программирования с джуном, рассказ о последних иследованиях, которые могут пригодиться для проекта. Также может быть встреча с оптимизацией бэклога/техдолга, обсуждение проекта, выступление на внутреннем митапе, и даже забитые слоты под 2-3 часа написания кода (Deep Work).

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

▫️Власть

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

▫️Скиллы

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

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

▫️Итого

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

Го огонечки за техлида, сердечки за тимлида

#softskills #career

Сидишь на работе в воскресенье, никого не трогаешь, и тут внезапно один из коллег выгорел 🤯

#meme

🦠 Поговорим про роль пет-проектов в вашем резюме

Привет, это Александр Исаков, руководитель группы прогноза в Яндекс Лавке. Я считаю, что в резюме кандидата должны быть личные проекты: иногда они показывают ваши навыки и умения даже лучше, чем рабочие задачи.

Смело кидайте ссылочку на репозиторий потенциальному работодателю! А если подходящих пет-проектов у вас пока нет, вот несколько занятных идей:

🈂️ Классификация медицинских статей по рубрикам

Данные: PubMed MultiLabel Text Classification Dataset MeSH
Бейзлайн: логистическая регрессия

Что делаем:

🔵 Грузим и готовим данные, ищем пропущенные значения и по возможности обрабатываем. Можно провести нормализацию текста
🔵 На основе текстовых описаний генерируем исходные численные параметры текста. Например, можно посчитать TF-IDF
🔵 Генерируем признаки на основе полученных начальных
🔵 Отбираем признаки, оставляем место только для самых важных
🔵 Разбиваем данные на train / OOS (out-of-sample) / OOT (out-of-time)
🔵 Обучаем базовую модельку логистической регрессии. Как это реализовать, показано вот тут

Как улучшить:

🔵 Использовать деревянные модели: Random Forest Regressor или любой бустинг, имя которого нам нравится
🔵 Копнуть чуть глубже и протестировать, например, нейросети для работы с последовательностями или архитектуры на основе трансформеров. Например, как тут

💎 Скилы, которые можно прокачать: работа с текстовыми данными, Feature Engineering, работа с табличными данными и NLP.

🈂️ Рекомендательная система для фильмов

Данные: MovieLens Dataset

Бейзлайн: матричные разложения (Matrix Factorization). Пример кода есть вот тут

Что делаем:

🔵 Классически собираем данные без обработки
🔵 На их основе строим user-item matrix. Дальше можно обработать данные — допустим, сделать взвешенный рейтинг по числу просмотров
🔵 По возможности засовываем туда SVD (singular value decomposition)

Как улучшить:

🔵 Перейти от матричных разложений к контентным рекомендациям. Например, подгрузить к каждому фильму описание. Или взять другую выборку с информацией об айтемах — например, датасет от Яндекса Yambda-5B (статья тут)
🔵 Взять весь скоуп рекомендательных моделей, про которые слышали, сделать фит-предикт и искать корнер-кейсы для улучшения

💎 Скилы, которые можно прокачать: рекомендательные системы, матричное
разложение, нейросетевые методы работы с рекомендациями.

🈂️ Распознавание объектов на изображениях

Данные: CIFAR-10 Dataset (или любой другой с кагглов)
Бейзлайн: любая (желательно самописная) CNN-сеточка

Что делаем:

🔵 Загружаем и нормализуем изображения
🔵 Строим базовый CNN с несколькими свёрточными и pooling-слоями. Более продвинутые модели можно поискать тут
🔵 Разбиваем данные на тренировку и валидацию
🔵 Обучаем модели с использованием нужного нам лосса, например Cross Entropy Loss

Как улучшить:

🔵 Используйте более сложные модели типа ResNet EfficientNet. И накидайте побольше эпох!
🔵 Применяйте Transfer Learning с использованием предобученных моделей. Или вообще попробуйте применить CLIP

💎 Скилы, которые можно прокачать: обработка изображений, свёрточные нейронные сети, Transfer Learning.

⏬ А если вам нужны ещё идеи — смотрите мой пост с пет-проектами в геоаналитике со спутниковыми снимками. Удачи!

Подписывайтесь:
💬 @Yandex4Analytics

От синьора до тимлида

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

Основная боль синьора, готового к росту - ограниченность масштаба. Мы можем в одиночку написать крутанский MVP, пересобрать полностью проект и даже перебрать архитектуру. Знаем, как с нуля построить например систему прогнозов, но в одиночку построить сложный продукт займет очень много времени и нас просто обгонят как стоячих. При этом внтури компании замедляется рост как специалиста, потому что вы уже столкнулись с 90% типовых проблем.

Что дальше

Переход от роли супер-исполнителя к роли "force multiplier". Это как раз та самая развилка, на которой нам нужно выбрать один из двух путей: Техлид или Тимлид. Чуть более подробно разницу между этими ролями я описал тут.

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

Быстро вспомним базу: техлид масштабирует свое влияния через технологии, а тимлид масштабирует свое влияние через людей. По сути для синьора это два разных ответа на одну и ту же боль: "Как сделать так, чтобы мой опыт и знания приносили в 10-100-1000 раз больше пользы?"

Давайте определимся, куда расти

Я бы предложил здесь задать себе честные вопросы. Что приносит нам больше удовольствия: найти топовое архитектурное решение или помочь коллеге разобраться с проблемой, чтобы он начал перформить лучше? Бесконечные встречи (со всеми подряд) или день, потраченный на разбор кода (который скорее всего супер-древнее легаси)?

Тест с баллами наверно можно не проводить, из ответов очевидны предпочтения.

Напомню только, что для техлида важна техническая оптимальность продукта, ответственность за архитектуру, выбор технологий, качество кода, снижение техдолга. Короче, чел - главный технический/технологический авторитет. Техлид далее может дорасти до Staff/Principal Engineer -> Главный архитектор -> CTO.

Для тимлида важна максимальная производительность и счастье команды, ответственность за достижение бизнес-целей, а также рост и развитие коллег. Доасти можно до Engineering Manager -> Head of Development -> VP of Engineering -> CTO / CEO. Это классический менеджерский трек.

Проактивность

Определились с путем? Отлично. Теперь нужно перестать ждать, пока нам что-то предложат.

Наш менеджер не умеет читать мысли. Если мы не заявим о своих амбициях руководителю, для него мы - просто надежный синьор. Можно прийти и сказать "Я хочу быть тимлидом, дайте должность", а можно: "Я думаю о своем развитии. Мне интересно попробовать себя в роли техлида/тимлида. Какие навыки мне нужно подтянуть? Могу ли я взять на себя часть твоих задач, чтобы набраться опыта?". Я за первый вариант

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

Легко не будет

▫️Наша задача — сделать так, чтобы другие делали хорошо. Придется смириться, что иногда они сделают не так, как мы. Делегирование — это больно, но необходимо
▫️Мы внезапно поймем, что давать обратную связь и составить план развития не так то просто. Это нормально. Пора читать книги (опытные менеджеры, кидайте в коменты какие стоит), посещать курсы и главное - найти себе ментора
▫️Наш успех больше не измеряется количеством написанного кода. Он измеряется успехом нашей команды

Начните с главного: просто поймите, что вас драйвит, и поговорите об этом со своим руководителем

Путь в тысячу миль начинается с одного разговора

#career #softskills