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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Девять причин, по которым ежегодные performance review – зло:
1️⃣Они усиливают существующее несправедливое отношение к людям
2️⃣Они поощряют оставаться в общепринятых рамках ожиданий и не проявлять нестандартной инициативы
3️⃣Они подталкивают к тому, чтобы давать фидбэк только раз в год вместо того, чтобы делать это постоянно
4️⃣Они мешают росту сотрудников, особенно долгосрочному
5️⃣Они уменьшают чувство безопасности и провоцируют тревожность
6️⃣Они являются напоминанием, что менеджер контролирует все самое важное в жизни сотрудника
7️⃣Они очень сильно вырывают из работы
8️⃣Они не придают ценности командной работе, оценивая результаты человека в отрыве от нее
9️⃣Они не учитывают существование системных проблем в компаниях, и приравнивают следствия их существования к личным результатам людей

Если вы вынуждены применять performance review, то вот, что можно делать:
📌В явном виде отделяйте его от постоянного фидбэка
📌Уменьшайте влияние его результатов на штрафы или награды
📌Постоянно помните, что процесс поломанный
📌Старайтесь сделать их менее токсичными и не давайте себе и остальным сильно вовлекаться в процесс
📌При любой удобной ситуации убеждайте отказаться от них

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

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

Для тех, кто подумывает о том, чтобы искать работу Engineering Manager’ом где-то за рубежом, я собрал небольшую подборку ссылок. Пользуйтесь!
📰Серия статей “Cracking the Engineering Manager Interview”: часть 1, часть 2, часть 3, часть 4, часть 5
📰Статья от Calm про устройство их процесса найма
🎥Рассказ бывшего Engineering Director из Google про найм инжиниринг менеджеров
🎥Mock-интервью про то, как ставить цели инженерным командам
🎥Mock-интервью про то, как отвечать на вопрос “What’s your leadership philosophy”
🎥Mock-интервью про приоритизацию в команде

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

Часто бывает так, что в компании нанимают нового человека, но не могут нормально сформулировать ожидания от него. В статье предлагается интересный способ по их систематизации. Он основывается на разделении всех проблем, которые должен решать человек, на четыре кучки:
1️⃣ Использование известных проверенных решений (copy and paste)
2️⃣ Комбинация нескольких известных решений (mix and match)
3️⃣ Адаптация и кастомизация решений под контекст (adapt and customize)
4️⃣ Создание новых решений (invent)

Эти требования различаются для типов задач и контекстов их возникновения. Например, завести процесс онбординга новых разработчиков – довольно тривиальная задача в большинстве компаний, и попадает в область 1️⃣ или 2️⃣. Но вот в моем случае, о котором я раньше кратко рассказывал, она попала в область 4️⃣, и потребовала от меня совсем других компетенций и времени на реализацию.

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

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

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

Пока все со страхом смотрят на проведение disaster recovery учений с отключением отдельных сервисов, Dropbox играет по-крупному, и отрубает целый дата-центр! В лонгриде ребята рассказывают про свою команду Disaster Recovery и ее путь от первых робких экспериментов с управляемыми падениями через 50-минутный downtime к выключению дата-центра без хоть сколько-то заметного влияния на доступность.

Кстати, если вам хочется больше технических материалов, подписывайтесь на рассылку Architecture Weekly Владимира Иванова, он делает отличную подборку статей!

Один из важных, но недооцененных навыков тимлида – умение управлять ожиданиями стейкхолдеров. От того, насколько хорошо вы умеете их вовлекать в проект, зависят и его шансы на успешное окончание, и ваши собственные перспективы роста в компании. Держите статью с несколькими техниками того, как работать со стейкхолдерами:
🤝Сделайте их своими партнерами – поймите, в чем конкретно интерес каждого стейкхолдера, и учтите его в своем плане.
🎯В явном виде обозначайте свои цели в виде outcomes, и придерживайтесь объективного подхода при приоритизации чьих-то хотелок.
📚Оперируйте фактами, а не саоим мнением – иначе любой более сеньорный стейкхолдер вас легко переспорит.

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

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

Одна из практик, которые помогают уменьшить нагрузку от встреч – no meetings days. Это специальные дни, в которые вся компания договаривается не назначать никаких встреч. Держите статью с результатами исследования того, как дни без встреч влияют на продуктивность команд. Сможете использовать его, когда будете убеждать коллег и топов внедрить такую практику и в вашей компании.