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

Гайд по работе с RFC

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

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

Несколько шаблонов таких RFC:
- Google Docs
- Notion

Интенсив по отстаиванию своей позиции за 15 минут

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

А помимо бота, в интенсив входит подробный видео-разбор темы и методичка с теорией и всеми приемами.

👉Симулятор в боте тут

Пример системы грейдов и инструкция по ее раскатке

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

В этот раз посмотрим на систему, выросшую из принятой внутри New Relic. Несколько интересных особенностей:

🤔Внутри каждого грейда есть три категории, которые отличаются фиксированным скачком в зарплате. Такое дробление ведет к тому, что повышения можно делать чаще.
💪Основной критерий различия между грейдами – импакт инженера на компанию. Он растет с уровня задач и фичей до уровня успеха всей компании.
🤝Менеджеры – отдельная ветка. При переходе в менеджеры зарплата не меняется, но тайтл может быть «меньше» текущего инженерного. Если зарплата находится за рамками нового менеджерского грейда, ее не понизят, но и повышать какое-то время не будут.

Давайте вместе разберем интересный кейс!

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

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

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

Кстати, если хотите разобрать ваш кейс, пишите мне в личку – какие-то разберу сам, а какие-то в похожем режиме вброшу в канал!

Ситуационное лидерство

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

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

Как написать стратегию инженерной команды

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

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

Пост по ссылке – золото. Автор кратко рассказывает о принципах из книги «Хорошая стратегия, плохая стратегия», прикладывает их к разработке стратегии инженерной команды и, самое главное, дает подробный пример такой стратегии. Сама книга, кстати, топовая, тоже рекомендую прочитать. Идеи оттуда я использовал и при написании инженерных, и продуктовых стратегий.

Внедрение и жизнь с Zero Bug Policy

Пару недель назад я выкладывал пост ребят из SkyEng про то, как они боролись с накопившимся бэклогом багов на специальном мероприятии – багатоне. Они сразу предупреждали, что проблему растущего бэклога они таким образом не решили, и следующим шагом стали внедрять Zero Bug Policy.

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

Конечно, в реальной жизни не в каждой команде получается внедрить практику в ее каноничном виде. В том же SkyEng в итоге пришли к трем ее подвидам:

1️⃣Классическая строгая, как описано выше
2️⃣Спринты любви, когда часть багов все-таки откладывается, но обязательно фиксится отдельным усилием команды раз в несколько итераций
3️⃣Сравнение багов по стоимости с фичами и принятие решения, что именно делать

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

Big Data – во многих случаях карго-культ

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

Бывший продакт-менеджер Google BigQuery поделился историями о том, насколько много данных действительно скапливается у компаний, и как они в итоге их используют.

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

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

💸Требования к хранимым данным ужесточаются. Политики вроде GDPR требуют реализации нетривиальной логики по тому, какие данные, когда и как надо удалять. Все это требует усложнения инфры, дополнительного времени разработки, и увеличивает риск нарваться на штрафы.
💸Данные могут играть против вас, если их затребуют при каком-нибудь расследовании.
💸Схема данных со временем эволюционирует, в результате чего запросы становятся все сложнее и сложнее, и в них проще допустить ошибки.

Мораль статьи – не нужно гнаться за построением огромных хранилищ данных, если вы не можете сформулировать, для чего вам нужны будут эти данные в сыром виде в будущем.

Трек Яндекса на TeamLeadConf про R&D и культуру компании

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

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

👀Алексей Гусаков из Яндекса расскажет о технологиях машинного обучения. А точнее как управлять самым инновационным отделом компании и сохранять баланс между бизнесом и наукой — и что хороший управленец может дать команде инженеров.
👀Александр Ложечкин из Райффайзен Банка, прошедший Microsoft и Amazon, точно повидал вообще всякого. В докладе он расскажет про то, можно ли менять корпоративную культуру и как она влияет на инновации.
👀Сергей Мельник, занимающийся Яндекс Станцией, расскажет про боли в создании хардварных стартапов, в которых на проверку гипотезы может требоваться несколько лет.
👀Максим Лапшин из Эрливидео расскажет о том, как инженерная культура помогает в прогнозировании сроков при разработке инноваций.

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

Обучение и шаринг знаний через группы поддержки

Обучение через опыт своих коллег часто становится самым эффективным. Ты не просто перенимаешь у них знания, а сразу же смотришь, как они применяются в контексте вашей компании и процессов. В статье рассказывается про практику Mini-M – регулярные «группы поддержки» менеджеров с постоянным составом. Идея такая:

1️⃣Собираете всех руководителей, которые хотят развиваться и обсуждать свои кейсы
2️⃣Делите их на небольшие группы по 5-8 человек, за каждой группой назначаете ответственного
3️⃣Группы собираются раз в пару недель. На встрече каждый участник рассказывает свой кейс, который он хотел бы разобрать, затем группа выбирает несколько самых интересных, и разбирает их с автором, помогая найти ему решение проблемы.

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

Если стало интересно, не пропустите продолжение поста с очень детальной инструкцией по проведению такой встречи.

Гайд по ненасильственному общению

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

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

Курс про работу с командой

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

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

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

Курс стартует 13 февраля — присоединяйтесь!

Как тимлиду рассказывать о результатах своей работы

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

🎯Поставьте цель, для достижения которой вы делитесь результатами
🤔Определите пользу для компании в своих результатах
👀Проанализируйте аудиторию – что им важно знать из вашего рассказа
✍️Выберите подходящую форму рассказа
🤷‍♂️Протестируйте на понятность, показав свой рассказ заранее нескольким людям

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

Сервис поиска менторов

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

Звучит красиво, а что делать, не очень понятно, особенно когда старичков нет, или они не горят желанием кого-то обучать. Рабочий вариант – поискать наставника на стороне. И тут я хочу очень сильно порекомендовать сервис поиска наставников GetMentor.dev, который делает Георгий Могелашвили. Первое, про что важно знать – сервис не коммерческий, нет никаких комиссий, и делается им просто ради фана и желания помочь решить частую проблему. Второе – за несколько лет его работы там собралось больше тысячи наставников по разным областям, у половины из которых опыт больше 10 лет. В третьих – многие из наставников, как и сам сервис, ничего не берут за свою помощь.

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

Про shit tolerance

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

Teamlead Good Reads – ежедневные советы про менеджмент людей и команд pinned «Большое исследование тимлидов и руководителей разработки Как давние подписчики канала могли заметить, я очень люблю проводить всякие опросы. Помните недавнее исследование продактов? Так вот, пришла очередь узнать, что происходит с тимлидами! 🤔Какие навыки…»

Советы по улучшению внутренних коммуникаций

Советы в основном относятся к топ-менеджерам, но в целом применими к другим уровням управления командой.

🕥Сообщайте новости на регулярной основе, даже тогда, когда значимых обновлений нет.
💬Всегда тестируйте свои сообщения на нескольких людях до того, как отправлять всем.
📦Структурируйте сообщения, чтобы их было проще воспринимать, давая ссылки на контекст и понятный summary.
📣Распространяйте сообщение по всем возможным каналам: и почта, и чат, и внутренние порталы.

Разгребание огромного бэклога багов на багатоне

Команда устала от постоянно растущего бэклога багов, и решила поменять процессы, внедрив Zero Bug Policy. Но перед этим они решили разобрать огромный бэклог багов, скопившийся годами.

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

Формат классный, мы организовывали очень похожую историю в Авито. Про нее важно понимать несколько вещей:

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