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

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

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

Книга "Understanding Michael Porter" Я уже упоминал эту книгу в своей подборке книг для менеджеров в модуле про стратегию. Так получилось, что именно ее в последнее время я стал советовать многим людям, поэтому решил и вам принести более подробную рецензию. Вся книга – это краткое и емкое изложение ключевых идей Портера: суть конкуренции, что такое конкурентное преимущество (и что им не является), и как на основе этого строить стратегию. При этом автор не добавляет своей собственной интерпретации, а максимально придерживается идей оригинала. Что важно – взгляды Портера со временем эволюционировали и уточнялись в отдельных научных работах и статьях, и книга как раз подбивает их самое актуальное состояние. Мои основные инсайты: 👉В конкуренции нужно стремиться быть не лучшим, а уникальным. 👉Стратегия и конкурентные преимущества имеют смысл только тогда, когда растут из каких-то уникальных активностей, которые другая компания не сможет скопировать. Другими словами – стратегия должна содержать набор трейд-оффов, уникальных именно для вас. 👉Делать продукт хорошим для всех – вредно. Наоборот, нужно осознанно пытаться оставить некоторых возможных клиентов недовольными. 👉Настоящее конкурентное преимущество это не то, в чем вы хороши, а то, что заметно влияет на P&L: либо ведет к меньшим затратам, либо дает ставить большие цены. 👉Стратегия не требует точных предсказаний будущего. Достаточно общей уверенности в том, что решаемая продуктом потребность будет существовать и через пять лет, и делать ставку на это. Короче, книга кайф – минимум воды, и больше сотни заметок на полях!

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

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

Почему бигтех такой медленный Мы часто смеемся над тем, как долго крупные компании могут реализовывать очень простые фичи. Добавить новую формочку на главной странице сайта у какого-нибудь стартапа займет считанные часы от идеи до релиза, а в каком-нибудь Amazon это станет проектом на два года для команды принципал-инженеров. У этого явления есть несколько наивных объяснений: 👉В бигтехе много некомпетентных слабых разработчиков, которые работают пару часов в день, причем одновременно на трех работах. 👉Тяжеловесные процессы вынуждают всех работать медленнее. 👉Координация между вовлеченными командами съедает большую часть времени. 👉Из-за того, что проектами бигтеха пользуются миллионы людей, приходится слишком много времени уделять решению проблем масштабирования решений. Какая-то доля правды есть во всех этих теориях, но гораздо больший вес вносит другая проблема – в продуктах бигтеха уже есть огромное количество фичей, каждая новая повышает сложность системы еще сильнее, и на проработку баланса и тестирование уходит бесконечность времени. Иногда фичи могут конфликтовать на уровне дизайна, соревнуясь за место на экране, иногда – на уровне технических требований, требуя существенно большего уровня надежности, иногда – на уровне юридических требований, усложняя работу с персональными данными. Кропотливое встраивание новых фичей и обработка всех граничных случаев ведет к сильному усложнению кодовой базы для внешне очень тривиальных сценариев. А сложная кодовая база повышает стоимость внесения новых изменений еще сильнее. Очевидный вопрос – а зачем вообще добавлять новые фичи, если продукты уже работают. Как всегда, ответ – деньги. На масштабе бигтеха повышения конверсий даже на доли процента могут приносить миллионы и кратно окупать стоимость всех этих принципал инженеров, перекрашивающих кнопки.

Как 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. Это подготовленные кем-то заранее универсальные спецификации, которые вы можете немного докрутить своими собственными бизнесовыми требованиями, и получить на выходе качественный модуль авторизации, личного профиля, кэширования или чего-то еще.

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

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

Что ведет к размыванию ответственности Уровень ответственности во многом индивидуальная штука. Есть люди, которые остро чувствуют дискомфорт от того, что с проектом, за который они отвечают, что-то идет не так, и этт подталкивает их к активным действиям. А есть люди, которые чаще ставят себя в роль исполнителей, и не ощущают вот этой самой ответственности, если не подкрепить это какими-то дополнительными механизмами. Вторых людей больше, чем первых, поэтому по умолчанию в больших компаниях, которые не уделяют внимания вопросу ответственности, происходит какое-то болото – все знают про горящие проблемы, постоянно их обсуждают, но все разговоры не выливаются вообще ни во что. Соответственно, сама компания тоже движется отвратительно медленно. Вот список поведений, которые ведут к тому, что ответственность размывается: 👉Менеджеры делегируют задачи без нормального контроля, и либо вообще не знают приоритетов своих сотрудников, либо закрывают глаза на то, что по ним нет результатов. 👉Фокус компании постоянно меняется – каждый месяц СЕО приносит новый самый важный проект, который автоматически вытесняет все предыдущие. Когда нет доверия к тому, что ваша работа продолжит оставаться важной нет никакой мотивации инвестировать в нее свои силы и внимание. 👉Несбалансированные цели и система поощрений. Сюда можно отнести любые проблемы как с целеполаганием, когда цели сформулированы либо слишком узко, либо слишком широко, так и какие-нибудь системы премий, которые поощряют деструктивные поведения. 👉Роли в организации пересекаются таким образом, что нельзя точно определить, а кто отвечает за проект. Эффект свидетеля в миниатюре. 👉Слишком глубокие организационные чарты, которые ведут к тому, что ответственность размывается между пятью уровнями иерархии.

Практикуем second-order thinking Одна из ключевых вещей, за которые нам платят деньги – изменения. А изменения в командах – штука очень сложная из-за различных системных эффектов. Подкрутили процессы в одном месте, эффективность разломалась где-то в другом. Наняли крутого сильного программиста, но пропускная способность команды в результате упала. Second-order thinking – ментальная модель, побуждающая нас думать на несколько шагов вперед. Никакой серебрянной пули, которая поможет гарантированно качественно анализировать последствия своих решений и эффекты второго порядка, конечно же, нет. Все, что вы можете делать – осознанно уделять время тому, чтобы подумать о них, и со временем ваша внутренняя нейронка будет выдавать все более и более качественный результат. В статье рекомендуют несколько конкретных практик, которые немного структурируют мышление: 👉"А что потом?". Думая о каком-то действии, задавайте себе этот вопрос несколько раз, пока не построите дерево возможных последствий ваших решений. 👉"10-10-10". Думайте о последствиях своих решений в трех временных горизонтах – 10 минут, 10 месяцев, 10 лет. Это поможет не фокусироваться на самых очевидных краткосрочных вещах.

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