Teamlead Good Reads – тимлиды, архитектура, менеджмент людей и разработки

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

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

2022-05-02 09:50:12 Девять причин, по которым ежегодные performance review – зло:
Они усиливают существующее несправедливое отношение к людям
Они поощряют оставаться в общепринятых рамках ожиданий и не проявлять нестандартной инициативы
Они подталкивают к тому, чтобы давать фидбэк только раз в год вместо того, чтобы делать это постоянно
Они мешают росту сотрудников, особенно долгосрочному
Они уменьшают чувство безопасности и провоцируют тревожность
Они являются напоминанием, что менеджер контролирует все самое важное в жизни сотрудника
Они очень сильно вырывают из работы
Они не придают ценности командной работе, оценивая результаты человека в отрыве от нее
Они не учитывают существование системных проблем в компаниях, и приравнивают следствия их существования к личным результатам людей

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

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

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

2022-04-30 10:25:14 Три частых трудности начинающих тимлидов:
Подозреваю, что есть инструменты, чтобы делать мою работу лучше, но я о них не знаю и не очень понимаю, где их достать;
Нелегко применять софты: быть открытым, уверенным, проявлять эмпатию.
Тяжело даются one-on-one, фидбек и общение, особенно когда надо поговорить не про работу, а про что-то еще.

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

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

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

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

2022-04-27 09:41:06 Гайд по тому, как завести в своей команде системный процесс карьерного роста с матрицами компетенций, планами персонального развития и регулярными ревью. Помимо общего описания, там много ссылок на готовые шаблоны и примеры. А если вам интересно разобраться, чем вообще наличие такого процесса может помочь – читайте первую часть цикла. Открыть/Комментировать

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

2022-04-25 09:50:09 Хороший разбор нескольких стандартных поведений начинающих тимлидов.
Видеть свою роль в том, чтобы решать задачи своими руками
Предполагать, что все знают, чем ты занимаешься
Придерживаться полярных точек зрения
Выступать «щитом» своей команды
Заниматься оптимизацией отдельных частей, а не всей системы

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

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