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

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

Пирамида ценностей большинства компаний выглядит так: Деньги -> Бизнес -> Люди. Компании создаются ради того, чтобы приносить их владельцам прибыль. Для этого ищутся способы создавать ценность для пользователей, превращающиеся в бизнес. Этим занимаются нанятые для этой цели люди.

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

В статье рассказывается про альтернативную систему ценностей: Люди->Бизнес->Деньги, в которой главной целью компании становится реализация и развитие ее сотрудников, а все остальное – просто производные от успеха людей.

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

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

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

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