Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Как и зачем менеджеру строить команду из своих пиров

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

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

👉Не нужно ожидать вмешательства или воли СТО для того, чтобы в компании происходили полезные изменения.
👉Улучшается обмен знаниями о лучших практиках, меньше делается велосипедов.
👉Менеджерам проще учиться друг у друга.

Обновление роадмапа для продактов

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

Как руководителю не растерять технические навыки

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

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

Техническая стратегия

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

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

🕵️‍♀️Диагноз – теория, объясняющая проблему, которую стратегия хочет решить.
👉Направляющая политика – набор принципов и трейдоффов, которые помогают двигаться к решению проблемы.
🗺️Согласованный план – конкретные шаги по решению проблемы, соответствующие направляющей политике.

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

Вакансия Team lead на Go от Ozon Tech

Команда rFBS Ozon Tech развивает формат взаимодействия Ozon с продавцами, при котором они сами хранят, формируют и доставляют заказы. А Ozon работает как витрина с десятками миллионов лояльных клиентов. Компания хочет порадовать пользователей новыми фичами уже в этом сезоне распродаж.

Чтобы достичь амбициозных целей, Ozon формирует новые команды. Сейчас они в поисках тимлида с опытом разработки на Go.

Их проект — это:
— Работа в одной из самых быстрорастущих вертикалей Ozon,
— Высокие нагрузки до 300k rps,
— Архитектурные вызовы в контексте масштабируемости сервисов,
— Быстрый time-to-market,
— Возможность работать из офисов России и Казахстана / удалённо / гибридно.

Стек: Golang, PostgreSQL, Kafka, gRPC.

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

Авито ищет сразу трёх тимлидов в разные команды. Ныряйте вниз за подробностями.

➡️ Тимлид разработки в команду маркетплейса
➡️ Тимлид разработки в команду «Запчасти и аксессуары»
➡️ Тимлид разработки в команду Data Quality

ЗП обсуждается с кандидатами лично, но вот что предлагают прямо сейчас:
• Талантливая команда и возможность реализовать свои идеи в проекте с многомиллионной аудиторией;
• Мощное железо, дополнительные мониторы и всё, что нужно для комфортной работы;
• Прозрачная система премий;
• Личный бюджет на обучение, который можно тратить на книги, курсы и конференции;
• ДМС со стоматологией с первого дня;
• Замечательный офис в двух минутах от «Белорусской»: панорамный вид на центр города, места для уединённой работы и зоны отдыха.

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

На глазок как методика оценки сроков

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

Чтобы такой подход сработал, важно соблюдать несколько правил:

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

Смерть от тысячи микросервисов

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

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

Пипл-менеджмент сложных инженеров

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

Do your one job first

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

Как вести смоллтолки

Если вас, как и меня, ставит в тупик вопрос "How are you?", заданный в начале созвона, или, еще хуже, вы не понимаете, насколько детально нужно описывать погоду за окном, чтобы сойти за своего, это идеальный пост для обучения культуре смоллтолков.

Ключевые идеи:

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

Фидбэком не решить проблему недостатка скиллов

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

Проблемы, попадающие в первую категорию, часто можно исправить быстрым фидбэком и синхронизацией ожиданий. А вот со второй категорией все сложно. Если сотруднику не хватает каких-то корных навыков для того, чтобы хорошо выполнять свою работу, бессмысленно думать, что после получения фидбэка или какого-нибудь performance improvement plan, он за месяц получит скиллы, которые не смог получить за последние годы своего опыта.

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

Фишинговые письма для проверки поведения людей

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

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

Подход к онбордингу джунов

Когда New Relic выросли до 60 команд, они решили активнее нанимать джунов. Вот как у них выглядел онбординг:

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

Холивары о собеседованиях

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

Так вот, расскажите в комментариях, а как все-таки правильно нанимать людей!

Как менеджеры могут влиять на мотивацию

Никак. Мотивация – это внутренняя сила человека, которая формируется в течение всей его жизни. Поменять то, что драйвит человека, практически невозможная задача. "Замотивировать" его – тоже. Вместо этого менеджер может:

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

Бреслав и Ложечкин про делегирование

Новый выпуск моего любимого (хоть я и немного аффилированное лицо) подкаста про тимлидство! Андрей Бреслав, Александр Ложечкин и приглашенный гость Мария Аникина обсуждают все про делегирование: зачем оно нужно, кому и что можно делегировать, и что делать, если делегировать не получается.

Кстати, вышла уже половина первого сезона. Если вам нравится подкаст, будет очень круто, если вы расскажете о нем у себя в рабочем чате или посоветуете друзьям! Ну и, конечно, подписывайтесь на ребят в телеге: @breslavandlozhechkin.

Что уменьшает продуктивность разработчиков

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

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

Пол и потолок в перфомансе

У баскетбольных аналитиков есть модель описания перфоманса игроков, основанная на их граничных показателях:

👉High floor, high ceiling: Самые лучшие игроки, которые показывают отличный результат и в хорошие дни, и в плохие.
👉High floor, low ceiling: надежные игроки с предсказуемо средним перфомансом.
👉Low floor, high ceiling: ненадежные игроки с проблесками гениальности. Могут сыграть как отвратительно плохо, так и слишком хорошо.

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

SRE принципы для CI/CD пайплайна

Хороший подход к определению ожиданий к стабильности CI/CD пайплайна с использованием хорошо известных SRE практик:

⭐️Service Level Objectives (SLOs): какой уровень стабильности гарантирован.
📊Service Level Indicators (SLIs): как именно трекается уровень стабильности.
🧳Error Budgets: как долго пайплайн может не отвечать требованиям SLO.

Пример:

⭐️SLO: Каждый коммит должен быть протестирован в течение 5 минут после пуша.
📊SLI: Общее время прогона билда.
🧳Error budget: 40 билдов, время прогона которых заняло больше 5 минут, на протяжении 4 недель.

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