Девять причин, по которым ежегодные performance review – зло:
1️⃣Они усиливают существующее несправедливое отношение к людям
2️⃣Они поощряют оставаться в общепринятых рамках ожиданий и не проявлять нестандартной инициативы
3️⃣Они подталкивают к тому, чтобы давать фидбэк только раз в год вместо того, чтобы делать это постоянно
4️⃣Они мешают росту сотрудников, особенно долгосрочному
5️⃣Они уменьшают чувство безопасности и провоцируют тревожность
6️⃣Они являются напоминанием, что менеджер контролирует все самое важное в жизни сотрудника
7️⃣Они очень сильно вырывают из работы
8️⃣Они не придают ценности командной работе, оценивая результаты человека в отрыве от нее
9️⃣Они не учитывают существование системных проблем в компаниях, и приравнивают следствия их существования к личным результатам людей

Если вы вынуждены применять performance review, то вот, что можно делать:
📌В явном виде отделяйте его от постоянного фидбэка
📌Уменьшайте влияние его результатов на штрафы или награды
📌Постоянно помните, что процесс поломанный
📌Старайтесь сделать их менее токсичными и не давайте себе и остальным сильно вовлекаться в процесс
📌При любой удобной ситуации убеждайте отказаться от них

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

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

Для тех, кто подумывает о том, чтобы искать работу Engineering Manager’ом где-то за рубежом, я собрал небольшую подборку ссылок. Пользуйтесь!
📰Серия статей “Cracking the Engineering Manager Interview”: часть 1, часть 2, часть 3, часть 4, часть 5
📰Статья от Calm про устройство их процесса найма
🎥Рассказ бывшего Engineering Director из Google про найм инжиниринг менеджеров
🎥Mock-интервью про то, как ставить цели инженерным командам
🎥Mock-интервью про то, как отвечать на вопрос “What’s your leadership philosophy”
🎥Mock-интервью про приоритизацию в команде

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

Часто бывает так, что в компании нанимают нового человека, но не могут нормально сформулировать ожидания от него. В статье предлагается интересный способ по их систематизации. Он основывается на разделении всех проблем, которые должен решать человек, на четыре кучки:
1️⃣ Использование известных проверенных решений (copy and paste)
2️⃣ Комбинация нескольких известных решений (mix and match)
3️⃣ Адаптация и кастомизация решений под контекст (adapt and customize)
4️⃣ Создание новых решений (invent)

Эти требования различаются для типов задач и контекстов их возникновения. Например, завести процесс онбординга новых разработчиков – довольно тривиальная задача в большинстве компаний, и попадает в область 1️⃣ или 2️⃣. Но вот в моем случае, о котором я раньше кратко рассказывал, она попала в область 4️⃣, и потребовала от меня совсем других компетенций и времени на реализацию.

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

Как бонус – автор для иллюстрации своих идей использует технику Wardley Mapping. Выглядит очень классно, я хочу попробовать вкатиться!

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

Пока все со страхом смотрят на проведение disaster recovery учений с отключением отдельных сервисов, Dropbox играет по-крупному, и отрубает целый дата-центр! В лонгриде ребята рассказывают про свою команду Disaster Recovery и ее путь от первых робких экспериментов с управляемыми падениями через 50-минутный downtime к выключению дата-центра без хоть сколько-то заметного влияния на доступность.

Кстати, если вам хочется больше технических материалов, подписывайтесь на рассылку Architecture Weekly Владимира Иванова, он делает отличную подборку статей!

Один из важных, но недооцененных навыков тимлида – умение управлять ожиданиями стейкхолдеров. От того, насколько хорошо вы умеете их вовлекать в проект, зависят и его шансы на успешное окончание, и ваши собственные перспективы роста в компании. Держите статью с несколькими техниками того, как работать со стейкхолдерами:
🤝Сделайте их своими партнерами – поймите, в чем конкретно интерес каждого стейкхолдера, и учтите его в своем плане.
🎯В явном виде обозначайте свои цели в виде outcomes, и придерживайтесь объективного подхода при приоритизации чьих-то хотелок.
📚Оперируйте фактами, а не саоим мнением – иначе любой более сеньорный стейкхолдер вас легко переспорит.

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

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

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

