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

Смерть от тысячи микросервисов В подавляющем большинстве случаев микросервисы принесут вам намного больше проблем в долгосроке, чем пользы в краткосроке. Думаю, вы уже и сами видите, что хайп на микросервисы довольно сильно упал, и некоторые компании, которые смогли его пережить и не загнуться от счетов от 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. При таком подходе легко нанять человека из третьей категории, который большую часть времени будет тянуть команду вниз.