Про руководство разработкой и продуктом | Олег Мохов

Кейс №3. Сотрудник регулярно смотрит видео

Сегодняшний кейс и простой, и непростой одновременно. По пути на кофепоинт вы проходите мимо сотрудника и регулярно замечаете, что он смотрит разные видео. Причём не на весь экран, а в небольшом окне — в режиме «картинка в картинке».

Что будете делать?

P.S. Предлагаю рассмотреть три варианта: вы его руководитель, коллега из смежной команды или вообще не знакомы с этим человеком.

Все кейсы — по тегу #кейсы@teamleading. Присылайте свои кейсы в директ или через форму.

«Приключения Электроника» как экспресс-курс по LLM

Смотрю с детьми советские «Приключения Электроника» и ловлю себя на том, что половину фильма легко переложить на современные реалии.

Сам Электроник — LLM в корпусе робота. Знаний море, контекст понимает, но без обвязки, скиллов и нормального описания задачи действует довольно прямолинейно.

«Крути педали, человека спасать надо» — обучение на лету. С велосипедом система быстро разбирается.

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

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

Писать в тетради почерком Сыроежкина — отдельный скилл. Поэтому Электроник может решить за него задачи и аккуратно всё записать. Но в промпте было только «реши», без уточнения «методами, доступными шестикласснику». Ответ правильный, а решение учитель не принял.

Собака Рэсси — субагент. Понимает команды Электроника, может самостоятельно выполнить поручение, а между вызовами чаще всего находится в замороженном состоянии.

Сыроежкин, который делегировал Электронику школу, спорт и домашние дела, — ранний кейс чрезмерной автоматизации. Сначала кажется, что у тебя просто освободилось время. Потом выясняется, что вместе с рутиной ты отдал системе всё, в том числе свою репутацию, отношения с людьми и место в команде (пу-пу-пу...)

Урри всё пытается найти у Электроника «кнопку» — универсальный системный промпт, который заставит его беспрекословно выполнять любые команды. Но кнопки нет: Электроник интерпретирует цели и действует исходя из собственной картины мира.

А банда Стампа в итоге не взламывает Электроника технически. Она просто убеждает его, что кража картин — хорошее и полезное дело. Классический prompt injection: подменить контекст и заставить агента применить свои способности в чужих интересах.

Профессор Громов при этом занимается не столько программированием, сколько alignment: пытается не просто добиться от системы правильных ответов, а научить её понимать людей и самостоятельно отличать хорошее от плохого.

А вообще фильм классный и очень добрый. И мысль в нём для нашего времени довольно актуальная: если делегировать машине отдельные задачи, у человека появится свободное время. Если делегировать ей вообще всё — машина незаметно займёт место человека.

Так что human in the loop нужен не только для контроля качества. Иногда он нужен, чтобы человеку самому оставалось чем заниматься.

Разбор кейса № 2. Как выбрать из трёх несовершенных решений
⠀
Итак, у нас есть три решения. Каждое закрывает два требования из трёх, а идеального варианта на рынке нет.
⠀
Главная ошибка в такой ситуации — продолжать сравнивать решения только по списку возможностей.
⠀
Я вижу два пути.
⠀
1. Выбирать не лучшее решение, а наиболее приемлемый недостаток
⠀
Для начала стоит ещё раз проверить сами требования. Если интеграция, аналитика и управление доступами объявлены одинаково важными, скорее всего, приоритеты просто не расставлены. «Нам нужно всё» — это не критерий выбора.
⠀
Нужно понять, что произойдёт, если каждого из требований не будет.
⠀
Без интеграции команде придётся переносить данные вручную? Без аналитики станет невозможно принимать решения или отчёты просто окажутся менее удобными? Отсутствие гибких доступов создаст реальный риск или только усложнит администрирование?
⠀
После этого нужно оценить не только сам недостаток, но и стоимость его компенсации. Какое-то ограничение можно обойти изменением процесса, какое-то — дополнительным инструментом, а какое-то невозможно компенсировать вообще. В конце концов, как предлагают в комментариях, недостающую функцию можно навайбкодить.
⠀
Следующий вопрос — насколько обратим выбор. Если отказаться от решения через полгода будет дорого и сложно, его недостатки нужно оценивать особенно строго. Если систему можно быстро заменить, допустимо выбрать вариант, который подходит сейчас, и проверить его на практике.
⠀
В итоге я бы сравнивал решения по трём параметрам:
⠀
— последствия отсутствующей возможности;
— стоимость временного обходного решения;
— стоимость ошибки и последующей замены системы.
⠀
Выбирать стоит вариант, недостаток которого создаёт наименьший риск и дешевле всего компенсируется.
⠀
2. Пилотировать все три решения
⠀
Второй вариант менее очевиден: пилотировать все три решения, но смотреть не только на их функциональность, а ещё и на взаимодействие с поставщиками.
⠀
Нам дали обещание вот-вот всё настроить и доработать — так давайте проверим, насколько эти обещания реалистичны.
⠀
Многие B2B-решения предлагают неплохие условия пилотирования. Можно развернуть каждое из трёх решений на трети компании и потратить сумму, сопоставимую с внедрением одного решения для всех.
⠀
Таким образом, через полгода вы протестируете сами решения и поймёте, с кем из поставщиков вам по пути.
⠀
Все кейсы — по тегу #кейсы@teamleading. Присылайте свои кейсы в директ или через форму.

