Непопулярные мнения про организацию команд

👉Не создавайте нано-команды из 2-3 человек. Вы создаете дополнительную менеджерскую нагрузку, редко когда получаете достаточно пользы, а потом сталкиваетесь с тем, что решить проблему и смерджить несколько команд, не задев эго их лидов и уронив их мотивацию на пол, очень сложно.
👉Не проводите хакатоны. Дефолтный результат любого закатона – куча сырых прототипов, про которые все забудут уже на следующий день. Видимость деятельности большая, а значимых результатов нет. Если вы ждете инноваций от команд, то лучше попробуйте интегрировать возможность экспериментировать с новыми идеями в их повседневную работу.
👉Не выделяйте 20% времени на техдолг. Это очень не структурный подход, который легко может привести к тому, что команда будет заниматься не приоритетными вещами. Вместо этого работайте с техдолгом как с обычными продуктовыми задачами, добавляя их в тот же бэклог, и пропуская через сквозную приоритизацию.
👉Не защищайте время инженеров. Многие тимлиды относятся к рабочим часам программистов как к самому ценному ресурсу, оптимизируя все вокруг них – продакты должны приносить детально описанные спецификации, а тестировщики работать в изоляции и не беспокоить своими вопросами. У такого подхода миллион плохих последствий, включая замедление работы, падение качества продукта и демотивацию тех самых программистов.
👉Цельтесь в здоровый рейт увольнений. Компания, из которой никто не увольняется, и в которую не приходят новые люди, становится очень замкнутой на себя. Людям некуда расти, новых знаний не появляется, формируется пузырь.
👉Избегайте чрезмерной специализации. Наличие очень узких экспертов ведет к появлению бутылочных горлышек и падению бас-фактора.

Как превратить хаос проверки гипотез в четкий процесс?

Узнаем в новом сезоне Podlodka Product Crew — онлайн-конференции для продакт-менеджеров🚀

В программе:

🎯 Виктория Харламова (Growth Advisor, ex-Growth в Miro) разберет фреймворк тестирования гипотез, который помогает кратно растить продукт

📊 Наталия Пантелеева (Т-Банк) поделится практическим руководством по организации опросов.

💡Кирилл Мозголин (Точка) и Дмитрий Ушаков (Авито) в формате рулетки кейсов разберут, как проверять гипотезы в условиях ограниченных ресурсов

📄 Вячеслав Бусаров (Авито) расскажет, как в 6 страниц уложить всю стратегию продукта

А еще для всех участников наши партнеры из GoPractice подготовили актуальный подарок: бесплатный доступ к новому курсу “Генеративный AI для продакт-менеджеров: мини-симулятор” 🎁

Конференций пройдет с 17 по 21 февраля, ждем вас!

📍Подробности и билеты: https://podlodka.io/productcrew

Как проводить интервью в эпоху AI

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

👉Если и оставлять тестовые задания, то лучше делать их короткими. Все равно единственный способ получить от них пользу – вместе с кандидатом проходиться по решению и закапываться в конкретные его аспекты. Большой проект это только усложнит.
👉Просите объяснить всю цепочку рассуждений вместо простых ответов на вопросы.
👉Вместо синтетических задач полагайтесь больше на behavioral-вопросы, разговаривая про детали прошлых проектов и принятые там решения.
👉Открыто спросите, как именно они привыкли использовать AI, и дайте им использовать его точно так же. В работе же это не поменяется, ограничивать нет смысла.

Как AI влияет на весь SDLC

The harder you push, the harder the system pushes back.

SDLC (Software Development Lifecycle) – как раз такая система. Все верят в то, что вот сейчас модельки поумнеют, все разработчики начнут активно использовать AI, и разработка ускорится в разы. Но на самом деле значимого ускорения не произойдет, просто бутылочные горлышки появятся в других частях системы.

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

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

Чтобы адаптировать SDLC под изменения, важно понимать их суть – помимо кода новым важным артефактом становятся промпты и спецификации, которые используются AI ассистентами и агентами. Из этого следует несколько практик, которые могут помочь:

👉Организовывать библиотеки промптов, которые с большой вероятностью дают хороший результат. Например, создают новый REST запрос с обработкой ошибок и валидацией входных значений. Эти промпты надо тестировать и версионировать.
👉Intent records. Это аналог Architecture Decisiob Records, который помогает сохранять контекст того, какую конкретно задачу решает определенный кусок кода, какие ограничения и требования на него накладываются.
👉Spec modules. Это подготовленные кем-то заранее универсальные спецификации, которые вы можете немного докрутить своими собственными бизнесовыми требованиями, и получить на выходе качественный модуль авторизации, личного профиля, кэширования или чего-то еще.

Почему бигтех такой медленный

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

У этого явления есть несколько наивных объяснений:

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

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

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

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

Не извиняйтесь за оправданные решения

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

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

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

Ментальные модели для менеджеров

Пару недель назад я делился статьей про second-order thinking, и вам она зашла. Держите еще несколько полезных для менеджера ментальных моделей:

👉Инверсия. Столкнувшись с проблемой, попробуйте посмотреть на нее с противоположной перспективы. Например, если вы хотите поднять мотивацию команды, составьте список вещей, которые вы сделали бы, если бы намеренно хотели ее демотивировать.
👉Инерция. Спрашивайте себя, продолжаете ли вы следовать какой-то привычке только потому что привыкли, или потому что она и правда полезна.
👉Энтропия. Любая система постепенно стремится к распаду, если вы не прикладываете осознанных усилий по поддержанию порядка – это касается и кодовой базы, и процессов.
👉Бритва Хэнлона – никогда не предписывайте злому умыслу то, что можно объяснить глупостью. Помнить то, что вам никто осознанно не желает зла, очень помогает.
👉Бутылочные горлышки. Если хотите улучшить систему, ищите бутылочные горлышки, именно они будут точками отказа.

Книга "Understanding Michael Porter"

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

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

Мои основные инсайты:

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

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

Мы убиваем программы

Манифест, который бьет прямо в сердечко:

💔Му убиваем программы, когда добавляем новые фичи, не учитывая вносимой ими дополнительной сложности.
💔Мы убиваем программы сложными билд-системами (гредл, я смотрю на тебя).
💔Мы убиваем программы, добавляя сложные цепочки бесполезных зависимостей.
💔Мы убиваем программы, говоря начинающим разработчикам, что они изобретают колесо, когда они пытаются попробовать что-то новое. Но именно переизобретение колеса позволяет разобраться, как что-то работает, и улучшить его.
💔Мы убиваем программы, забивая на обратную совместимость.
💔Мы убиваем программы, заставляя разработчиков переписывать код, который и так работает.
💔Мы убиваем программы, когда необдуманно прыгаем на каждый новый язык и фреймворк.
💔Мы убиваем программы, когда считаем, что стандарт-де-факто в какой-то области гарантированно лучше того, что мы можем сделать сами.
💔Мы убиваем программы, когда считаем их чисто инженерным занятием.
💔Мы убиваем программы, проектируя их таким образом, что вносить простые изменения становится сложно.
💔Мы убиваем программы, пытаясь писать код как можно быстрее вместо того, чтобы дизайнить его как можно лучше.
💔Мы убиваем программы, и то, что в итоге останется от них, больше не будет приносить разработчикам никакой радости.

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

Как и обещал раньше, мы записали выпуск Подлодки про открытые зарплаты. В гости позвали Антона Бевзюка из компании Mindbox, в которой решения об изменениях зарплат друг друга принимают сами сотрудники.

Интересные факты оттуда:

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

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

Тимлиду в кризис приходится лавировать между поддержкой команды, выполнением бизнес-целей и собственными ресурсами. Как с этим справиться?

Разбираемся на онлайн-конференции Podlodka Teamlead Crew (10-14 марта)🔥

Программа ожидается насыщенная:

📢 Дебаты: Кризис — это проблема или возможность?
Анастасия Абрашитова и Евгений Антонов (Яндекс) посмотрят на кризис с двух точек зрения и принесут аргументы, чтобы разобраться - тимлидом в кризис быть тяжелее или все-таки легче, чем в нормальности.

✂️ Сокращения: как минимизировать потери и даже найти плюсы?
Дмитрий Ситников (Audible, ex-Amazon) объяснит, какие шаги помогут пройти сокращения с минимальными последствиями и даже получить из этого выгоду.

⚖️ Как сепарироваться от решений сверху и продолжить эффективно работать?
Екатерина Митусова (Women in Tech Russia, ex-Google, ex-Wrike) расскажет, как поддерживать себя и команду и приносить результаты, даже если решения руководства тебе не нравятся.

🚀 Как развивать команду, когда ресурсов нет?
Александр Птахин (Prestatech) поделится практическими подходами, как поддерживать рост сотрудников, даже если бюджеты заморожены.

И многое другое! Все знания сразу применяем на практике.

🎟 Присоеденяйся, билеты уже в продаже: https://podlodka.io/tlcrew

Meetily – локальный генератор заметок со встреч

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

👉Подключаться к аудиосессии и захватывать ее
👉Транскрибировать встречи с помощью whisper.cpp, причем сразу с разметкой спикеров
👉Использовать разные локальные модели для суммаризации

Забираю себе потестировать, вы тоже потом расскажите! Демку можно посмотреть вот тут.

Про переработки

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

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

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

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

DEI – хорошая идея, плохая реализация

👉Хороший менеджер оценивает людей не только по их текущим результатам, но и по потенциалу. Компания – это система, которая может как раскрывать этот потенциал, так и убивать его.
👉Задача компании – зарабатывать деньги. Этому помогают ценности и культура. DEI (diversity, equity, inclusion) – инструмент, который может помочь с реализацией некоторых ценностей, но он не должен подменять ни их, ни цель существования бизнеса.
👉Инклюзивная культура помогает строить хай-перфоманс команды за счет того, что расширяет как воронку кандидатов в целом, так и воронку тех, кому окружение не мешает добиваться крутых результатов. А чем больше перформящих людей, тем выше планочка поднимается для всех.
👉Пример того, почему это важно – после скандала в Uber процент женщин в SRE команде упал с 25% до 3%. А это означает кучу упущенных возможностей получить крутых сотрудников.
👉Разумные DEI инициативы направлены на то, чтобы уменьшить когнитивные искажения, которые мешают какой-то группе людей нормально работать и расти в компании.
👉При этом на самом деле большинство DEI кампаний бессмысленные – вместо того, чтобы объяснять, чем бизнесу важна инклюзивность, и решать конкретные точечные проблемы, они навязывают карго-культы и заворачивают их в обертку пустых ценностей.

Открытое собеседование на СТО

Роль СТО сильно зависит от размера, структуры и культуры компании. Собеседования тоже довольно сильно отличаются от компании к компании, но при этом общее ядро выделить точно можно.

Ведущие подкаста "Бреслав и Ложечкин" уже завтра проводят открытое собеседование СТО – Саша будет собеседовать Андрея. Помимо самого собеседования будет детальный анализ всех вопросов и ответов вместе с экспертом, который отвечает за Executive Search.

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

Capable и capability

Capable - can already do the “work”
Capability - has potential to be capable to do the “work”

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

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

Новые выпуски менеджерских подкастов

👉"Три тимлида заходят в бар" про техлидов – как и зачем искать техническое лидерство, и должен ли техлид быть инженером, разбирающимся во всех технических нюансах проекта.
👉"Бреслав и Ложечкин" продолжают говорить про дайверсити – в этот раз про стереотипы, предвзятость, и то, как с ней бороться.
👉"Frontend Weekend" с Евгением Россинским, СТО Иви, про то, как не выгореть, работая техническим директором 15 лет в одной компании.

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