Что делать менеджеру менеджеров, которого волнует, чтобы проекты на уровне конкретных команд делались в срок, но который не хочет скатываться в микроменеджмент? В этой заметке предлагаются наборы инструментов для того, чтобы разобраться в ситуации, добавить в систему недостающие элементы и устранить возможные препятствия. Для привлечения внимания несколько конкретных техник:
📌Установить систему кроссфункциональных приоритетов, чтобы проект одной команды не останавливался из-за собственных планов другой
📌Провести Skip levels встречи с членами команд, чтобы понять их картину мира
📌Проверить наличие у команд сразу нескольких стейкхолдеров с разными запросами или других источников приоритетов, которые могут отвлекать их от основной задачи

#инструменты #люди

Требуется разработка, нанимать специалистов долго и дорого, а дедлайны горят?
Сервис brainskills.tech помогает разрабатывать IT-продукты без сдвига сроков и без сбоев в работе🔥

Brainskills.tech — аутстаффинг и аутсорсинг специалистов в области Data Science, AI и разработки:
🔺Разработка продуктов на базе open source стека
🔺Решение бизнес-задач с помощью искусственного интеллекта
🔺Решение задач автоматизированного сбора, хранения и анализа данных
🔺Разработка CV/NLP/RecSys инструментов с использованием глубоких нейронных сетей
🔺Поддержка, эксплуатация и мониторинг

✔️40 опытных разработчиков и дата саентистов
✔️Безрисковые 2 недели — вернем деньги на старте, если не устроил результат
✔️0 рублей — стоимость плана MVP по вашему проекту

Чтобы получить бесплатную консультацию, оставьте заявку на нашем сайте или напишите в telegram. Обсудим задачу и поможем сформулировать требования к проекту!

https://brainskills.tech/

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

#управление_компанией

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

Но если вы не Meta, и верите в то, что внутреннюю документацию в вашей компании надо улучшать, в статье рассказывается, как к этому подойти, определить цели, продать бизнесу, выбрать инструменты и внедрить в рабочие процессы. Все это – с фокусом на улучшение developer experience.

#техлидство

Разбор трех принципов работы с людьми из хорошей книги «The One Minute Manager»:
🎯Ставьте короткие и понятные цели
🙏Хвалите за хороший перфоманс
💬В случае плохого перфоманса давайте незамедлительный точный фидбэк

Каждый из принципов раскладывается на простые алгоритмы и разбирается на примерах. Если понравится – добавляйте и саму книгу в избранное, она стоит того!

#люди

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

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

В итоге команда выработала свой подход с двумя типами итераций: build iteration со скользящей продолжительностью для работы над конкретной пользовательской проблемой и refine iteration фиксированной продолжительности для багфиксов и закрытия техдолга.

#процессы

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

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

В Яндекс Практикуме есть курс “Управление командой для начинающих руководителей”. Это базовый набор инструментов, который позволит лучше разобраться в новой роли, увидеть свои недостатки как руководителя и выстроить работу команды.

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

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

Старт потока 19 мая

Зарегистрироваться на бесплатную вводную часть

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

Прокачаться в вопросах Continuous Delivery можно на новом сезоне конференции Podlodka Techlead Crew. За неделю сессий вы:
👉 Разберетесь в CI\CD\QA\QC.
👉 Узнаете все про разные стратегии деплоймента.
👉 Научитесь собирать и тестировать нефункциональные требования на поставку вместе с экспертами из Bolt, AWS и Scentbird.
👉 Узнаете, как выстроены CD процессы, выкатка новых фич, A\B тестирование и проверка качества в компаниях мирового уровня.

Подробное расписание и билеты с хорошей скидкой уже на сайте!

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

#техлидство

Системный разбор всех возможных подходов к системе финансовой компенсации

🗺Влияние локации сотрудника на зарплату
🪙Почему важно разбираться с локальными налоговыми системами
💰Как работают бюджеты на зарплаты
🧐Грейды и зарплатные перцентили
✨Опционы
📚Как, когда и зачем проводить compensation review

#найм #управление_компанией