© Изображение принадлежит Союзмультфильму

Кейс № 2. Как выбрать из трёх несовершенных решений

Вам нужно выбрать новую систему для работы команды (таск-трекер, например). Перед началом поиска вы определили три важных требования:
— интеграция с текущими инструментами;
— необходимая аналитика;
— гибкое управление доступами.

После изучения рынка осталось три решения.

Первое поддерживает аналитику и управление доступами, но не интегрируется с вашими инструментами.

Второе поддерживает интеграции и управление доступами, но не даёт нужной аналитики.

Третье поддерживает интеграции и аналитику, но не позволяет гибко настраивать доступы.

Каждое решение закрывает два требования из трёх. При этом команда считает важными все три и не готова однозначно отказаться ни от одного.

Идеального варианта на рынке нет, но решение нужно принять.

Как будете выбирать?

p.s. Для тех кто любит посложнее — у вас есть доступ к производителям решений и каждый уверяет что в течение ближайших 3-х месяцев недостаток их решения скоро исчезнет и они вот-вот зарелизят эту фичу.

Все кейсы — по тегу #кейсы@teamleading. Присылайте свои кейсы в директ или через форму.

Разбор кейса № 1. Сотрудник выносит конфликт в публичное поле

Итак, давайте разберём кейс.

Здесь важно разделить два вопроса.

Первый: почему сотрудник изменил договорённость и решил уйти сегодня?

Мне кажется, главное, что должен понимать любой руководитель: не надо пытаться угадать мотивы сотрудника. За его поступком могут стоять обида — что вполне объяснимо — и желание выйти из ситуации условным «победителем». Но это лишь предположения, на которых не стоит строить свои дальнейшие действия.

Так вот, не надо искать ответа на первый вопрос. Нужно просто принять происходящее как новый факт. Обычно, спустя какое-то время, ответ или сам собой находится, или же оказывается не важен.


Второй: что делать?

Итак, сотрудник публично обвинил руководителя. Ответ на эти обвинения зависит от того, насколько они справедливы.

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

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

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

Но вступать в большой публичный спор не стоит в обоих случаях.

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

Разбираться в мотивах сотрудника необязательно, а вот разобраться в собственных словах и поступках — необходимо. И мотайте на ус, кому можно доверять и с кем можно шушукаться. Я не строю иллюзий на этот счёт: сплетни были и будут всегда.

Знающие меня люди уже догадались, что этим кейсом я завуалировал происходящее в группе «Слот». Кэш, бери на вооружение.

Все кейсы — по тегу #кейсы@teamleading. Присылайте свои кейсы в директ или через форму.

Кейс № 1. Сотрудник выносит конфликт в публичное поле

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

Чтобы проинформировать команду, вы вместе выступили перед коллегами и рассказали о принятом решении.

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

Как вы поступите? Пишите свои варианты, а свой я напишу в среду.

Все кейсы тут #кейсы@teamleading

