Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

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

Вебинар про то, как строить кросскомандную работу Меня попросили рассказать про вебинар, а у меня сразу активировались вьетнамские флешбеки. Чтобы добавить в язык программирования новую фичу, требуется взаимодействие десятка команд. Сначала продакт-менеджеры находят какую-то проблему пользователей, которую можно решить на уровне языка. Затем языковые дизайнеры прорабатывают пропозал того, как фича может выглядеть и работать. После этого начинается самое сложное – фича реализуется в компиляторе, который разюит на пять подсистем, за каждую из которых отвечает своя команда. А еще нужно поддержать фичу в IDE, написать документацию, записать маркетинговое видео… Ну, короче, идею вы поняли. Так вот, больше всего проблем появляется на стыке взаимодействия разных команд. Кто-то не так понял требования, у кого-то случился конфликт приоритетов, а кто-то просто продолбался. Мы пробовали разные подходы организации работы, и идеального, конечно, пока так и не нашли. Кросскомандное взаимодействие – боль практически любой компании. Универсального решения ее нет, но посмотреть на существующие инструменты и опыт других людей может быть полезно. Кажется, вебинар ребят из КСК как раз про это – они обещают как поразбирать известные боли, так и посоветовать инструменты, в том числе и свою платформу КСК Service & Teamwork. 📆30 мая, 11:00 по Москве 👉Регистрация

Как понять, приносит ли менеджер пользу 👉Не бывает эффективных руководителей в вакууме. Успешность менеджера зависит от команды, проекта и момента времени. Те качества, которые помогли ему привести к успеху один проект, могли бы привести к провалу другой. 👉Эффективность менеджера надо оценивать только вместе с эффективностью его команды. При этом важно выделять его личный вклад в эту эффективность. 👉Надо смотреть не на одну команду, но и на организацию в целом. Менеджер, который достигает успеха своей команды за счет других – такая себе история. 👉Эффективность работы менеджера нельзя объективно измерить, это вредная задача. Оценить ее получится только субъективно.

Большой тимлидский курс от Практикума Если я что-то и понял, смотря на поколения тимлидов, которые вырастали у меня на глазах, так это то, что лучший способ обучения тимлидству – это наличие опытного ментора, которому на тебя не наплевать. Если это еще и твой руководитель, так вообще идеально. Понятное дело, что в такой ситуации оказывается не каждый, и гораздо более частый паттерн – бросить вчерашнего разработчика в ледяную прорубь, поставив ему задачу вытащить оттуда тонущую команду. Без всякой поддержки, конечно же, потому что улицы научат. Ко мне пришли ребята из Практикума и рассказали про новый большой курс про управление командой разработки, который они запускают как раз для начинающих тимлидов. Что мне в нем нравится: 👉Наличие индивидуальных консультаций с ментором. Это все еще не погруженный в вашу работу человек со шкурой в игре, но тоже норм. 👉Теория дается асинхронно в интерактивном учебнике, а на воркшопах разбираются только кейсы. Со страшным сном вспоминаю занудное корпоратское обучение, когда тебе часами читают лекции про ситуационное лидерство. 👉Подборка тем. Курс получается довольно разносторонним, и это важно, ведь тимлиды – снежинки, и надо уметь заниматься сразу всем. В общем, посмотрите на курс тоже, выглядит клево. Если надумаете, то первый старт уже 25 мая. 🔗Регистрация

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

Вакансии в Трипстере Трипстер – это сервис экскурсий от локалов с довольно богатым выбором разных вариантов. Я довольно часто пользовался сервисом, поэтому порекомендовать вакансии ребят только рад! Еще фактов в копилочку. Трипстер – прибыльный сервис, и растет х2 год к году. MAU – 2,5 млн активных пользователей. 👀Вот кого они сейчас ищут: - Head of backend с упором на Python - Head of frontend со знанием Vue.js - Тимлида в одну из трех продуктовых вертикалей - Lead devops / SRE 💬Если стало интересно, то отправляйте своё резюме на [email protected] или напрямую @yamacarov.

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

Ошибки начинающих лидов и способы их преодолеть 😞Просадка уровня дофамина: в отличие от инженерной работы, ты не получаешь быстрого фидбэка о том, что ты молодец и делаешь что-то ценное. 💻Попытка совмещать менеджмент и программирование приводит к тому, что не получается успевать ни одно, ни другое. 👉Отсутствие контроля работы подчиненных из-за боязни скатиться в микроменеджмент. 🙈Прокрастинация сложных и неудобных вопросов в надежде на то, что все как-то само собой порешается. 📆Откладывать важные, но не срочные задачи в угоду ежедневной рутине и пожарам.

Почему автокомплит кода по выходным работает быстрее Я уже рассказывал, что я не совсем настоящий тимлид. Четыре года назад я сгорел от бюрократии и бессмысленности того, чем я занимаюсь, и стал продакт-менеджером. При этом мне всегда нравилось разрабатывать инструменты для других разработчиков, поэтому я стал продакт-менеджером языка программирования Kotlin. Так вот, месяц назад я сделал небольшой доклад про то, чем я занимаюсь. Получилось довольно бодро, оценки высокие, поэтому и с вами поделиться вроде бы не стыдно. Как бонус – если вы разрабатываете инструменты или API, который будет использоваться кем-то, кроме вас, доклад может подкинуть пару полезных идей.

⬆️ На курсе «Профессия Архитектор ПО» вы вырастете как разработчик и повысите свой доход. Разберёте реальные кейсы от ведущих разработчиков «Альфа-Банка» и сможете проектировать масштабируемые и отказоустойчивые приложения. За 4 месяца вы научитесь: ✅ применять архитектурные стили и паттерны проектирования — API Gateway, CQRS и «Сага»; ✅ выявлять и проверять нефункциональные требования и характеристики систем; ✅ строить распределённые системы на основе микросервисов и создавать cloud-native-приложения; ✅ принимать архитектурные решения исходя из контекста; ✅ учитывать вопросы кибербезопасности при проектировании. Навыки отточите на реальных задачах, а в конце курса презентуете итоговый проект. Спешите приобрести курс со скидкой! Майские скидки до 60% по промокоду «TechLead» по ссылке https://epic.st/_kQnL

Выбор новых технологий для компании Выбор нового фронтенд фреймворка, базы данных или языка программирования – всегда сложная задача. С одной стороны, люди, которые продвигают новую технологию, могут быть не всегда объективны и не думать о бизнесовой пользе, а с другой стороны – требования бизнеса со временем меняются, и технический стек должен им соответствовать. Несколько советов из статьи про то, как подходить к таким решениям: 👉Помнить о том, что стоимость поддержки технологии в долгосроке значительно перевешивает краткосрочные преимущества вроде ускорения решения какого-то типа задач. 👉Люди, топящие за новую технологию, чаще всего не объективны, да еще и могут не иметь достаточно опыта работы с ней. 👉Основной целью всегда должна быть поддержка бизнесовых результатов, а не использование интересных технологий ради искусства. В том, чтобы построить рабочие процессы, поддерживающие системное принятие решений, могут помочь: 👉Фреймворк принятия решений, который говорит, какие решения могут прмниматься командой, а какие должны подниматься на уровень всей компании 👉Внутренний технический радар, который определяет, что можно адоптить, а что – нельзя 👉Процесс RFC для оценки и обсуждения новых технологий 👉Architecture Decision Records, которые помогут не забывать причин принятия решений

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