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

В этом канале самые жаркие холивары разгораются всегда вокруг одной и той же темы – это применимости различных метрик к различным аспектам работы тимлида. Ну, вы знаете, все вот эти попытки по частотности коммитов предсказывать перфоманс, и по скорости деплоя оценивать успешность своей работы. Так вот, ребята из программного комитета 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️⃣Отсутствие управления ожиданиями стейкхолдеров

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

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

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

👉Редкий релизный цикл, так как разработчики не скажут спасибо за обновления языка, прилетающие каждый день или неделю.
👉Практически невозможно собирать автономные команды, которые могут реализовывать значимые фичи от начала и до конца. Группировать команды приходится вокруг конкретных подсистем, и, как следствие, при планировании решать много задач по управлению зависимостями.
👉Очень сложно оценивать влияние изменений на пользовательские метрики. Во-первых, набор собираемых метрик очень ограничен. Во-вторых, никаких 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.

Привет, на связи Podlodka Teamlead Crew!
Пришли со свежими подробностями сезона.
Стартуем уже 1 апреля: научимся выбирать, внедрять, анализировать и масштабировать метрики.

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

❓В каких сферах применимы метрики? Сергей Воробьёв объяснит как использовать популярные виды метрик и где брать для них данные.

❓Как принимать решения на основе метрик? Сергей Петрук из QIWI владеет этой магией: проведёт воркшоп по фреймворку принятия решений, разберёт реальные кейсы.

❓Как говорить с бизнесом на языке метрик? Серафима Чекулаева поделится священными тайнами продуктовых метрик и их потенциальной пользой.

Билеты уже на сайте, забирай свой!
https://podlodka.io/tlcrew

Про внедрение стандартов

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

Статья напоминает про то, что в решении таких проблем разумно обратиться к существующим стандартам и выбрать подходящий для вас. Например, ISO, IETF RFC, ICANN. Даже если внедрение стандарта потребует переписать какой-то существующий код и мигрировать данные, в долгую, скорее всего, это вложение окупится.

Как декомпозировать проекты

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

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

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

Teamlead Crew стартует уже завтра

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

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

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

Нам надо двигаться быстрее

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

Конечно, рыночек часто мотивирует компании ускоряться. При этом не стоит путать реальную нужду со следующими похожими на нее вещами:

👉Ностальгия. Когда-то компания была маленькой, двигалась и менялась быстро. Но рост всегда несет за собой сложность и неповоротливость, и вернуться в прошлое при всем желании не получится.
👉Хаотичность. Быстрая и интенсивная работа сама по себе не всегда несет за собой пользу для бизнеса.
👉Героические усилия. В компаниях, живущих от пожара до пожара, частым элементом культуры становится поощрение тех, кто, превозмогая все, решает очередную проблему. Это ведет не только к выгоранию, но и к тому, что компании разучиваются работать над долгосрочными проектами.

Когда от вас требуют двигаться быстрее, задайте следующие вопросы:

👉Зачем? Откуда вообще берется это требование, чем оно продиктовано, как согласовано со стратегией компании.
👉Какого типа скорость нужна? Идет ли речь о скорости поставки ценности или скорости адаптации к внешним изменениям на рынке?
👉В каких конкретно областях бизнеса надо двигаться быстро? Ускориться одновременно везде нельзя, да и не имеет смысла.
👉Что мы готовы заплатить за скорость? Ускорение не дается бесплатно, нужно чем-то пожертвовать. Например, качеством.
👉Какая поддержка будет оказана? Для того, чтобы команда работала быстрее, нужно, чтобы ее вход и выход были так же оптимизированы – грамотный менеджмент, понятные требования, налаженная автоматизация.

Метод Монте-Карло для прогнозирования сроков

За последний месяц мне нужно было построить сразу несколько финансовых моделей и моделей роста на основе довольно ограниченных объективных данных о размере рынка и конверсиях. Получить хоть какое-то представление о возможных разбросах значений очень помог метод Монте-Карло. И вот как раз наткнулся на статью, где подробно разбирается, как его использовать в Google Sheet, и применять для прогнозирования сроков выполнения задач и приоритизации бэклога.

Может ли тимлид не быть программистом

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

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

На мой взгляд – полная ерунда. А вы что думаете?