P.S. Да, кейсы возвращаются. С наступлением осени я решил вернуть эту рубрику и она будет выходить по понедельникам. Присылайте свои кейсы в директ или через форму.

Концерт Канье Уэста в России, или при чём тут Agile?

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

Если вы пропустили: недавно объявили, что Ye даст аж два концерта в октябре на «Газпром Арене» в Петербурге. Для России, где с 2022 года мировые звёзды практически не появлялись, это, мягко говоря, событие. Новость разлетелась повсюду, и многие начали надеяться: а вдруг вслед за Канье к нам снова поедут и другие артисты?

И вот вчера «Газпром Арена» сообщила, что никаких договоров на проведение концертов не подписывала. Организаторы при этом уверяют: всё идёт в штатном режиме. Комичности ситуации добавляет то, что двумя постами ранее в аккаунтах Арены разыгрывают билеты на эти же самые концерты, которые не подписаны 😃

Основываясь исключительно на этих формулировках, могу сделать единственно возможный вывод: мы наблюдаем столкновение двух моделей управления проектами — Waterfall и Agile.

Чтобы организовать концерт Ye по Waterfall, нужно:
Позвонить Канье и договориться → позвонить на площадку и договориться → согласовать всё с властями → подписать документы → анонсировать концерты.

В Agile всё иначе.

Менеджер проекта одной рукой звонит на арену и уточняет свободные даты, другой — Канье и спрашивает, когда свободен он. Находит пересечение, просит всех пока ничего туда не ставить и кричит маркетологу:
— Вася, запускай продажу билетов!

Потому что если организовывать такой концерт по Waterfall, он, возможно, не состоится никогда.

Как и многие другие проекты, глядя на которые со стороны, думаешь: «Что у них там за бардак?»

А бардак там не потому, что никто не знает, что делать. Просто без него, возможно, не получилось бы вообще ничего.

Стратегия — это не список хотелок

Я тут готовлю обзор на готовящуюся к публикации книгу Уилла Ларсона «Стратегия разработки» (кстати, по ссылке предзаказ с приятной скидкой). Книга напомнила мне про Ричарда Румельта и его подход к стратегии.

Наверняка вы видели стратегию примерно такого вида:
— увеличить выручку на 30%
— выйти на новые рынки
— повысить качество продукта
— внедрить ИИ
— стать лидером отрасли

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

Румельт в книге «Хорошая стратегия, плохая стратегия» пишет, что у хорошей стратегии есть довольно простое ядро:
диагноз → руководящая политика → согласованные действия. Давайте разберём.

▫️. Диагноз

Сначала нужно честно ответить на вопрос: что именно мешает нам получить желаемый результат?

Не «рынок меняется».
Не «нужно ускориться».
Не «у нас недостаточно инноваций».

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

Например:
«Продукт перестал расти, потому что новые пользователи не доходят до первого полезного результата и уходят в течение первого дня».

Это уже диагноз. Его можно проверить, обсудить и даже опровергнуть. И это важный момент: если вы неправильно определили проблему, дальше можно очень качественно идти не туда.

▫️. Руководящая политика

Дальше нужно выбрать общий подход к решению проблемы.

Например:
«Мы сосредоточимся на активации новых пользователей: упростим первый сценарий и сократим время до получения пользы от продукта».

Это ещё не подробный план. Это принцип, который помогает принимать решения.

— Добавлять ли новую фичу?
Если она не помогает активации — скорее всего, нет.

— Делать редизайн онбординга?
Да, если именно там теряются пользователи.

— Запускать ли ещё одну рекламную кампанию?
Наверное, не сейчас: нет большого смысла приводить больше людей в дырявую воронку.

Хорошая руководящая политика не только говорит, что делать. Она ещё и помогает понять, чего делать не надо.

▫️. Согласованные действия

И только теперь появляются конкретные инициативы:
— сократить регистрацию с пяти шагов до двух
— переделать первый пользовательский сценарий
— убрать необязательные настройки из онбординга
— добавить аналитику точек отваливания
— ускорить загрузку первого экрана
— изменить коммуникацию с новыми пользователями

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

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

Это просто несколько подразделений, у каждого из которых есть свой план. И вот здесь, как мне кажется, находится самая неприятная часть стратегии.

