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

Вообще, обучение тимлидов – сложная штука. Одной теорией все запросы закрыть не получится – ведь полученные знания надо как-то применять и отрабатывать. Практику наработать тоже сложно – не у всех сходу есть готовая команда и проект, на которых можно учиться. Нам со Стасом всегда очень нравился Go Practice – симулятор работы продакт-менеджеров. Симулятор удерживает крутой баланс между прикладными знаниями, авторским опытом и проверкой изученного материала на живых заданиях и кейсах. И все это доступно для прохождения в асинхронном режиме в удобном именно для тебя темпе.

Мы решили попробовать перенести эту модель на обучение тимлидов, и несколько месяцев назад начали разрабатывать Симулятор Тимлида – большой интерактивный курс, который обучает и дает попробовать на практике самые важные инструменты и практики для менеджера, управляющего командами разработки. Чтобы разработать Симулятор, нам нужно подготовить огромную гору контента – и мы понимаем, что этот проект может спокойно занять год-полтора. Ждать столько времени, чтобы получить первичную обратную связь о том, насколько сам формат обучения и контент полезны – с продуктовой точки зрения самоубийство. Поэтому мы решили начать собирать фидбэк как можно раньше, и открыть программу раннего доступа к Симулятору. Что у нас уже есть – MVP версия обучающей платформы, одна очень большая глава про управление встречами и календарем, и еще две близкие к релизу главы – одна про обучение сотрудников, другая – про подбор людей в команду.

Мы видим ранний доступ как очень маленький, не больше 20 участников, закрытый клуб из тимлидов, которые готовы активно участвовать в разработке проекта – проходить новые главы, давать много обратной связи, делиться своими рабочими кейсами и проблемами, помогать нам шлифовать все предлагаемые модели. Мы хотим собрать маленькое, но очень живое коммьюнити, которое будет прокачиваться в профессии паралелльно с тем, как мы пишем Симулятор. По опыту работы с другими сообществами я знаю, что такие закрытые тусовки работают гораздо лучше, когда за доступ в них есть небольшой донат. Пока мы не знаем, сколько будет стоить доступ к итоговому курсу – поэтому ежемесячный донат за доступ к ранней версии выбрали практически наугад, 300 рублей.

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

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

👉Форма регистрации

Принципы здорового алертинга и on-call процесса

Почти во всех компаниях процесс on-call дежурств – боль, страдание и частая причина увольнений. В презентации СТО Honeycomb предлагает следующие шаги по исправлению ситуации:
🌡Выключить алерты на симптомы, заменить их алертами на SLO, которые привязаны непосредственно к болям пользователей.
🤔Удалить все флакующие алерты, потому что моральное состояние людей важнее.
🚨Почти все алерты должны падать во второстепенную очередь, на которую не требуется мгновенная реакция дежурного. Вместо этого, очередь можно разбирать с началом рабочего дня.
📝Каждый алерт должен идти со ссылкой на подробную документацию о том, что его может вызвать.
👀Инвестируйте в observability своего кода и сервисов, профилируйте максимально часто и ловите баги до того, как они отстрелят у пользователей
📈Используйте SLO для того, чтобы приоритизировать работы по техническим улучшениям

#техлидство

Подборка инструментов, помогающих думать

Сайт с каталогом инструментов и фреймворков, которые помогают улучшить коммуникацию, прокачать системное мышление и принятие решений. Среди них – Пирамида Минто, Six Thinking Hats, Decision Matrix.

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

✍️Менеджерские практики
Большой гайд по менеджменту remote команды
Надо ли включать камеры на созвонах
Выпуск Подлодки про то, что оценки не нужны
Подборка шаблонов RFC и PRD

👀Поиск работы тимлидом
Коллекция видео Team DrivenCon про поиск работы тимлидом в Европе
Как подготовиться к собеседованию на Engineering Director
Публичное собеседование тимлида

💬Коммуникации
Как научить не бояться просить о помощи
Рассказываем о своем опыте, используя метод STAR
Системный разбор рабочих конфликтов
Как связаны выгорание и рабочие конфликты

👨‍👨‍👦‍👦Найм и рост
Почему карьерная линейка Staff инженеров часто не работает

🐣Подписывайтесь на мой Твиттер – там я пишу немного смешные шутки про айти, полезные тимлидские треды и рассказы про то, как мы деляем язык программирования.

Если дайджест вам понравился – ставьте ❤️, 👍 и 🔥. Благодаря этому я пойму, что собирал его не зря! А если у вас будут конкретные предложения по его улучшению – смело пишите в комментарии!

#digest

Как общаться с топ-менеджерами

- Лучший способ подготовиться – изложить свои мысли в документе, это само по себе заставляет подходить к проблеме структурно.
- Попробуйте фреймворк SCQA: Situation – Complication – Question – Answer.
- Поговорите с теми, кто уже показывал что-то этому топ-менеджеру. Это поможет узнать дополнительные советы, которые помогут правильно подойти к разговору.
- Не стоит спорить с обратной связью. Лучше сделать это позже.
- Не избегайте ответственности и проговаривания проблем.
- Не приходите без готового ответа.

