Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Баги – не проблема, а ее симптомы

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

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

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

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

Что происходит в индустрии – Developer Ecosystem Report 2024

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

👉Языки программирования, которые скорее всего покажут самый большой рост в будущем: TypeScript, Rust, Python и Go. Отдельно советую посмотреть на матрицу по тому, какие языки для каких задач используются, там интересно.
👉Десктопная разработка ого-го как жива. Разработчиков, которые разрабатывают что-то под десктоп, на 6% больше, чем мобильщиков. Я где-то год назад исследовал, чем же они занимаются – оказалось, что подавляющее большинство пилит внутренние приложения в огромных энтерпрайзах: бесчисленные ERP и CRM.
👉18% респондентов разрабатывают что-то, что попадает в категорию "AI фичей".
👉Большая тройка облаков теперь четверка. Alibaba Cloud сравнялся по доле рынка с Google Cloud, но до AWS, занимающего половину рынка, им всем еще очень далеко.
👉60% компаний пытаются измерять developer experience и productivity, причем в большинстве случаев за это отвечают тимлиды. Жаль, нет проверки корреляции реального счастья программистов с попыткой его измерить.
👉Самые популярные AI ассистенты: ChatGPT, GitHub Copilot, Google Gemini и JetBrains AI Assistant. Из интересного – в 11% компаниях вообще запрещены любые AI тулы.
👉В среднем на активности вокруг написания кода уходит 70-80% времени, а на митинги и чаты – 10-20%. Лучше, чем я ожидал!
👉Больше половины опрошенных говорят, что лэйоффы на них никак не сказались, треть затронуло по касательной, а реально потеряло работу 16%.
👉Написать код – наименее сложная из задач. Тяжелее всего понять, что конкретно хочет пользователь, и общаться с другими людьми.

Что определяет сильных инженеров

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

👉Вера в себя. Сложные проблемы всегда несут с собой огромное количество неопределенности. Вы не можете их оценить, вы не понимаете их технических деталей, вы не можете сходу сформулировать путь их решения. Для многих работа в такой обстановке невозможна. Вера в себя помогает не бояться таких проблем, браться за них. и постепенно эту неопределенность снимать.
👉Прагматичность. Для таких инженеров качество решения определяется не его элегантностью или какими-то другими критериями в вакууме, а тем, насколько эффективно оно решает изначальную проблему.
👉Скорость. Благодаря ей появляется возможность пробовать много разных подходов к решению задачи, и выбирать самый жффективный. Скорость важна и на длинном горизонте – чем больше разных идей инденер пробует, тем больше опыта он накапливает.
👉Технические скиллы. Здесь сложно выделить какой-то базовый уровень, но основная идея такая – хорошая техническая насмотренность помогает инженеру увидеть пути решения задачи, которые остальным будут не очевидны.

Давайте пообсуждаем пост про DISC тут. Обновленный спам-бот в чате типизирует себя как D по DISC, поэтому доминантно принял решение сам, и удалил комменты к прошлому посту.

Никогда не используйте DISC

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

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

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

И ладно бы еще DISC был просто бесполезным, но он еще и вреден:

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

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

Как строится репутация

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

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

Из этого получается следующая логика:

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

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

Роли principal инженеров

Инженеры уровня principal почти такие же снежинки, как и тимлиды – они очень сильно отличаются друг от друга, и могут выполнять очень разные роли. Благодаря тому, что в Amazon инженерная команда бесконечного размера, принципалов тоже скопилось достаточно много, чтобы выделить самые частые и полезные роли, которые они могут выполнять:

👉Спонсор – лидер проекта, который разрабатывается несколькими командами. Отвечает за то, чтобы проект двигался вперед, проблемы, встающие перед командами, быстро решались, а решения вовремя принимались. Такую роль может выполнять и менеджер, но в случае принципала люди ему напрямую не подчиняются.
👉Гид. Доменный эксперт, глубоко вовлечен в техническую часть, в отличие от спонсора не занимается проектным менеджментом или организационными задачами. Часто драйвит архитектуру, но при этом не становится главным архитектором, вместо этого активно вовлекая всю команду. Продакшн код не пишет. Гид работает с целой командой, а не менторит отдельных людей.
👉Катализатор. Проводит проект от очень сырой идеи до момента официального запуска: пилит прототипы, готовит все нужные документы, получает buy-in от нужных стейкхолдеров. Как только проект запущен, катализатор либо меняет свою роль на гида или спонсора, либо берется за следующую идею.
👉Tie Breaker (помогите найти аналог на русском). Подключается к принятию очень важных решений, в которых нет очевидного правильного ответа, и которые команда не может принять сама. Он глубоко погружается в проблему, разбирает все точки зрения, принимает финальное решение и документирует его. Это временная роль, в отличие от всех предыдущих.
👉Ловец. Подхватывает проект, столкнувшийся с проблемами и сошедший с трека, и приводит его в порядок. Его основная задача – провести независимый анализ, выявить проблемы, придумать и осуществить план их решения.
👉Участник. Если принципал не занимает одну из перечисленных выше ролей, он работает как обычный член одной или нескольких команд.

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

А вы что думаете?

Сокращения неэффективны

Both within-firm market and accounting performance suffer in the period immediately surrounding the downsizing event, while post-downsizing financial outcomes are generally negative and, at best, highly heterogenous and centered around zero.

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

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

Как прокачаться в менеджменте за год

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

Месяц 1 – Учимся учиться и управлять своим временем
- Путь джедая
- The 7 Habits of Highly Effective People
- A Mind for Numbers