Стратегия требует выбора.

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

Короче, когда вам в следующий раз покажут стратегию, попробуйте задать пять вопросов:
— Какую конкретно проблему мы решаем?
— Почему мы считаем главной именно её?
— Какой подход мы выбрали?
— От чего мы решили отказаться?
— Как действия разных команд поддерживают друг друга?

Если ответов нет, то, скорее всего, перед вами не стратегия, а пожелания к будущему.

Хорошая стратегия, по Румельту, — это не красивое описание того, куда мы хотим прийти. Это ещё и честный ответ на вопрос: что нам мешает и как именно мы собираемся с этим справиться.

Если руководитель не контролирует каждый шаг команды — всё развалится? Или наоборот, именно постоянный контроль мешает людям брать ответственность?

Разбирались, существуют ли вообще «самоходные команды» и где проходит граница между доверием и потерей контроля — с гостями моего эфира:

🎙️ Галей Ширанковой — CPO социальных взаимодействий ВКонтакте, автором Telegram-канала «Полтора продакта»
🎙️ Олегом Моховым — руководителем разработки, автором Telegram-канала о лидерстве и управлении IT-командами

Обсудили самые острые вопросы управления командами:
🔸что на самом деле означает «самоходная команда» и почему это не отсутствие руководителя,
🔸как вовремя отличить настоящую автономность от хаоса и безразличия,
🔸когда лидер обязан вмешаться, а когда лучше дать команде право на ошибку,
🔸почему продуктовые и технические KPI часто конфликтуют,
🔸чем отличается управление в стартапах и крупных технологических компаниях,
🔸нужно ли быть «переводчиком» между бизнесом и разработкой,
🔸как нанимать людей, способных работать самостоятельно,
🔸почему без понимания собственного стиля лидерства невозможно выстроить сильную команду.

Полный выпуск уже на всех платформах, сохраняйте пост, чтобы посмотреть интервью в удобное время:
📺 YouTube
📺 Рутуб
📱 LinkedIn

А как считаете вы? Можно ли действительно построить полностью автономную команду, или «самоходность» — это красивый управленческий идеал, который неизбежно разбивается о реальность?

Читалка. Перезагрузка

11 лет назад я сделал читалку. «Пожалуй, лучшую читалку для чтения Льва Николаевича Толстого онлайн».

Нет, не так. 11 лет назад мы делали Яндекс Книги. Ничего общего с текущими Яндекс Книгами этот проект не имел кроме названия. Это был виджет в поиске Яндекса для покупки книг и одна из его фичей была «Предпросмотр книги». Сам сервис мы запустили в бету на ограниченный круг пользователей, а через две недели закрыли, так как наверху решили что проект не перспективен.

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

После того как проект Яндекс Книги закончился я получил разрешение заопенсорсить Читалку, создал репозиторий и перенес код туда.

Я рассказывал про читалку на русском и даже на английском. Но затем меня захватила работа и я забросил проект.

Недавно я решил посмотреть заново на читалку, с учетом того что за 20$ в месяц теперь можно купить почти команду сениоров. Во-первых, потому что я сам много читаю. Во-вторых, потому что многих фич, которые я уже тогда реализовал, до сих пор нигде нет.

Пара недель вайбкодинга и встречайте читалку 2.0... Всё ещё чисто браузерная читалка, просто кидаете файл с книгой и читаете... Теперь с поддержкой epub, закладками и цитатами, синхронизацией через гугл.драйв или яндекс.диск. Но при этом практически идеальную по типографике, дизайну и удобству использования. Это единственная читалка с режимом встроенных сносок и умеющая идеально сохранять позицию чтения кроссдевайсно. При этом в бэклоге ещё куча вкусных фич, и скоро я и их реализую.

А ещё у читалки теперь есть маскот — Тиграша.

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

p.s. А ещё подписывайтесь на телеграм-канал читалки.

Три вопроса вместо реакции на автопилоте

Сейчас я читаю книгу Дэниела Сигела и Тины Брайсон «Дисциплина без драм. Как помочь ребёнку воспитать характер». И уже с первых страниц нахожу в ней идеи не только про воспитание детей, но и про управление.

