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

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

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

- Используйте принципы 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.

Принципы построения команды, ориентированной на качество

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

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

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

Огромный гайд по инцидент-менеджменту

- Как организовать on-call программу
- Основные принципы процесса инцидент-менеджмента
- Как реагировать на инциденты и обрабатывать их
- Как обучаться на инцидентах и улучшать систему со временем
- Рекомендации книг и статей по теме

Звёзды в команде – зачем нужны, как нанимать и удерживать

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