Месяц 2 – Разбираемся, как внедрять изменения
- The Goal
- Influencer
- Bulletproof Problem Solving

Месяц 3 – Строим систему управления
- Team Topologies
- An Elegant Puzzle
- Thinking in Systems

Месяц 4 – Создаем сильную команду
- Radical Candor
- The Five Dysfunctions of a Team

Месяц 5 – Прокачиваем коммуникации
- Джедайские техники конструктивного общения
- Facilitator's Guide
- The Culture Map

Месяц 6 – Разбираемся, как устроен бизнес
- The Personal MBA
- The Hard Thing About Hard Things
- High Output Management

Месяц 7 – Прокачиваем мышление
- Thinking, Fast and Slow
- The Great Mental Models

Месяц 8 – Погружаемся в стратегию
- Understanding Michael Porter
- Good Strategy Bad Strategy
- The Innovator's Dilemma

Месяц 9 – Ставим сильные цели
- Radical Focus
- How to Measure Anything

Месяц 10 – Управляем сложными проектами
- Critical Chain
- The Deadline
- How Big Things Get Done

Месяц 11 – Погружаемся в продуктовый менеджмент
- Intercom on Product Management
- When Coffee & Kale Compete
- Mom's Test

Месяц 12 – Покоряем корпоративную политику
- Политика у шимпанзе
- The 48 Laws of Power
- The 33 Strategies of War

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

Как давать фидбэк

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

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

Главные фейлы за 2024

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

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

Как помочь плохо перформящей команде

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

👉Узнайте всех членов команды.
👉Разберитесь с тем, зачем команда существует: как она влияет на бизнес, на конечный продукт, как выровнена с продуктовой стратегией, какой ее роль видят стейкхолдеры.
👉Разберитесь с тем, что нужно пользователям.
👉Погрузитесь в кодовую базу, особенно в ее эволюцию за последний год.
👉Явно проговорите команде, что сейчас вам нужно стабилизировать работу, после чего вы вместе сможете поэкспериментировать с изменениями.
👉Затормозите поток новых входящих запросов в команду. Тут вы можете выступить в роли основного фильтра, через который должны проходить все новые требования и хотелки.
👉Проведите ревью последних месяцев работы команды: как выставлялись приоритеты, как команда влияла на свои ключевые метрики.
👉Вместе с продакт-менеджером опишите внятную стратегию команды на ближайшее время.
👉Постепенно берите в работу новые задачи, сразу встраивая их в понятный цикл разработки, и приоритизируя поддержку здорового поедсказуемого темпа работы тому, чтобы все постоянно были заняты.
👉Постепенно переходите к тому, чтобы отпускать директивное управление, и давать команде вводить изменения.

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

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

Что важно понимать – если обстановка внутри компании не дает возможности использовать такие основанные на здравом смысле подходы, то каких бы опытных менеджеров вы ни нанимали, ситуации они не изменят.

Когнитивная нагрузка

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

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

👉Intrinsic – нагрузка, неотделимая от самой задачи, вызванная ее реальной сложностью. Ее уменьшить практически никогда нельзя.
👉Extraneous – нагрузка, вызванная способом представления информации. Как раз ее можно и нужно уменьшать.

Примеры того, что вызывает extraneous cognitive load:

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

Ретроспектива произошедшего с LLM в 2024

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

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

👉Инференс стал дешевле на порядок, вызов младших моделей теперь стоит совсем копейки
👉Размер контекста существенно вырос
👉Локально можно запускать довольно мощные модели, сравнимые с GPT-4
👉Тренировка на синтетических данных работает, причем иногда лучше, чем на органических
👉В целом плато способностей LLM, которым периодически любят пугать, пока не видно
👉Генерация простых веб-приложений из промптов стала сравнительно неплохо работать
👉Использовать LLM обычному пользователю все труднее, нужно больше знаний об их устройстве, ограничениях и доступной инфре, чтобы добиваться нормальных результатов

3X Framework – Explore/Expand/Extract

Все вы знаете Кента Бека как автора XP, одного из подписавших Agile манифест и громкого сторонника TDD. Но помимо всего этого, у него много других классных статей и мыслей.

Одна из моих любимых – про фреймворк 3Х, который очень простым способом объясняет основные стадии жизни продукта и то, как они влияют на подходы к разработке:

1️⃣Explore. Этап прототипирования, когда вы только пытаетесь нащупать рабочую идею, которая получит отклик у пользователей. Правильная стратегия разработки на этом этапе – максимально снижать стоимость экспериментов, и запускать их как можно больше.
2️⃣Expand. Product/market fit нашелся, пошла фаза быстрого роста. В этот момент основной фокус разработки должен быть на поиске бутылочных горлышек в технологиях, процессах и команде, потому что именно они могут остановить рост.
3️⃣Extract. Проблемы роста решены, формула продукта в целом понятна. Теперь вы превращаете создаваемую им ценность в деньги. И тут фокус смещается на устойчивость, снижение костов разработки и поддержки, и вот все то, чем мы любим заниматься в бигтехе.

Какие ключевые мысли дает эта модель:

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

PR/FAQ про AWS Lambda

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

Отличный пример такого PR/FAQ – по ссылке в заголовке. К десятилетию запуска AWS Lambda ребята из команды решили выложить свой документ с дополнительными комментариями. Очень рекомендую почитать, можно забрать хорошие идеи, если вы тоже придерживаетесь культуры письменных коммуникаций.