Представьте: ребёнок кричит в общественном месте, бросается едой или ударил брата. Первая реакция понятна: как можно быстрее это прекратить. А заодно отругать, наказать или хотя бы выразительно сообщить, что «так делать нельзя».

Авторы предлагают сначала сделать паузу и задать себе три вопроса:
— Почему?
— Что?
— Как?


Почему ребёнок так поступил?

Первый ответ, продиктованный гневом: «Потому что он маленький засранец!» или «Он специально хочет свести меня с ума!»

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

Понять причину не значит оправдать поступок. Бить брата всё равно нельзя. Но от причины зависит, что делать дальше.

Какой урок я хочу преподать?

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

Как лучше всего преподать этот урок?

Здесь важно учитывать возраст ребёнка, его состояние и способность сейчас вообще что-то услышать. Иногда сначала нужно помочь ему успокоиться и только потом что-либо объяснять.

Мне кажется, этот фреймворк полезен и в работе — правда, вопросы стоит немного адаптировать.

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

Автоматическая реакция руководителя: команда сопротивляется, ленится или просто не хочет брать ответственность.

Но можно спросить себя:

Почему команда реагирует именно так?
Что должно измениться по итогам разговора?
Как провести разговор, чтобы это изменение произошло?

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

Три вопроса не гарантируют, что конфликт исчезнет. Но помогают хотя бы не принимать управленческие решения в режиме «потому что я так сказал».

Что делать, а не «не делать»

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

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

Проблема в том, что простое «не» не даёт нам нового сценария поведения.

Представьте непролитое молоко. Получилось? Скорее всего, вы представили стакан или пакет с молоком. Потому что «непролитое молоко» само по себе не существует — ему всё равно нужна какая-то конкретная форма.

Так же и с действиями. «Не молчать» — это что именно? Задать вопрос? Высказать возражение? Предложить свой вариант?

В книге «Эмоциональный интеллект. Российская практика» предлагают после ошибки задавать себе другой вопрос:
«Что в следующий раз я сделаю иначе?»

Не «перестану откладывать», а «начну с черновика во вторник».
Не «не буду перебивать», а «сначала дослушаю и задам вопрос».
Не «перестану волноваться», а «заранее запишу первые две фразы».

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

Этот совет работает и с собой, и когда вы даёте фидбек коллеге, и при взаимодействии с детьми.

В самой частице «не» нет ничего плохого, если за ней следует плодотворная работа надо вопросом «а что тогда да?», иначе вы получите цикл как в известной шутке про розового слона. Не думайте о розовом слоне, думайте о капибарах.

«Я давно хочу стать руководителем»

На карьерной встрече эта фраза обычно воспринимается как хороший сигнал. Человек мотивирован, готов брать ответственность. Что может пойти не так?

В майском выпуске The Quarterly Journal of Economics вышло исследование о том, как находить хороших менеджеров. Его активно обсуждали в англоязычных соцсетях: только один пост на r/science набрал почти 10 тысяч голосов.

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

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

А второй веселее.

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

Команды с наиболее мотивированными кандидатами в среднем показали результат немного хуже.

Но... не спешите назначать руководителей генератором случайных чисел. Исследование говорит не это.

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

Желание руководить может быть сигналом амбиций. Но оно не доказывает, что человек умеет:

— распределять работу;
— видеть сильные стороны людей;
— замечать узкие места;
— менять решение после появления новых фактов;
— добиваться результата не только собственными руками.

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

Первая — повысить самого громкого. Он активно берёт слово, рассказывает, как готов руководить, и уже мысленно раздаёт задачи. Его заметно. А тихого человека, к которому коллеги ходят за советом и координацией, — нет.

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

Поэтому я проверяю кандидатов не только вопросом «Хочешь ли ты?», но и небольшими управленческими задачами:

— координация проекта без формальной власти (например, вечерние настолки или поход в бар);
— декомпозиция цели/эпика и распределение работы;
— сообщение неприятных новостей;
— изменение решения после новой информации;
— обратная связь от коллег, с которыми человек работал на равных.

И обязательно спрашиваю, зачем человеку руководство.

