Что делать, когда продукт перестает расти

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

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

The Hard Thing About Hard Things

Абсолютно восхитительной книге The Hard Thing About Hard Things, которую можно рекомендовать как настольную большинству СЕО, да и другим руководителям, на днях исполнилось 10 лет. Больше всего из нее мне запомнилась одна цитата, которая позволяет мне с тех пор давать более менее трезвую оценку разным СЕО:

Some employees make products, some make sales; the CEO makes decisions. Therefore, a CEO can most accurately be measured by the speed and quality of those decisions.

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

Интервью с СТО Netflix про их инженерную культуру

Держите часовое интервью с СТО Netflix про различные аспекты их инженерной культуры и практики, которые помогают ее поддерживать:

👉Фокус на найм и удержание самых сильных талантов
👉Упор на инновации, приходящие снизу, вместо целей, навязываемых сверху
👉Радикально честный фидбэк

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

Новый сезон Podlodka Product Crew

Через неделю мы стартуем новый сезон нашей онлайн-конференции для продактов. В этот раз тема сезона – как внедрять AI и ML в свои продукты, чтобы это было не пустым хайпом, а приносило пользу бизнесу и пользователям. Мои сессии-фавориты:

👉Доклад от Маши Полтановой из MTS AI про то, как вообще AI меняет процессы в компаниях
👉Доклад Кости Рубцова из Тинькова про то, как запускать новые AI продукты
👉Воркшоп от Кирилла Маркина про то, как самому без большой боли строить сложные AI пайплайны со своими агентами

А помимо топовых докладов и спикеров – море нетворкинга, разбор ваших кейсов, куча прикладных знаний, которые вы сможете начать использовать сразу после конфы!

📆Дата: 18–22 марта, сессии утром и вечером
🔗Регистрация

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

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

Лучшая конференция для тимлидов – уже через две недели

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

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

Вот какие сессии мне кажутся самыми интересными:

👉Воркшоп про обеззараживание метрик. Как плохо выбранные метрики могут портить работу, и как от них избавиться.
👉Доклад про Cycle Time, Feature Time, Lead Time. Как грамотно подойти к анализу времени поставки фичей до продакшна.
👉Дебаты с защитой и критикой метрик, используемых разными командами. Два эксперта будут под лупой рассматривать несколько реальных кейсов управления командой на основе метрик, и разбирать, что в них стоит оставить, а что – уничтожить.

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

📆Дата: 1–5 апреля, сессии утром и вечером
🔗Регистрация

Быстрый тест идеи. Думаю завести отдельный канал, в котором разные менеджеры-эксперты каждую неделю разбирали бы кейсы и вопросы про управление командами и разработкой от подписчиков. Что думаете? Накидайте в комментарии фидбэка!

Про overthinking

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

Кратко про то, что в статье предлагается с этим делать:

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

Как продакту строить свою карьеру

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

📆Дата: 19 марта в 19:00
👉Ссылка на регистрацию
💬Больше деталей

Важно – записи не будет, только онлайн.

Как принимать карьерные решения

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

Альтернатива – принимать карьерные решения осознанно, говоря каким-то из открывающихся возможностей "нет". Shreyas Doshi, классный PM, регулярно разливающий свою мудрость, предлагает принимать такие решения опираясь на четыре критерия:

👉Какую жизнь вы хотите вести
👉Какие суперспособности у вас есть
👉Какой тип работы дает вам энергию
👉С каким типом людей вы хотите работать вместе

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

Самые частые причины провала проектов

1️⃣Разработчики слишком самоуверены

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

2️⃣Неопытные и некомпетентные менеджеры

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

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

3️⃣Отсутствие управления ожиданиями стейкхолдеров

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

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

Украду вводную цитату из самой статьи:

"Ninety minutes of your time can enhance the quality of your subordinate's work for two weeks, or for some eighty-plus hours."

- Andy Grove

Одно из полезных применений этих 90 минут – давать детальную обратную связь вашим сотрудникам на артефакты их работы. Вот некоторые советы из статьи про то, как сделать ее более полезной:

👉Если вы никогда раньше не давали много фидбэка, то начинайте аккуратно, и предупредите его получателя о ваших мотивах. Когда руководитель приходит в твой документ и оставляет там сотню комментов – можно лишиться спокойного сна.
👉Критикуя, давайте более широкую картину. Вместо того, чтобы писать, что что-то не нравится, объясните логику, которой вы руководствуетесь.
👉Не стоит пытаться все заворачивать в пресловутый шит сендвич. Комментарий может целиком состоять из критики, но если он конструктивный и полезный – это ок.
👉При этом в контексте всего документа старайтесь не только выделить слабые стороны, но и подчеркнуть сильные, чтобы было понятно, что нужно сохранить.
👉Сначала давайте фидбэк про смысл и структуру, не спускайтесь до уровня мелких правок.
👉Попробуйте использовать выражение “I believe you were trying to do x, and if so, this part fell flat because y. Consider trying z instead.”

Подкаст про то, как мы делаем Котлин

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

