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

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

Держите гайд по тому, как стать техническим инфлюенсером. Несколько запомнившихся мыслей:
📌Большинство профессионально успешных людей не заметны в онлайне, не стоит верить своему пузырю.
📌Самая полезная метрика – количество людей, которые обращаются к тебе за советом.
📌Выбирайте самые топовые свои материалы и прорабатывайте для них сертезный план дистрибуции. Каналов получения новых читателей очень много.
📌Вы всегда можете присосаться к чужому каналу дистрибуции – например, написав гостевой блогпост (я тоже, если что, с радостью выложу ваши статьи)

Три частых трудности начинающих тимлидов:
1️⃣Подозреваю, что есть инструменты, чтобы делать мою работу лучше, но я о них не знаю и не очень понимаю, где их достать;
2️⃣ Нелегко применять софты: быть открытым, уверенным, проявлять эмпатию.
3️⃣Тяжело даются one-on-one, фидбек и общение, особенно когда надо поговорить не про работу, а про что-то еще.

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

А вот еще один классный материал про найм. Лайвкодинг бесит. Алгоритмические задачи по большей части проверяют не скиллы человека, а то, насколько упорно он готовился к этому интервью. Что, если вместо написания кода, просить его читать?
📌Читать код – базовая задача, занимающая 95% времени программиста.
📌Читать гораздо быстрее чем писать, время проверки сокращается.
📌Кандидаты меньше стрессуют на таком задании, интервью менее искажается.

Вот какой процесс предлагает автор:
1️⃣Подготовить несколько задач вида «что выдаст этот код», от простого уровня к сложному.
2️⃣Опробовать эти сниппеты на тех, с кем вы уже работаете.
3️⃣Объяснить кандидату, что вы не проверяете его знания синтаксиса, не ставите дедлайнов, не ожидаете правильных результатов. Попросите его рассуждать так, будто он дебажит незнакомый код.
4️⃣Когда кандидат дает свой ответ, запустите этот код, и если результат отличается, попросите прокомментировать.

Недавно я выкладывал статью про найм, автор которой предлагал упростить весь процесс оценки кандидата до оценки четырех простых показателей. Для баланса держите интервью с бывшим VP из Амазона, который топит за гораздо более подготовленный и выверенный процесс найма. Вот несколько интересных мыслей:
📌 Не тестируйте на кандидатах только что придуманные вопросы. И всегда знайте, как звучит хороший ответ.
📌Все достижения из резюме, кажущиеся интересными, надо проверять. Например, узнавать, а что конкретно инженер сделал, чтобы «повысить доступность системы на 50%».
📌Качественное интервью — это работа. Требуется время, чтобы подготовиться, затем провести собеседование и подвести его итоги. Если вам лень, не проводите собеседований.

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

Рассказ про то, как в Netflix организован инцидент-иенеджмент и взаимодействие разработки и операций. Ключевые моменты:
📌Netflix работает по принципу «you build it, you run it». Кто написал сервис, тот и отвечает за его деплой и успешное функционирование в проде.
📌Есть команды разработки внутренних инструментов, помогающих с обеспечением надежности. Например, Chaos team, которые и пишут инструменты для chaos engineering, и запускают их сами.
📌Есть команда CORE, задача которых – находить и расследовать самые запутанные инциденты.

Хороший разбор нескольких стандартных поведений начинающих тимлидов.
1️⃣Видеть свою роль в том, чтобы решать задачи своими руками
2️⃣Предполагать, что все знают, чем ты занимаешься
3️⃣Придерживаться полярных точек зрения
4️⃣Выступать «щитом» своей команды
5️⃣Заниматься оптимизацией отдельных частей, а не всей системы

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

Крутая подборка лучших практик того, как сделать принятие решений в команде распределенным:
📌Описать текущую систему принятия решений и то, кто отвечает за их принятие.
📌Вся команда выписывает решения, которые надо принять, на одной доске. Тимлид помечает те из них, которые ему сложно делегировать, и сразу поясняет, почему. Затем члены команды из списка помеченных выбирают те решения, которые они хотели бы принять сами, и придумывают, как снять тревожность тимлида.
📌Замена post-approval на pre-approval. Вместо того, чтобы аппрувить конкретное решение, лучше аппрувить условия его принятия. Например, бюджет, в рамках которого команда может работать сама. Декларативный стиль вместо императивного.
📌Если кто-то отвечает за принятие решений, то ему никто не может указывать, как правильно поступить. Все могут только давать советы, которым можно как следовать, так и нет.

Какие-то компании очень внимательно подходят к вопросу инфраструктурных костов, а какие-то вообще не следят за затрачиваемыми деньгами. В статье разбирается, как к инфраструктурным расходам стоит относиться на разных стадиях развития компании:
🥚На ранней – можно вообще не заморачиваться. Ваша задача – придумать продукт, нужный пользователям, и экономия на костах сильно картину не поменяет.
🐣Период роста. Здесь важно смотреть на то, какой процент от переменных расходов занимает инфра. Если отношение затрат на инфру к доходам не растет со временем, то все нормально.
🐥Когда рост прекратился. Вот тут уже пора резать косты, смотря на два показателя: расходы на каждого инженера, расходы на количество продуктовых операций (поиски, покупки).