Ответы «хочу больше влиять на результат» и ответ «не хочу больше получать задачи от других» звучат только когда человек понимает работу руководителя издалека.

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

Мы тупеем из-за ИИ?

На прошлой неделе вышла статья с отличным тревожным заголовком: «Is AI making us stupid?». Авторы разбирают этот вопрос комплексно и пытаются понять: если мы всё чаще отдаём ИИ думать за нас, не разучимся ли мы думать сами?

Ответ, конечно, не такой простой. Мы всегда разгружали голову: навигатор помнит дорогу, календарь — встречи, поиск — факты. И это хорошо. Проблема начинается не тогда, когда ты делегируешь работу, а когда вместе с ней делегируешь понимание.

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

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

Умение пользоваться калькулятором не должно уничтожать навыки умножения и других математических операций.

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

Поэтому я бы смотрел на использование ИИ не через «сколько процентов работы мы автоматизировали», а через три простых вопроса:

Человек после работы с ИИ может объяснить принятое решение?

Он понимает, что и как надо проверить?

Сможет ли он решить похожую задачу без ИИ хотя бы на приемлемом уровне?

Если нет, то мы не сэкономили когнитивную нагрузку. Мы просто взяли её в кредит.

И ещё одно: не стоит запускать параллельно столько агентов, сколько может запустить компьютер. Запускать надо столько, результаты работы которых вы способны нормально понять, проверить и принять. Всё остальное — не ускорение, а ещё одна очередь задач в голове.

Скорость — это здорово. Но умение думать, принимать решения и отвечать за них пока всё ещё главная ценность команды.

Умение вовремя сказать стоп

В работе руководителя очень важно научиться иногда говорить: «Стоп».

Допустим, вы поставили таргет по метрике. Технари хотят uptime в 99,95%, продакты — месячный retention в 20%, а руководитель отдела продаж — 10% успешных тёплых звонков.

Вы настроили графики, дашики и еженедельные процессы. Проходит полгода, но метрика не достигнута.

Вы требуете план. Команда приносит план, вы его утверждаете, проходит ещё месяц — ничего не меняется. Тогда появляется новый план. Потом план исправления предыдущего плана.

А можно в какой-то момент остановиться и спросить: мы вообще всё ещё делаем что-то разумное?

Как-то раз мне позвонил менеджер банка и предложил рефинансировать кредит.

Зная текущие ставки, я отнёсся к предложению скептически, но всё-таки решил послушать. Менеджер спросил, на какую сумму у меня текущий кредит. Допустим, я ответил: 100 000 рублей.

Он немного подумал и сказал:

— Мы можем выдать вам кредит на 102 000 рублей. Правда, ежемесячный платёж будет выше нынешнего и срок будет больше.

Я, конечно, отказался. Но дальше произошло неожиданное, потому что менеджер спросил:

— А почему?

— А какой в этом смысл?

— Ну как же, у вас появится ещё 2 000 рублей. Вы сможете позволить себе дополнительные траты.

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

Можно добиться нужной цифры, но потратить на это больше, чем она принесёт. Можно увеличить retention бесконечными пушами и испортить продукт. Можно поднять uptime на сотую долю процента, остановив ради этого всё продуктовое развитие. Можно увеличить число продаж, раздав такие скидки, что каждая продажа будет приносить убыток.

Поэтому иногда нужно остановиться и проверить:

Мы всё ещё решаем важную проблему?

Эта метрика действительно связана с нужным результатом?

Цена достижения цели остаётся разумной?

Или мы продолжаем только потому, что уже потратили на неё полгода?

Сказать «стоп» не означает сдаться при первой неудаче. Иногда надо поменять способ достижения цели. А иногда — признать, что сама цель больше не имеет смысла.

Настойчивость без проверки реальностью превращается в упрямство.

И иногда главная задача руководителя — не добиться поставленной цели, а первым понять, что добиваться её больше не нужно.

Как разговаривать с мудаками

⭐️ О чём книга?

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

Марк Гоулстон, психиатр и бывший тренер переговорщиков ФБР и полиции, объясняет, почему так происходит и что с этим делать. Главная мысль книги: иррационального человека бесполезно побеждать рациональными аргументами. Сначала нужно понять, что происходит у него в голове, снизить напряжение и только потом пытаться о чём-то договариваться.

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

