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

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

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

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

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

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

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

В ней разбираются следующие практики:
📝Decision Records для хранения контекста принятых ранее решений
📆Architecture Advisory Forum для того, чтобы обмениваться архитектурным опытом между командами и валидировать решения друг друга
📚Architectural Principles, которые задают общее направление для принимаемых решений
🎯Tech Radar для фиксации и соблюдения договоренностей по используемым технологиям

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

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

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

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

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

Приход в команду нового человека – это классная возможность для того, чтобы увидеть неочевидные проблемы, которые у вас есть. Он еще не привык говорить «так историяески сложилось» и стоически переносить все запахи ваших процессов.

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

Серия небольших интервью с инженерными руководителями распределенных команд про то, как выглядит их оргструктура, как устроен их рабочий день, и какими практиками они пользуются, чтобы сделать удаленную работу лучше.
DuckDuckGo
The Beyond HQ
JobGet

Вспомните какой-то компонент своей системы, к которому вы обычно относитесь как к техническому долгу. А теперь ответьте на несколько вопросов про него:
1️⃣Этот код чистый?
2️⃣Этот код протестирован?
3️⃣Вы чему-то научились, взяв этот технический долг?
4️⃣Есть план, как отдавать долг?
5️⃣Бизнес хорошо информирован об этом долге?

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

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

Модель BICEPS – еще один подход к систематизации мотивационных факторов, подкрепленный различными исследованиями. Она состоит из шести факторов:
📌Belonging
📌Improvement/Progress
📌Choice
📌Equality/Fairness
📌Predictability
📌Significance

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

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

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

Кстати, если вам интересны продуктовые темы, рекомендую в целом подписаться на рассылку от Lenny – там много золотых материалов появляется.

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

А если у вас есть опыт управления командами дизайна – расскажите интересных историй в комментариях!

Туту подробно рассказали про то, чем занимался их СТО за 13 лет работы в компании. Помимо того, что в рассказе просто много интересных баек, это еще и очень крутой заход на найм нового СТО. Ребята детально рассказали про область ответственности, привели примеры старых челленджей, показали культуру компании, и все это завернули в отличную историю. Берите инструмент повышения интереса к вакансии себе на заметку!

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

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

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

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

Я когда-то уже писал пост про то, что система собственных принципов, описанных в явном виде, это прекрасный инструмент для того, чтобы принимать последовательные решения. Лучше всего про это рассказывается в книге Рэя Далио «Принципы». Если вы еще не читали ее, то добавляйте в вишлист.

Ваши принципы могут быть не только высокоуровневыми, описывающими принятие жизненных решений, но и частными. Например, принципы, которыми вы пользуетесь при написании кода или при работе с командой. Автор сегодняшней статьи использует четыре собственных принципа для того, чтобы отстраивать конкретные процессы в команде. Например, принцип «Humans behind lines of code» приводит его к тому, чтобы заниматься распределением знаний между членами команды с помощью дизайн сессий и парного программирования.

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

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

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

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

Чтобы увольнение человека из команды не стало для вас сюрпризом, задайте ему на следующем one-on-one такие вопросы:
1️⃣Что в твоей работе за последний год было самым интересным?
2️⃣Какие возможности для роста у нас совпадают с твоими собственными целями?
3️⃣Какая поддержка от меня могла бы тебе помочь?
4️⃣Если бы у тебя была волшебная палочка, и ты мог бы изменить только один аспект своей работы, что бы это было?