👉Редкий релизный цикл, так как разработчики не скажут спасибо за обновления языка, прилетающие каждый день или неделю.
👉Практически невозможно собирать автономные команды, которые могут реализовывать значимые фичи от начала и до конца. Группировать команды приходится вокруг конкретных подсистем, и, как следствие, при планировании решать много задач по управлению зависимостями.
👉Очень сложно оценивать влияние изменений на пользовательские метрики. Во-первых, набор собираемых метрик очень ограничен. Во-вторых, никаких A/B тестов не покрутишь практически никогда. В-третьих, релизы состоят из большого количества изменений, отделить их влияние друг от друга не получается.
👉Большой упор на процессы обеспечения качества на всех этапах разработки. Из интересного – интенсивный догфудинг во внутренних проектах; большое количество quality gates, на которых изменения в компиляторе тестируются против пользовательских проектов; плотная работа с закрытой группой "early access champions", инженеров из бигтеха, которые накатывают пререлизные версии Котлина в своих продуктах и рассказывают про то, что сломалось; подробный RCA для любых регрессий, которые прошли через проверки качества.

В общем, если интересно – послушайте подкаст. А я когда-нибудь даже статью напишу про это.

И держите еще пару ссылок на выходные:
🔗Офигенный доклад про то, как монетизируются языки программирования
🔗Недавний подкаст со мной у "Мы обречены", но тут больше треп про жизнь

Подробный гайд по поиску работы Engineering Manager'ом

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

👉Менеджеры, которые искали работу в 2023/2024 году, говорят про конверсию в примерно 1 оффер на 100 откликов. На скрине картинка от 2022 года.
👉Два списка компаний, которые платят много денег: раз и два.
👉Неплохой короткий шаблон для описания своих ачивок на каждом месте работы: {action verb} {deliverable/achievement} {impact (quantifiable if possible}} {tech used (if applicable)}
👉Автор пропагандирует немного спорный с моей точки зрения подход – вместо обычного резюме собирать сайт-визитку. Как по мне, пахнет какими-то 2010-ми.
👉Один из каналов поиска работы – вступить в несколько закрытых пулов клевых кандидатов, для доступа к которым рекрутеры платят деньги (раз, два, три, четыре).
👉Очевидное, но стоит повторить еще раз – если вы действительно хотите попасть в какую-то компанию, ищите внутреннего реферрала.
👉В терминах ROI полезнее всего вкладываться в подготовку к Behavioral Interview. Его результат чаще всего перевешивает технические секции. Вот тут есть разная инфа про подготовку.

На каких трех вещах надо фокусироваться менеджеру

1️⃣Direction – делать так, чтобы каждый член команды четко понимал, что и когда от него ожидается
Это понимание важно сразу на нескольких уровнях, причем на каком конкретно из них фокусироваться зависит от конкретных людей:

👉Смысл – зачем вообще существует компания, разрабатываемый командой продукт, и сама команда
👉Вижн – долгосрочная картина того, куда конкретно вы должны прийти
👉Цели – понятные и измеримые ориентиры на ближайшее время
👉Приоритизация – очень четкие и понятные ответы на вопросы, важнее ли задача Х чем задача У.

2️⃣Coaching – коучить людей, помогая им понять, что им стоит продолжать делать, и как стать лучше

👉Работайте не только над исправлением недостатков, но и над прокачкой сильных сторон
👉Готовьте свою положительную обратную связь не менее внимательно, чем негативную
👉Давая обратную связь, будьте очень конкретными, и указывайте на детальные аспекты поведения
👉Подталкивайте людей к тому, чтобы они выдавали обратную связь вам

3️⃣Career – инвестировать в карьерное развитие своей команды, думая о нем за рамками следующего промо, и даже за рамками текущей компании

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

Осознанный подход к метрикам

Сегодня в 19 часов на канале Подлодки организуем доклад и Q&A секцию про то, какой вред плохо выбранные метрики могут нанести команде. Рассказывать про это будет Ярослав Астафьев, менеджер с очень большим опытом работы как в стартапах, так и в кровавом энтерпрайзе. В программе доклада обсуждение разных кейсов работы с метриками, рефлексия и выработка осознанного подхода к их применению.

Если что, то эту сессию проводим как разогрев перед полноценным сезоном Podlodka Teamlead Crew про метрики, который стартует на следующей неделе. Программа и спикеры уже на сайте, билеты распродаются как горячие пирожки, так что покупайте, пока не кончились (на самом деле это онлайн-конфа, поэтому билеты бесконечны!!111).

📆Дата: 26 марта, 19:00 по Москве
👉Ссылка на Youtube

Несколько фактов про оценку сроков разработки

👉Задачи с маленьким сроком чаще всего недооцениваются, а с длительным – переоцениваются.
👉Конкретные разработчики имеют тенденцию либо постоянно недооценивать, либо постоянно переоценивать задачи. Причем, скорее всего, это связано с их индивидуальным риск-профилем.
👉Около 30% всех оценок оказываются точными, 68% – в пределах двух раз от изначальной оценки, 95% – в пределах четырех раз.
👉Точность оценки отдельных разработчиков не меняется с опытом и практикой.

Эти выводы основаны на доступных публично датасетах с прогнозами и реальными сроками выполнения задач, и на исследованиях Magne Jørgensen.