⭐️ Мысли из книги

▫. Как прощать, если тебя глубоко обидели

Гоулстон предлагает метод четырёх Р:

— раскаяние;
— расплата;
— реабилитация;
— просьба о прощении.

Для меня здесь особенно важны первые два пункта.

Сначала человек должен не просто сказать «извини», а показать, что действительно понял, какую боль причинил. Причём в этот момент его задача — слушать, а не объяснять, почему он «на самом деле не это имел в виду».

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

Без этого прощение часто превращается в требование к пострадавшему: «Ну я же извинился, теперь перестань обижаться».

▫. Как договариваться с «вредными» родителями

В книге есть пара хороших советов о том, как разговаривать с родителями, которые либо изводят детей, либо говорят: «Мне ничего не надо», — а потом страдают от отсутствия помощи.

Первый — спокойно описать ближайшее будущее и свои границы:

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

Не угрожать, а заранее объяснить последствия.

Второй совет — не задавать вопрос, на который человек автоматически ответит «нет», если вы уже понимаете, что помощь ему нужна. Не «хочешь, я запишу тебя к врачу?», а «тебе удобнее сходить к врачу на этой или на следующей неделе?».

Я, сам того не осознавая, применил эту тактику, когда уговаривал маму пройти обследование. И она отлично сработала.

▫. Попробовать описать чувства другого

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

Не утверждать: «Ты почувствовал вот это», — а проверять гипотезу:

«Мне кажется, в тот момент ты почувствовал, что я тебя не ценю. Это так?»

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

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

⭐️ Мои впечатления

Книга очень сильная, но у неё дико кликбейтное русское название. Оно может отпугнуть именно тех, кому книга была бы полезна. Потому что быстрый ответ на вопрос «как разговаривать с мудаками?» звучит просто: никак, по возможности избегать.

Но книга на самом деле не про мудаков и даже не про сумасшедших. Оригинальное название Talking to Crazy тоже не слишком точно раскрывает суть. Для меня идеальное название звучало бы примерно так: «Как разговаривать с людьми, которые думают не так, как вы».

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

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

Оценка книги: 9/10

Остальные обзоры книг доступны по тегу #книгобзор@teamleading

😂👍👍❤️👌😅😊😊😍😘
10 июля (пятница), 18:00 ч. (Мск)

Последние две недели в «Летней Лаборатории» мы разбирали метанавык «Осознанность». Теперь пришло время поговорить о том, где его применение становится особенно заметным. Ответ прост — в управлении командами.

Свобода вдохновляет и развивает сильных специалистов. Но как руководителю сохранить влияние, не превращая его в контроль? Как оставаться осознанным лидером, а не микроменеджером?

Обсудим эту тему с экспертами. У меня в гостях:

🔠 Галя Ширанкова — CPO социальных взаимодействий ВКонтакте, автор Telegram-канала «Полтора продакта»

🔠 Олег Мохов — автор Telegram-канала о руководстве разработкой и проектами, руководитель с опытом работы как в крупных технологических компаниях, так и в небольших IT-командах.

Разберем на эфире:
🔠 Где на самом деле проходит граница между «самоходной командой» и потерей управления?
🔠 Что делают сильные руководители, когда план перестает работать, а команда уже «на свободе»? Как не скатиться обратно в ручное управление в момент кризиса и какие решения помогают сохранить автономию команды в условиях давления?
🔠 Как принимать решения, когда «сверху» постоянно меняются правила игры? И как не разрушить доверие, когда приходится «пересобирать» курс?
🔠 В какой момент руководителю стоит задать себе вопрос: «А если я неправ?» И что это реально меняет?

❗️Для участия обязательно пройдите РЕГИСТРАЦИЮ, иначе вам не придет ссылка для подключения. Это важно!

Готовьте свои вопросы экспертам и до встречи на эфире 👋

Метод чекпоинтов

Сегодня расскажу про свой способ контролировать асинхронные вещи в жизни. Я называю его методом чекпоинтов.

Асинхронные вещи — это всё, что нельзя сделать мгновенно в тот момент, когда ты про это вспомнил.