Путь из СТО в инженеры

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

- Готовьтесь к тому, что технические скиллы вы потеряли – они забываются гораздо быстрее, чем менеджерские.
- Проблема не столько в потерянном умении писать код, сколько в том, что вы разучились фокусироваться на одной задаче, и привыкли работать с постоянной сменой контекста.
- Лучше всего начать с нового технического стека, а не с того, экспертиза в котором у вас была раньше.
- Желательно найти проект, в котором ваш код действительно влияет на пользователей, так будет проще вспомнить забытое удовольствие.
- Избегайте вакансий архитекторов, иначе рискуете быть все так же далеко от кода.

Должен ли менеджер быть щитом от дерьма для команды

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

Как давать полезный фидбэк

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

Как сделать так, чтобы сотрудники приходили к тебе с решениями, а не проблемами?

Кажется, что так бывает только в раю, но эффективный менеджмент и честное взаимодействие с коллегами ещё и не на такое способны!
Вот несколько шагов, которые помогут взрастить уровень ответственности подчинённых.
👇🏻
Держитесь позиции взрослого
Не берёте ли вы на себя роль “родителя”, когда сотрудники обращаются к вам с позиции детей и приглашают взять на себя функции спасения? Есть вероятность, что у команды гораздо больше компетенций для решения проблем.
👇🏻
Сверяйте степень директивности
Не душите контролем тех, кто уже показывает высокий уровень ответственности. Лучше поощряйте автономность и воспроизводите постепенно эту модель с теми, кто пока нуждаются в конкретике.
👇🏻
Будьте готовы к ошибкам
Любая инициатива и изменения увеличивают шанс на ошибку, но без этого вы не получите развития коллег. Планируйте люфт и ресурсы для возможных экспериментов, внедряйте общие практики спокойного и позитивного разбора ошибок.
👇🏻
Спрашивайте, а не отвечайте
Постепенно увеличивайте количество навигирующих вопросов по задачам, чтобы побудить сотрудника к собственным предложениям. Не «Давай сделаем так», а «Как ты считаешь, что здесь можно сделать?»

👥 Этот и другие сложные управленческие кейсы разбирают на курсе «Как управлять командой и собой». Живые воркшопы от экспертов с многолетним опытом в управлении помогут решить ситуации, которые волнуют вас прямо сейчас. Вы подготовитесь к любым трудностям в команде — от кризиса до реструктуризации.

Все детали о спикерах и обучении здесь: https://clck.ru/sTiTx

Подборка статей про стратегию

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

- Оценка стратегии через призму “ставок”, и баланса между risk и reward
- Про то, почему многим стратегиям не достает ясности, и почему они очень абстрактны
- Чем отличаются фокусировка и обобщение в стратегии
- Как собирать фидбэк на стратегию, и почему разные люди говорят разные вещи
- Почему у многих команд и компаний нет стратегии
- Нормально ли, если стратегия часто изменяется

Переход из тимлида в менеджеры менеджеров: вредные советы

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

🎤Автор предлагает с первого месяца в новой роли ворваться в хайринг – разобрать все открытые вакансии, выяснить как они ложатся в общую стратегию, подключиться к процессу интервью самостоятельно. Цель всего этого – получить общую картину по тому, насколько здоровый в команде процесс найма.
💬Найм – это инструмент. До того, как пытаться его чинить, надо понять, а есть ли с ним вообще проблема. Наличие проблемы не определить, пока ты не понял, а что и зачем в командах разрабатывается. Поэтому я бы построил план по-другому:
1. Разобраться с общей стратегией компании, поговорив с релевантными людьми.
2. Выяснить, в чем заключается успех работы каждой из команд.
3. Поговорить с заказчиками и сотрудниками и собрать список известных им проблем, которые мешают достижению успеха.
4. Вместе с тимлидами своих команд оценить влияние этих проблем друг на друга, выделить корневые.
5. В зависимости от того, в чьей зоне влияния находятся проблемы, делегировать их решение тимлиду или заняться этим самостоятельно.

Найм – не обязательно самая горящая проблема. Без понимания контекста вы будете еще одним бесполезным ценным мнением, которое будет толтко мешать.

🎤Автор советует организовать регулярные встречи со всеми, с кем только можно – 1/1 с заказчиками, синки с коллегами, еженедельные митинги с прямыми подчиненными.
💬Синхронное общение – отличный инструмент для тех случаев, когда требуется соединить картины мира и знания нескольких людей чтобы быстро прийти к общему решению. Это очень дорогой инструмент – он сильно вырывает людей из рабочего контекста, причем в то время, которое удобно автору встречи, а не им.

Заводить кучу встреч без явной агенды с целью «посинкаться про статус» – вредно для всех участников. Вместо этого я бы рекомендовал следующий подход:
1. Асинхронное общение по умолчанию. Если вам нужно узнать статус каких-то проектов – настройте общение в чате или в проектном трекере.
2. Если требуется регулярное общение с одними и теми же людьми в рамках решения какой-то конкретной проблемы – регулярные встречи рабочих групп с внятной повесткой – тоже нормально.

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

Как подходить к решению крупных проблем

