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

1️⃣S – Situation
Контекст истории. Почему решаемая задача была важной, почему за ее решение взялись именно вы, какие дополнительные внешние факторы играли роль.

2️⃣T – Task
В чем именно состояла ваша задача. Максимально конкретное описание.

3️⃣A – Actions
Что конкретно вы сделали для того, чтобы задача решилась. Здесь важно отделять свой вклад от остальной команды, и показать связь предпринятых действий с задачей.

4️⃣R – Results
Какие результаты получились после выполнения задачи. Как вы поняли, что все стало хорошо.

Дополнительно рассказ можно усилить, ответив еще на пару вопросов:
*️⃣Что можно было сделать лучше?
*️⃣Как можно было бы достигнуть таких же результатов с вдвое меньшим бюджетом?

🔗Дополнительные ссылки
Пример ответа по STAR от Uber SRE
Пример ответа по STAR от Stripe Engineer
Твиттер-тред по теме

Только что начался офигенный открытый собес. Андрей Бреслав проводит софтскилловую секцию собеседования на техлида. Подключайтесь!

Stack Overflow подбили итоги своего ежегодного большого исследования разработчиков. Для тимлида такие отчеты полезны по следующим причинам:
📖Можно увидеть изменение трендов по тому, как люди входят в IT и учат новые технологии, и адаптировать под них свою воронку найма
🧐Технологии постоянно устаревают. Это не должно быть немедленным поводом для смены технического стека, но одним из факторов, влияющих на тот же найм, вполне может быть.
⏰Понимание того, из каких активностей состоит рабочий день разработчика может вырвать вас из радужных представлений о том, что код пишется 4-8 часов в день, и приземлить на суровую реальность.

Чаще всего тимлидом становятся по следующей схеме:
1️⃣Сидишь, пишешь код, никого не трогаешь
2️⃣Тебя хлопает по плечу руководитель, и говорит, что ты теперь тимлид
3️⃣Тимлидишь

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

Яндекс Практикум запускает большой курс «Как управлять командой. Курс для руководителей» на целых четыре месяца. Ребята обещают научить расставлять прилритеты, оптимизировать процессы и системно развивать команду. Курс расчитан на тех, кто уже стал руководителем и работает с командой с постоянным составом.

Старт обучения: 21 июля. Если вы узнали себя, посмотрите – такой курс может вам помочь!

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

#люди #инструменты

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

Поняв, что такая схема не работает, Интерком создали отдельную виртуальную команду дежурств, состоящую целиком из добровольцев. Эта команда стала отвечать за слежение за всеми алертами и постепенное улучшение системы. Количество единовременно дежурящих сократилось с 30 до 6 человек, и количество инцидентов тоже постепенно снизилось.

#процессы #техлидство

Большой гайд от GitLab про то, как управлять командой в условиях удаленной работы. Как и все остальные материалы из их плейбука – хорошо проработан и основывается на куче примеров из их же опыта. Несколько мыслей, которые мне понравились:
📌Многие руководители неосознанно начинают микроменеджерить, когда не могут видеть свою команду глазами. То, что вам может казаться здоровой синхронизацией, для вашего сотрудника может быть жестким микроменеджментом.
📌Нужно стараться как можно большее число процессов переводить в асинхронный режим. Это помогает получить максимум пользы от ремоута, когда каждый может работать в своем удобном режиме и часовом поясе.
📌Сохраненная в письменном виде информация становится еще более ценной. Документируйте больше своих решений, ожиданий от сотрудника и фидбэка. Это даст людям возможность потреблять информацию в своем темпе.

#процессы

Начинающие тимлиды сталкиваются с разными задачами: первое совещание, распределение нагрузки, контроль за соблюдением дедлайнов. Хочется правильно выстроить процессы и сохранить доверие команды — не превратиться из руководителя-коллеги в грозного начальника.

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

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

7,5 часов вебинаров, где можно отработать навыки, и бессрочный доступ к интерактивному учебнику с теорией. Интенсив длится девять дней и стоит 15 000 ₽.
Новый поток стартует 18 августа. Записаться →

Когда инженерная команда Uber выросла до 100 человек, было принято решение разбить ее на две большие части:
🪄Program – команды, которые делают продукт для конечных пользователей
🪠Platform – команды, которые разрабатывают инфраструктуру и продукты для внутренних потребителей

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

#управление_компанией

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

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

#процессы

Руководители команд, 26 июля в 18:30 встречаемся в московском офисе Авито на первом TeamLead meetup!

Спикеры и темы 🔥

👉🏻 Чего ждут коллеги разных уровней от тимлида?
Работа тимлида не ограничивается собственной командой. Надо контактировать с другими командами, начальством, продактом, и у каждого есть свои ожидания. Евгений Рейх, руководитель кластера Goods Classified, подробно разберёт их.