Нужно привезти детей в сад к 8:30.
Нужно не забыть купить домой бытовые штуки.
Нужно довести проект до октября.

Проблема обычно не в том, что мы не понимаем финальную точку. С ней как раз всё понятно.

Паста закончилась.
В детский сад опоздали.
Проект не готов.
Все грустят.

Проблема в том, что финальная точка — это уже поздно.

Метод чекпоинтов устроен иначе: нужно заранее найти момент, когда ещё не поздно.

Разберем пример, дома должна быть зубная паста. Да не колгейт, который доставка привезет за 5 минут, а специальная, которая обычно идёт около 20 дней.

Тогда главный вопрос , который я бы задал себе — «как выглядит тюбик за 20 дней до того, как паста закончится?».

Может быть, в этот момент он уже начал скручиваться.
Может быть, визуально заметно, что осталась примерно треть.
Может быть, вы уже начали давить его с таким усердием, будто добываете последние капли нефти из месторождения.

Вот это и есть чекпоинт.

Не «паста закончилась, надо заказать».
А «тюбик дошёл до состояния Х, пора заказать, потому что через 20 дней он закончится».

С детским садом то же самое.

Если нужно быть там в 8:30, а дорога занимает 30 минут, то чекпоинт не в 8:30. В 8:30 уже всё, вы либо молодец, либо объясняете воспитателю, почему сегодня опять пробки, снег, дождь, ретроградный Меркурий и маленькие человеки двадцать минут выбирали носки.

Чекпоинт раньше: в 7:50 надо выйти из дома.

А ещё раньше может быть другой чекпоинт: в 7:30 дети должны быть одеты.
А ещё раньше: в 7:10 они должны закончить завтрак.
И так далее.

С проектами сложнее, потому что тюбика пасты у проекта обычно нет. Нельзя посмотреть на него и сказать: «О, он уже скручивается, пора заказывать аналитику».

Поэтому чекпоинты приходится делать искусственно.

Если проект должен быть готов к октябрю, надо не просто сказать «ну к октябрю сделаем», а декомпозировать: что должно быть готово к июлю, к августу, к сентябрю. Причём не в формате «мы активно работаем», а в формате проверяемого результата.

Не «идёт разработка».
А «есть прототип».
Не «обсуждаем интеграцию».
А «интеграция работает на тестовом контуре».
Не «почти всё готово».
А «пользователь может пройти основной сценарий».

Хороший чекпоинт — это не напоминание в календаре. Это состояние мира, по которому понятно: всё идёт нормально или пора вмешиваться.

Мне кажется, в этом и есть главная польза метода. Он помогает не обнаруживать проблему в момент, когда уже почти поздно. Потому что «паста закончилась» — это не чекпоинт. Это уже инцидент.

Техника ИСР

Представьте: вы поставили сотруднику плохую оценку на ревью.

Оценку аргументировали. Привели примеры. Объяснили, чего не хватило до следующего уровня. Вроде бы всё сделали правильно.

Но человек услышал совсем другое:

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

После ревью вы пытаетесь поговорить ещё раз, но нормального разговора не получается. Сотрудник либо спорит с каждым примером, либо замыкается и отвечает односложно. Чем подробнее вы объясняете оценку, тем сильнее он защищается.

В книге Talking to Crazy — русский перевод «Как разговаривать с мудаками», на мой взгляд, крайне кликбейтный — Марк Гоулстон предлагает для таких разговоров технику ИСР: извинение, сочувствие, раскрытие.

И — извинение.

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

С — сочувствие.

«Понимаю, что ты много работал, рассчитывал на другую оценку и в итоге мог почувствовать, что все твои усилия просто обесценили».

Р — раскрытие.

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

Последняя часть самая сложная. Нужно вслух назвать то неприятное, что человек, вероятно, уже думает о вас.

Это не означает, что оценка была неправильной и теперь её нужно повысить. ИСР вообще не про отказ от своей позиции.

Оценка остаётся прежней. Примеры и обоснования никуда не исчезают. Требования к следующему уровню тоже.

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


И вот вы всё это сказали. Что же дальше?

Всё просто — помолчите.

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

Разговор либо начнётся прямо сейчас, либо человеку понадобится ещё немного времени.