🤔Не всегда первое приходящее на ум решение будет самым лучшим. Потратьте время на то, чтобы аргументировать его.
💬Проверьте, что проблему вообще стоит решать, поговорив с людьми с другим бэкграундом.
🤬Не поддавайтесь на критику сомневающихся, но отрабатывайте их возражения.
🤝Учитесь убеждать стейкхолдеров, находя свои аргументы для каждого из них.
👨‍👩‍👧‍👦Постройте две команды – инженерную, которая будет работать над решением каждый день, и расширенную, включающую в себя юристов, бизнес, дизайн и другие функции, которые могут пригодиться.

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

Яндекс Практикум и бизнес-школа Сколково собрали образовательную программу Executive Product Management, которая уже в процессе обучения помогает посмотреть на бизнес-модель с точки зрения роста в текущих реалиях рынка и пересобрать ее так, чтоб получить новых клиентов и новые деньги.

Программа состоит из модулей:
⚫️Анализ ситуации и мышление на уровне бизнес-модели.
⚫️Трендвотчинг и изменение бизнес-модели
⚫️Редизайн бизнес-модели. Коммуникация изменений и питчинг.
⚫️Дорожная карта внедрения инноваций.
⚫️Лидерство в продуктовой команде.

В финале обучения вас ждёт презентация итогов работы и обратная связь от лидеров индустрии.
Обучение проходит в смешанном формате: офлайн и онлайн и длится 4,5 месяца. На обучение вам понадобится 10-15 часов в неделю:
- на офлайн-занятиях вы будете участвовать в воркшопах и деловых играх с лидерами индустрии и коллегами из других цифровых компаний,
- в онлайне вас ждут лекции, практические руководства от экспертов, а также мастермайнды и встречи с сокурсниками.

Стоимость программы 600 000 руб.

Узнать подробнее и записаться на курс можно по ссылке

Письмо от СЕО

Люди в команде всегда ценят прозрачность со стороны руководства. Интересный способ ее обеспечивать – писать регулярные письма или дайджесты на всю команду. Они могут включать в себя:
🤔Список ключевых проблем/хайлайтов, которые держат ваше внимание прямо сейчас
🚦Performance update – статус движения по ключевым целям или проектам
💬Разбор какого-то волнующего всех вопроса

Инструмент подойдет не только СЕО, но и руководителям больших команд на несколько десятков человек.

Дизайн-спринт – набор практик для быстрой проверки гипотез

- Подход предлагает провести полный цикл тестирования идеи – от формулировки проблемы до создания прототипа и проверки его на пользователях за пять дней
- В Додо попробовали адаптировать его к еще более короткому промежутку – к трем дням
- В первый день формулируется исходная проблема, критерии успешности и вопросы, на которые надо найти ответ
- Во второй день генерируются способы решения проблемы, выбирается самый перспективный и дорабатывается
- В третий день разрабатывается максимально простой прототип и тестируется на пользователях
- Подробнее про методологию можно почитать в книге «Спринт»
- Похожий подход мы пробовали применять и в Kotlin, когда решали проблему улучшения онбординга пользователей и создания нового сценария Get Started – получилось очень полезно

Что делает разработчиков несчастными

- В статье разбирается исследование 2000 разработчиков, задача которого – понять, на что влияет счастье разработчиков, и в чем основные причины его отсутствия
- Отсутствие счастья коррелирует с плохой продуктивностью, качеством кода, задержками и плохим перфомансом
- Оптимальная менеджерская стратегия – не пытаться растить счастье, а уменьшать причины несчастья
- Основные причины несчастья находятся в области, на которую могут влиять менеджеры: давление из-за сроков, плохое качество кода и инженерных практик, неперформящие коллеги, рутинные задачи

Как разные компании платят за дежурства

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

⛑Для дежурств нанимают выделенных людей, это основная их работа
📵Дежурства вне рабочих часов отсутствуют
📳Дежурства вне рабочих часов отсутствуют, но потенциально вас могут поднять звонком
🌏Дежурства обязательны для всех инженеров, регулируются сообразно трудовому кодексу конкретного региона
💵Дежурства – часть работы, оплачиваются либо компенсируются выходными
☝️Дежурят волонтеры, но все компенсируется
🤬Дежурства обязательны для всех и никак не компенсируются

Сложные вопросы, которые помогают придумывать новые идеи

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

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

Такие вопросы можно адаптировать и к небольшой команде разработки:

- Что произойдет, если ваш основной фреймворк задепрекейтят
- Все рекрутеры уволились, как поддержать найм
- В компании запретили все митинги до единого, как подстроить к этому ваши процессы

Вред KPI и метрик в процессе разработки

«Единственная причина вводить KPI – это отсутствие доверия к тому, что ваши разработчики заинтересованы разрабатывать с максимальным вложением своих сил и знаний и становиться лучше со временем».

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

Митап по продуктовой разработке от Яндекс Go

1️⃣ Как проводить архитектурное ревью продуктовой фичи
2️⃣ Как забытые сценарии влияют на разработчиков
3️⃣ Как эффективно проектировать фичи

Митап пройдет в офлайне, в московском офисе Яндекса, 25 августа в 18:00.