Помимо этой классификации, в статье приводятся полезные инструменты по оценке расходов и советы, как их сократить.

У команды inDriver была проблема – кода много, проверок качества много, а автотестов и тех, кто их умеет писать – мало. Чтобы решить проблему, они начали обучать автоматизации ручных тестировщиков. За несколько этапов реализации этой идеи они собрали кучу очень интересных граблей. Если вас посещают идеи сделать свой внутренний курс по чему угодно, обязательно почитайте – вы точно натолкнетесь на что-то подобное!

Вот те, что мне понравились:
📌Разный уровень первоначальных знаний мешал группе учиться синхронно
📌Вроде все хотели, чтобы обучение шло в рабочее время, но по факту учились в выходные
📌Готовить хорошую инфру и задачи для отработки навыков – долго и дорого

One-on-one встречи – не панацея. Хороший менеджер должен работать не только над выстраиванием связей между собой и каждым отдельным сотрудником, но и между всеми членами команды. Кто-то может лучше вас обучать техническим деталям, кто-то – поддерживать в сложных ситуациях. Держите небольшую заметку про то, как достичь таких отношений в команде.

Приоритизация – это не просто аналитический процесс. Очень часто к любым попыткам разложить задачи по RICE, Kano или другим фреймворкам, начинает примешиваться политика. В статье собрали подходы, которые помогают и не работают в таких случаях:
❌Просить стейкхолдеров коллективно приоритизировать длинный список задач
❌Обучать всех алгоритмам приоритизации и процессам разработки
❌Настраивать модельку в спредшите и ожидать, что она все объяснит
✅В явном виде распределить ресурсы по нескольким верхнеуровневым категориям
✅Собирать у каждого стейкхолдера короткий список их ключевых потребностей
✅Использовать разбитие задач по категориям «сейчас»/«следующая»/«никогда»
✅Заранее продумывать возможности аутсорса части работы

Пять лет назад мы с Виталиком Леоновым работали вместе в Авито. Я руководил мобильной разработкой, а он – бэкендом. Виталик – крутой инженер и технический руководитель, у которого очень многому можно научиться. Сейчас он – СТО в Skyеng, а параллельно ведет Telegram-канал "Тимлид Леонид", в котором делится разными тимлидовыми практиками и результатами их внедрения. Вот мои любимые посты:
Time to productivity новичков: замеряем по десятому пулл реквесту
Затраты на инфраструктуру в разных типах российских компаний
Как СТО вкатиться в новую компанию
Эволюция тимлида

Подписывайтесь, Виталик фигни не посоветует!

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

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

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

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

🐣Развитие тимлида
Как развивать свое продуктовое чутье
Как принципы помогают тимлиду отстраивать процессы в команде
Антипаттерны поведения тимлида

🐞Работа над качеством
12 принципов обеспечения качества в GitLab
Чем технический долг отличается от технического хлама

🛠Инструменты, гайды, чек-листы
Ментальные модели, помогающие принимать тяжелые решения
Таблица с карьерной лестницей для инженерной ветки развития
Что делать, когда заказчик не понимает, какую проблему он хочет решить

👨‍👨‍👦‍👦Работа с людьми
Как оптимизировать время, которое нужно новичку в команде, чтобы вкатиться
Лоу-перформеры не всегда мало работают, а иногда просто делают не то
Что такое микроконтекст, и как его избежать, чтобы команда была продуктивной
Причины, по которым сеньоры не могут раскрыться в вашей команде

📚Рекомендации по книгам
Цель, Элияху Голдратт
Цель 2, Элияху Голдратт
Теория ограничений Голдратта, Уильям Детмер
Принципы, Рэй Далио

Если дайджест вам понравился – ставьте ❤️, 👍 и 🔥. Благодаря этому я пойму, что собирал его не зря!

#digest

Все знания, которые нужно получить новичку во время онбординга, можно разделить на две категории:
1️⃣Known unknowns
2️⃣Unknown unknows

Первая категория – это вещи, о которых вам известно, что вы их не знаете. Например, новая команда использует Vue.js, а вы до этого работали только с React. Вам понятно, что надо изучить.

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

Задача хорошего процесса онбординга – выводить вещи из второй категории в первую, а оттуда – в разряд known knowns. В статье предлагается неплохой подход к его организации, разделяющий все погружение на 4 стадии: первые 30, 60, 90 и 150 дней, и дающий критерии оценки успуха каждой.

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

Команда безопасников обычно отвечает за три вещи:
📌Защита от утечек данных
📌Продуктовая безопасность
📌Поддержка пользователей по практикам безопасного использования продукта

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

Автор статьи предлагает кардинально упростить систему найма. Вместо того, чтобы оценивать кандидата по десяткам параметров, он сводит все к четырем базовым:
1️⃣Талант: способность создавать что-то новое, ум, креативность
2️⃣Выдержка: способность завершать то, что начал
3️⃣Эстетика: качество результата работы
4️⃣Репутация: наличие рекомендаций от бывших коллег

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

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