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

Прямо сейчас три команды Авито находятся в поиске опытных тимлидов разработки:

➡️ Тимлид разработки в команду инфраструктуры поиска
➡️ Тимлид разработки в команду внутренних проектов (Legal Tech)
➡️ Тимлид разработки в команду Support Systems

Здесь вы сможете реализовать свои идеи в проекте с многомиллионной аудиторией и талантливой командой.

Зарплата достойная (обсуждается на собеседовании), а ещё:

– мощное железо, дополнительные мониторы и всё, что нужно для продуктивной работы;
– личный бюджет на обучение, который можно тратить на книги, курсы и конференции;
– ДМС со стоматологией с первого дня;
– прозрачная система премий;
– удалёнка и крутой офис в 2-х минутах от метро «Белорусская»;
– терапевт и массажист, которые принимают в офисе.

Откликайтесь на вакансии и присоединяйтесь к одной из команд!

State of Developer Ecosystem

Подъехали результаты большого ежегодного исследования разработчиков от JetBrains.

👉77% разработчиков используют ChatGPT, а 46% – CoPilot. Самый частый сценарий – задавать вопросы общего характера про программирование.
👉Выгорание за свою карьеру переживали 73% разработчиков.
👉Для 58% первым шагом к обучению программированию было формальное образование. На втором месте – книги, но уже только 10%.
👉Только у 63% разработчиков в проекте есть юнит тесты.
👉Среди языков программирования единственным растущим остался Rust.
👉Три самых высокооплачиваемых языка: Scala, Go, Kotlin.
👉Новые языки чаще всего учат просто ради интереса, для работы над личными проектами и чтобы следить за трендами.

Инструкция по быстрому бенчмаркингу зарплат в команде

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

Когнитивные искажения в программировании

Серия из трех постов про частые когнитивные искажения, которые особенно заметны в работе программистов. Вот несколько примеров:

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

Оптимальное количество людей у менеджера

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

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

Приемы по внедрению изменений в процессы

👉Если все в команде понимают решаемую проблему, и нужно выровняться по конкретным улучшениям, подойдет Improvement Kata. Это простой подход к проведению процессных экспериментов и оценке их влияния на результат. Основной плюс – удобная визуализация происходящего.
👉Если общего понимания проблемы нет, и ее сначала нужно продать, лучше всего начать с разговоров с отдельными людьми, и, только получив согласие от всех вовлеченных, делать презентацию на группу. Такой подход называется японским термином Nemawashi.
👉Если количество людей, которых надо убедить в изменении, слишком большое – лучше всего описывать его в виде документа. Как варианты: A3 problem solving или RFC.

Уточняйте свои просьбы

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

Поэтому, если вы просите кого-то о помощи, будьте конкретными:

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

Outcome roadmap

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

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

Посмотрите схемы, возможно, такой роадмап подойдет именно в вашей ситуации!

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

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

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

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

Шесть концепций системного мышления

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

Три менеджерских подхода

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

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

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

Кент Бек про вред оценок и дедлайнов

Хороший пост от Кента Бека, одного из отцов XP. Он напоминает про то, почему оценки и дедлайны не просто бесполезны, а еще и вредны для успеха продукта, и предлагает простой agile процесс, направленный на принесение клиентам максимальной пользы:

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

NDA не работают

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

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

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

42 урока, вынесенных из опыта создания новой базы данных

Техлид Delos, базы данных, активно использующейся во внутренней инфре Meta, делится наблюдениями, которые будут рклевантны всем, кто руководит платформенными командами или делает какие-то инфраструктурные продукты. Несколько любимых советоа:

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

Не копируйте оргструктуру Spotify

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

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

Как научить людей принимать решения

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

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

1️⃣Человек не распознает проблему и не знает, как ее решать
2️⃣Человек видит проблему, но не может найти решение
3️⃣Человек видит проблему и несколько способов решения, но не знает, как выбрать один из них
4️⃣Человек видит проблему, несколько способов решения и предлагает один из них
5️⃣Человек распознал проблему, выбрал один вариант решения из нескольких, исполнил его, и теперь просто делится с вами статусом

Как запускать кросскомандные проекты

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

1️⃣Выровнять всех относительно общей цели

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

- Обсудите проблему в вашей собственной команде, в том числе с менеджером. Соберите фидбэк.
- Напишите или расскажите о проблеме публично, чтобы получить видимость внутри компании. Это поможет получить поддержку других менеджеров.

2️⃣Составить роадмап

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

3️⃣Быть прозрачным

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

Сэм Олтмен про продуктивность

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

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