👉🏻 Как осознать себя в роли руководителя тимлидов?
Если вы хорошо научились управлять разработчиками, это ещё не значит, что будет просто координировать тимлидов. Сергей Баранов, который недавно возглавил юнит Тарифы и не понаслышке знает об этом, поделится своим опытом смены образа мышления, ошибками и источниками силы.

А ещё после каждого выступления ребята проведут открытые дискуссии с коллегами из СберЗдоровья, Тинькофф, Skyeng и Ozon.
Регистрируйтесь: clc.to/Te3ETg.

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

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

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

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

#люди #процессы

У меня тут интересный кейс про развитие EdTech в России. В сентябре 2022 года ребята из iSpring открывают полноценный институт в Йошкар-Оле. Первый бакалавриат запускается по 4 специальностям: программирование, продакт-менеджмент, маркетинг и дизайн продукта. Почему это крутая новость – институт работает в тесной связке с различными IT компаниями, и стажировки студентов на реальных проектах начинаются фактически с первого дня, а со второго курса каждый уже работает парт-тайм. Я очень верю в то, что тесная связь между образовательными учреждениями и бизнесом дает более прикладные знания и позволяет студентам уже в процессе обучения прицельно выстраивать свою карьеру. Разрывается порочный круг джунов, которые получают отказы на собеседованиях, потому что на момент поиска работы у них нет опыта.

Из интересных фактов:
📌Результаты ЕГЭ не главное, в институте iSpring разработали собственную систему набора с фокусом на мотивацию, внимание и когнитивные способности
📌В преподаватели набирают только практиков
📌В первом наборе – всего 120 мест, на 82 из которых предусмотрены гранты
📌Новый кампус института больше похож на офис IT-компании, чем на учебные аудитории

В общем, отличный шанс залететь в IT и уже на 1 курсе стать участником большого продакшн проекта! Все подробности – на сайте института iSpring.

За последние годы во все большем количестве компаний появляются расширенные инженерные карьерные пути. Часто их обозначают как Staff+. Но одним только введением новых карьерных уровней не обойтись. Staff+ роли требуют соответствующего уровня задач, инженерной и менеджерской культуры. Автор статьи проинтервьюировал кучу staff+ разработчиков из больших и маленьких компаний и сделал подборку самых частовстречающихся дисфункций. Вот некоторые из них:
📌Под красивыми лозунгами про автономность в выборе целей и соедств их достижения staff+ инженеров на самом деле скрывается отсутствие поддержки от менеджеров и понимания с их стороны того, что нужно делать
📌Staff+ инженерам предлагается управлять другими за счет авторитета, в то время как вся корпоративная культура ориентирована на управление за счет административных полномочий
📌Менеджмент требует тратить на написание кода все время, не учитывая другие активности
📌Staff+ инженерам ставятся большие амбициозные цели, но менеджмент не пытается помочь в их достижении за счет работы со стратегией и оргструктурой, в результате ничего не получается

#люди #найм #управление_компанией

Несколько важных законов, понимание которых сильно облегчает работу тимлида:
1️⃣Закон тривиальности Паркинсона: «Люди в обсуждениях уделяют гораздо больше времени банальным или косметическим вопросам, нежели серьезным и существенным»
2️⃣Закон Брукса: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»
3️⃣Закон Иглсона: «Любой ваш код, который вы не видели шесть или более месяцев, выглядит так, будто написал его кто-то другой»
4️⃣Закон кибернетической энтомологии: «Всегда есть еще один баг»

#инструменты #развитие_себя

Еще один подход к описанию всех функций, из которых состоит роль менеджера.

Если вы задумываетесь о поиске работы тимлидом в Европе, обязательно посмотрите серию видео с недавней конференции Team DrivenCon:
📝Публичное собеседование с интервьером из Meta
📝Публичное собеседование с интервьюером из LinkedIn
👨‍👩‍👧‍👦Групповое ревью резюме инжиниринг менеджеров и советы по их улучшению
💰Обзор зарплат тимлидов и механизмов компенсации в разных странах Европы

Как в Flo переработали процесс найма

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

В итоге, основные изменения, которые внедрила команда, получились такими:
📝Использовать единый пайплайн для схожих позиций
📝За каждый пайплайн отвечает группа менеджеров
📝Этапы пайплайна визуализируются
📝Слоты на интервью бронируются в календарях заранее и не меняются
📝Все интервью ведутся в парах
📝Составляется список людей, отвечающих за bar rising, и они включаются в процесс

Все изменения команда завернула в эксперимент, который в результате привел к уменьшению среднему времени закрытия вакансий с 70 до 30 дней.

Я рекомендую статью для всех, кто недоволен своим процессом найма, как пример системного подхода к изменениям.

#найм

Разгружаем команду разработки от любых внешних коммуникаций с помощью дежурных

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

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

#процессы