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

А кроме практики, она предлагает неплохой шаблон по донесению новостей до команды:
1️⃣Официальная позиция компании
2️⃣Конкретные факты, которые раскрывают эту позицию
3️⃣Ваша личная позиция и мнение
4️⃣Ваши следующие шаги в коммуникации

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

В сегодняшней статье роль тимлида рассматривается через призму двух таких моделей:
- Стадии развития команды (те самые storming-norming-performing)
- Шесть доменов лидерства

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

Недавно я выкладывал большой пост про платформенные команды. Судя по реакциям и обсуждениям в чате, тема вам зашла. Вот еще одна статья на тему, на этот раз из блога Мартина Фаулера. В ней дается несколько советов тем, кто строит у себя такую команду:
🧮Иметь стратегию с измеряемыми целями
💬Выяснять, что нужно вашим пользователям
🏁Онбордить пользователей максимально рано
🎤Ясно доносить техническое видение
💻Догфудить

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

Около 20% подписчиков канала еще не стали тимлидами, а только постепенно присматриваются к этой роли. Если вы еще не поняли, то к работе тимлида прилагабтся не только плюсы вроде чуть большей зарплаты, но и куча минусов. Статья неплохо проходится по части из них. Переходя из инженерной позиции в менеджерскую вы теряете:
⏱Большое количество времени на сфокусированную работу
💬Короткий цикл фидбэка о том, молодец ты или нет
⚡️Возможность уклоняться от конфликтов
💻Принятие технических решений
📚Развитие новых технических скиллов

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

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

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

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

Компания Documentat занимается именно этим: заказной разработкой документации и консалтингом в области документационных процессов.

Вот чем они могут вам помочь:

🔷 Возьмут написание документации на аутсорс (пользовательская документация, документация API/SDK, ГОСТ...) или дадут вам технического писателя в аутстаффинг.

🔷 Наведут порядок во внутренних и внешних базах знаний.

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

🔷 Обучат ваших разработчиков писать и поддерживать документацию, а менеджеров — управлять процессами вокруг нее.

Услугами Documentat пользуются Сбер, 2ГИС, Miro, JetBrains, Yandex.Cloud, Avito, Timepad, Росплатформа и еще десятки российских IT-компаний.

Приходите за документацией!

documentat.io

[email protected]

Держите полезный алгоритм работы с командой в кризисные периоды, такие, как сейчас:
1️⃣Оцените и разберитесь с собственным состоянием до того, как идти говорить с командой (от себя добавлю, что это гипер-важно – унылый тимлид на панике поддержать команду не сможет)
2️⃣Примите, что опыт и чувства каждого человека в команде будут очень разными, не ожидайте одной реакции.
3️⃣Люди чувствуют беспомощность и потерю контроля, учитывайте это и попробуйте помочь им увидеть смысл в своей работе.
4️⃣Открыто обсудить текущие события и их влияние на будущую жизнь полезно для команды, а правильный формат этого зависит от культуры в компании.
5️⃣Найдите возможность дать команде немного расслабиться и восстановиться, избавьте их от давления.
6️⃣Подключите команду к обсуждению возможных последствий кризиса для компании и пользователей.

Серия статей про то, как различные виды организационных зависимостей могут тормозить команды. Мне особенно понравилась последняя, про роль главного архитектора, где на понятном кейсе объясняется, почему такая роль – это зло.
1️⃣Зависимости внутри команды
2️⃣Зависимости вне команды
3️⃣Часть команд разбиты по фичам, часть по компонентам
4️⃣В сложном продукте все команды разбиты по компонентам
5️⃣Зависимость от одного человека снаружи команды

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

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

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

Я нашел хороший твиттер-тред с несколькими ментальными моделями, которые помогают в принятии тяжелых решений. Если вы умеете использовать хотя бы часть из них, то это может защитить от того, чтобы автоматически выбирать путь наименьшего сопротивления.
Версия для тех, у кого нет 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️⃣Бизнес хорошо информирован об этом долге?

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

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